AVR-IoT WG / AC164160 :: No response to ARP 'Who has <gateway>' broadcast request

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Having followed the AVR-IoT AC164106 QUICK START GUIDE on two development boards, I've had no success on getting either board to connect to WiFi correctly 'out-of-the-box'.

Given the simplicity of the three step QUICK START procedure ... it's not met my "Get Started in 30 second" expectation. sad

 

 

1st ISSUE: I needed to update the firmware before I was able to get the blue (WiFi connected) led to go on (after the board's initial start up check). Before I applied the update (i.e. in the out-of-the-box state) only the red (error status) led would light.

If this is always going to be the case ... it might be better to highlight this as the first step in the QUICK START procedure webpage.

 

 

2nd ISSUE: After the firmware update was applied the blue (WiFi connected) LED turned on ... but only for a short while. On one device it would remain on for 5 seconds before the fault led lit. On the 2nd device it took around 20 seconds. I have not investigated yet, so have no idea as to why there is this discrepancy in time, only that it is consistent and related to the board.  After a further period of time the red (error status) led goes off and thew blue (WiFi connected) led turns on. This cycle continues indefinitely.

While a list of meanings is provided for various led states is given in the USER GUIDE ... none of the documented led states relate to this: red then blue then red led sequence. 

 

3rd ISSUE: having done some investigation, I observe both boards correctly get their reserved IP address from the network DHCP server, but then seem to drop off the WiFi network. As such neither gets to connect out of the network to the Google IoT Cloud.

 

My investigation with WireShark suggests this may be an ARP related issue (see attached)

 

Specifically the ARP broadcast from the devices requesting the MAC address of the gateway is NOT getting a response. Thus, presumably, the board is NOT able to update it's APR table... and thus communicate out across the local network.

 

Naturally my suspicions, fall onto the local network or router configuration

 

I notice the ARP 'Who has' request sent out by the AVR-IoT board is 60 bytes long ... and getting NO response.

 

Whereas I can see similar 60 byte broadcast requests from other devices on the network, that are getting answered as a 42 byte response.

For completeness, I can see 'Who has' requests being sent out as 42 bytes to a specific host and getting answered as 60 bytes.

 

Is anyone able to shed light on what might be happening ... and how to correct it, so these AVR-IoT boards connects to Google IoT Core Cloud correctly? 

 

Thanks in advance,

Michael

Attachment(s): 

Michael

Last Edited: Thu. Oct 25, 2018 - 05:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

    Are you sure your router IP address is 192.168.1.1 ?

 

    If yes, probably the ARP packet is malformed. ARP protocol is not that complicated. Wikipedia explains it very well. You can take field by field and look into it. Or post here one packet from Wireshark and someone will look into it.

 

Edit: if you run your Wireshark on "Elitegro" machine, you most likely won't see the ARP reply you are looking for since the response is no longer a broadcast. Some routers allows you to set a port in promiscuous mode, so then you can see everything that moves on that LAN.

Last Edited: Wed. Oct 24, 2018 - 04:37 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MichaelG380 wrote:
Naturally my suspicions, fall onto the local network or router configuration
One at Microchip mentions that as an issue so does the network setup for his smart phone as a WLAN access point.

https://youtu.be/WK4ljyKDMIQ?t=178

at

Getting Started With Your AVR-IoT WG Development Board

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Angelu

 

1)  Yes the router IP address is 192.168.1.1

2) same result when I set the capture interface to: "ether host F8:F0:05:EE:AD:B6 or ether host 10:56:CA:04:2E:20" & am able to see all ARPs on the LAN

 

HOWEVER ----

 

a) after leaving the board connected for several hours, I have arrived at a state where I see a SOLID Blue LED ... but was unable to access the filesystem

(NB: this state change may have been triggered by connecting to the board with Atmel Studio) 

 

b) after shutting down Atmel Studio & power cycling the board it fired up, ran the 2x led test, then went into the blue to red to blue cycle while I redid the wireshark tests ... but this time it eventually stayed red.

 

 

 

THIS IS A SAMPLE ARP request capture as a BROADCAST from the AVR-IoT BOARD looking for the PeplinkI_ (ROUTER)

 

8676    341.808834    NewportM_ee:ad:b6    Broadcast    ARP    60    Who has 192.168.1.1? Tell 192.168.1.77

 

Frame 8676: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: NewportM_ee:ad:b6 (f8:f0:05:ee:ad:b6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
Address Resolution Protocol (request)

 

0000   ff ff ff ff ff ff f8 f0 05 ee ad b6 08 06 00 01   ÿÿÿÿÿÿøð.î.¶....
0010   08 00 06 04 00 01 f8 f0 05 ee ad b6 c0 a8 01 4d   ......øð.î.¶À¨.M
0020   00 00 00 00 00 00 c0 a8 01 01 00 00 00 00 00 00   ......À¨........
0030   00 00 00 00 00 00 00 00 00 00 00 00               ............

 

... & not getting a reply

 

 

FOR COMPARISON:

 

THIS IS A SUCCESSFUL ARP REQUEST as unicast from the PeplinkI_ (ROUTER) looking for Elitegro_

 

14957    651.851644    PeplinkI_04:2e:20    Elitegro_7e:75:21    ARP    60    Who has 192.168.1.121? Tell 192.168.1.1

 

Frame 14957: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: PeplinkI_04:2e:20 (10:56:ca:04:2e:20), Dst: Elitegro_7e:75:21 (b8:ae:ed:7e:75:21)
Address Resolution Protocol (request)

 

0000   b8 ae ed 7e 75 21 10 56 ca 04 2e 20 08 06 00 01   ¸®í~u!.VÊ.. ....
0010   08 00 06 04 00 01 10 56 ca 04 2e 20 c0 a8 01 01   .......VÊ.. À¨..
0020   00 00 00 00 00 00 c0 a8 01 79 00 00 00 00 00 00   ......À¨.y......
0030   00 00 00 00 00 00 00 00 00 00 00 00               ............

 

 

 

AND this is the Elitegro_ RESPONSE (as the next frame captured)
 

14958    651.851679    Elitegro_7e:75:21    PeplinkI_04:2e:20    ARP    42    192.168.1.121 is at b8:ae:ed:7e:75:21

 

Frame 14958: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Ethernet II, Src: Elitegro_7e:75:21 (b8:ae:ed:7e:75:21), Dst: PeplinkI_04:2e:20 (10:56:ca:04:2e:20)
Address Resolution Protocol (reply)

 

0000   10 56 ca 04 2e 20 b8 ae ed 7e 75 21 08 06 00 01   .VÊ.. ¸®í~u!....
0010   08 00 06 04 00 02 b8 ae ed 7e 75 21 c0 a8 01 79   ......¸®í~u!À¨.y
0020   10 56 ca 04 2e 20 c0 a8 01 01                     .VÊ.. À¨..

 

 

CONCLUSION: This appears to be something to do with:

 

i) the way the Peplink router is (NOT) responding to ARP requests broadcast over the WiFi network segment.  I'm going to try connecting via a different router & WiFi  

-or- 

ii) the fact the AVR-IoT WG is broadcasting it's ARP request 

 

 

Attachment(s): 

Michael

Last Edited: Thu. Oct 25, 2018 - 08:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman

 

Thanks for the video link ... will give it a go.

 

Michael  

Michael

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good News - Got it working perfectly! smiley   .... but not over the LAN.

 

I did this via a HotSpot connection with WiFi sharing turned on from my mobile phone ... not entirely clear on the procedure (will go through it again) but pressing SW0 may have something to do with it.

 

Still tracking down the dropped ARP broadcast request issue, but honing in on the behaviour of WiFi connections passing over "Access Points" (& bridges? &/or PowerLine adapters) 

 

 

For INFO:

The LAN network configs I'm using are:

 

 

STD)  INTERNET <> ROUTER <> SWITCH <> ACCESS POINT <> AVR-IoT board

                                   <> PC

 

 

ALT)  INTERNET <> ROUTER <> SWITCH <> ACCESS POINT <> AVR-IoT board

                                                   <> PC

 

In both these network configs the AVR-IoT board's ARP request broadcast doesn't get a response

Whereas Unicast ARP request (sent by other devices) are getting responses.

 

 

It seems the state of ARP caching on Access Points may be the culprit. 

This post explains:  https://mrncciew.com/2013/03/10/...

 

There are numerous posts about network issues relating to dropped ARP responses causing a whole range of network connection issues.

 

If I'm correct (still to be verified) then others using the AVR-IoT board to connect via an Access Point -or- WiFi bridge risk seeing their board fail to connect (as I have)

 

SUGGESTION: 

 

Given the gateway address is provided to the board by DHCP when the board connects to the network  

 

... would it not be better to a) program the WINC1510 to send out a Unicast request direct to the router (based on reading the GW address from ifconfig)?  

-or- b) send the current broadcast ARP request (as it does now) then, if no response, use Unicast ARP or ping or other method, to get the Router MAC.

 

This would need to be done in the next release of firmware... but for developers with WiFi AP's, Bridges or PowerLine devices, could make the difference between a "30 second setup" or several days of diagnostics I had to do ... or, worse, dropping their attempt to get the board running. 

 

HTH 

Michael

 

Michael

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MichaelG380 wrote:

Given the gateway address is provided to the board by DHCP when the board connects to the network  

 

... would it not be better to a) program the WINC1510 to send out a Unicast request direct to the router (based on reading the GW address from ifconfig)?  

-or- b) send the current broadcast ARP request (as it does now) then, if no response, use Unicast ARP or ping or other method, to get the Router MAC.

 

HTH 

Michael

 

first, you can't assume that the router and the DHCP server is one and same device

a. this looks like adding an ARP entry manually; no need to change anything

b. to send a ping, you need a MAC first, so you can't send a ping for now. To extract the MAC from a DHCP reply, it is doable, but it is really messy. And what about if the user uses static IP (no DHCP)?

 

It looks like that AP is not doing its job correctly. It sure is aware of router's MAC address (let AP and the router be on for a while before you power your device). When you send an ARP broadcast request, it only needs to reply you back with that MAC address from its cache. No need to forward it to the router or to broadcast it further. If the Ap claims that it is smart and helps save power, then it should look in the broadcast packet what it is. If it is an ARP, then proceed like it was an unicast. If it is UDP or whatever, then drop it. Dropping ARP broadcasts I think is not right.

 

Maybe that "optional" clause may help.

 

What I would do, I would add a static ARP entry with the router's MAC and see if your device is smart enough to send unicast ARP packets. Maybe is not.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi there! I have very serious problems with this board. Specifically with the WiFi connection.

 

I have connected it in two modems of different brands and I have only been able to test it using my cell phone as an hotspot.

 

I have tried in different ways without having satisfactory results. I was reading the programming documentation of WINC1510C and I got to the topic of the "ScanRegion" section Asia = 14 North_America = 11 I don't know if this has anything to do with my problem.

 

And I comment this because if I can see in the setup of my home Router that it does connect. But nothing else happens. They recently published some MQTT libraries but they won't help me much if I have to use my cell phone as an intermediary for their application (it makes no sense)

 

I hope you can help me with this issue. Any guide will be welcome

Aprendiz de códigos

Last Edited: Thu. Sep 5, 2019 - 04:20 AM