Serious Issue: IP = 0.0.0.0 Teensy 4.1 Native Ethernet Library

Status
Not open for further replies.

jimmie

Well-known member
I have a Teensy 4.1 sketch which uses the NativeEternet library. I am using the latest versions of TeensyDuino and NativeEthernet.

My program runs without ANY problems for days. The program uses the watchdog to restart every 48 hours. And it normally restarts and everything works well.

Every once in a while, the program loses network connection. When it restarts, it picks a "0.0.0.0" IP and I have no idea why!

Normally, when the board is not connected to the network, the code blocks and it never gets an IP. I do not know how it returns with IP = 0.0.0.0 ?

Disconnecting power and reconnecting often does NOT solve the problem! Leaving the board disconnected for a few minutes somehow fixes the issue and everything goes back to working normally.

Is this a hardware or a software problem?

I would appreciate the community's input on this serious issue.
 
As suggested, try QNEthernet, for most users there won’t be a noticeable difference besides less bugs and relying on a different TCP/IP stack. Though I’m not sure if this is a DHCP issue with your modem or not, I wouldn’t expect the Teensy to behave differently after being left unpowered for a few minutes as opposed to immediately reconnecting. Of course there could always be a bug in FNET’s DHCP client so try QNEthernet which uses the more popular LWIP stack.
 
Thank you vjmuzik. This problem has been really demoralizing to me.

DHCP should not be involved because I am using a Static IP. So I am really puzzeled as to why it is getting a 0.0.0.0 IP.

I will try QNEthernet. When using QNEthernet, can you please tell me what is the equivalent to those lines of code:

Code:
          #include <NativeEthernetUdp.h>

          EthernetClient webClient

          EthernetUDP Udp;

Thanks in advance.
 
Check the QNEthernet examples, I know you don’t need the include, but you need to add a namespace.
 
The ServerWithAddressListener example in QNEthernet should be robust against network disconnects (tested with DHCP and with swapping physical networks (i.e. changing subnets)). The listener approach that’s used there seems to be reliable. See that for a very simple “HTTP” example. It doesn’t do proper HTTP header handling, however; it simply watches for a blank line after some input. Start there and see if it works for you.

Also see the How to write data to clients section in the README. It discusses how to ensure data is “written fully” to a client.
 
Note that I forgot to add to that README section that the client class now provides a writeFully implementation, so you don’t need to provide your own.
 
Status
Not open for further replies.
Back
Top