W5500 FIN packet
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Ethernet Chips
No replies yet. Be the first to reply.
Join the discussion.
Share projects and connect with makers.
Joined before the site update? first.
New to WIZnet Makers?
We sent a verification link to your address. Open it to activate your account, then log in.
Accounts from this email provider are reviewed by an administrator after verification. Approval usually takes one business day.
Already have an account?
Enter your email address. If it belongs to an account, we'll send a link to set a new password. Members who joined before the site update use this to set their password.
If an account uses that address, we sent a link to set a new password. The link works once and expires in 30 minutes.
Know your password?
Need an account?
RE: W5500 FIN packet
by Eugeny ·
Technologically you can, but will other side be still listening?
Party sending FIN packet informs another party that former does not have anything more to say.
Thus if your application sees FIN state, it means that another device is done sending its data, and you must not expect anything from there. But it does not mean you can not send anything in the direction of that device. If that device is still listening, it will be acknowledging packets you send, but if that device is finished completely and closed all sockets and pursged its buffers, you will receive RST packet in response and W5500 will close the socket.
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
i wrote w5500 driver, TCP client and server, it works perfectly, but sometimes connection process took too long time, debugging log shows that SYN packet is transmitted (0x15 status) ,
what might be ?
RE: RE: W5500 FIN packet
by Eugeny ·
Not enough information to tell you exactly; do you reuse same source port at W5500 side?
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
yes , but after disconnecting,
socket status, and second is command
here is log, frst is a
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
at first i am closing port(uninit all) than opening, and at last connecting , but sometimes timeout is generated by w5500
RE: W5500 FIN packet
by Eugeny ·
You must use different source ports if connecting to the same server with the same destination port # in less than several minutes.
Routers and target node may cache source port#/destination IP address/destination port# information and treat them as continuation as previous connection and do not respond with SYN and rather respond with RST.
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
i am using source ports according IANA, from 49152 and above
TCP server destination port is 9999
RE: RE: W5500 FIN packet
by Eugeny ·
The point is that you use different port number every time you connect. So now you connected with local port # 49152, in 3 minutes you disconnected and in another minute you connect with local port # 49153 (for example).
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
thanks, can i use random ports from 49152 - 65535?
as i guessed , i must use different port for each connection?
RE: RE: W5500 FIN packet
by Eugeny ·
Yes, you can use random port # in the range, just ensure your new generated random number is not the same as previous you were connected with. I think it should also be ok to use fixed 49152 after reset if you do not reset every minute.
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
you meant RST packet?
RE: RE: W5500 FIN packet
by Eugeny ·
No, I mean you reset your device controlling W5500 (pressing reset button or power cycling it) so that W5500 appear on the network with port 49152 every minute for the same target host.
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
for example , after resetting my device(w5500) i set src port 49152 , i received data from server, and server sent me FYN packet, i disconnect current connection. for new connection to the same server with same port and ip i must use 49153 or somethin, not 49152 , i will try that
RE: RE: W5500 FIN packet
by Eugeny ·
Right, it is advised doing this way to eliminate possible conflict with previous sessions. Try it and see if your board will still experience sticking in 0x15 state.
RE: W5500 FIN packet
by Giorgi Kurtanidze ·
unfortunately i have the same issue
((
RE: RE: W5500 FIN packet
by Eugeny ·
Ok, so now time for Wireshark to see what is going on the network. SYN packet requires ACK packet, and looking at response (or prove the lack of such) may help. In your case, if it is possible, it would be good to install Wireshark on the server so that you can see activity at its interface related to this connection attempt.
First I would prove that server actually responds with SYN/ACK packet in case W5500 is hung in 0x15 state. If it does but W5500 is still in this state, it may happen that packet does not reach the chip.