FINAL (I hope) RRF 1.20 release candidate 4 and DWS 1.20RC1

okercho

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.120

Starting 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.

Gosu

this version made the wifi module much more stable i still get ocassional disconnects but im always able to reconnect

Thanks a lot

dc42

@okercho:

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.120

Starting 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?

dc42

@Gosu:

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!

okercho

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

@dc42:

@okercho:

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.120

Starting 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?

dc42

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.

okercho

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

@dc42:

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.

dc42

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.

okercho

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!

@dc42:

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.

KeeganB

Ok, I just updated to the latest RC's on all three. Lets see how it goes!