APIPA connection: limited or no connectivity

TekkenLaw

Distinguished
Mar 18, 2011
4
0
18,510
Hi,

I am working on development of a Windows based application which connects to a PDA like device over USB & communicates with it using RNDIS protocol. The device has a static IP in the APIPA range (169.254.2.1). When it is connected to PC, Windows allocates a dynamic APIPA IP (169.254.x.x) to the RNDIS adapter. I have confirmed that there is proper connectivity with the device (I can ping it, can access a web server on the device etc.). But the problem is that after Windows allocates the dynamic IP, a 'limited or no network connectivity' message is displayed in system tray.

Since the device & software will go out in the market, display of this message (& exclamation mark on the network tray icon) is undesirable. I know that it can be suppressed by setting property of network adapter, but would prefer a solution that would not require end users to do any settings. Also, please note that using APIPA addresses is essential as we would like to avoid conflicts with end users' LAN addresses.

Sorry for the verbose post..hope someone can help.

Thanks in advance.
 
Solution
Well do you actually *need* TCP/IP for the device? Is this just a case of Windows defaulting to include TCP/IP, but you don't actually use it?

If so, and you can't really alter that behavior (or unbind TCP/IP) due to authorization issues, then why not "go with the flow. Suppose *you* responded to the DHCP request and provide valid (if useless) TCP/IP configuration info. IOW, since TCP/IP is always bound by default, and uses DHCP by default, and you can’t alter that behavior, you respond to it w/ your own DHCP server.

I know that sounds a bit extreme, but it seems to me the situation has you boxed in if you can't alter Windows behavior for various reasons. So all you can do is respond as Windows would expect and thus avoid error...
The "limited connectivity" message isn't a product of using APIAP, but a result of having no default gateway (hence, why it's "limited"). Obviously an APIPA range is always going to result in no gateway IP, but it could just as well happen any time a gateway IP is unavailable.

So I would simply provide a gateway IP of 169.254.x.1 and see if it fixes the problem. I can’t guarantee it does since I don’t know if there are any other special issues wrt APIAP, but that would be my first attempt at a solution.

 

TekkenLaw

Distinguished
Mar 18, 2011
4
0
18,510


Thanks for the explanation..unfortunately when Windows assigns the APIPA address, it does not seem to set the default gateway. Maybe assigning the IP through code can resolve this issue, but that is not acceptable to our client as it requires admin rights on Win7. However, for confirming if setting default gateway works, I'm going to try it out..thanks again & do let me know if you have any other ideas..
 
Well do you actually *need* TCP/IP for the device? Is this just a case of Windows defaulting to include TCP/IP, but you don't actually use it?

If so, and you can't really alter that behavior (or unbind TCP/IP) due to authorization issues, then why not "go with the flow. Suppose *you* responded to the DHCP request and provide valid (if useless) TCP/IP configuration info. IOW, since TCP/IP is always bound by default, and uses DHCP by default, and you can’t alter that behavior, you respond to it w/ your own DHCP server.

I know that sounds a bit extreme, but it seems to me the situation has you boxed in if you can't alter Windows behavior for various reasons. So all you can do is respond as Windows would expect and thus avoid error messages. Fortunately DHCP is such a simple protocol, you could probably implement it w/ a few lines of code.

 
Solution

TekkenLaw

Distinguished
Mar 18, 2011
4
0
18,510
Yes, we do need tcp/ip as we need to call CGI scripts on the web server running on the device attached by USB.

Your idea of running DHCP server is spot on..in fact, this is exactly what we had suggested to the client, but they did not accept it for some reason..I guess we'll push it again now..thanks.