Anyone got wired ethernet working?

Firmware Device OS
43

Thanks for the info! Would you please share your simple test code. I'd like to see if I can reproduce your results. Due to the root cause, I can see why the connection times will vary, but the lock up is what I'd like to reproduce.

44

hi @BDub

check out our test code here
this will try to connect to the particle cloud per ethernet. if it does it reports time it took and restarts

it works with our board and also the particle p2 eval board with adafruit ethernet featherwing

issues:

  • after a while (sometimes minutes, sometimes hours) it will hang (solid color), code always at the same point. watchdog enabled but does not kick in (with our board and with the p2 eval board)
  • certain lans: if it connects is takes a long time (up to 1500s)
  • sometimes it will connect all the time and some other runs it will never connect. seems like when it connects once it will keep connecting
  • one of my 2 lans is "difficult", has issues above, the other lan will connect no problem all the time (in about 30s)

thanks
frank

1 Like
45

I've run the connection test now for over 5100 connections and it actually looks pretty decent. Only two 3 digit connection times (~100s), and hasn't locked up.
ethernet-connection-test.log

I'll leave it running though hoping for a lockup, because I also have the debugger attached.

The only thing I've changed in your code is the remote logger line was commented out, but I'm not sure if that has improved connection times for me. Possibly though?

// RemoteLogHandler remoteLogHandler("monitor.edgetech.nl", 8888, "network-test");

46

Separate issue, but has remote logging ever worked for you on Ethernet? I don't think the library correctly supports Ethernet. It needs to resolve the syslog server hostname to an IP address. There is no Network.resove() function so It calls Cellular.resolve() or WiFi.resolve() directly. There is no case for Ethernet.resolve() because that function also does not exist, so it will look up the hostname using the native network interface, not the Ethernet interface. It also does a bunch of stuff on network up/down, so that could be an issue.
Edit: Network.resolve() was added in Device OS 1.1.0 and should work properly, so I switched the library to use it. Version 0.0.4 released.

47

it sort of works on ethernet but not very reliable: missing lots of lines especially when in quick succession

how does one resolve hostnames on ethernet? i (wrongfully) assumed that Network.resolve() would resolve on the active interface (in this case Ethernet.resolve())

thanks
frank

48

I just checked, and Network.resolve was added in Device OS 1.1.0. I'll change the library to use that instead of Cellular.resolve() or WiFi.resolve() which should help.

49

i had 2 board run over the weekend and did not see any hang:

board 1: p2 eval board connected to mac that shares wifi internet to ethernet dongle: 10k connects, typically in 30s
board 2: our hw connected to unify lan: never connects..

mac is on the same network as board 2 (only wireless)

(it has nothing to do with the hw, switch the boards and the results are the same: directly connected to lan almost never connects)

why no hang this time? who knows. slight change in the sw somewhere? just (bad) luck

1 Like
50

any pointer to hook up a debugger? think that will be very useful for us

51

so will Network.resolve() work for ethernet? or what do i use in that case?

52

I just released version 0.0.4 of the RemoteLogRK library that uses Network.resolve(). That should work properly.

53

just to be 100% sure: Network.resolve() will work for wired ethernet?

54

I didn't test it, but it uses the LwIP DNS resolver that's used everywhere else, so if it doesn't work, DNS resolution wouldn't work anywhere, including for the cloud connection, so I'm confident it should work properly.

55

well, funny you mention this: when connected to my lan directly (almost never connects): i see a lot of:

0000117487 [system] TRACE: Resolving 0a10aced202194944a004d3c.v5.udp.particle.io#5684
0000136344 [system] ERROR: Failed to determine server address
56

A quick update... no lockup over 4 days of testing. Sorry, couldn't reproduce that. We are still looking into the root cause of slowness to connect though, even though I didn't see that happening much with this testing (I have seen it).

57

This is what we suggest Workbench | Getting Started | Particle

58

can you try another lan?

i have trouble with unify (hardly ever connects) but not with my mac sharing internet. you can see it in my logs and traces

59

I'm using a Ubiquiti US-16-150W. I have some other switches I could try, but it seems since it's already working on UniFi that's probably the right test?

60

i think it is more the gateway. something with dhcp or dns

my lab has a this unify gateway

61

That's actually the same gateway I use with the switch, USG. I wonder what strange firewall settings it might have on yours, or if it has an explicit DNS that is used that gives some issues?

62

oh, interesting...

weird things i see when (directly) to the lan:

  • my mac is on the same network (but wireless) and shares the wireless internet over a usb-c ethernet dongle. p2 connected to this dongle has no problem connecting
  • an argon (with ethernet) has no issue connecting to lan (at the exact same point as where the p2 does have problems)
  • lots of "Failed to determine server address", "Cloud socket connection failed: -230" and "DNS server list changed"