This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
Link up up and act led blinking but connection dropped
Hi there,
I have several PoE switches and connect them with PoE devices, in some cases self-made with arduinos.
I have noticed only on this brand of switches (NETGEAR GS series) the connection is lost when the device runs a slightly more complex code.
I assume that means that the switches drop the connection with a device too slow to reply at the demanded pace, is there any way to increase this timeout in the switches settings?
I have noticed only on this brand of switches (NETGEAR GS series) the connection is lost when the device runs a slightly more complex code.
I don't think this is a brand issue, and much less a problem with what you globally designate as GS Series. Far to many swich models in the field.
Forgive my frustration but I tested the hardware on other brands (Level-one and TG2492LG-VM) and got no connection problem.
If your tiny systems struggle with PoE and/or basic IEEE 802.3 e.g. by no longer sending the "ticks" required to keep the link up on the switch, resp. loosing the "ticks" coming from the switch so the controller does take the link down.
I assume that means that the switches drop the connection with a device too slow to reply at the demanded pace, is there any way to increase this timeout in the switches settings?
If this should be off IEEE 802.3 specs, Netgear (resp. the maker of the switch core) must look into it. However, as you state the problem happens on running more complex code on the tiny system (best guess simply CPU and/or interrupt handling), I suspect the issue much more on the small system Kernel and Ethernet driver which fails to handle things in time. Whereas I would expect the basic link ticks to be handled by the Ethernet controller resp. it's microcode/firmware what must not cause issues regardless of the system load - if these stop to come the other peer on the link must take the link down.
Suspect not much the community can do here - troubleshooting does require very low level work on either side.
I throubleshooted my code and found out the solution: more than a problem of ticks (as I suspected) was a problem of mac addresses:
The code I wrote was assigning FF as default to one of the mac address bytes and the switch was denying the service. I would have spotted earlier the problem if that wasn't the case for other switches/routers.
I post this in the hope that could be of use to any others encoutering a similar problem of course 😄
I have noticed only on this brand of switches (NETGEAR GS series) the connection is lost when the device runs a slightly more complex code.
I don't think this is a brand issue, and much less a problem with what you globally designate as GS Series. Far to many swich models in the field.
If your tiny systems struggle with PoE and/or basic IEEE 802.3 e.g. by no longer sending the "ticks" required to keep the link up on the switch, resp. loosing the "ticks" coming from the switch so the controller does take the link down.
I assume that means that the switches drop the connection with a device too slow to reply at the demanded pace, is there any way to increase this timeout in the switches settings?
If this should be off IEEE 802.3 specs, Netgear (resp. the maker of the switch core) must look into it. However, as you state the problem happens on running more complex code on the tiny system (best guess simply CPU and/or interrupt handling), I suspect the issue much more on the small system Kernel and Ethernet driver which fails to handle things in time. Whereas I would expect the basic link ticks to be handled by the Ethernet controller resp. it's microcode/firmware what must not cause issues regardless of the system load - if these stop to come the other peer on the link must take the link down.
Suspect not much the community can do here - troubleshooting does require very low level work on either side.
I have noticed only on this brand of switches (NETGEAR GS series) the connection is lost when the device runs a slightly more complex code.
I don't think this is a brand issue, and much less a problem with what you globally designate as GS Series. Far to many swich models in the field.
Forgive my frustration but I tested the hardware on other brands (Level-one and TG2492LG-VM) and got no connection problem.
If your tiny systems struggle with PoE and/or basic IEEE 802.3 e.g. by no longer sending the "ticks" required to keep the link up on the switch, resp. loosing the "ticks" coming from the switch so the controller does take the link down.
I assume that means that the switches drop the connection with a device too slow to reply at the demanded pace, is there any way to increase this timeout in the switches settings?
If this should be off IEEE 802.3 specs, Netgear (resp. the maker of the switch core) must look into it. However, as you state the problem happens on running more complex code on the tiny system (best guess simply CPU and/or interrupt handling), I suspect the issue much more on the small system Kernel and Ethernet driver which fails to handle things in time. Whereas I would expect the basic link ticks to be handled by the Ethernet controller resp. it's microcode/firmware what must not cause issues regardless of the system load - if these stop to come the other peer on the link must take the link down.
Suspect not much the community can do here - troubleshooting does require very low level work on either side.
I throubleshooted my code and found out the solution: more than a problem of ticks (as I suspected) was a problem of mac addresses:
The code I wrote was assigning FF as default to one of the mac address bytes and the switch was denying the service. I would have spotted earlier the problem if that wasn't the case for other switches/routers.
I post this in the hope that could be of use to any others encoutering a similar problem of course 😄
