Problem with networking and DWC



  • Back in Feb 2020 I decided that I would get an Duet 2 Ethernet board. Since then, I did get the board, and I'm in the early stages of setup. I want to use it for an FolgerTech FT-5 printer.

    I connected with USB to my bench computer. I seem to be able to get the board to respond to commands sent from YAT over USB. The computer is running Windows 10 and seemed to automatically recognize the printer and set it up on COM4 nicely.

    I issued the M552 command and got back from the Duet board that the network was enabled, and the address was 192.168.1.14. Since I'm currently in a test environment, it was very easy to just tell the bench router to route 192.168.1.0/24 and reside at 192.168.1.254.

    I ran the M553 command and got back the subnet mask was 255.255.255.0 Perfect.

    I ran the M554 command and got back the gateway as 192.168.1.255. For a while, I left it like that, and later I changed the gateway to 192.168.1.254.

    The problem is, the board is not responding on the ethernet network. When I look at the status lights on the network jack, I have a solid yellow link light, and the green activity light flashes from time to time. The router also lights up its light for the port that the Duet board is plugged into. That all looks good.

    The problem is first illustrated by just pinging 192.168.1.14 from the computer's command prompt. I get no replies. The second illustration is when I point a web browser to 192.168.1.14, and it times out trying to connect.

    I am presuming that the board should respond to pings. All symptoms are the same regardless of whether the gateway is set to .254 or .255

    I also sent the M586 command and got back that HTTP was enabled on port 80, and that FTP and Telnet were disabled.

    As for the board itself, this is what is says when asked about its firmware levels with M115:
    FIRMWARE_VERSION: 2.03
    Duet Ethernet 1.02 or later
    FIRMWARE_DATE: 2019-06-13b2

    I've run out of ideas to try for now, unless perhaps flashing in newer firmware is the way to approach this. So far, I have not done that at all; the board is still just as shipped a couple of months ago.



  • @bjackson said in Problem with networking and DWC:

    All symptoms are the same regardless of whether the gateway is set to .254 or .255

    .255 is the broadcast address, so you'll have to stick with .254 for a gateway

    what is missing is which network are you trying to connect from? if a network different than 192.168.1.0/24 I'm not sure the duet would work unless you ran NAT on the 192.168.1.254 gateway

    board should respond to ping if everything is working properly.

    i doubt updating the firmware will have any effect on the issue, but as you'll want to update to at least 2.05.1 you might as well; from 2.03 its just put the firmware binary in the /sys folder of the SD card and run M997

    can you have your router ping the Duet to rule out any issues with routing to/from the your client computer?



  • The bench setup is quite simple. It's a Netgear SOHO router with a public IP on the WAN port, and the two devices (the Duet board, and the computer) plugged into LAN ports. The computer is getting it's address by DHCP, and it currently resides at 192.168.1.100.

    If things were working as hoped, I should be easily able to ping the .14 host from the .100 host. There is no way to starting pings from the router. The computer at .100 is getting out on the Internet just fine, so it's talking to the router and beyond.

    I tried to get the Duet board to use DHCP as well, but I never saw that actually work. If it did, the board would probably be given the .101 address.

    When this is all working, a static address is what is preferred.

    It sounds like from what you said that the firmware in the board right now is not awfully old. Since I'm new to this board, I'd really prefer not to mess around trying to update firmware because I might brick something. Better to wait until I'm more familiar and confident with the hardware.

    Are there any hardware jumpers someplace that I need to look at? With this thing "almost working", with the link & activity lights behaving normally and all, I also have to consider the chance that I just got a bad board.



  • @bearer
    One other thing to mention:

    When I connect via USB using YAT, besides the firmware info line, I also get:

    Executing config.g...Error: Bad command; FOR TESTING ONLY! Use https:/configurator/.reprapfirmware.org/ to generate configuration

    Warning: Heater 0 appears to be over-powered. If left on at full power, its temperature is pr

    Now all that my be normal enough insofar as I've done absolutely nothing yet to try and configure things for the printer. I have never yet even touched config.g

    In fact, nothing is connected to the board yet except the USB cable and the ethernet cable.



  • The bench setup is quite simple.

    oh, right "everything" is on the same router and subnet, sounded more complex, my bad!

    indeed the .100 host should be able to connect to the .14 host; you shouldn't have to specify gateway on the duet.

    @bjackson said in Problem with networking and DWC:

    because I might brick something.

    nah, worst case scenario you have to use bossa or sam-ba to recover over usb, but the chip has bootloader in ROM so unless you wire something wrong you can't brick the board.

    Are there any hardware jumpers someplace that I need to look at?

    no, the there is just he 5v enable and erase jumper, the latter you don't use unless you need to recover the firmware the first is in the correct position if the board works from Vin.

    Bad command; FOR TESTING ONLY!

    that just means you haven't replaced the config.g file on the sd card /sys/config.g to be exact. it contains the factory default config used in testing the board, warning about heater 0 is because of the same.

    until you do go to https://configtool.reprapfirmware.org/ to create your own config you could strip out all but M552 S1 P192.168.1.14 from the config.g file (or just M552 S1 if you want to try DHCP)


  • Moderator

    If you let it use DHCP does it show up on the router? Ideally you would leave the duet in DHCP and then reserve the IP at the router end. Setting static IPs leads to headaches down the road.

    Updating the firmware is nothing to fear generally. 2.03 is rather old at this point. 2.05.1 is the last in the line of RRF2 and is a good place to get accustomed to the firmware, but RRF3 is really the way to go due to the added flexibility and the fact that is where the development is now, so don't stay on old firmware too long, you'll just learn things you'll need to forget.



  • @Phaedrux
    Well, here is what I did: I gave the command M552 P0.0.0.0, and got an ok. I gave the command M552, and it came back with the report that the IP address was 0.0.0.0. If I understand how it's supposed to work, that should put the board in DHCP mode.

    Do I have to do something else to actually trigger the DHCP process, like a specific M command? I left it in that mode for at least 30 minutes, then did M552 again, but nothing had changed.

    I didn't power cycle the board because I'm assuming the original IP it says it had (192.168.1.14) was coded in the config.g file, and if I power cycled, then that would be reasserted.

    I guess I will go ahead and take the firmware to 2.05.1 for now, and then consider moving to 3.x.x soon. I need to have a better idea of how to prepare for a major change like from 2 to 3.

    As for static IPs and headaches, yes I know what you mean. I have had good luck managing this small network with a combination of static & dynamic addresses. My general rule is if it's nailed down, screwed down, or to heavy to move, it gets a static IP. If it's mobile (especially mobile enough to go visit other networks :), then it gets a dynamic address.



  • @bjackson said in Problem with networking and DWC:

    M552 P0.0.0.0, and got an ok. I gave the command M552, and it came back with the report that the IP address was 0.0.0.0. If I understand how it's supposed to work, that should put the board in DHCP mode.

    Missing S1 and P0.0.0.0 is not needed unless you've previously assigned another address.



  • Ah yes. Well I issued M552 S1 P192.168.1.102. It came back and told me the network was enabled, and IP addresses (both configured and actual) were 192.168.1.102.

    I tried to ping the printer from the computer, but no replies from the printer. I'm assuming that there is not a way to ping using the printer while interacting with the USB connection?

    Other than try the firmware update, I don't know where to turn. This all seems straightforward enough, and should "just work". When it does not, I have to start suspecting hardware. Maybe it's just something with that little ethernet daughter board plugged onto the mainboard. I guess I could try another one of those perhaps?


  • Moderator

    On a fresh boot M552 S1 will enable networking and assume DHCP and should grab an address. Have you tried without the P.0.0.0.0 yet?


  • Moderator

    @bjackson said in Problem with networking and DWC:

    Maybe it's just something with that little ethernet daughter board plugged onto the mainboard.

    You could try reseating it.

    Try a different cable? Different port on the router?
    Straight connection to the PC without the router? If you do that and assign each an IP address you should be able to communicate.



  • I carefully removed, inspected, and re-seated the ethernet daughterboard. No change. Everything looked fine mechanically.

    I eliminated the router and connected the printer to the computer directly with a brand new and different ethernet cable. At that time, both devices had static IP addresses. The printer reported it was at .14, and the computer .101.

    Pings still fail, and nothing come up when I point a browser there.

    Everything you can see by visual inspection seems fine. Jacks & plugs engaging properly, link lights on both end lighting up. Even with the direct PC to printer connection, I do see occasional flashes of the activity lights on both devices, but what I see there does not seem to correlate with anything I'm actually doing (like executing a ping command).

    I get the feeling that there's no actual network traffic happening to or from the printer. Without any actual connectivity, then the DHCP process can't work, and pings would of course fail.

    This still makes me worry about hardware failure.



  • @bearer said in Problem with networking and DWC:

    just put the firmware binary in the /sys folder of the SD card and run M997

    I went to here: https://github.com/Duet3D/RepRapFirmware/releases/tag/2.05.1

    From there I can download Duet2Firmware-2.05.1.zip

    When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".

    If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?

    If I have that right, then I'll try it to see if it has any impact on the networking issue. Now, I think I'm understanding the the board I have is capable of running later versions (3.x.x) of the firmware, but getting from 2.05.1 to that is not quite so simple as getting to 2.05.1 was from where I started.


  • administrators

    @bjackson said in Problem with networking and DWC:

    When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".
    If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?

    Correct.



  • @bjackson said in Problem with networking and DWC:

    I do see occasional flashes of the activity lights on both devices, but what I see there does not seem to correlate with anything I'm actually doing (like executing a ping command).

    would you be able to install wireshark on your computer and run it when the board is connected directly with a network cable to the computer?

    the flashes could be compute doing regular broadcasts or the duet trying to obtain a dhcp lease, wireshark shoud be able to show you which.

    @bjackson said in Problem with networking and DWC:

    When I look in that zip file I see among other files one called "Duet2CombinedFirmware.bin".
    If I understand the process, I can simply copy that bin file of about 411,236 bytes into the sys folder of the microSD card on the mainboard. When it boots up with that SD card so configured, I can then just execute the M997 command?

    Yes, that'll take care of the RepRapFirmware. To upgrade to 3.1.1 you'll need to repeat the steps with the adittion of getting both Duet2CombinedIAP.bin and Duet2CombinedFirmware.bin from of Duet2and3Firmware-3.0.zip and Duet2and3Firmware-3.1.1.zip., and run M997 after each set of files. (the extra steps compared to 2.05.1 is you need to first update to 3.0.0 and the inclusion of the Duet2CombinedIAP.bin file)

    Then to finish it off you should update the web interface by getting all the files from DuetWebControl-SD-3.1.1.zip and put into the /www directory on the SD card.



  • So far, I've been unable to get the board from 2.03 to 2.05.1. I copied three files from the software repository to the sys folder on the SD card. They were:
    Duet2CombinedFirmware.bin
    DuetWiFiServer.bin
    iap4e.bin

    Put the card back, powered up, ran M997 S0:1

    I get the warning that the serial interface will be shutdown for a firmware upgrade, and that I should check back in 30 seconds. I gave it the time, and then gave the M115 command to see if the firmware level had changed. It still reports 2.03. Also tried a reset to see if that helped, but it did not.

    Also, no progress so far on getting the networking to function. I really don't expect a minor firmware update to fix it, but I wanted to at least get started advancing the firmware.


  • Moderator

    Odd that the firmware didn't succeed.

    Did you place those files in the /sys folder or the root? It should be in the /sys folder. Those files would already exist in the /sys folder for the current 2.03 version, so if you didn't replace them, when you sent the command to update, it may have just been using the same 2.03 version to flash.

    DuetWifiServer.bin isn't needed as you have an ethernet board but it being there shouldn't matter.

    Can you try one more time on the firmware update using M997 S0 only? The S0:1 would be for the main firmware and wifi firmware.

    Can you list the contents of the /sys folder? Perhaps you're missing a different iap file.

    On the networking front, wireshark would be a good test at this point.



  • On the matter of firmware:
    OK, sure. Here's what's in the sys folder:
    bed.g cancel.g config.g Duet2CombinedFirmware.bin, iap4s.bin
    DuetWiFiServer.bin, homedelta.g iap4e.bin pause.g
    resume.g sleep.g stop.g test1log.txt test2log.txt
    test3log.txt test4log.txt tfree0.g tpost0.g and tpre0.g

    BTW, here is what's actually in test3.log.txt:

    2020-05-21 14:46:40 Event logging started
    2020-05-21 14:46:40 HTTP client 192.168.1.134 disconnected
    2020-05-21 14:46:44 HTTP client 192.168.1.134 login succeeded
    2020-05-21 14:47:14 Event logging stopped

    That seems to suggest that in testing it did communicate with a host that was at .134

    I re-ran the firmware update command, this time with only the S0 after the M997. It still comes back stuck at 2.03 for some reason. I wonder if I really have the right content in the firmware binary. The file is named Duet2CombinedFirmware.bin, and reports a time stamp of 02/09/2020 @ 05:25. The files is 411,236 bytes, and 413,696 on disk.

    On the matter of networking:
    I got a different computer (just in case in some wild way that mattered) and continued testing. I installed Wireshark, fired it up, and executed "ping 192.168.1.14". That put some content in the Wireshark display, but I didn't see a single thing in the packet capture that was sourced from the computer. What I saw was a ARP request saying "Who has 192.168.1.14", but nobody replied.

    I have emailed Filastruder and asked for an RMA, starting with the little ethernet daughter board. I feel like I really need to try to do something to prove or eliminate hardware failure as a possibility.


  • Moderator

    Just to be sure you could download this one and place it in /sys and give it one more try.

    https://github.com/Duet3D/RepRapFirmware/releases/download/2.05.1/Duet2CombinedFirmware.bin

    And just in case, grab these two iap files and place them in /sys as well, over write what you have in there already.

    https://github.com/Duet3D/RepRapFirmware/releases/download/2.03/iap4e.bin

    https://github.com/Duet3D/RepRapFirmware/releases/download/2.03/iap4s.bin

    What device is .134?


  • Moderator

    @bjackson said in Problem with networking and DWC:

    I have emailed Filastruder and asked for an RMA, starting with the little ethernet daughter board. I feel like I really need to try to do something to prove or eliminate hardware failure as a possibility.

    If we can't get it figured out, yes we will get it exchanged. It's just very rare for an ethernet to fail to connect for hardware reasons, though not impossible.

    Could you provide some close up photos of the module and board area?



  • I obtained those three files and put them in the /sys folder, overwriting whatever I might have had with the same names. It still comes back from M115 reporting no change in the firmware version. After it recovered from the supposed firmware update, I checked, then I powered down the board, re-energized it again, and checked again. Still no change.

    BTW, at this time, I don't have the printer power supply on. The board is being powered via USB. I presume that's enough power available to run the ethernet too?

    As for device .134, I can only guess. I did not create those testlog files, but I assume somebody did who was doing final QC on the equipment before releasing it for distribution. I would assume it was a computer they used to test network connectivity to the board. It seems to say that it worked at one time.

    I have attached a couple of photos. I even got one that actually caught the green activity light on the ethernet jack on for a quick flash. You can barely make out the orange glow from the link light on the other side of the plug retainer.close-up-of-ethernet-board.jpg )oveerall-view.jpg


  • Moderator

    @bjackson said in Problem with networking and DWC:

    The board is being powered via USB. I presume that's enough power available to run the ethernet too?

    Normally it would be. Perhaps your supply can't keep up? Have you tried applying VIN yet?

    @bjackson said in Problem with networking and DWC:

    I assume somebody did who was doing final QC on the equipment before releasing it for distribution.

    Yes, of course. I was being dense.


  • Moderator

    It was also suggested to me by someone far more on the ball than me that there might be an issue with auto negotiation, so see if your router/switch has the option of forcing the link to 100 full duplex.



  • Have you tried applying VIN yet?

    Yes, I did try that. That doesn't change the behavior I'm seeing. The computer who's USB port is powering the board for these tests is a very standard Dell Optiplex 755 desktop machine.

    I left things up over night and looked again at the packets that Wireshark had captured. All I'm seeing is IPv4 and IPv6 packets coming from the computer, and nothing coming from the Duet.

    The auto-negotiation issue was considered. Right now, I'm using the super simple test environment of the computer connected to the Duet board with an ethernet cable. The router is not involved currently.

    I went into the speed/duplex settings for the network card on the computer and experimentally set it to 100 half, and 100 full. Those choices did not work, but in fact made the error messages seen when trying the ping command to be more severe 🙂 I put it back to Auto.


  • Moderator

    @bjackson Can you try the Duet again directly connected to your PC? Assuming the PC isn't connected to any other network, you only need to set the ethernet adaptor's IP address and subnet mask, and the Duets IP address and subnet mask. If the PC is connected to another network through another adaptor (WiFi or wired), you just need to make the Duet/PC network sufficiently different. See https://duet3d.dozuki.com/Wiki/Setting_up_networking_on_Duet#Section_Wired_direct_connection for full details.

    Are you actually editing the config.g with the new settings, or typing them in through a serial console (eg YAT) over USB? The settings you used in your original post come from the standard SD card contents: https://github.com/T3P3/Duet/blob/master/Duet2/SD Card Contents/sys/config.g

    I can't remember if changing network settings take immediate effect, or if it's better to disable the network, change the settings, then enable network. But it may be worth trying in this order.

    Finally, check the SD card has a www folder, which should contain the files for the Duet Web Console (DWC). See here for the folder structure and contents: https://duet3d.dozuki.com/Wiki/SD_Card#Section_Creating_the_file_structure

    Ian


Log in to reply