No connection to Duet-Wifi

dc42 · 22 Jul 2017, 07:54

To check that the SD card can be read, run M503.

You can also use M98 to run other macros, e.g. M98 Phomeall.g

If the Wireshark trace is short, post it here as ascii. Otherwise put the .pcap file on a file sharing site and post a link to it.

We know that the pre-1.19 WiFi module firmware used to crash repeatedly for a very small number of users. The same Duet would work perfectly when attached to one network but crash when connected to a different network. We never tracked this down because we couldn't reproduce it. The version 1.19 WiFi firmware is largely rewritten, uses very little of the ESP8266 Arduino core, and shifts most of the server functionality to the main processor of the Duet where we can track down any issues much more easily.

HTH David

fma · 22 Jul 2017, 09:46

Ok, I see. pcap file is here:

https://sys.gbiloba.org/owncloud/index.php/s/wXQK1JBNIyaoRNm

But I'm now in troubles: I tried to totally erase the firmware, using the erase button, but I'm unable to flash it again! I tried to use bossa, a free linux tool (still waiting from Atmel web site for their soft, but I don't get any notification once registered. When things go wrong…). The strange thing is I still have /dev/ttyACM0 port, but nothing related to bossa.

[2634139.039937] usb 5-1: New USB device found, idVendor=03eb, idProduct=6124
[2634139.039941] usb 5-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[2634139.043067] cdc_acm 5-1:1.0: ttyACM0: USB ACM device

But I'm also unable to send gcodes on this port, so I think there is no more firmware in the flash…

fma · 22 Jul 2017, 10:43

Ok, I was able to flash again the firmware using Atmel tool. But it didn't fix the com problem.

I tried to enable telnet and ftp. Only ftp works; telnet does not answer neither.

Strange thing: after the telnet connexion, I initiate a new web connexion, and I got:

12:39:43.153 : New conn on socket 0 for local port 23 <<<<<<<
12:39:43.153 : HTTP connection accepted
12:39:43.155 : Found responder
12:39:43.155 : Received 404 bytes
12:39:43.159 : Sending reply, file = yes
12:39:43.162 : HTTP req, command words { GET / HTTP/1.1 }, parameters { }
12:40:04.388 : Client disconnected on socket 0
12:40:04.388 : Can't send anymore

Port number seems to be wrong (I think it is only in debug message).

fma · 22 Jul 2017, 10:49

Arrgglll!!!! I made a test with a windows machine, running firefox, and it works!!!

WTF? Why firefox nor chromium does not work from my linux machine???!!???

dc42 · 22 Jul 2017, 11:37

If you get a Wireshatk trace from the Windows machine too, perhaps we be able to spot the difference.

fma · 22 Jul 2017, 12:24

If all my problems are related to the wifi module, it would be better for me to switch to the ethernet version.

Is it possible to make an exchange?

fma · 24 Jul 2017, 05:05

Here is the pcap file recorded from a Windows machine:

https://sys.gbiloba.org/owncloud/index.php/s/DssgVCz78OtqBGq

dc42 · 24 Jul 2017, 06:38

@fma:

If all my problems are related to the wifi module, it would be better for me to switch to the ethernet version.

Is it possible to make an exchange?

That will depend on the policy of whoever you purchased it from and/or consumer rights legislation in your country.

dc42 · 24 Jul 2017, 11:38

@fma:

Here is the pcap file recorded from a Windows machine:

https://sys.gbiloba.org/owncloud/index.php/s/DssgVCz78OtqBGq

Thanks. The traces show that your Windows PC uses an MSS of 1460 and your Linux machine uses 1452. If I set the MTU on my Windows machine to 1492 instead of 1500, this forces the MSS to 1452 as it is on your Linux machine, and I get similar connection problems. So it appears that the TCP/IP stack on the WiFi module is failing to auto-negotiate the MSS.

I will look into this. If all else fails, I can rebuild the TCP/IP stack using maximum MSS of 1452 instead of 1460. Meanwhile, if your Linux system allows you to use an MSS of 1460, that may work around the problem.

dc42 · 24 Jul 2017, 12:25

I think I found the cause: this bug in LWIP http://savannah.nongnu.org/bugs/?func=detailitem&item_id=46384. It's been fixed, so with luck we just need to update the version of LWIP we are using.

fma · 24 Jul 2017, 12:32

That's great news!

Do you think this can also be the source of crashs with the 1.18 and previous firmwares, where code is entirely managed by the ESP? If you apply the patch in this branch too, I can make some tests…

Thanks for your support.

fma · 24 Jul 2017, 12:36

I will also see if I can use a MTU of 1500, instead of 1492 (I think I reduced it to handle ssh connexions, but I'm not sure if I need it anymore, as I changed my router, and OpenWRT version).

dc42 · 24 Jul 2017, 12:50

Please try this preview of DuetWiFiServer 1.19beta10: https://dl.dropboxusercontent.com/u/19369680/DuetWiFiServer.bin. If you don't have networking functional at present, you will need to copy the file into /sys on your SD card, put the SD card back in the Duet, restart the Duet, and run M997 S1 from USB or PanelDue. Then wait until the blue light on the wifi module stops flashing.

My windows machine now connects with an MSS of 1452.

I can't easily make that patch to the older version of DuetWiFiServer, because that version used a build of lwip pre-compiled by Expressif. In any case, we have no interest in going back to that version because the newer version offers a number of advantages, such as FTP and Telnet support.

fma · 24 Jul 2017, 13:29

I test this this evening…

No problem for the 1.18; it was just a suggestion.

fma · 24 Jul 2017, 16:34

Ok, all works fine with a MTU 1500: I can have access to the duetwifi, and ssh connexions still work! And the test firmware you linked works fine with a MTU 1492.

Good! Let's start playing with this great tool

Thanks again for the support.

dc42 · 24 Jul 2017, 17:53

I'm glad to have been of assistance.