buglwIP - A Lightweight TCP/IP stack - Bugs: bug #41787, DHCP Discovery is invalid when an...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #41787: DHCP Discovery is invalid when an IP is set to thet netif.

Submitter:  Nick van IJzendoorn <dipswitch_>
Submitted:  Thu 06 Mar 2014 08:40:21 AM UTC
   
 
Category:  DHCP Severity:  3 - Normal
Item Group:  Faulty Behaviour Status:  Fixed
Privacy:  Public Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
lwIP version:  1.4.0

Sun 06 Apr 2014 06:33:48 PM UTC, comment #3: 

Fixed by sending discover, request and decline from 'any' even if netif has an address asigned.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 Apr 2014 08:02:26 PM UTC, comment #2: 

In section 4.1, it says:
"DHCP messages broadcast by a client prior to that client obtaining
its IP address must have the source address field in the IP header
set to 0."

But I guess you can argue whether that fits to our case, because we already obtained an IP address through AutoIP or user configuration...

Anyway, I'd think it would be better to have 0.0.0.0 as the source address for DHCP broadcasts.

Simon Goldschmidt <goldsimon>
Group administrator
Fri 04 Apr 2014 07:59:45 PM UTC, comment #1: 

The DISCOVER packet does not seem invalid to me: the 'ciaddr' field is zero. Only the source address of the IP packet is != 0.0.0.0, I haven't found yet whether that's valid or not...

Simon Goldschmidt <goldsimon>
Group administrator
Thu 06 Mar 2014 08:40:21 AM UTC, original submission:  

The DHCP client will send an invalid DHCP Discovery packet (according to RFC2131 the ciaddr MUST be zero in the DISCOVERY phase) when the IP of the netif is already set. For instance when you are switching from static IP to dynamic IP.

I know you could clear the IP, subnet and gateway yourself before starting the DHCP client. But I personally think it would be cleaner / better if LwIP clears the IP, subnet and gateway before turning on the DHCP client.

One solution could be to patch the DHCP client like the patch provided.

Nick van IJzendoorn <dipswitch_>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #30790:  dhcp.patch added by dipswitch_ (2KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by goldsimon (Posted a comment)
  • -email is unavailable- added by dipswitch_ (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-04-06 goldsimon CategoryNone DHCP
        Item GroupNone Faulty Behaviour
        StatusNone Fixed
        Assigned toNone goldsimon
        Open/ClosedOpen Closed
    2014-03-06 dipswitch_ Attached File- Added dhcp.patch, #30790

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code