From Bugzilla Helper: User-Agent: Mozilla/5.0 (compatible; Konqueror/3.0.0-10) Description of problem: Machine has two network interfaces: eth0 for static local address and eth1 for ISP's DHCP'ed address. When eth0 is up before eth1 (as it always is), pump sends DHCP request to eth1, seemingly coming from an address of eth0, not 0.0.0.0 which it should. Now after some upgrade (?) on the ISP's side the server either refuces to answer these packets or replies are getting lost somewhere (routed to some other 192.168.1.1 ??). ISP confirmed that requests were getting to the server. (It used to work...). Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Have two network adapters 2. Bring eth0 up with static address 3. Try to get eth1 up with pump Actual Results: Tcpdump outputs the folloing: 192.168.1.1.bootpc > 255.255.255.255.bootps: xid:0xac42c044 [|bootp] (DF) 192.168.1.1.bootpc > 255.255.255.255.bootps: xid:0xac42c044 secs:768 [|bootp] (DF) 192.168.1.1.bootpc > 255.255.255.255.bootps: xid:0xac42c044 secs:2048 [|bootp] (DF) 192.168.1.1.bootpc > 255.255.255.255.bootps: xid:0xac42c044 secs:4352 [|bootp] (DF) Expected Results: From tcpdump: 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x6243c044 [|bootp] (DF) 80.222.80.1.bootps > 255.255.255.255.bootpc: hops:1 xid:0x6243c044 Y:80.222.81.38 S:10.16.10.16 G:80.222.80.1 ether 0:0:c0:bb:6c:50 [|bootp] 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x6343c044 secs:256 [|bootp] (DF) 80.222.80.1.bootps > 255.255.255.255.bootpc: hops:1 xid:0x6343c044 secs:256 Y:80.222.81.38 S:10.16.10.16 G:80.222.80.1 ether 0:0:c0:bb:6c:50 [|bootp] 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x6443c044 secs:256 [|bootp] (DF) 80.222.80.1.bootps > 255.255.255.255.bootpc: hops:1 xid:0x6443c044 secs:256 Y:80.222.81.38 S:10.16.10.16 G:80.222.80.1 ether 0:0:c0:bb:6c:50 [|bootp] Additional info: From rfc2131, section 4.1: "DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0."
*** This bug has been marked as a duplicate of 23052 ***