Bad arg length error when other devices request DHCP during stage 1

[bkpsu]

When the script is running through stage 1 (DHCP Discovery), if other devices send DHCP requests at the same time, the script sometimes fails with the following error:

"
DHCP Discover cc:50:e3:d5:90:fd 10.44.57.19
DHCP Discover cc:50:e3:d5:90:fd 10.44.57.19
DHCP Request cc:50:e3:d5:90:fd 10.44.57.19
DHCP Discover a0:20:a6:0d:e1:bd
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157, <$fh> line 28.
Exiting....
Shutting down...
"

In this case, device with the MAC cc:50:e3:d5:90:fd is the target device (ZOOZEE SA101 plug), while a0:20:a6:0d:e1:bd is another ESP sensor (waking up from deepsleep). Stage 1 did complete, and I was able to continue with stage 2 and complete the flash satisfactorily!

[SynAckFin]

Thanks for that
It seems the plug sends half a DHCP packet and when the built in DHCP server tries to interpret an IP address in the packet it crashes out because it is to short.

[axiom00]

Thanks SynAckFin for all the great work!

I ran into the same error flashing a Teckin SP20 plug. First plug flashed without issue, while the second encountered the Bad arg length error. I reran a few times and it eventually bricked the plug. As stated by bkpsu, the mac address in the log below belongs to another device on my network and not the SP20 plug.

What do you think is the best way to avoid other devices sending a dhcp request and causing the script to error out? I have an old router that I can setup just for the raspberry pi and the target device to be flash.

...
URL: /gw.json?a=s.gw.dev.update
Response: HTTP/1.1 200 OK
{"t":1547677229,"e":false,"success":true}
DHCP Discover 00:15:5d:17:8d:0e
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157, <$fh> line 18.
Exiting....
Shutting down...

[bkpsu]

@axiom00 - are you sure the plug was bricked? In my case, I did end up getting the two ..."e":false,"success":true... statements, and was able to continue with stage 2. It might be worth running the script again with the "-b 2" option just to see if it works...

Also, good idea for a workaround (using a dedicated router/guest SSID)!

[axiom00]

@bkpsu - I am 90% sure it was bricked. After running the script a few times without -ip, the script wasn't able to detect the plug and my router no longer show the leased ip. Pressing the button did not activate the LED or relay. I also tried factory resetting it by holding down the button for 5 seconds, but nothing happened.

Unfortunately I returned the plug today so I can't try your suggestion.

[SynAckFin]

@axiom00 Hopefully I've fixed the DHCP issue.
Your device might not be a brick. Use you phones WiFi and look for Access Points called "FinalStage" or "Sonoff-XXXX" where X are numbers.

[axiom00]

@SynAckFin I tried the updated script to fix the DHCP issue and still getting the error. I am weary to run it with the -ip and bricking. Any thoughts?

$ sudo ./tuyota.pl
Getting interface into stable state
RTNETLINK answers: Cannot assign requested address
Done
Using WiFi device wlan0 for Access Point
Starting Access Point with SSID ZAGDU-789
Giving Access Point IP address 10.44.57.1, pid is 808
**** New device detected. ID: 88020554cc50e3cf22f9 IP:192.168.10.145
DHCP Request 40:98:ad:9e:d9:70 10.44.57.214
DHCP Request 80:be:05:37:43:0c
80:be:05:37:43:0c: Unknown host
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157, <$fh> line 5.
Exiting....
Shutting down...

[SynAckFin]

Think I've found what the problem was.
A bug meant that all the DHCP leases were handed out to the first device to ask for one so when a second device tried to get one there were no more leases and it was given a blank IP address,
As long as you don't have 255 devices all asking for a lease at the same time this should be fixed.