Develop Reference

Why am I sending an RST if my socket is connected and not closed?

I have an Android device that communicates wirelessly with a PC, using a java.net.Socket. Everything hums along fine, but if I do nothing (i.e., no network use) for exactly 1 minute then when the Android sends a packet of data to the PC the PC receives it and sends an ACK, but the Android responds with an RST.
From Wireshark ( 10.1.2.1 is the Android, 10.1.2.11 is the PC)...
356 0.112470 10.1.2.1 10.1.2.11 TCP 97 34360→181 [PSH, ACK] Seq=1
Ack=1 Win=4935 Len=31 TSval=156103571 TSecr=320673352
359 0.000011 10.1.2.11 10.1.2.1 TCP 66 181→34360 [ACK] Seq=1 Ack=32
Win=260 Len=0 TSval=320738236 TSecr=156103571
360 0.000304 10.1.2.1 10.1.2.11 TCP 60 34360→181 [RST] Seq=32 Win=0
Len=0
At this point if I interrogate the socket's member variables it says . . .
isConnected = true
isCreated = true
isInputShutdown = false
isOutputShutdown = false
isClosed = false
isBound = true
... which looks like I should still be receiving packets just fine. So how do I figure out why I'm sending RST?
N.B. - there are no settings to "sleep" or turn off the wifi or display or any other battery-saving features set enabled on this device.

The 1 minute delay looks like a timeout. It may be the SO_TIMEOUT but this does not generate network activity on itself. Also the fact that the last packet sent contains 31 bytes of data seems to indicate that the application is involved. A possible scenario would be :
The android application times out (on its own or triggered by a socket's SO_TIMEOUT)
It sends a last chunk of data, e.g. by flushing an output stream.
It closes abruptly the socket, for example by using the setSoLinger(true, 0) socket option.

None of those Socket methods returns the state of the connection. They are all about the internal state of the java.net.Socket object, as determined by which constructors and methods you have called on it. They don't magically start returning false if the peer drops the connection.
You will find when you go to use the socket for I/O that you will get an IOException: 'connection reset'.
Why the connection has been reset is another matter. The usual reason is that you had sent to a connection that had already been closed by the peer, or that the peer closed the connection without reading all the data that had already arrived. In other words, an application protocol error. There are other reasons, but these are the most common.

This could be caused by your NAT router that tries to close sockets after a timeout to free up resources. Turning on keep_alive may help. You can also try to create your own network with static IP addresses bypassing the router to rule out this hypothesis.

When the connection is closed the isClosed() method should return TRUE.
It's OK for the isConnected() method to return TRUE even if the connection has been closed because what that method tells you is "if ever you managed to get connected", the variable state is not changed/refreshed when you get disconnected.
However in your case the connection has definitely not been closed as per documentation.
For more info see:
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#isConnected--
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#isClosed--
Note: It might help you to set to TRUE setKeepAlive(boolean)
See also:
https://docs.oracle.com/javase/8/docs/api/java/net/SocketOptions.html#SO_KEEPALIVE
https://docs.oracle.com/javase/8/docs/api/java/net/Socket.html#setKeepAlive-boolean-
Back to the problem, check for one of the following:
Can you make sure for some reason there isn't another device with
the same IP as the Android? Also turn off you 3G/4G and stay
connected only in the wireless network.
Is there a router doing NAT ? In this case the router can send the
RESET flag.
If everything seems fine (it's your Android phone replying with RST) and the SO_KEEPALIVE does not work then it might be some application level error that is killing the connection.

smack / ejabberd Connection Timeout

We are using the Pub/Sub mechanism of ejabberd to send messages between multiple clients. The ejabberd version running on the server is 16.04 and the smack library version is 4.1.1.
The publishing and subscribing of messages work fine for a period of time, after some time we get the following exception on the client side :
org.jivesoftware.smack.SmackException$NoResponseException: No response received within reply timeout. Timeout was 15000ms (~15s). Used filter: IQReplyFilter: iqAndIdFilter (AndFilter: (OrFilter: (IQTypeFilter: type=error, IQTypeFilter: type=result), StanzaIdFilter: id=T89NL-174)), : fromFilter (OrFilter: (FromMatchesFilter (full): pubsub.unio.com))
Tried googling the cause but was unable to find out a resolution. Any help is appreciated.
Thanks in advance.

I had the same issue. I changed the packet reply timeout for the connection to some suitable value (like 10 seconds) after login. In smack, after connection.login()
you can set
connection.login();
connection.setPacketReplyTimeout(10000); // 10 sec
UPDATE I tried for smack library version 4.3.2 (and newer), method connection.setPacketReplyTimeout is removed, so use this instead:
connection.login();
connection.setReplyTimeout(10000); // 10 sec

Android Baidu push doesn't work with WiFi but works with cellular data

I have an Android app implemented which uses the Baidu push service. Baidu SDK version is 50 (jar lib is pushservice-5.0.0.66.jar).
Currently I see strange behavior: I get successful response in onBind (so I receive Baidu token). But if I use Wifi data, the app won't create a socket for Baidu.
With Baidu's debug mode enabled, I see this error:
com....:bdservice_v1 E/BDPushSDK-PushConnection: Create socket err, errno: 2socketfd: -1
com....:bdservice_v1 I/BDPushSDK-PushConnection: disconnectedByPeer, mStoped == false
com....:bdservice_v1 I/BDPushSDK-PushConnection: destroy
com....:bdservice_v1 I/BDPushSDK-PushConnection: Schedule retry-- retry times: 2 time delay: 30000*
It is hard to find any info about all these errors (this is all seems to be in Chinese). But seems that the Error 2 says smth like: "No such file or directory". Also I was getting before: Error 110 "Connection timed out". So this is not really helpful.
But the thing is that everything works when using cellular data.
It doesn't look like any local settings for my network, as many users report the same issue for WiFi.
com....:bdservice_v1 D/BDPushSDK-PushConnection: create Socket ok
com....:bdservice_v1 D/BDPushSDK-PushSDK: heartbeat set : 180 secs

UDP source port number is missing in the SETUP response message

I am working on a Wifi Display Sink application in android and am facing an issue where the source is not sending the UDP server-port number in the RTSP SETUP message.
The SETUP RESPONSE is as below
'RTSP/1.0 200 OK
cseq: 2
date: Tue, 11 Aug 2015 15:12:38 +0000
server: Mine/1.0
session: 1719935144;timeout=60
transport: RTP/AVP/UDP;unicast;client_port=15550-15551;
'
NOTE:
I have figured out the server-port number using tcpdump in the source device. It is 16660. It doesnot look like any specifically assigned port number as well.Seems like a random port number hardcoded into the source device for Wifi Display Application.
Is there any other way to know the server-port number to which I should listen to for incoming UDP packets?

You should be listening on port 15550 and 15551 and the incoming UDP packets will contain their source port.

Android sipdemo timeout when making calls

Having a problem with the android sipdemo timing out when making calls. The native sip client on the phone has no issues calling, works perfect. Its When i initiate the call within the sipdemo i get a timeout in the logcat. timeout is set to standard of 30 seconds.. a local asterisk box is what its connecting to. Registers fine.

I'm having the same problem.
I traced packages in wireshark and here's what I found:
I register to SIP server in SipDemo
I register to SIP server on Desktop (using Ekiga)
I place a call in SipDemo to Ekiga.
INVITE message gets sent to Ekiga
Trying is sent from Ekiga to the server
Ringing is sent from Ekiga to SipDemo
I answer the call on Ekiga client
OK (with session description) is sent from Ekiga to SipDemo. This happens 11 times before Ekiga just gives up
BYE is sent from Ekiga client to SipDemo
Please note that OK is being sent 11 times before Ekiga just gives up and ends the call. This is why the call lasts just 30 seconds.
If you take a look at the RFC here:
http://www.ietf.org/rfc/rfc3261.txt section 13.3.1.4
you can see that the reason Ekiga is giving up on SipDemo client is because it never gets ACK back from SipDemo.
I believe this is android bug, but I can't imagine they could have missed something this basic in their SIP implementation.
In the next few days, I'll try to dig up some answers in android source code...
I'll try see what happens when establishing calls between 2 SipDemo applications. If it works, that means android just ignores ACK all together.
EDIT:
I just tried a call between 2 SipDemo clients. It sends OK 5 times and gives up on the OK, but does not end the call. Interesting behavior :)
EDIT2:
I dug up androids SIP implementation, and I found that ACK should get sent... Even logcat logs this, but I still see nothing in Wireshark. I thought maybe it gets blocked or something, so I ran Shark (like Wireshark for android) on the device, pulled the dump to my laptop, opened it up in Wireshark, and I don't see ACK anywhere. I even looked trough all packets... No filters, just in case I might be filtering it out. Anyways... Here's what I found in android code:
http://hi-android.info/src/com/android/server/sip/SipSessionGroup.java.html
class: SipSessionImpl
method: private boolean outgoingCall(EventObject evt)
in case Response.OK:
you can see this call:
mSipHelper.sendInviteAck(event, mDialog);
In SipHelper, method sendInviteAck, you can see:
if (DEBUG) Log.d(TAG, "send ACK: " + ack);
dialog.sendAck(ack);
Dialog is nist javax.sip, so I don't think there's a need to go further...
I see this message "send ACK" in my logcat when running the application
EDIT3:
I noticed that this issue occurs only with some SIP servers. I now tried opensips, and it works fine. I guess the problem I was having had to do with the server responding to androids keep-alive OPTIONS messages with 404 Not Found. Then, android tried to not use the server as soon as possible. Because of that, as soon as android got the address of its peer client, it tried to send a direct message, and failed

Hard to tell just like that. Try capturing the packages with wireshark, filter for the SIP protocol and have a look at what is sent over the network. Also try it with the native client and compare it to the sipdemo.
Another starting point is the log of your asterisk instance (systemlog)
If you can't figure it out yourself, post the results here.