[BUG] DHCP Ethernet crashes after repeated switching of network interface [OPTA/Portenta H7] about arduinocore-mbed HOT 4 CLOSED

@Channel59 thank you for submitting this problem.
The patch should solve it. I have just a couple of remarks about the way you replicate the problem:

1. your DHCP server must be configured in a way that the OPTA gets always the same ip address (so that at a certain MAC address is always associated the same ip address). Otherwise OPTA could be assigned a different ip address and you so fail the ping because you are using the wrong IP address (the old one).
2. DHCP assign address could take a bit so it is maybe useful to wait just a little after the interface goes up, before to ping again the device
   Thanks!

from arduinocore-mbed.

Dear @maidnl,

Thank you very much for taking the time to investigate this problem. I agree with your remarks regarding the replication of the problem.

I have tested your patch and it seems like the issue is partly resolved.
After applying this patch on ArduinoCore-mbed 4.0.10 and the mbed-os-arduino 4.0.10, it seems that the network interface of the opta does not get stuck after the first iteration of the shell script to test the Opta.

However, the opta can still become unresponsive quite easily, using e.g. this code:

#include <Arduino.h>
#include "EthernetInterface.h"
#include "mbed.h"
auto net = EthernetInterface::get_default_instance();

void setup(){
    net->set_blocking(true);
    net->set_dhcp(true);
    net->connect();
}

void loop() {
    rtos::ThisThread::sleep_for(1000);
}

and by simply using this commands (or unplugging the ethernet cable for 3 seconds and re-plugging it):

sudo ifconfig eth0 down && sleep 3 && sudo ifconfig eth0 up

This is already enough to break it, however re-running this will also restore the connecition

With static IP there is no issue it seems.

or with this more elaborate script, including your wait time:

#!/bin/bash

opta=192.168.0.100
eth=eth0

for i in {1..2000}
do
        for j in {1..5}
        do
                t_down=$((500 + $RANDOM % 5000))
                t_up=$((1000 + $RANDOM % 2000))
                echo -ne "_"
                ifconfig $eth down
                ./usleep $(($t_down * 1000))
                echo -ne "\b-"
                ifconfig $eth up
                ./usleep $(($t_up * 1000))
                echo -ne "\b."
        done

        if (( $t_up<3000 )); then
                t_wait=$((3000 - t_up))
                ./usleep $(($t_wait * 1000))
        fi
	sleep 2
        if ping -c 1 $opta &> /dev/null
        then
                echo -n "|"
        else
                echo "X"
                exit 1
        fi
done

(Use e.g. this for usleep: https://github.com/pklaus/usleep-binary)

In this case, another ethernet interface down/up from the host seems to resolve the problem and the opta starts sending DHCP requests again and obtains an ip.

It seems there is still something stange going on with the DHCP.

As a side-note, that may or may not be related, I have done some more testing of the Opta in the context of ethernet disconnect/reconnects, and have found an issue that is seems to be related UDP multicast (see:#904). I assume the DHCP uses somewhere under the hood also some UDP multicast socket, and thus these issues might be related / the same.

from arduinocore-mbed.

I have done a little bit of testing and it seems that this issue and also #904 are resolved with f97304b.

from arduinocore-mbed.

@Channel59 Thank you for test it, we hoped that this would fix this problem.

This issue is then closes thanks to commit 97304bffff1852de6ebf10ccbb941f431b70b16

from arduinocore-mbed.