tasklwIP - A Lightweight TCP/IP stack - Tasks: task #10446, DHCP extensions for AutoIP

 
 

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

task #10446: DHCP extensions for AutoIP

Submitter:  Bill Auerbach <billauerbach>
Submitted:  Tue 08 Jun 2010 06:21:41 PM UTC
   
 
Category:  DHCP Should Start On:  Tue 08 Jun 2010 04:00:00 AM UTC
Should be Finished on:  Tue 08 Jun 2010 04:00:00 AM UTC Priority:  3 - Low
Status:  Cancelled Privacy:  Public
Percent Complete:  0% Assigned to:  goldsimon
Open/Closed:  Closed Planned Release:  None
Effort:  0.00

Jump to the original submission

Tue 06 Jul 2010 12:27:57 PM UTC, comment #9: 

I submitted a patch I'm current using in 3 products.  It includes a minor bug-fix to dhcp.c which is needed to correctly determine if DHCP or AutoIP provided the IP address.

https://savannah.nongnu.org/patch/?7224

Bill Auerbach <billauerbach>
Mon 05 Jul 2010 02:45:45 PM UTC, comment #8: 


> You and I are going down the same path. We need named devices


Ehrm, not really: we want the device to have a valid network configuration in most cases, i.e. we have a configuration tool that uses UDP broadcast to find and configure devices. This one can then tell whether the IP configuration is correct or not. We only need AutoIP to be able to update the firmware (via TFTP unicast) when DHCP-enabled devices are connected via a loopback cable.

For us, having a static IP as fallback would not be an option, as a user would have to configure one, which is what we want to avoid. You could say that we very much copied the way windows does it, as 100% of our customers use this device with windows.

Nevertheless, I'm not against this one going in, only I don't have the time to do it (currently, and for some months).

Simon Goldschmidt <goldsimon>
Group administrator
Wed 16 Jun 2010 01:24:14 PM UTC, comment #7: 

You and I are going down the same path.  We need named devices and the intent is if the named device is has an AutoIP address, we will change the IP address to make it "reachable".  If the system is set up with "Fallback to static", we don't touch it.  We are simply using the name to return to the PC application the IP address of the device.  Although ZeroConf would be nice, it's a big project and there is a device in our system that does not support it.  We can give it a name that we can query.

With AutoIP optionally falling back to static, I can start lwIP in one of my 3 modes (from Msg #1) and go away and let lwIP come up.

One place I needed to do work is loss and recovery of the link.  It would be nice if lwIP would handle this.  With a static address, it should do a dhcp_inform.  With DHCP (AutoIP or not) dhcp_network_changed needs to be called to restart dhcp.  The DHCP code is not aware that the netif has a static IP address and I think it would be good if it knew this.

Bill Auerbach <billauerbach>
Tue 15 Jun 2010 08:15:30 PM UTC, comment #6: 

I'm not against such changes, only I didn't fully understand it ;-)

Anyway, for my current project, we can't really rely on AutoIP or fallback to static: We have a configuration application that can find and configure a device with any IP configuration (via broadcasts). This is used at the time of configuring the site, only.

Later, the communication application is configured with IP addresses only, so any kind of fallback (either to AutoIP or to a static IP) means communication failure. The only way out here would be some kind of name service, but that either only works on one subnet (or "broadcast domain", rather), or it needs a central server.

This is only my explanation why I can't benefit from such a fallback. Still, if it doesn't blow the code too much, it might be a nice feature...

Simon Goldschmidt <goldsimon>
Group administrator
Tue 15 Jun 2010 08:01:47 PM UTC, comment #5: 

Hmmm, I misunderstood that you liked the feature that if DHCP fails that AutoIP will use (by the user calling a function) a static IP address.  We use this because it allows falling back to a known address so that the device can be pinged, tested and still accessed (on the same static subnet).  If it falls back to true AutoIP, the IP address isn't known.

This is a common situation if you have 2+ NICs in the PC with the lwIP devices on a switch on one NIC (without DHCP).  If the devices fall back to static addresses on the subnet of the NIC with DHCP, the devices are accessible.

I don't have to provide a patch for this - it's OK. I have functionality I needed without watching a timer and setting a static IP manually in my application code.  There is less code now letting AutoIP fall back to a static address and I can easily configure my device to fall back to a normal AutoIP address.

I will supply a patch for detecting that the address is AutoIP and not DHCP.

Bill Auerbach <billauerbach>
Tue 15 Jun 2010 07:51:12 PM UTC, comment #4: 

Actually, I don't really know what you mean by "AutoIP with fallback to a user-defined IP address". At which time do you want to use the static IP? After the first conflict? Or after some conflicts? Using random IP addresses in the AutoIP range (and a good random function, of course), conflicts shouldn't appear that often...

I don't really have an opinion on this, the only thing I currently want to make sure is that when changing networks, the result is the same as if the device had booted in the new network...

Simon Goldschmidt <goldsimon>
Group administrator
Tue 15 Jun 2010 06:32:59 PM UTC, comment #3: 

Simon, if the user specifies AutoIP with fallback to a user-defined IP address, the probing will still take place at this user-defined address.  If there is a conflict, autoip_restart will increment this address and try again.  I don't mind this as it prevents a potential IP address conflict.

OTOH, we could simply see that there is fallback to a static address, set the netif IP address to the user-defined fallback and use dhcp_inform and be done with it.  Naturally devices configured to the same fallback IP address will conflict if both appear on a network.

I have it working with conflict avoidance and can prepare a patch unless you prefer fallback to static can have conflicts.

Bill Auerbach <billauerbach>
Mon 14 Jun 2010 04:07:37 PM UTC, comment #2: 

I can do the part of indicating the address is an AutoIP address. I did the fallback in my application, but it would be nice if there was a static address for AutoIP to fallback to.  I can add that because it would be nice for it to be autonomous.  I'll do both items.

I've had to do still more in my application.  When a static IP address is set, I call dhcp_inform.  I think with LWIP_DHCP being 1 that netif_set_ipaddr should do this internally. I know it does a gratuitous ARP, but isn't a DHCP INFORM good etiquette as well when setting a static IP address?  In fact, I didn't check but it might be required.

Bill Auerbach <billauerbach>
Sat 12 Jun 2010 07:21:35 PM UTC, comment #1: 

I like the idea, but do you have any code prepared? I'm not in a situation to put much time into this, currently. Also, where would you save the preconfigured address? We currently only have one IP address per netif, so that cannot be used to store the preconfigured static fallback IP.

BTW, I also think the current settings for AutoIP-cooperation is set too high, I think I'll lower that: DHCP continues after AutoIP is started, anyway.

Simon Goldschmidt <goldsimon>
Group administrator
Tue 08 Jun 2010 06:21:41 PM UTC, original submission:  

In order to be more flexible with lwIP products in the field, I'd like a little more control over AutoIP.  It's minor but I believe it might help others.

We have 3 modes of IP Address configuration in our lwIP-based products which are:

1. DHCP/AutoIP    - DHCP with fallback to AutoIP.
2. DHCP/Static IP - DHCP with fallback to a preconfigured static IP.
3. Static IP

Mode 2 allows use with DHCP and if it's not available the user will know the static IP address.  To use this mode it would be nice to be able to disable AutoIP at runtime so I can implement my own DHCP timeout and fall back to the static address.

Something like dhcp_start_no_autoip would be sufficient.  Maybe it could set autoip_coop_state to DHCP_AUTOIP_COOP_STATE_DISABLED and simply not start autoip.  Although AutoIP occurs way later than DHCP and I can timeout before it starts, I had to shorten LWIP_DHCP_AUTOIP_COOP_TRIES because 30+ seconds to get an IP address was too long.  Shortening it leaves me in the position to get an AutoIP address when I want to time out.

Thanks,
Bill




Bill Auerbach <billauerbach>

 

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

No files currently attached

 

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 billauerbach (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-04-24 goldsimon StatusNone Cancelled
        Assigned toNone goldsimon
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.12.
    Corresponding source code