B4J Question Firebase notofication stops to work (2)

marcick

Well-Known Member
Licensed User
Again I have problems with Firebase notifications.
I have a JRDC server application on three identical server and the problem appears only on one of them.
The JRDC contains code for managing websockets and also the code for sending notification (copied from the Erel SendTool).
After some times (actually happens every couple of days) the JRDC server seems to works (websocket side) but stop to send notification.
This is the error I grabbed when sending notification:

B4X:
java.net.SocketException: No buffer space available (maximum connections reached?): connect
    at java.net.DualStackPlainSocketImpl.connect0(Native Method)
    at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:83)
    at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
    at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
    at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
    at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172)
    at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
    at java.net.Socket.connect(Socket.java:589)
    at okhttp3.internal.platform.Platform.connectSocket(Platform.java:124)
    at okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.java:187)
    at okhttp3.internal.connection.RealConnection.buildConnection(RealConnection.java:173)
    at okhttp3.internal.connection.RealConnection.connect(RealConnection.java:114)
    at okhttp3.internal.connection.StreamAllocation.findConnection(StreamAllocation.java:196)
    at okhttp3.internal.connection.StreamAllocation.findHealthyConnection(StreamAllocation.java:132)
    at okhttp3.internal.connection.StreamAllocation.newStream(StreamAllocation.java:101)
    at okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.java:42)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.java:93)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.java:93)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.java:120)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:92)
    at okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.java:67)
    at okhttp3.RealCall.getResponseWithInterceptorChain(RealCall.java:179)
    at okhttp3.RealCall.execute(RealCall.java:63)
    at anywheresoftware.b4h.okhttp.OkHttpClientWrapper.executeWithTimeout(OkHttpClientWrapper.java:156)
    at anywheresoftware.b4h.okhttp.OkHttpClientWrapper.access$0(OkHttpClientWrapper.java:153)
    at anywheresoftware.b4h.okhttp.OkHttpClientWrapper$ExecuteHelper.run(OkHttpClientWrapper.java:201)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

When I'm in this situation, if I open Google Chrome it says there is no connection (but it's not true because I'm connected to the server with remote desktop).

If I close the JRDC application and launch it again, it doesn't work correctly, it stops after the first debug lines and hangs. I must restart the computer to solve.
Any idea ?

Nuova immagine bitmap.jpg
 

OliverA

Expert
Licensed User
I do not see any traffic going to 13000. Are you receiving traffic on port 13000? Do your devices connect to your server at 13000 or are you connecting to your devices from the server?
 
Upvote 0

OliverA

Expert
Licensed User
The only port that outside sources seem to try to exploit is 3389, your RDP (remote desktop) port. 41 different IP addresses scanned/attempt to connect to that port.
 
Upvote 0

marcick

Well-Known Member
Licensed User
I’ll check tomorrow and tell you. The log was captured during the night and it is possibile that no devices were operating, this would explain why you don’t see connections on port 13000.
About Remote Desktop, me and a colleague often connect with smartphones and the ip changes every time I think. But I will investigate, thanks.
 
Upvote 0

marcick

Well-Known Member
Licensed User
Hi, it's not possible that during those times we were connecting with rmote desktop, but I see another rule in the firewall that allow incoming connection on port 3389, I don't know what it is

upload_2019-2-18_8-31-25.png
 
Upvote 0

OliverA

Expert
Licensed User
That's the port for RDP. If you want to RDP into the server, you'll have to leave that open. Just make sure you have a good password policy on the accounts that are allowed to RDP into the server.
 
Upvote 0

marcick

Well-Known Member
Licensed User
@OliverA: but how explain those connections to that port from those 41 different IP during the night when we were sleeping ?
@antsnel: Thanks, I'll have a look.

Anyway, after reinstalling Windows 2019 and all my apps, now everything works fine again without trouble
 
Upvote 0

OliverA

Expert
Licensed User
but how explain those connections to that port from those 41 different IP during the night when we were sleeping ?
People are trying to get in via RDP, be it via RDP security holes or via weak passwords. One way you could stop/diminish others from attempting to RDP in is to only allow a fixed number of IP addresses from which on can initiate a remote desktop connection.
 
Upvote 0

marcick

Well-Known Member
Licensed User
There are two rules in the firewall about port 3389. One is related to RDP, the other to svchost.exe (termservice).
Both are RDP ?
Also we recently changed the password to be sure, sound strange people is already able to connect
 
Upvote 0
Top