I’m wondering if there is any possibility for the Fez connect shield to detect ethernet cable plug or unplug?
And I also have another quesition about the connection via the shield: If a computer connected with the device via LAN (the device retreived the dynamic IP from the DHCP server of LAN), after that the computer sends a hardware reset command for the uC (I use fez Panda 2) to execute command of “PowerState.RebootDevice(…)”. My question is: Is is possible to keep the connection between the PC and Panda2 without sending a connect request from PC side? Because when Panda2 is doing the HWreset, it will disconnect with the dhcp server, and retreive a new IP from it (usually the same IP as before), but from the DHCP server side, the connection will be defined for new channel and when the PC try to communicate with Panda II, it will throw an error of no connection, then I have to send a connect reques again. It will be inconvenient for user to do that.
@ Thaho,
If you are brave you could add a wire from the connect led to a digital pin, then poll it now and again, but it will only tell you if you have a bad or disconnected cable either end of the cable. You would already know that by looking at the led.
Thaho, fundamentally, how do you “know” that the connection existed?
Your description of who “knows” about a connection is wrong. The DHCP server just knows it has allocated an IP address to a device and the PC, it doesn’t know that they are talking in any way.
You need to explain what form of communication you’re using, and how you’re managing session state, on both the PC side and the Fez side. If you’re using sockets, once the socket is closed (because the Fez reboots) there is no open channel; If however you’re using something like a HTTP connection then that is stateless and after the reboot the next HTTP request will proceed.
If you’re in control of the PC app (ie you can have code added if needed) then if you’re using sockets and the user chooses to reset the Fez, then once you know the Fez is back up (perhaps ICMP?) then you can then re-open a socket without the user interacting with the app.
@ Brett: I use soket for the communication. I know that when the socket is closed (the Fez reboots), the assigned address of it on the DHCP server will be closed, and it will be allocated the new one after that. Therefore, there is no way to keep the connection alive between these two ends but we have to do something like a “tricky way” to handle this problem, your way to re-open the soket automatically from the PC side for instance. Thanks
@ Bec a Fuel: I also think so.
I’m new with GHI and also this community. Thank for all of the advices.
A socket is a pre-established communication channel between the PC and your Fez. It happens to be established because of two IP addresses from the DHCP server, but that’s the only interaction, related to DHCP.
When the Fez reboots, the socket at the Fez end has disappeared, the channel has been broken, and so the socket at the PC end is invalid and has to undergo setup again.
How do you establish the socket connection - from the PC or the Fez end? And how do you resolve the necessary address, from DNS? Lots of things to think about like what happens when the DHCP server does give the Fez a new address, what will the PC app do then; how long does the Fez take to reboot and be ready to recieve the connection from the PC?
Glad to help out, and hope you enjoy the community - there’s plenty of people here who like to help !
Once the FEZ side reboots, the socket connection is closed, because the FEZ won’t think it’s open. Once either side of the connection thinks it’s closed, it’s closed. If the other side did attempt to send a packet, the “closed” side would respond with an RST packet (which means, essentially, “yo, we’re not connected, you’re confused”) and then the “open” side would close the connection as well.
The IP address changing is a red herring. If the FEZ reboots, the connection is gone, regardless of whether the IP address changed or not.
My only point was, to cater for the IP address changing, you need to re-establish the address using a reliable method, not just assume you can reopen the socket to the same IP address. But you’re right, once the Panda reboots the connection is history
Yes, exactly, I was agreeing with you. In a DHCP environment you cannot safely rely on IP addresses being the same over time. You should use DNS, WINS, or some other mechanism for mapping names to IP addresses.
Because the connection is gone from the Fez side when it reboots, but I want to keep it opened for the PC app to keep controlling without re-connection after Fez rebooted (then I have to care about lots of things as Brett mentioned above). I changed my solution to make Fez do something like “software reset” by just simply reset all the configuration as it’s powered on.
It’s not possible for a connection to be closed on one side but kept open on another side. If either side thinks the connection is closed, then it is closed on both ends (or will be, as soon as the first RST packet comes across. The side that thinks the connection is closed will immediately respond with an RST as soon as the side that thinks the connection is open tries to send a packet, and the RST will result in a forcible closure on the “open” side.
Note that when I say “closed” here, that’s different than “partially shutdown”, where data can continue flowing in one direction but not the other. That’s a whole different ball game.
It is (probably) theoretically possible for a certain combination of hardware (an ethernet MAC/PHY with built-in TCP/IP stack, such as the WizNet offering) and software (a special firmware build that wouldn’t reset the ethernet interface upon boot, and would “learn” about already-established connections upon boot, and with some way to inform the user code about those connections) to be constructed that could do what you want, but it’s not worth it. Just reconnect.
It would make the firmware non-standard, in that it would no longer work like “normal” sockets. That would certainly not be desirable, and not worth it. What you really need is a way to resolve names to addresses in case addresses change. That particular problem has been solved, and solved well. Don’t reinvent the wheel (or, as in this case, design a whole new transportation paradigm just because you don’t like the color of the wheels).
