Bug 143793 - network manager uses wrong address when sending out dhcp discovers
network manager uses wrong address when sending out dhcp discovers
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dan Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-28 02:09 EST by Kaj J. Niemi
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-01-14 02:20:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Kaj J. Niemi 2004-12-28 02:09:45 EST
Description of problem:
On a system with multiple assigned addresses, NetworkManager sometimes uses the
wrong one (not 0.0.0.0 as defined by dhcp spec) while sending a DHCP DISCOVER
message. This results in the router not responding properly as the message looks
like it came from another segment.

eth0 = e1000
eth1 = ipw2100
vmnet8 = vmware ethernet driver

% /sbin/ip addr
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,NOTRAILERS,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:0d:60:38:25:6c brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:04:23:77:a8:ba brd ff:ff:ff:ff:ff:ff
4: cipsec0: <BROADCAST,MULTICAST> mtu 1400 qdisc noop qlen 100
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
5: vmnet8: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:c0:00:08 brd ff:ff:ff:ff:ff:ff
    inet 192.168.128.1/24 brd 192.168.128.255 scope global vmnet8

In the trace below NetworkManager sent the packet out with vmnet8's address
instead of the source 0.0.0.0. The MAC address is correct and corresponds to
eth0 (as it is supposed to).

% sudo tcpdump -n -vvvv -s 1500 -x port 68
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
09:01:46.929685 IP (tos 0x0, ttl  64, id 2, offset 0, flags [DF], proto 17,
length: 309) 192.168.128.1.bootpc > 255.255.255.255.bootps: [bad udp cksum
f0d2!] BOOTP/DHCP, Request from 00:0d:60:38:25:6c, length: 281, xid:0xc6237b32,
secs:10, flags: [none] (0x0000)
          Client Ethernet Address: 00:0d:60:38:25:6c
          Vendor-rfc1048:
            DHCP:DISCOVER
            MSZ:548
            LT:4294967295
            PR:SM+DG+NS+HN+DN+RP+TTL+BR+MD+RD+SR+YD+YS+NTP
            VC:""
            CID:[ether]00:00:00:00:00:00
        0x0000:  4500 0135 0002 4000 4011 f90c c0a8 8001  E..5..@.@.......
        0x0010:  ffff ffff 0044 0043 0121 41dc 0101 0600  .....D.C.!A.....
        0x0020:  c623 7b32 000a 0000 0000 0000 0000 0000  .#{2............
        0x0030:  0000 0000 0000 0000 000d 6038 256c 0000  ..........`8%l..
        0x0040:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0050:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0060:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0070:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0080:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0090:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00a0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00b0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00c0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00d0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00e0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x00f0:  0000 0000 0000 0000 0000 0000 0000 0000  ................
        0x0100:  0000 0000 0000 0000 6382 5363 3501 0139  ........c.Sc5..9
        0x0110:  0202 2433 04ff ffff ff37 0e01 0306 0c0f  ..$3.....7......
        0x0120:  1117 1c1d 1f21 2829 2a3c 003d 0701 0000  .....!()*<.=....
        0x0130:  0000 0000 ff                             .....

Looking at syslog output it corresponds to this:

Dec 28 09:01:29 localhost NetworkManager: nm_state_modification_monitor():
beginning activation for device 'eth0'
Dec 28 09:01:29 localhost NetworkManager: nm_device_activation_worker (eth0)
started...
Dec 28 09:01:29 localhost NetworkManager: dhcp_interface_init: MAC address =
00:0d:60:38:25:6c
Dec 28 09:01:29 localhost NetworkManager: ClassID  = "Linux 2.6.9-1.1014_FC4
i686" ClientID = "61.7.1.00.00.00.00.00.00"
Dec 28 09:01:29 localhost NetworkManager: Broadcasting DHCP_DISCOVER
Dec 28 09:01:29 localhost NetworkManager: DHCP: Starting request loop
Dec 28 09:01:29 localhost NetworkManager: DHCP: Sending request packet...
Dec 28 09:01:29 localhost NetworkManager: DHCP: Sent request packet.
Dec 28 09:01:29 localhost NetworkManager: DHCP: Waiting for reply...
Dec 28 09:01:29 localhost NetworkManager: DHCP waiting for data, overall timeout
= {1104217295s, 22308us}
Dec 28 09:01:29 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {5s, 92670us}
Dec 28 09:01:30 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {4s, 93493us}
Dec 28 09:01:31 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {3s, 93515us}
Dec 28 09:01:32 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {2s, 93627us}
Dec 28 09:01:33 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {1s, 93726us}
Dec 28 09:01:34 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {0s, 93841us}
Dec 28 09:01:35 localhost NetworkManager: DHCP: Sending request packet...
Dec 28 09:01:35 localhost NetworkManager: DHCP: Sent request packet.
Dec 28 09:01:35 localhost NetworkManager: DHCP: Waiting for reply...
Dec 28 09:01:35 localhost NetworkManager: DHCP waiting for data, overall timeout
= {1104217306s, -34521us}
Dec 28 09:01:35 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {10s, 36808us}
Dec 28 09:01:36 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {9s, 37238us}
Dec 28 09:01:37 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {8s, 37430us}
Dec 28 09:01:38 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {7s, 37456us}
Dec 28 09:01:39 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {6s, 37556us}
Dec 28 09:01:40 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {5s, 35703us}
Dec 28 09:01:41 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {4s, 35787us}
Dec 28 09:01:42 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {3s, 35891us}
Dec 28 09:01:43 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {2s, 36003us}
Dec 28 09:01:44 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {1s, 36108us}
Dec 28 09:01:45 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {0s, 36270us}
Dec 28 09:01:46 localhost NetworkManager: DHCP: Sending request packet...
Dec 28 09:01:46 localhost NetworkManager: DHCP: Sent request packet.
Dec 28 09:01:46 localhost NetworkManager: DHCP: Waiting for reply...
Dec 28 09:01:46 localhost NetworkManager: DHCP waiting for data, overall timeout
= {1104217319s, 929064us}
Dec 28 09:01:46 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {12s, 999675us}
Dec 28 09:01:47 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {12s, 29us}
Dec 28 09:01:48 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {11s, 138us}
Dec 28 09:01:49 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {10s, 326us}
Dec 28 09:01:50 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {9s, 358us}
Dec 28 09:01:51 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {8s, 468us}
Dec 28 09:01:52 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {7s, 663us}
Dec 28 09:01:53 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {6s, 686us}
Dec 28 09:01:54 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {5s, 792us}
Dec 28 09:01:55 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {4s, 908us}
Dec 28 09:01:56 localhost NetworkManager: DHCP waiting for data, remaining
timeout = {3s, 1101us}


Version-Release number of selected component (if applicable):
NetworkManager-0.3.2-4.3.cvs20041208

How reproducible:
Almost always

Steps to Reproduce:
1. Turn on laptop
2. Login
3. 
  
Actual results:
Fails. "ifup eth0" does work though.

Expected results:
Should not fail.

Additional info:

Thanks. Let me know if you need any other info, I'll be happy to help.
Comment 1 Kaj J. Niemi 2005-01-14 02:20:09 EST
Looks like this got fixed somewhere before 0.3.3-1.cvs20050112.3.
Thanks...
Comment 2 Dan Williams 2005-01-14 09:36:44 EST
Yes, I switched the code back again from letting the Kernel fill in
that information to creating the Ethernet packets myself in
NetworkManager.  That fixed it.  I have no idea what the kernel was
thinking or where it was getting the source address from.

Note You need to log in before you can comment on or make changes to this bug.