FINAL (I hope) RRF 1.20 release candidate 4 and DWS 1.20RC1
-
Thanks. Perhaps this is an alternative to installing the WiFi firmware twice, which is what I did when it didn't work first time.
-
Hi there,
I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.
I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)I still have the printer on, in case you want me to execute something on it.
-
this version made the wifi module much more stable i still get ocassional disconnects but im always able to reconnect
Thanks a lot
-
Hi there,
I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.
I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)I still have the printer on, in case you want me to execute something on it.
Can you get a Wireshark trace of an attempt to to connect the browser?
-
this version made the wifi module much more stable i still get ocassional disconnects but im always able to reconnect
Thanks a lot
Thanks for the feedback!
-
Here you have it: https://www.dropbox.com/s/9z1pxu1v7rl1pd5/DuetWifiFiltered.pcapng?dl=0
I've filtered by source or origin equal the Duet IP, and I've confirmed before that the MAC address is the duet one.
- First you can see some errors
- then a ping (requests and replies, so the duet is there)
- then I tried a curl to http://DUET_IP, with no success (curl: (7) Failed to connect to 192.168.1.120 port 80: Operation timed out)
- then I tried with the browser, with same results
Nmap still says port is filtered.
Do you want me to execute something else before rolling restart the duet?
Regards
Hi there,
I put a little print last night, and it finished as expected. Ping is still working, although the web interface is not working anymore.
I've tested a few things and host seems to be up, but port 80 is filtered (??)
nmap -sV 192.168.1.120Starting Nmap 7.01 ( https://nmap.org ) at 2017-12-22 10:13 CET
Nmap scan report for 192.168.1.120
Host is up (0.0018s latency).
Not shown: 999 closed ports
PORT STATE SERVICE VERSION
80/tcp filtered http
MAC Address: 5C:CF:7F:XX:XX:XX (Espressif)I still have the printer on, in case you want me to execute something on it.
Can you get a Wireshark trace of an attempt to to connect the browser?
-
Thanks! Please can you connect via USB and get a M122 report. Then send M552 S0 followed by M552 S1 and see if you can connect after that, giving it time to connect to the AP. If not, send M552 S-1 followed by M552 S1 and see if that is any better.
That's all, so restart after that.
-
Here you have it: https://www.dropbox.com/s/w4j58dw8nk8a3lu/DuetLog.zip?dl=0
You will find 3 files:
- DuetLog-20171222: Contains the M122 report
- DuetLog-20171222-2: Execution of M552 S0 and M552 S1. After the S1 the web was accesible again… until I disconnected Pronterface to avoid the tons of "aux: M408 S0 R110" (clicking in disconnect), in that moment, web stopped working (but duet still answers pings)
- DuetLog-20171222-3: Execution of M552 S-1 and M552 S1. After clicking in "Connect" again, web came back again... however, after the S-1 and S1, log reported "incorrect password" and wifi never came back, even with a roll restart (after the roll restart it keeps saying wrong password).
I had to execute M552 S0 and S1 through panel due, and then it came back.
Makes sense to you?
Regards
Thanks! Please can you connect via USB and get a M122 report. Then send M552 S0 followed by M552 S1 and see if you can connect after that, giving it time to connect to the AP. If not, send M552 S-1 followed by M552 S1 and see if that is any better.
That's all, so restart after that.
-
If you were getting those aux:M408 reports from Pronterface, then a M111 S1 command has been executed at some point to turn debugging on. That could be responsible for the network issues too. Next time you get these issues, try sending M111 from PanelDue to report the current debug state. If any debugging is turned on, send M111 S0 to turn it back off.
-
Ouch!
Yes, my bad… when I updated to the RC, I enabled debugging in the config file... I've disabled it now.
Thanks a lot!
If you were getting those aux:M408 reports from Pronterface, then a M111 S1 command has been executed at some point to turn debugging on. That could be responsible for the network issues too. Next time you get these issues, try sending M111 from PanelDue to report the current debug state. If any debugging is turned on, send M111 S0 to turn it back off.
-
Ok, I just updated to the latest RC's on all three. Lets see how it goes!