Hopefully someone in this forum can help me understand what I am doing wrong or help me find a solution to a problem I am having. I am writing an embedded application that communicates to a linux tcp/ip server. Ocassionally the embedded controller either looses its tcp connection or get rebooted and tries to reestablish a connection. Being an embedded application to boot time is minimal (5 second or so). The problem I am having is reestablishing a tcp connection quickly. For some reason the server (RedHat 9.0) thinks I am still connected even after issuing a tcp RST. After issuing a RST waiting for 30 seconds or so then issuing a SYN yields a "tcp retransmission" from a previous session. I would have expected a SYN+ACK response. I've recompiled my kernel with minimal time-outs for all connection tracking perameters (nothing except ESTABLISHED is larger than 10 sec). I have also monitored /proc/net/ip_contrack after issuing a RST it goes to a CLOSED_WAIT state for the proper amount of time (2 sec) then nothing shows up in the /proc/net/ip_contrack for the connection that was established. I have to wait sometime (maybe 2 minutes(don't quote me on this)) after the CLOSED_WAIT state has disappeared before I can issue a SYN that gets the proper response SYN+ACK from the server. If someone has a suggestion of what my be going on or what I am doing wrong I'd love to hear about it.

Do the client has to use the same source port? You should use an ephemeral source port on the client, that's more standard. Currently if you run two client applications from the same box, it won't work.

Try to see with setsockopt.

Not sure there is a solution to your problem if you use fixed ports... (I guess for security reasons with firewalls?)

Thanks for the reply nx500.

The client currently uses the same port since there is really no way of know what the last port it used was. I could potentially store the last port used in eeprom and make sure it is different on the next connection, but eeprom has so many writes before it eventually fails. Yeah, it is about 100,000 times, but it eventually will fail. I guess I am looking more for a way to disable/minimize the time after I close a socket before it can be reopened with the same IP address and port. Maybe I'm there. I thought this had to do with connection tracking (which I modified), but it seems like there is something else lingering somewhere. I'm just not sure where to look.

Actually in general, you let linux choose the source port for you (probably what you do unless you really set it manually). Source port 0 means that the system has to choose one by itself.
I forgot that probably your system when it boots is predictable, which means that your application will always get the same source port IF linux takes 1024 then 1025.
In the last kernels, the source port is choosen randomly for security reasons.
See https://www.linuxquestions.org/quest...25#post2360825
This would solve your problem. Maybe?
You could modify very carefully the kernel code to apply the same patch.
Depends on which kernel you're running..
No no no much too complicated and as you said not good for hardware.
If this timeout is there, it's because there is a reason:
IP packets can get re-ordered. You rst might "overtake" a real data. If the connection is closed, this real data will not be accepted while it should.

I think there is a way to stop quickly (setsockopt) a connection but in the case of a clean close. For a dirty close, the remote system thinks you're still alive.


Btw, how do you manage to send an rst when your board resets?


edit:
or in your application, if you can get a semi-random source, modify it and fix manually the source port.
s.addr=random(65535) <-- its for fixing idea, its not the real code

Unfortunatly, the embedded system is not running linux. It is more a dedicated system (no OS) I had to build the entire stack from scratch, pick my source port etc... So this approach is not an option for me. I wish I had a random number generator this might make things a little easier.

I am constantly sending data back and forth between the embedded controller and the linux server every 4 seconds. If the server doesn't see any response to it's "keep-alive" signal it gracefully closes the socket after 13 seconds with a close. Therefore, I think the setsockopt will work for me. I looked through the options available and it looks like the SO_LINGER option will do exactly what I need it to do. I can adjust the values keep-alive, sending a SYN and SO_LINGER values to suite my needs. I'll try this later tonight (I'm at work :-( ).

I first try to send a SYN if I get a response other than SYN+ACK or a timeout occurs I then send a RST. Which I was hoping put me back to a known state (at least from the embedded controller point of view).


Thanks for the help. I'll keep you posted on the above SO_LINGER option. I think it has potential.