DHCP: PicoTCP keeps discovering when going back to 'init' state about picotcp HOT 7 CLOSED

Actually, this happens in every case when the client goes back to init state.

from picotcp.

ROOT CAUSE:

• On mbed platform the dhcp_cb function adds a route to ip 0.0.0.0 which messes up the DHCP client during INIT state

if (gateway.addr != 0) {
pico_ipv4_to_string(gw_addr, gateway.addr);
eth_dbg("Default gateway assigned : %s\n",gw_addr);
pico_ipv4_route_add(zero, zero, gateway, 1, NULL);
}

DETAILED ANALYSIS:
-There are several conditions for the bug to occur and to be 100% reproducible on any environment:

1. The route to 0.0.0.0 needs to be added in the DHCP client callback function
2. The DHCP server needs to answer with OFFER using the broadcast address and not directly the IP (bug reproduced with dnsmasq; bug not reproduced with picoTCP DHCP server )
   -In the chronological order below is what happens:
3. ACK is received from the server. IP is registered. Callback is called with DHCP_SUCCESS and route to 0.0.0.0 is added but the IP in the link contains the IP registered.
4. Renew time expires. NAK received from server. Resetting the DHCP client and going to INIT state
5. In INIT state the DHCP client creates a 0.0.0.0 link and tries to add it to the route table -> FAIL because there already is this link; The return status of the route_add function is not checked to initialization continues
6. OFFER messages arrive but these messages are dropped. The current implementation of picoTCP socket allows broadcast messages to be received only if the linked IP is 0.0.0.0. Socket looks for the dest.addr in the IP link of the route table of destination 0.0.0.0 and the IP is the initial registered IP

SOLUTION PROPOSED:

• Remove the route present in the DHCP client callback function.

from picotcp.

Initial solution proposed has been dropped as the route is needed for the default gateway.

SECOND SOLUTION PROPOSED:

• clear the 0.0.0.0 route in the reset function of the dhcp client. Little probability of regression because in case the route is not found, initialization continues as normal. Also the route should not exist after init because a new IP might be received from dhcp server

from picotcp.

IMPACTED MODULES:

• pico_dhcp_client.c function reset
• call pico_ipv4_route_del to delete the route assigned to dest 0.0.0.0

TESTS:

• mbed and linux using dnsmaq as dhcp server -> OFFER messages are processed

Merged on both mbed and github

from picotcp.

After the fix, no discover messages are send by PicoTCP after he received the NAK.
Reproduce with:
sudo ./run.sh --test nackafterrequest testcases/hardware/dhcp_client_dora.txt
The test will fail with: "Sniff timed out after 40.00 seconds"

from picotcp.

The dhcp client callbacks us with a reset after the first NAK
it waits some time then it's reporting error and it gives up.
Checking further into dhcp client..

from picotcp.

Even though the issues seem to be related the root cause is different. Closing this ticket and opening Issue #45 to track the fix for the new behavior described by Maarten

from picotcp.