Auto-IP Library questions

[sblair]

I'm looking to replace my own poor-man's AutoIP implementation with the new AutoIP library that was released.

1. Where is the example app located for AutoIP? I couldn't locate it after installing v2.6.0.

2. There are some statements in the docs about the AutoIP library that concern me about not running the AutoIP client with the DHCP client at the same time which is why I want to see the example app to see how it is being used.

Generally most AutoIP implementations involve trying to obtain an a DHCP address first and then failing that resorting to AutoIP, which is obviously the implementation I want to use. It's easy to start/stop the DHCP client when it fails to get an address fire up the AutoIP client. However, there are requirements in the AutoIP standard RFC3927 that require that if a device has an AutoIP address that when it sees a DHCP server become available that it switch to that and abandon the AutoIP address. That's the one thing my own AutoIP implementation doesn't properly do and was expecting to see that being done with this new library, but given the implications of the language in the Runtime Library doc I'm not sure how that would work?

[dciliske]

I'm not sure whether the response I'm going to give you will relieve your concerns or frustrate you. Put simply, there is no example app for AutoIP. This is because it is automagically run, if the system library is compiled to support it (which is the default). Basically, what the system does is create a secondary logical network interface and attaches the AutoIP client to that interface. This interface will always be up. As for DHCP, the standard bringup for the client occurs on the primary Logical/physical network interface. As such, if it can obtain a lease, that interface will have an ip address and therefore be routable. If it does not obtain a lease, it will not have an ip address and keep requesting one until a DHCP server comes online.

During this period, the system will have the AutoIP assigned address, allowing it to send packets. At any rate, once a DHCP lease is obtained, the Netburner will route packets based on which interface has a route to the destination (aka which one of them is on the same subnet/has the right netmask).

This is not, strictly speaking a direct adherence to the RFC, but does indeed allow for the proper functioning of the network in the switchover situation. Hope this answers your questions.

[sblair]

Dan,

Thanks very much for your response. I had a nice long follow up post written last night but then when I hit submit I found the crappy hotel wifi connection had dropped so I lost it all. Hopefully this will be as clear as what I had written before.

I'm surprisingly okay with it being automagical as long as the automagical behavior is in the way I expect it to be

What you said about the implementation using a second interface makes sense and better follows the intent of the RFC in the crossover conditions much better than the cheap 'ghetto' auto-ip implementation I had done myself. I had just checked for DHCP failure and then assigned a static IP of 169.254.Rand(x).Rand(y) that I didn't persist to flash. It worked in the basic cases, but didn't do a lot of the things it should have done to be a proper implementation.

The information in your previous post was much clearer than the info that is in the Runtime Libraries doc and clears up a lot of confusion. It may be a good idea to put more of that explanation in the doc. The reason I was asking for the auto-ip example app is that I saw it being referenced here in this post: http://forum.embeddedethernet.com/viewt ... 6059#p6059

My biggest questions about how it operates is what is the best way of monitoring states and addresses? My application is that I'm implementing a protocol that uses SLPv2 as it's discovery mechanism so I need to know which IP address to advertise at a given point in time.

What is the best way to monitor whether I have a valid DHCP address or not? I'm guessing a call to ValidDhcpLease()?

For the Auto-IP interface, how can I access the IP address it is using? Can I get that info using the Configuration Record? If so which CONFIG_IF_ID # do I use for the Auto-IP interface?

Thanks!
Scott

[dciliske]

You can either poll the DHCP interface with ValidDhcpLease or with the 'leaseObtainedCallback' function pointer that the DHCP client has. There's also a 'leaseExpiredCallback' pointer that will inform you when the DHCP interface no longer has a valid address.

As for obtaining the AutoIP address on that interface and confirming it as valid... that's a little trickier (perhaps I should make it less so...). You'll need to grab hold of the InterfaceBlock for the AutoIPClient and query it's IP address. As for verifying it as valid, you'll need the AutoIPClient for the given interface and call getState() on the object. The IP address is only valid if the state returned is AUTO_IP_CONFIGURED. A word of warning though, getState will need to be made public, as in the current releases the function is marked private (why should that information ever be exposed? Ah, well, my fault ). Also, it should be noted that the address assigned from the AutoIPClient is not stored in any config record; the AutoIP address is determined by using a pseudo-random number sequence generated using the lower 4 octets of the device's MAC address.

As for getting a hold of the InterfaceBlocks, you will want to use GetFirstInterface() and GetNextInterface(int) to walk all network interfaces. To determine whether the interface is running a DHCP or AutoIP client, simply check the pointers on the InterfaceBlock (dhcpClient and AutoIPC, respectively). You may want to also check whether the interface is a multihome interface (bMultiHome) and only advertise on that interface if it's root interface (root_if) does not have a valid IP address.

I've attached a short example/framework that will announce on root interfaces at most once (potentially utilizing a multihome interface for the IP address though).

[sblair]

Thanks Dan! Very helpful info! What are the odds of getting that changed from private to public in the next release (and maybe a couple of the other ease of use additions)?

I'm very careful about never modifying the library code because that is obviously not a good idea in terms of being able to easily upgrade and move forward, especially when I've got a couple other developers involved.

Thanks
Scott

[dciliske]

It's done. I had debated whether to expose that functionality originally (why I decided not to, I cannot remember) and have checked in the change.

[roland.ames]

I was hoping that I would be able to read something about this new function, but I can't seem to find the up-to-date PDF on the website. I don't have that release yet so my docs folder does not contain the latest PDF. If I want to get some info on any new functions before getting the release, it would be useful to have access to the latest version of all the various PDFs.

[dciliske]

Hmm... I'll have to take a look into that. In the meantime, here's the latest reference document.

Auto IP is covered in section 6. Note that getState is not mentioned, as it previously was a private function.

6. AutoIP Library
6.1. Introduction
The AutoIP Library provides a client daemon (AutoIPClient) for assigning an IP address to a network interface using the Auto IP configuration process. It allows a device to configure a nonconflicting IP address dynamically without reliance on a central authority or resource (unlike DHCP). It should be noted that there should never, under any circumstances, be a DHCP client and an AutoIP client running on the same interface. This will lead to abarent behavior resulting in a shifting IP address and configurations for that interface.

When this library is in use, the main library is compiled to create a multihome interface off of the primary network interface that runs an AutoIP client. The intent of this feature is to allow a user to directly connect to the device, without assigning a static ip to either the device or their computer, in order to facilitate development or field access.

To disable the AutoIP library and the multihome interface, remove or comment out the #define AUTOIP in <predef.h> and then recompile the main library.

Header File
#include <autoip.h> // Found in C:\Nburn\include

Functions for AutoIPClient objects
- start
: Starts the AutoIPClient.
- stop
: Stops the AutoIPClient and resets the interface’s IP and configuration.
- restart
: Resets the interface and restarts the AutoIPClient.

6.2. AutoIPClient
Synopsis:
AutoIPClient( int interface );
Description:
Constructor for the AutoIPClient autoip client daemon.
Parameters:
interface – The network interface number the client will be using/configuring.
Return Values:
None.

6.3. start
Synopsis:
void start( );
Description:
This function starts the AutoIPClient state machine.
Parameters:
None.
Return Values:
None.

6.4. stop
Synopsis:
void stop( );
Description:
This function stops the AutoIPClient state machine and resets its network interface’s IP and configuration.
Parameters:
None.
Return Values:
None.

6.5. restart
Synopsis:
void restart( );
Description:
This function resets its network interface’s IP and configuration then restarts the AutoIPClient state machine.
Parameters:
None.
Return Values:
None.

[roland.ames]

Thanks for that Dan. The version on the website was 2.02, about 17 months old!

This is the main problem I have with the website: the documentation available is not always up to date. This applies to other docs, not just this one.

I think notification via the forum of when new/updated documents or tools / applications are published on the site would also be appreciated. In a similar way to how notification of new releases of the NNDK are handled.

Roland

[dciliske]

We hear you Roland. And I've usually been pretty good about pointing out things that need updating/changing, but unfortunately I use our internal repository for most things and don't notice a lot of the time.

That said... well, there's changes in the wind. A much improved (massively so) version of the site is in the works, and we're working on the actual system aspects of deploying it as we speak.