@ mhstr -
I don’t think so, because, as my understanding, ReuseAddress is not supported.
G120 should have same behavior with G400 and not only ENC28 but also all other interfaces will have this issue
@ Dat - Ok, so in case this is an issue is here any recommended workaround?
@ mhstr - I would suggest to retry a couple of times with short delays in between.
Once you get a Feeling how log it takes until the port can be reused you can Limit the numeber of repetitions.
@ Reinhard Ostermeier - It takes about minutes (3-5minutes). Is this expected time? I would expect much lower delay, but maybe it is a standard, I am really not network specialist.
@ Dat - I am wondering why it is possible to use SocketOptionName.ReuseAddress in code if this is not supported?
Reinhard do you have any clue about user restriction in your ftp implementation? I mean there’s just the starrt directory that changes. Have you already try to add restriction such as non deletion of file?
@ leforban - No, I havn’t.
Not sure if this implementation supports specific Access rights. It’s based on the implementation from NETMF SDK V4.2.
I guess this would have to be added.
But if I remember correctly there is read only flag that can be set.
I confirm the same issue when trying to rebind a socket that has been previously closed. Sometime it works sometime not…
This is frustrating, the ftp server itself is quite stable but if the underlying engine has such issue, this can’t be provide to customer.
There’s also something weird: _m_HostIP is affected during FtpListenerManager instantiation. Therefore if the ip change I do not understand how this variable is updated. Any idea?
… better m_HostIP is not used for the socket… so this seems not to be the cause of the problem
May be an interesting thing. I can plug unpug the eth cable several time as soon as the ftp connection have been properly closed remotely (i.e. closing ftp connection using filezilla) but if i do not close the connection, it fails to rebind…
the current issue is that unplugging replugging the eth cable results in an unreachable ftp server if the previous ftp session has not been closed
In my experience, detecting a cable disconnect is impossible in the general case; even if you could detect disconnection of the cable from your local machine/module, you couldn’t detect a disconnect somewhere farther down the line, after a switch. All you can really do is try to send some data, and if it fails, you know something went wrong.
This is true for every operating system.
Most/all desktop operating systems support something called “TCP Keepalive” packets, which can automate the process of detecting disconnects: Keepalive - Wikipedia
I don’t know whether NETMF supports it.
cable disconnect event works well but the problem is when I call the socket.close method , in some cases, the socket.bind methods fails
@ leforban - The event only works when the local cable is disconnected; it won’t tell you when the cable plugged into the other device is disconnected. It’s not a general solution.
As for the socket failing to bind after it’s been closed, your socket is probably in the FIN_WAIT_1 state (i.e. your side sent a FIN packet to close the connection, and now it’s waiting for the other side to respond with an ACK or a FIN/ACK). It’ll time out eventually, but not immediately.
I have disconnected on the local port and the event is fired. Reconnecting also fires the event. I then disconnect on the switch and the event is also fired.
For the problem of binding after closing, this is really annoying. Is there any way to force the time out?
@ leforban - I think the reuse socket Option is the usual way to ignore the timeout, but if GHI says it’s not implemented, then I guess thats a dead end.
If you have no other open Network Connection, you could propably reset/reinitialize the whole Ethernet Interface.
@ leforban - Right, but it won’t be fired if you disconnect the other device from the switch. It’s not detecting a broken socket (indeed, just because the cable is disconnected doesn’t mean the socket is…), it’s just detecting that the physical link on the Ethernet interface went down.
So it’s a bug and it has to be solved!
I am not sure where the bug is I started to write minimal code but didn’t succeed to get the same issue
@ Reinhard Ostermeier - SO_REUSEADDR can allow you to reuse a socket that’s in TIME_WAIT, but it’s not clear to me that it allows you to reuse a socket that’s in FIN_WAIT_1 (which his probably are).
I have never tried, however.