had final stage for a minute, now gone.

[AndyRPH]

So the first of two Hyleton-311's went fine. Running tasmota nicely now. The second one no luck. I got to see a final stage AP, but a couple cycles of the script and power cycling the device and no luck. Now i lost the final stage ap, it isn't response to holding the button to factory reset, however, when i run the script, it does see a device request a dhcp. Nothing ever comes of it though. The script eventually goes to listen to final stage, and then closes when it gets no reply. toggling the power on the device gets it to send another dhcp request. No devices are ever listed as found by the script.

Thats really puzzling considering how cut and dry the first one went and it was successful.

[sylvandb]

If it was once transmitting as FinalStage it was running the intermediate firmware. I don't know what the button would do there, but I suspect nothing.

If you are seeing a device request a DHCP, it isn't from the intermediate firmware.

About the only thing the intermediate firmware can do is transmit as FinalStage and wait for someone to connect and send new firmware. Maybe that happened. Do you see anything transmitting as sonof-#### ?

If you can check using your phone, you might still see FinalStage, or maybe sonoff-####. Maybe your system running the script needs rebooted.

[AndyRPH]

Yeah rebooted the pi3b+ running the script and no change. No ssids broadcast anymore. Not sure how the outlet would handle being unplugged and plugged back in if it was stuck at finalstage ssid being broadcast. It must be connecting to the ZAGDU ssid now since it's asking for dhcp, but then It never communicates. Going to let the script run overnight and see what's what.

[SynAckFin]

Use your phone to search for WiFi hotspots. If you see a "FinalStage" or a "Sonoff-XXXX" then that is your device. If its Sonoff-XXXX then connect to it with your phone, open a browser and go to 192.168.4.1 Make sure that wpa_supplicant is not running on the Pi as that will interfere with the process. If it is running it can prevent the Pi from seeing the FinalStage/Sonoff-XXXX access points.

[AndyRPH]

Yeah neither ssid shows.

[SynAckFin]

Can you run the following command from the same directory you run the script from?

sudo hostapd hostapd.conf Then power on the device. If you see something like this:

wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated
wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx
wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 5C45B774-00000000

Then that does mean the device is connecting to the ZAGDU-789 access point. If that is the case then in another terminal run the following:

sudo tcpdump -n -s0 -i wlan0 port 67 or port 80 or port 8080 or port 1883 or arp

and let me know what the traffic is.

[AndyRPH]

No luck: didn't see wpa supplicant running either.

pi@raspberrypi:~/tuya/TuyOTA $ sudo hostapd hostapd.confConfiguration file: hostapd.conf Failed to create interface mon.wlan0: -95 (Operation not supported) Could not set channel for kernel driver Interface initialization failed wlan0: interface state UNINITIALIZED->DISABLED wlan0: AP-DISABLED wlan0: Unable to setup interface. wlan0: interface state DISABLED->DISABLED wlan0: AP-DISABLED hostapd_free_hapd_data: Interface wlan0 wasn't started nl80211: deinit ifname=wlan0 disabled_11b_rates=0 pi@raspberrypi:~/tuya/TuyOTA $ ps -fu root | grep wpa pi@raspberrypi:~/tuya/TuyOTA $

On Jan 21, 2019, at 7:31 AM, Terry Sanders notifications@github.com wrote:

Can you run the following command from the same directory you run the script from?

sudo hostapd hostapd.conf Then power on the device. If you see something like this:

wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 5C45B774-00000000

Then that does mean the device is connecting to the ZAGDU-789 access point. If that is the case then in another terminal run the following:

sudo tcpdump -n -s0 -i wlan0 port 67 or port 80 or port 8080 or port 1883 or arp

and let me know what the traffic is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SynAckFin/TuyOTA/issues/11#issuecomment-456058500, or mute the thread https://github.com/notifications/unsubscribe-auth/ArYhZHzO_MnHAqNPfwWgIXc1c4Up3U9sks5vFbMdgaJpZM4aKEhv .

[AndyRPH]

But I'll get this and another pair of dhcp notes every time I plug/unplug the failed plug.

pi@raspberrypi:~/tuya/TuyOTA $ 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 2129 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.73 DHCP Request b4:e6:2d:13:d1:ba 10.44.57.73

On Jan 21, 2019, at 7:31 AM, Terry Sanders notifications@github.com wrote:

Can you run the following command from the same directory you run the script from?

sudo hostapd hostapd.conf Then power on the device. If you see something like this:

wlan0: STA xx:xx:xx:xx:xx:xx IEEE 802.11: associated wlan0: AP-STA-CONNECTED xx:xx:xx:xx:xx:xx wlan0: STA xx:xx:xx:xx:xx:xx RADIUS: starting accounting session 5C45B774-00000000

Then that does mean the device is connecting to the ZAGDU-789 access point. If that is the case then in another terminal run the following:

sudo tcpdump -n -s0 -i wlan0 port 67 or port 80 or port 8080 or port 1883 or arp

and let me know what the traffic is.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SynAckFin/TuyOTA/issues/11#issuecomment-456058500, or mute the thread https://github.com/notifications/unsubscribe-auth/ArYhZHzO_MnHAqNPfwWgIXc1c4Up3U9sks5vFbMdgaJpZM4aKEhv .

[SynAckFin]

The DHCP messages could be red herrings. If you have any devices on your network sending DHCP requests the script will respond to the request.

You are using a Pi3b so can you confirm that it has a wired network connection? Can you run the following 3 commands and paste the output:

sudo iwconfig wlan0
sudo ifconfig wlan0
sudo ip link show wlan0

Then run the script like this:

sudo ./tuyota -ip <ipaddr> | tee /tmp/tuyota.log

and then attach the file /tmp/tuyota.log

[AndyRPH]

Oh I thought the DHCP requests only come In on the wlan, thus only on things connecting to the new ssid the script creates?

I'll run that this evening and post the log.

On Jan 22, 2019, at 7:52 AM, Terry Sanders notifications@github.com wrote:

The DHCP messages could be red herrings. If you have any devices on your network sending DHCP requests the script will respond to the request.

You are using a Pi3b so can you confirm that it has a wired network connection? Can you run the following 3 commands and paste the output:

sudo iwconfig wlan0 sudo ifconfig wlan0 sudo ip link show wlan0

Then run the script like this:

sudo ./tuyota -ip | tee /tmp/tuyota.log

and then attach the file /tmp/tuyota.log

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SynAckFin/TuyOTA/issues/11#issuecomment-456388571, or mute the thread https://github.com/notifications/unsubscribe-auth/ArYhZNUKVshOqBPnBDgmRUWYmlwC7BHKks5vFwmFgaJpZM4aKEhv .

[SynAckFin]

Oh I thought the DHCP requests only come In on the wlan, thus only on things connecting to the new ssid the script creates?

I had some issues just listening to the wlan interface so I had to listen on all. The responses are only sent out on the wlan so they wont interfere with other equipment.

[AndyRPH]

The DHCP messages could be red herrings. If you have any devices on your network sending DHCP requests the script will respond to the request.

You are using a Pi3b so can you confirm that it has a wired network connection? Can you run the following 3 commands and paste the output:

sudo iwconfig wlan0
sudo ifconfig wlan0
sudo ip link show wlan0

Then run the script like this:

sudo ./tuyota -ip <ipaddr> | tee /tmp/tuyota.log

and then attach the file /tmp/tuyota.log

pi@raspberrypi:~/tuya/TuyOTA $ sudo iwconfig wlan0 & sudo ifconfig wlan0 & sudo ip link show wlan0
[1] 1245
[2] 1246
wlan0     IEEE 802.11  ESSID:off/any  
Mode:Managed  Access Point: Not-Associated   Tx-Power=31 dBm   
Retry short limit:7   RTS thr:off   Fragment thr:off
Encryption key:off
Power Management:on

wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 ether d2:08:00:32:fe:84 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN mode DORMANT group default qlen 1000 link/ether d2:08:00:32:fe:84 brd ff:ff:ff:ff:ff:ff [1]- Done sudo iwconfig wlan0 [2]+ Done sudo ifconfig wlan0 pi@raspberrypi:~/tuya/TuyOTA $ sudo ./tuyota.pl | tee /tmp/tuyota.log Getting interface into stable state

No need to attach the log, it's small: 

pi@raspberrypi:~/tuya/TuyOTA $ sudo ./tuyota.pl | tee /tmp/tuyota.log Getting interface into stable state RTNETLINK answers: Cannot assign requested address 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 1281 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover 70:77:81:cb:97:0a 10.44.57.200 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover 5c:cf:7f:bd:95:c8 10.44.57.147 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 DHCP Discover 70:77:81:cb:97:0a 10.44.57.200 DHCP Discover b4:e6:2d:13:d1:ba 10.44.57.139 Shutting down... Setting up IP Address 192.168.4.2 for Final Stages Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Setting up wifi scan Setting up listener for FinalStage wlan0 Interface doesn't support scanning : Device or resource busy

Shutting down... Getting interface into stable state RTNETLINK answers: Cannot assign requested address Done Finished Exiting.... Shutting down... pi@raspberrypi:~/tuya/TuyOTA $

So:  The 5c MAC, b4 MAC, are both previously seen on my network as the tuya switches when i was using tuya's firmware.  Attempted to convert them over and wasn't successful.  the 70.. MAC is an amazon fire tablet that was used to get the tuya local key back when that was the best way for local control, but it's never been connected to the pi, so that's odd.   I never know what IP to enter as the ip parameter.  When I run this again, the same MACs appear, but get different dhcp discover addresses. Does that mean that they're connecting to my normal wifi and it's seeing that from over the wired lan connection, or is the pi reaching out to see if dhcp MACs it used to see are still hanging around? 

[AndyRPH]

pi@raspberrypi:~/tuya/TuyOTA $ sudo hostapd hostapd.conf
Configuration file: hostapd.conf
Failed to create interface mon.wlan0: -95 (Operation not supported)
Could not set channel for kernel driver
Interface initialization failed
wlan0: interface state UNINITIALIZED->DISABLED
wlan0: AP-DISABLED 
wlan0: Unable to setup interface.
wlan0: interface state DISABLED->DISABLED
wlan0: AP-DISABLED 
hostapd_free_hapd_data: Interface wlan0 wasn't started
nl80211: deinit ifname=wlan0 disabled_11b_rates=0
pi@raspberrypi:~/tuya/TuyOTA $ sudo hostapd hostapd.conf
Configuration file: hostapd.conf
Failed to create interface mon.wlan0: -95 (Operation not supported)
wlan0: Could not connect to kernel driver
Using interface wlan0 with hwaddr 36:ae:89:72:79:8d and ssid "ZAGDU-789"
wlan0: interface state UNINITIALIZED->ENABLED
wlan0: AP-ENABLED 

Nothing showed on the other terminal.

pi@raspberrypi:~ $ sudo tcpdump -n -s0 -i wlan0 port 67 or port 80 or port 8080 or port 1883 or arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: pcap_loop: The interface went down
0 packets captured
0 packets received by filter
0 packets dropped by kernel
pi@raspberrypi:~ $ 

commands look good, since it does generate data on both terminals if i then connect to ZAGDU with my iPhone.

[SynAckFin]

So: The 5c MAC, b4 MAC, are both previously seen on my network as the tuya switches when i was using tuya's firmware. Attempted to convert them over and wasn't successful. the 70.. MAC is an amazon fire tablet that was used to get the tuya local key back when that was the best way for local control, but it's never been connected to the pi, so that's odd. I never know what IP to enter as the ip parameter. When I run this again, the same MACs appear, but get different dhcp discover addresses. Does that mean that they're connecting to my normal wifi and it's seeing that from over the wired lan connection, or is the pi reaching out to see if dhcp MACs it used to see are still hanging around?

Any DHCP Discover you see means that that particular device is on your network or the ZAGDU-789 access point. If you don't see a DHCP Request after the Discover then that means the request more than likely came in through the hard wire and not the WiFi.

If you stop my script and run the following:

sudo tcpdump -n -s0 -i eth0 port 67

and you see repeated requests from the same ether address then that means you have devices on your network that are trying and failing to get an IP address. Do you have a DHCP server that you have disabled?

[AndyRPH]

It looks like they're all on my network. But they aren't showing up when i browse to their IP, nor search with tasmota device manager plugin for HA. So if I know I can ping ESP devices on my network, is there a way to interact with them and then finish the firmware flashing? I kind of feel like they all got hung in-between one of the stages now that I can see them on my network, but can't see them running tasmota. What connectivity is there if they're running on of the intermediate firmwares?

[SynAckFin]

They are not showing up because they don't have an IP address yet. There are 2 stages to any device connecting to your network. The first stage is to join the WiFi network and for this they need the SSID and password. The second stage is to obtain an IP address and this is what you are seeing them attempt to do. Usually on a home network the router from your service provider handles all the IP addressing via DHCP so unless you have your own DHCP server that is the first place you should look. The good news is that the devices must completed the firmware install and be running tasmota.

[AndyRPH]

I've actually got them all with IPs now, but there's just nothing at their web address, whereas my successful tasmota's (2), all give me the expected tasmota web interface.

On Jan 25, 2019, at 5:01 AM, Terry Sanders notifications@github.com wrote:

They are not showing up because they don't have an IP address yet. There are 2 stages to any device connecting to your network. The first stage is to join the WiFi network and for this they need the SSID and password. The second stage is to obtain an IP address and this is what you are seeing them attempt to do. Usually on a home network the router from your service provider handles all the IP addressing via DHCP so unless you have your own DHCP server that is the first place you should look. The good news is that the devices must completed the firmware install and be running tasmota.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/SynAckFin/TuyOTA/issues/11#issuecomment-457520282, or mute the thread https://github.com/notifications/unsubscribe-auth/ArYhZOE42Ak528VTaoeaFyhuqSiE9OiBks5vGtXvgaJpZM4aKEhv .

[SynAckFin]

Open a terminal and run the following:

nc -u -l -k -p 6666 | strings

Leave it running and if any of the devices are still running tuya firmware then output will appear.

In another terminal run the following:

sudo nmap x.x.x.x

Change x.x.x.x for the IP address of one of the devices. In a third terminal run the following:

tcpdump -n -s0 ether host b4:e6:2d:13:d1:ba

Change the ethernet address to one of the devices.

nmap might take a while but it will tell you what ports the device is listening to. The tcpdump will only capture broadcast messages but it may tell you who or what the device is trying to talk to.

[AndyRPH]

Was able to get in touch with them all! Thanks.