I am trying to figure out how to start and stop Ethernet server and to change its port. The Ethernet server object has a .begin() method, but no corresponding .stop() or .end() method so there seems to be no way to cleanly stop the server and re-start it on another port.
During my searching I did find the following issue logged:
It was logged back in 2016, but there is no indication as to whether this has been implemented or not. Nevertheless I gave the code example in the third post (sandeemmistry) a try and it does seem to work.
There is still a problem though. When opening a tcp connection to server it seem possible to open a connection on ANY port and a session can be established. The port cannot receive or send data - only the configured port will do that - and it does time out eventually, but why is the connection not instantly rejected as it should be?
Also, if I want to stop (even temporarily) the serial-tcp passthrough how do I do that?
with Sandeep's trick you can only change the port in setup() before starting the server.
there is no way in Ethernet library to stop the server. but you can stop handling or reject clients.
Thank you for your reply, but... how does one reject clients? My searches did not reveal anything although I did find this unresolved question on StackOverflow:
It seems that the issue may run a bit deeper since from my experiments I have discovered that so long as Ethernet.begin() has been called, it is possible to make tcp connections to the interface. It is not necessary to even define an EthernetServer or start it with .begin(). A TCP client will still connect on any port although it will time out after a couple of minutes.
If Ethernet.begin() has not beein called, then there is no IP address bound to the interface and the terminal just responds with "No route to host" as might be expected.
So how is it that the interface is accepting connections without a server being started? How do I prevent it from doing so unless a server is running and listening on a specific TCP port?
May I ask which chip your shield is using? Mine is based around the W5100. Perhaps the W5200 or W5500 behave differently? If that is the case then I will have to buy a shield with a W5500, otherwise this is rather weird.
BitSeeker:
May I ask which chip your shield is using? Mine is based around the W5100. Perhaps the W5200 or W5500 behave differently? If that is the case then I will have to buy a shield with a W5500, otherwise this is rather weird.
Juraj, thank you for taking the time and trouble to confirm this and reassuring me that I am not going nuts! I didn't have any problem of this sort with any other device and having run a process of elimination on the software side, the evidence did seem to narrow it down to the shield hardware. However, the fact that you have now independently confirmed the problem, it would seem that this is a generic issue with the W5100 chip and not just my particular board.
I'm going to get a W5500 so I can continue development of my project without this kind of weirdness.
I couldn't find any firmware downloads on the WizNet website so I am I correct in presuming that this bug is hard coded in the hardware and cannot be fixed? I ask only because it does have SPI so theoretically it does have the means of communication at least to receive and update?
BitSeeker:
I couldn't find any firmware downloads on the WizNet website so I am I correct in presuming that this bug is hard coded in the hardware and cannot be fixed? I ask only because it does have SPI so theoretically it does have the means of communication at least to receive and update?
it looks like the firmware in this chips is not update able. there is still a small chance that the problem is in the library, but I doubt that. there is a recent fork of the Ethernet library with fixes, but I didn't try it. GitHub - SapientHetero/Ethernet: Ethernet Library for Arduino
Yes, on reflection that did ocurr to me as well since an Ethernet class object is created and has been started at this point otherwise the interface would not be accessible at all. Unlike the W5200 and W5500, the W5100 does not implement link status detection so it might be being handled slightly differently by the library and some step might have been missed. I will have a dig around the library when I get an opportunity.