Re: 0.3.2-4.3.cvs20041208

[Dan Williams <dcbw redhat com>]

On Thu, 2004-12-09 at 10:43 -0500, Bill Moss wrote:
> I tried the 0.3.2-4.3.cvs20041208  on my IBM T42 with FC3 fully updated, 
> ipw2200-0.16 wireless driver, and SMC Barricade AP/switch/DNS 
> server/DHCP server. The syslog messages output by NetworkManager were 
> the same as for the 0.3.2-3.cvs20041117 version except that DHCP failed.
> 
> NetworkManager: AUTO: Best wired device = (null), best wireless device = 
> eth1 (mosswap)
> NetworkManager: HAVELINK: act=1
> NetworkManager: HAVELINK: act=1
> NetworkManager: dhcp_interface_init: MAC address = 00:0e:35:14:60:d0
> NetworkManager: Broadcasting DHCP_DISCOVER
> NetworkManager: DHCP: Starting request loop
> NetworkManager: DHCP: Sending request packet...
> NetworkManager: DHCP: Sent request packet.
> NetworkManager: DHCP: Waiting for reply...
> NetworkManager: DHCP waiting for data, overall timeout = {1102605975s, 
> 117223us}
> NetworkManager: DHCP waiting for data, remaining timeout = {5s, 160415us}
> NetworkManager: DHCP waiting for data, remaining timeout = {4s, 161255us}
> 
> The SMC Barricade never replied. I went back to the 0.3.2-3.cvs20041117 
> version and DHCP works fine.

Ok, can you help me debug it a bit?  It needs to be done like this:

1) stop the NetworkManager service
2) use NetworkManager --no-daemon
3) immediately switch to another terminal and do "tcpdump -i <your
interface>"
4) if at any point that tcpdump quits iwth "interface down", hit the up
arrow and return to start it up again (NM will bring the device down at
least once, so this will happen)
5) Wait until DHCP has failed completely, then kill NM
6) Wait until the DHCP packet output gets printed to the tcpdump console

Then post that output here.  If you're not seeing anything from tcpdump,
wait a while longer (at least a minute or two) since sometimes its quite
slow to get the packets from the kernel, or something like that.  If you
never see it, make sure you have the right interface, and that tcpdump
was active when NM printed its "Sending request packet..." to its
terminal.

For some background, I've notcied that sometimes the IP address of your
current adapter is wrong in the outgoing IP packet, usually when there's
a VPN set up, and then the outgoing IP packet will adopt the address of
the VPN connection, even though the code clearly sets the IP address on
the card to 0.0.0.0.

Dan