@BDub @no1089 @rickkas7 is there a way to "reset a network session"? always do a clean start - just for testing connecting to the network
i noticed that once connected there is a better chance to connect next time. and it says things like "Updated file: /sys/network.dat".
it would be nice to know if this is possible ("clean start for testing ethernet") as it will save us lots of time testing. so far we have 2 networks dat do not work and 5 that do work.
I can add to it that we have tested 7 networks in total. For 1 network it all works fine, but for the other networks we have to restart the P2 to have the P2 connect to the cloud. It seems that this CoAP protocol has issues for several networks. Please note that the behaviour is reproducible:
P2 first boot, connecting to ethernet works fine, IP address obtained, cloud socket connected
P2 keeps on trying to communicate with Particle cloud, never success, many attempts like this
0000121913 [comm.coap] TRACE: Retransmitting CoAP message; ID: 59; attempt 1 of 3
reboot the P2, connects right the first time
I can share the log. This is not workable in production as after a reboot of the network the device does not link to the Particle cloude automatically.
any luck @marekparticle debugging the ethernet issue?
Hi @boddeke -- no updates yet, it will continue to be addressed next sprint!
Hi @boddeke @swallage, or for anyone else that wants to help with testing. Since we have not been able to reproduce one issue (not connecting at all), would you mind helping out with collecting some secure logs? We are still testing things to resolve the longer connection times.
Please make sure not to post these logs online and share them directly with me via DM, as they will log a PCAP of your network traffic. We will only be looking at Particle traffic, and then will delete the files after debugging. If you are not comfortable with this, please do not capture and share.
To test, you can start with v5.5.0 on your P2, make sure it's booting up and connecting... then apply the p2-system-part1@5.5.0+logging.bin in the zip below. This will output logs on Serial1 (TX) pin at 115200 baud 8 N 1. I've also included a compile of @boddeke 's test application, with the cloud logging removed. If you have an Ethernet Wing, this should all be plug and play testing. This test may also remove long connection times, at the cost of them being more consistently longer for this test.
Thanks all <3
will do
there are already logs (wireshark and logging) here
Thanks! If possible I would like to get logging with the new method, specifically for you I think you said it was not connecting on your UniFi network.
@BDub i flashed the files but see no difference. will try again. what can i search for in the Serial output that i know for sure i have your "logging" version?
Sent you a DM 
Hi folks, the latest on this is that it is intended to be addressed in 5.6. Ongoing work is devoted to this. Unable to offer an ETA, but the target is likely around early November for a full release.
hi @marekparticle,
please let us know if we can test or help with anything
also since you are working on this now: is it possible that Ethernet.off() actually puts the ethernet chip in low power mode (or keep it in reset)? it does not in the current implementation
thanks,
frank
@marekparticle Any update overall please on this thread - maybe a summary of current understanding and status of resolution?
Hi @armor, sorry, was OOO. I know there's an investigation into a potential limitation of the Realtek chipset behind this this week, and that there's active work against this problem due this sprint. However, I still can't offer a definitive timeline here.
@marekparticle Thanks for the update. That's concerning that this problem might be a problem with the Realtek chipset.
Just wanted to throw my hat in the ring on this one and see if there is an update since 10 days ago? Any progress being made on a resolution? We have 3 different custom designs using P2s with hard wired ethernet, and we're seeing the exact same issues.
please share an update... (has been 3 months now...)
Rest assured this is still a major priority for engineering; this channel will be the first to know as soon as we have something ready to test.
Just to note - we're in the planning phases for our Argon replacement, and this not (currently) working is definitely a risk - a form of ethernet connection is a requirement for us.