Red Hat Bugzilla – Bug 42559
dhcpcd problem with kernel 2.4.2
Last modified: 2008-05-01 11:38:00 EDT
Description of Problem: I find this in /var/log/messages of my dhcp-server (RedHat 6.2) May 27 20:40:39 neb dhcpd: DHCPREQUEST for 192.168.1.3 from 00:10:5a:71:6b:c4 via eth0 May 27 20:40:39 neb dhcpd: DHCPACK on 192.168.1.3 to 00:10:5a:71:6b:c4 via eth0 May 27 20:40:39 neb dhcpd: fallback_discard: Connection refused Running tcpdump on my dhcp-server: 192.168.1.1: tcpdump -i eth0 -n '(icmp or (udp port 67 or 68))' =============================================================== 20:40:39.104524 < 192.168.1.3.bootpc > 192.168.1.1.bootps: xid:0x7b520505 secs:3 C:192.168.1.3 [|bootp] 20:40:39.106236 > 192.168.1.1.bootps > 192.168.1.3.bootpc: xid:0x7b520505 secs:3 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.1 ether 0:10:5a:71:6b:c4 [|bootp] 20:40:39.106576 < 192.168.1.3 > 192.168.1.1: icmp: 192.168.1.3 udp port bootpc unreachable (DF) [tos 0xc0] But when I run tcpdump on the client (RedHat 7.1, kernel 2.4.2-2): 192.168.1.3: tcpdump -i eth0 -n -p '(icmp or (udp port 67 or 68))' =============================================================== 20:28:48.453032 < 192.168.1.1.bootps > 192.168.1.3.bootpc: xid:0xdd351577 secs:3 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.1 ether 0:10:5a:71:6b:c4 [|bootp] 20:28:48.453032 > 192.168.1.3 > 192.168.1.1: icmp: 192.168.1.3 udp port bootpc unreachable (DF) [tos 0xc0] 20:33:48.453032 < 192.168.1.1.bootps > 192.168.1.3.bootpc: xid:0x7b520505 secs:3 C:192.168.1.3 Y:192.168.1.3 S:192.168.1.1 ether 0:10:5a:71:6b:c4 [|bootp] 20:33:48.453032 > 192.168.1.3 > 192.168.1.1: icmp: 192.168.1.3 udp port bootpc unreachable (DF) [tos 0xc0] [ 2 dhcp-transactions, second is the one corresponding to the 192.168.1.1-tcpdump. The clocks are not syncronized. The client (192.168.1.3) never sees the first packet 192.168.1.3 -> 192.168.1.1 of the transaction, although it arrives at 192.168.1.1 (I don't know why).] pump works, but doesn't understand some dhcp-options.
Can you try with a 2.4.9 kernel on the client side?
Btw, I was wondering if we could bind a datagram socket to the local udp port 68, in addition to the raw socket that is being used. Indeed, the problem with a raw socket is that a copy of the datas also go through the udp/ip stack. And at this point if no datagram socket is bound, the kernel considers that the udp packet has no reachable destination, and may emit an icmp message error (depending on the kernel version). So, adding a datagram socket would resolve this issue. Can someone give me an advice?
I'm very sorry that I didn't close this bug: the problem was a stray static route, on 192.168.1.3: route net 192.186.1.0/24 gw 192.168.1.1 I only saw this after two weeks. I still do not understand why tcpdump didn't see all packets leaving, but the dhcpcd problem is over.
Can you tell me if you still see icmp port unreachable messages or not?
No, no icmp-errors anymore.
Well... if I disable iptables rules, I can see these icmp on my linux box (dhcpcd-1.3.18pl8-10 + kernel 2.4.9). So???
You're right, I was still running pump. Time to go to sleep I guess. The icmp-errors reappear the moment I switch to dhcpcd. FYI, I'm running kernel 2.4.9-ac5 and dhcpcd 1.3.20pl0 at the moment (I've been compiling various dhcpcd's). The dhpc-server is Debian stable, with the stock Debian dhcpd.
Indeed, pump uses a datagram socket strategy, so the icmp-error problem is not present. But pump has much more bug^H^H^Hissues elsewhere ;)
Created attachment 30634 [details] bound a datagram socket to port 68 to prevent icmp-error
The above patch is against dhcpcd-1.3.20-pl0. Can you give it a try?
The patch works.
Now included in dhcpcd-1.3.20pl1.
I have put dhcpcd-1.3.21pl0 into rawhide. This should make everyone happy.