Anyone got wired ethernet working?

There is a PR scheduled for 5.6.0 that should improve Ethernet on the P2/Photon 2.


You can test the fix here!


what is the best way to compile and flash our code with these?


How long until 5.6.0 is released please?

@rickkas7 can you throw in the compile from source instructions? i'm afk
@armor current timeline is nov 27 for 5.6

The easiest way is to use the custom Device OS build option in Workbench. The PR mentioned earlier has been merged into develop so you can just follow the instructions to use that branch. When you use Configure: Project for device be sure to select DeviceOS@source. Also use the Particle: Flash application & DeviceOS (local).

hi @rickkas7

the repository that custom device os build refers to is not accessible?


frank@Aussimento particle % git clone
Cloning into 'device-os'... Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
frank@Aussimento particle % 

It's public; I think it's just that clone URL format no longer works. Try this instead:

git clone

thanks @rickkas7, also updating the documentation

all seems to build/flash well. but initial quick test does not show any improvement: how can i be sure i am running "the fix"? (System.version() still is "5.5.0")


hi @marekparticle, @rickkas7,

if i compiled&flashed correctly (let me know how i can check) then "the fix" will not connect per ethernet (unify network). see repository for code and logging

(it still does connect per ethernet shared from my mac)


btw: using Particle.connect() instead of our connectivity library (based on @rickkas7's) gives the same results - never connects

Can you validate that you flashed the enclosed system part 1 binary -- that's actually all you need here to test. If that's confirmed, I'll bring this back to our engineering team.

@avtolstoy just a note about the above ^.

@marekparticle @rickkas7 @avtolstoy @no1089

second try: here is what i did (see below also):

  • flash device-os as delivered by @marekparticle using device-os-flash
  • flash our test application (only) using visual studio: Particle: flash application (local)

what i see now is that eventually eth will connect but still much slower than e.g. argon. it takes from half a minute to 2 minutes

see logging (serial-2.log and console-2.log) in the repository



frank@Aussimento release % pwd
frank@Aussimento release % device-os-flash --all-devices .
Initializing module cache
Initializing flash interface
Enumerating local devices
Flashing target devices
Target devices:
1. 0a10aced202194944a005484 (P2)
[Device 1] Skipping p2-prebootloader-mbr@fix-p2-eth-perf-fef71d2bb.bin. It's required to be encrypted
[Device 1] Preparing device for flashing
[Device 1] Flashing p2-system-part1@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Flashing p2-tinker@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Resetting device
[Device 1] Using control requests to flash remaining modules
[Device 1] Preparing device for flashing
[Device 1] Not allowed
[Device 1] Flashing p2-prebootloader-part1@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Preparing device for flashing
[Device 1] Not allowed
[Device 1] Flashing p2-bootloader@fix-p2-eth-perf-fef71d2bb.bin
[Device 1] Flashed successfully
frank@Aussimento release % 

visual studio:

 *  Executing task: make -f '/Users/frank/.particle/toolchains/buildscripts/1.13.0/Makefile' flash-user -s 




Creating /Users/frank/Code/edge-site-network-test/target/source/p2/memory_platform_user.ld ...
Creating /Users/frank/Code/edge-site-network-test/target/source/p2/memory_platform_user.ld ...
   text    data     bss     dec     hex filename
  20318     124     542   20984    51f8 /Users/frank/Code/edge-site-network-test/target/source/p2/edge-site-network-test.elf
dfu-suffix (dfu-util) 0.9

Copyright 2011-2012 Stefan Schmidt, 2013-2014 Tormod Volden
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Suffix successfully added to file
Serial device PARTICLE_SERIAL_DEV : not available
Flashing using dfu:
dfu-util 0.9

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to

Opening DFU capable USB device...
ID 2b04:d020
Run-time device DFU version 011a
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 011a
Device returned transfer size 4096
DfuSe interface name: "Internal Flash   "
Downloading to address = 0x085fb000, size = 20480
Download        [=========================] 100%        20480 bytes
Download done.
File downloaded successfully
Transitioning to dfuMANIFEST state


 *  Press any key to close the terminal. 

@boddeke -- are you able to reproduce in another environment? we're unable to -- for example, can you try using a laptop + eth and sharing laptop internet connection? the fact that the DTLS handshake is taking so long (20 seconds!) points to some high packet loss which could be WAN or LAN issue -- but it doesn't look like a DeviceOS problem.

these are the results (see repository):

  • serial-2.log: connected to unify switch: takes half minute up to 2 minutes
  • serial-argon.log: same but with argon: takes less than 6s
  • serial-mac.log: connected to eth-dongle mac with internet sharing: takes less than 20s


my conclusion:

  • same code on argon works well (as does any other wired device on the network) -- network is fine
  • same hardware on different lan works well (still slow though) -- hardware is fine

maybe @armor and/or others can test as well?

@marekparticle @rickkas7 @avtolstoy @no1089

we do need to know this issue will be fixed. we must have reliable ethernet with whatever netwerk our users plug into (well, as long as there is internet connectivity)

we experimented quite a bit with the argon and that worked very reliable. we did not have any trouble with any network we tested it on and do expect this from the p2 as well

we now get a bit the feeling that it will not get fixed?!

@no1089 - let's speak about this in Triage today.

@boddeke - unfortunately we cannot reproduce the phenomenon you are describing, though the logs are very helpful. As I mentioned in the other thread, it might be useful to set up a call.