I've been seeing something odd when working on my equipment at home. When I boot up a MODM7AE70 device (one of several that I incorporated on various products) I'm having some network connection issues. The MODM7AE70 connects to my network (regular 10/100 Ethernet) then it "disappears". By disappears I mean that nothing on my network can see it and the MODM7AE70 can't communicate with anything else on the network including other MODM7AE70 devices. I've found that I can disconnect the Ethernet jack from the unit and then plug it in again and it often will be "seen" by IPSetup and then disappear again. When it disappears IPSetup can't find it.
I go through this ritual of unplugging and plugging in the Ethernet jack, attempting to browse to the unit, and then losing it perhaps a dozen times before it eventually seems to settle down and stays online. When it disappears I still get the "connected" LED on the jack.
A few more observations...
1). Once the unit becomes stable and I have it doing something that requires network activity, it stays online with no problems. If I don't give it any network activity it will eventually disappear again.
2). When I browse to the Orbi router I don't "see" any MODM7AE70 devices even though there are several and they are connected and communicating with my PC and other MODM7AE70 devices. These units are set up with Static IP addresses and so for grins I set one up to use DHCP. The router grants the device an IP address but it does not show up on the list of connected devices.
3). I never seem to have a problem with the same devices at work using the buildings Ethernet. So far I've never had a customer complain about it either. At work I'm still using 10/100 switches.
4). I've tried using a new switch on the network connected to these devices but that doesn't seem to make a difference.
5). When the module disappears it can't be seen by my PC nor can it be seen by other network devices connected to the same switch. Being all static devices they should not need to talk to the router. I often just connect everything to switches and let them run.
6. When the unit disappears neither TCP nor UDP seem to work. I can't ping it either.
I don't mean to imply there is anything wrong with the MODM7AE70! I think it's something unique to my network. Any ideas on why my home network is haunted?
Regards,
John
MODM7AE70 Ethernet with Netgear Orbi router
Re: MODM7AE70 Ethernet with Netgear Orbi router
Hi John,
I had no idea what would cause this either, but did some searches and found the data below. Note its from an ai, so nothing is guaranteed.
Here's the reply as plain text, ready to paste into the ticket.
Nothing you've described points to a problem with the MODM7AE70 itself, and your instinct that it's something about the home network seems most likely. The behavior you're seeing could be an interaction between the energy-saving Ethernet features on consumer routers (Netgear calls it "Green Ethernet," the standard name is Energy-Efficient Ethernet, or IEEE 802.3az) and quiet, low-traffic devices.
The detail that gives it away is this one: the unit stays online as long as it has something to do on the network, but disappears once it goes idle, all while the link LED stays lit. That "link is up but no packets pass when idle" pattern is the signature of the switch port deciding the port is idle and parking it into a low-power state, then not waking it cleanly. Unplugging and replugging forces a fresh negotiation, which is why it briefly comes back. It also explains why you never see this at work: the building switches and your older 10/100 switches don't do this (or do it harmlessly), whereas the Orbi does it aggressively by default.
A few things to try:
1. Disable "Green Ethernet" or energy-saving on the Orbi's wired ports, if your model exposes the option in its Advanced settings. Some Orbi models don't, which is why the switch test above is the more reliable check. Not sure if orbi lets you do that.
2. Put a plain, old 10/100-only unmanaged switch directly on the module, a genuine Fast Ethernet switch, not a modern gigabit one. A new gigabit switch usually has the same energy-saving feature, which is likely why the switch you already tried didn't help. A true 10/100 switch has none of this power-saving logic and cleanly isolates the module from the Orbi's behavior. This is the quickest way to confirm the cause.
3. If you'd rather fix it in firmware so it's independent of whatever network the module is plugged into, the most robust option is to keep the link from ever going idle by having your application send a tiny packet every couple of seconds. That matches exactly what you've already noticed keeps it alive. I've included a short code snippet below you can drop into your project.
Something seen with some routers and their connected-devices view (even the DHCP one) is tha list leans on devices that actively talk to the router, and static, quiet modules that never need it simply won't show up there. It doesn't mean they aren't on the network.
Give the 10/100 switch test a shot and let me know what you see. I'm confident we'll have your "haunted" network sorted out.
---
Keepalive snippet (a small periodic broadcast keeps the PHY/port out of its idle power state). Drop this into the project and start the task from UserMain() after the network is up:
#include <udp.h>
#include <nbrtos.h>
#include <ipv4/ip4.h>
// Emit a tiny UDP broadcast every couple of seconds so the Ethernet link
// never sits idle long enough for a power-saving switch port to park it.
// Workaround for "Green Ethernet" / EEE (802.3az) link drops on some routers.
static uint32_t keepAliveStack[USER_TASK_STK_SIZE] __attribute__((aligned(4)));
void KeepLinkAliveTask(void *pd)
{
const uint16_t kPort = 7777; // arbitrary; nothing needs to listen
const char kMsg[] = "nb-keepalive";
while (true)
{
UDPPacket pkt;
pkt.SetSourcePort(kPort);
pkt.SetDestinationPort(kPort);
pkt.AddData(kMsg);
pkt.AddDataByte(0);
pkt.Send(IPADDR4::GlobalBroadcast()); // 255.255.255.255
OSTimeDly(TICKS_PER_SECOND * 2); // every 2 seconds
}
}
Then, in UserMain() after init() / WaitForActiveNetwork():
OSTaskCreatewName(KeepLinkAliveTask,
nullptr,
&keepAliveStack[USER_TASK_STK_SIZE],
keepAliveStack,
MAIN_PRIO - 1,
"KeepAlive");
A couple of notes you can pass along: 2 seconds is comfortably below the idle window these ports use, so it can be tuned up or down. It's a broadcast, so nothing has to be listening; it just keeps the link busy. If you would rather not broadcast, sending to the gateway IP works equally well.
I had no idea what would cause this either, but did some searches and found the data below. Note its from an ai, so nothing is guaranteed.
Here's the reply as plain text, ready to paste into the ticket.
Nothing you've described points to a problem with the MODM7AE70 itself, and your instinct that it's something about the home network seems most likely. The behavior you're seeing could be an interaction between the energy-saving Ethernet features on consumer routers (Netgear calls it "Green Ethernet," the standard name is Energy-Efficient Ethernet, or IEEE 802.3az) and quiet, low-traffic devices.
The detail that gives it away is this one: the unit stays online as long as it has something to do on the network, but disappears once it goes idle, all while the link LED stays lit. That "link is up but no packets pass when idle" pattern is the signature of the switch port deciding the port is idle and parking it into a low-power state, then not waking it cleanly. Unplugging and replugging forces a fresh negotiation, which is why it briefly comes back. It also explains why you never see this at work: the building switches and your older 10/100 switches don't do this (or do it harmlessly), whereas the Orbi does it aggressively by default.
A few things to try:
1. Disable "Green Ethernet" or energy-saving on the Orbi's wired ports, if your model exposes the option in its Advanced settings. Some Orbi models don't, which is why the switch test above is the more reliable check. Not sure if orbi lets you do that.
2. Put a plain, old 10/100-only unmanaged switch directly on the module, a genuine Fast Ethernet switch, not a modern gigabit one. A new gigabit switch usually has the same energy-saving feature, which is likely why the switch you already tried didn't help. A true 10/100 switch has none of this power-saving logic and cleanly isolates the module from the Orbi's behavior. This is the quickest way to confirm the cause.
3. If you'd rather fix it in firmware so it's independent of whatever network the module is plugged into, the most robust option is to keep the link from ever going idle by having your application send a tiny packet every couple of seconds. That matches exactly what you've already noticed keeps it alive. I've included a short code snippet below you can drop into your project.
Something seen with some routers and their connected-devices view (even the DHCP one) is tha list leans on devices that actively talk to the router, and static, quiet modules that never need it simply won't show up there. It doesn't mean they aren't on the network.
Give the 10/100 switch test a shot and let me know what you see. I'm confident we'll have your "haunted" network sorted out.
---
Keepalive snippet (a small periodic broadcast keeps the PHY/port out of its idle power state). Drop this into the project and start the task from UserMain() after the network is up:
#include <udp.h>
#include <nbrtos.h>
#include <ipv4/ip4.h>
// Emit a tiny UDP broadcast every couple of seconds so the Ethernet link
// never sits idle long enough for a power-saving switch port to park it.
// Workaround for "Green Ethernet" / EEE (802.3az) link drops on some routers.
static uint32_t keepAliveStack[USER_TASK_STK_SIZE] __attribute__((aligned(4)));
void KeepLinkAliveTask(void *pd)
{
const uint16_t kPort = 7777; // arbitrary; nothing needs to listen
const char kMsg[] = "nb-keepalive";
while (true)
{
UDPPacket pkt;
pkt.SetSourcePort(kPort);
pkt.SetDestinationPort(kPort);
pkt.AddData(kMsg);
pkt.AddDataByte(0);
pkt.Send(IPADDR4::GlobalBroadcast()); // 255.255.255.255
OSTimeDly(TICKS_PER_SECOND * 2); // every 2 seconds
}
}
Then, in UserMain() after init() / WaitForActiveNetwork():
OSTaskCreatewName(KeepLinkAliveTask,
nullptr,
&keepAliveStack[USER_TASK_STK_SIZE],
keepAliveStack,
MAIN_PRIO - 1,
"KeepAlive");
A couple of notes you can pass along: 2 seconds is comfortably below the idle window these ports use, so it can be tuned up or down. It's a broadcast, so nothing has to be listening; it just keeps the link busy. If you would rather not broadcast, sending to the gateway IP works equally well.
Re: MODM7AE70 Ethernet with Netgear Orbi router
Thanks Tom. I'll give it a try. If I can isolate it from the network (everything connected to a simple 10/100 switch) that should point me in the right direction.
John
John