Windows Reserved DHCP and Meraki AP

[3h50]

Having issues with 1.2.1. With DHCP it is able to connect to a WPA network fine. Create a reserved DHCP address and the device will connect fine the first time, then if you reset it it can never get the IP address. Loaded up Wireshark and the client (Arduino) rejects the reserved IP address stating it is already on the network (it's as if it's quickly connecting, then checking to see if its in use, then rejecting it itself.) . This is repeatable across 4 Wifi Rev 2 arduinos, and works fine as long as there is no reservation, as it just takes a different IP.

It also works with a static IP just fine.

If you change the reservation to one IP higher it also will connect find, but reboot it and it once again floods the network(not really floods I have a connection delay) trying to get an IP and rejecting the reserved IP it was offered, as if a phantom of the old IP is in memory or something somewhere. Which makes no sense.

[sandeepmistry]

Hi @mrarmyant,

Would you be able to try again but with the v1.2.2 firmware bundled with the hourly IDE? https://www.arduino.cc/en/Main/Software#hourly

If it still happens, could you please provide your Wireshark capture as an attachment to a comment on this issues. Thanks.

[3h50]

I did, and it is still an issue. Attached is the DHCP dump. Had to rename the file from .pcapng to .txt for posting.
Capture DHCP.txt

[3h50]

How do I get the status changed from awaiting feedback?

[sandeepmistry]

Hi @mrarmyant,

I think this issue is related to: https://www.esp32.com/viewtopic.php?t=7431

Would it also be possible to get another Wireshark capture with ARP packets included?

In the meantime I'll think of a way to reproduce this locally. So I can try the suggested fix of setting CONFIG_LWIP_DHCP_DOES_ARP_CHECK from yes to no in the Espressif IDF SDK and make sure the fix works.

How do I get the status changed from awaiting feedback?

This is not something you can do, when a maintainer of the project checks the issue they need to manually clear the Github label.

[3h50]

Hi @mrarmyant,

I think this issue is related to: https://www.esp32.com/viewtopic.php?t=7431

Would it also be possible to get another Wireshark capture with ARP packets included?

In the meantime I'll think of a way to reproduce this locally. So I can try the suggested fix of setting CONFIG_LWIP_DHCP_DOES_ARP_CHECK from yes to no in the Espressif IDF SDK and make sure the fix works.

How do I get the status changed from awaiting feedback?

This is not something you can do, when a maintainer of the project checks the issue they need to manually clear the Github label.

I'll try to get the ARP packets today, it's on our company's internal network so I have to have someone else sanitize and approve it being sent out. This sounds exactly like the problem though and I know I've seen ARP packets being sent in the mix of this. It's a Windows DHCP server which might make it a minority issue as far as being a production environment (seems most I deal with are cisco based.)

If you cant reproduce it locally but can send me the compiled firmware I would be happy to test it out.

Thanks for the tip on Git Hub! Was just making sure I wasn't doing something wrong.

[3h50]

All of the ARPs. Every couple of days there seems to be a glitch or something and they connect, upon reset it starts the failure loop over.

arpdump.pcapng.zip

[sandeepmistry]

Hi @mrarmyant,

If you cant reproduce it locally but can send me the compiled firmware I would be happy to test it out.

Thanks for offering to try it out, I've opened pull request #17 with an attached binary that is zipped up.

You can try it by replacing the IDE's bundled NINA_W102.bin firmware file and running the updater. For example on macOS it would be /Applications/Arduino.app/Contents/Java/tools/WiFi101/tool/firmwares/NINA/1.2.2/NINA_W102.bin

Let me know if this makes sense. Looking forward to your feedback!

[3h50]

Got it copied, renamed it to NINA_W102.bin (and renamed the other as a backup) and no dice. However before I renamed it I loaded the firmware tool and it didn't list an additional firmware from when it was named "NINA_W102 2.bin" before I unzipped the .cpgz. So not entirely sure it's getting the correct firmware. To confirm it was pulling new 1.2.2 firmware I deleted all of the .bin files, loaded the firmware tool, and it is still showing 1.2.2 as an option, though it might populate this drop down from the folder structure. Basically the flash didn't fix it, but I'm not entirely sure it flashed the new bin :p

[3h50]

Tried to flash no firmware in the folder, its looking specifically for NINA_W102-UniWiFe_Rev2.bin so I'm going to rename it that and try.

[3h50]

Confirmed it wrote the new firmware. And, wait for it, VICTORY.

[sandeepmistry]

@mrarmyant awesome news!

My bad, I missed that you were using the Uno WiFi Rev2, I'll attach a binary for that in the pull request now. (Just to note, BLE features won't work with the binary your renamed).