Products > Embedded Computing

ESP8266 / 8285 / 32 ARP issues with work around.

(1/1)

paulca:
Been having an issue with my SOnOff switches.  Basically ESP8266 or ESP8285 chips.

The issue is that while they will happily contact any host on the LAN, they are incredibly hard to get a hold off the other way around, contacting them.

This came down to ARP caches.  The ESP seems not to respond to ARP requests, or it's ARP responses are not forwarded by various access points.

An example replication of this issue is as follows, an ESP8285 is available on 10.0.0.7 and I am on "everest".

Flush the ARP entry if there is one:

--- Code: ---su -c "arp -d 10.0.0.7"
--- End code ---


--- Code: ---paul@everest ~ $ ping 10.0.0.7
PING 10.0.0.7 (10.0.0.7) 56(84) bytes of data.
From 10.0.0.199 icmp_seq=1 Destination Host Unreachable

--- End code ---

Resulting in:

--- Code: ---20:23:59.764113 ARP, Request who-has 10.0.0.7 tell everest, length 28
20:24:00.804257 ARP, Request who-has 10.0.0.7 tell everest, length 28
20:24:01.844115 ARP, Request who-has 10.0.0.7 tell everest, length 28
20:24:02.884099 ARP, Request who-has 10.0.0.7 tell everest, length 28

--- End code ---

The ESP does not respond to ARP broadcasts for it's MAC.  It's dead Jim!

However, if .. and this is a bit weird... if you get it to ping itself, this happens:

--- Code: ---20:24:48.136621 ARP, Request who-has 10.0.0.7 tell 10.0.0.7, length 46
20:24:49.138602 ARP, Request who-has 10.0.0.7 tell 10.0.0.7, length 46
20:24:50.135752 ARP, Request who-has 10.0.0.7 tell 10.0.0.7, length 46

--- End code ---

And eventually this:

--- Code: ---20:26:53.447901 ARP, Reply 10.0.0.7 is-at dc:4f:22:a8:0b:cb (oui Unknown), length 46

--- End code ---

For some reason, getting the device to ping itself seems to wake up it's ARP subsystem and it's MAC is discoverable again.  Without doing this I can't even find the ESP on the LAN using nmap scans!

Navigation

[0] Message Index