dc9.62 gets dhcp address when dhcp is turned off

Rabbit
1

Using DC9.62

About one time out of five, the following code causes Rabbit to get an address from the DHCP server, even though DHCP is clearly turned off.

Four times out of five, it correctly uses the static address provided.

Turning on BOOTP_VERBOSE confirms that DHCP is activating sporatically.

The values of addr, netmask, nameserver and router strings are
192.168.1.79, 255.255.255.0, 192.168.1.1 and 192.168.1.1

result = ifconfig(IF_ETH0,
  IFS_DHCP, 0,
 IFS_IPADDR, aton(CurrentConfiguration()->ipString),
 IFS_NETMASK, aton(CurrentConfiguration()->netmaskString),
 IFS_NAMESERVER_SET, aton(CurrentConfiguration()->nameserverString),
 IFS_ROUTER_SET, aton(CurrentConfiguration()->gatewayString),
  IFS_UP,
IFS_END);
2

Are you multitasking? What kind of user interrupts are you using? A problem like this would be a big problem in the applications I am writing. It would be nice to know if Rabbit employees can reproduce this. Does your code function correctly in a previous version, say DC9.52?

[QUOTE=charliehrabbit;2650]Using DC9.62

About one time out of five, the following code causes Rabbit to get an address from the DHCP server, even though DHCP is clearly turned off.

Four times out of five, it correctly uses the static address provided.

Turning on BOOTP_VERBOSE confirms that DHCP is activating sporatically.

The values of addr, netmask, nameserver and router strings are
192.168.1.79, 255.255.255.0, 192.168.1.1 and 192.168.1.1

result = ifconfig(IF_ETH0,
  IFS_DHCP, 0,
 IFS_IPADDR, aton(CurrentConfiguration()->ipString),
 IFS_NETMASK, aton(CurrentConfiguration()->netmaskString),
 IFS_NAMESERVER_SET, aton(CurrentConfiguration()->nameserverString),
 IFS_ROUTER_SET, aton(CurrentConfiguration()->gatewayString),
  IFS_UP,
IFS_END);

[/quote]

3

I’ve only used 9.62 on this project, but I understand 9.52 had more problems. I’ve actually encountered multiple DC problems attempting to create a program that can be configured at boot time to configure as either static or dhcp. There were about five Dynamic C bugs in the way of doing that.

In the course of clearing through the bugs, I discovered a post (sorry I’ve misplaced the link) which explained that there are certain ram data initialized in sock_init, such that if you call ifconfig before sock_init (as all the samples suggest), there can be intermittent failures based on what happens to be in those uninitialized memory locations after power-up. The author of the post was addressing an ARP bug, but the same mechanism may be at work with the sporatic dhcp behavior. It would explain the non-deterministic-ness of the behavior.

I have changed a lot of things, including calling sock_init before ifconfig, and I don’t see the sporatic dhcp any more. Perhaps calling sock_init first will do the trick for you.

Remember: runtime network configuration in DC was glued on top of the original compile-time configuration and the result is a god-awful mess. Don’t assume anything. Make liberal use of the various _VERBOSE and _DEBUG macros.

4

I appreciate the information. I am sure you have saved me many hours work. I will move sock_init in my program. For my application, DHCP is not used at all (too many problems and not needed in my case). Thanks again. Doug