Module set STATIC still does DHCP, DHCP on SonicWall fails == TROUBLE!

Using Net+OS 7.0 code on a ConnectME, if I set the module to use DHCP, and I am connected to a network using a SonicWall firewall (which is also a DHCP server), the module fails to get an IP address. Using Wireshark/Ethereal to capture the exchange, I see the following sequence:

DHCP Discover >
< DHCP Offer
DHCP Request >
< DHCP Ack
DHCP Request >
< DHCP Ack
DHCP Request >
< DHCP Ack
DHCP Request >
< DHCP Ack
(repeated for 30 seconds)

For some reason, the ConnectME does not like the SonicWall’s ACK message (the one that contains the IP address and answers for all of the parameter requests in the Request message). Comparing this ACK with one from a Microsoft DHCP Ack, and one from a SOHO internet router, I only find a few differences.

The SonicWall does not provide Option 15 (Domain Name). Neither does Microsoft, so that shouldn’t be the problem.

The SonicWall does not provide Options 58 (Renewal Time Value) or 59 (Rebinding Time Value). Neither does the SOHO router, so that shouldn’t be the problem.

The SonicWall provides Option 52, which overrides the Server Host Name and Boot File Name with options. Neither of the working servers do that. Considering that the Digi can use TFTP to reload firmware, and TFTP gets its filename from the Boot File Name, I suspect this is the problem.

To make matters worse, however, if I set the ConnectME to use a STATIC IP, I still can’t bring up the unit with the SonicWall firewall present. The problem seems to be that even though the Digi is set to use a static IP, it knows it once had a DHCP address, so it tries to connect to the DCHP
server to release that address. With the Microsoft DHCP server, I’ve captured with Ethereal the process, and it goes through a full DHCP exchange, sends the release, and then proceeds to use the static address. Since it can’t get through the DHCP exchange, it never gets to the point of using the static address when connected to the SonicWall. To make matters worse, unlike when I am set to use DHCP, this doesn’t seem to quit after 30 seconds and let the static IP take effect. The network stack never seems to start and relinquish control to my application. Thus I can’t use the ConnectME at all if there is a SonicWall on the network.

Any idea how to work around this issue? Anyone familiar with the SonicWall and know how to make it quit messing with the Boot File Name? Any way to make the Digi quit doing DHCP even though it is configured for a STATIC IP?

Thanks for any help,
Jeff.

I haven’t worked with 7.0 yet, but an idea -
The static IP that is set in appconf.h is only the default static IP - what is in memory overrides it. If you were running DHCP on the last boot, it will use the old DHCP address, which, depending on the router hardware, may start a release or renewal.

The trick may be to start the module unplugged, reset the address to the static IP, then restart connected.

-Erik

Erik, I’ve worked with Digi today, and their is a known problem they are working on with SonicWall firewalls. The issue with static vs. dynamic is caused by my use of the AWS demo code. In the AWS demos, when you use the web configuration to switch between static and dhcp, the code only changes whether static is enabled or disabled. Dhcp is left always enabled. In that situation, static “wins” and you will go through dhcp exchange, but use the static address. This is normally a “good” thing, in that it lets you use dhcp to trigger a TFTP reload of your application in case you hose FTP. But in my case, it was a “bad” thing. The workaround is to turn dhcp off when you turn static on, and vice versa. It means that a static addressed module will have no update method if you hose your FTP code, though.

Very useful info - I’d noticed something odd with the DHCP on/off control, but not yet investigated.

More to the point, I suspect that address setting via ADDP uses the same mechanism - and we presumably don’t have any control over that.

> More to the point, I suspect that address setting via ADDP uses the same mechanism - and we presumably don’t have any control over that.

I’ve sniffed ADDP quite a bit, and I don’t think it relies on DHCP in any significant way. It uses multicast UDP packets to discover, then embeds the selected MAC into the setup commands. All units see them, but presumably only one has the matching MAC, so only one will change its settings.

That said, I’ve found ADDP very unreliable when switching between static and dynamic. It may not be ADDP’s fault after all, and is instead that ADDP does the same thing my code did, only switching the static.isEnabled parameter and leaving the dhcp.isEnabled alone. I’ll have to investigate that possibility.