Modify

Opened 9 years ago

Closed 8 years ago

Last modified 15 months ago

#4108 closed defect (fixed)

udhcpc ignores renew replies from dhcp server

Reported by: openwrt@… Owned by: developers
Priority: normal Milestone:
Component: base system Version:
Keywords: udhcpc renew connection drop Cc:

Description

I'm suspecting a bug in udhcpc. It just can't renew a dhcp lease. When the lease time is sufficiently big, you wouldn't easily notice, however mine is 15 minutes.

The result is that every 15 minutes (dhcp lease time) all my connections drop. When the lease expires, udhcpc notices, and instead of trying to renew, just requests a new lease, which works.

# udhcpc -f -t 0 -i eth0.1 -b -p /var/run/eth0.1.pid
udhcpc (v1.4.2) started
Sending discover...
Sending select for 10.0.65.172...
Lease of 10.0.65.172 obtained, lease time 900
adding router 10.0.65.254
deleting old routes
adding dns 134.58.126.3
adding dns 134.58.127.1

[ I did a kill -SIGUSR1 to force renew ]

Performing a DHCP renew
Sending renew...
Sending renew...
Sending renew...
[and keeps on repeating...]

In the mean while I'm running tcpdump:

# tcpdump -n -e -v -i eth0.1 port 68 or port 67
tcpdump: listening on eth0.1, link-type EN10MB (Ethernet), capture size 96 bytes

[ Here udhcpc will do it's initial dhcp request ]

00:32:46.683964 00:12:17:b7:86:a3 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 305) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:17:b7:86:a3, length: 277, xid:0xcdc8ff73, flags: [none]

Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:32:46.701838 00:0f:1f:6f:ea:f5 > 00:12:17:b7:86:a3, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 335) 10.0.65.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 307, hops:2, xid:0xcdc8ff73, flags: [none]

Your IP: 10.0.65.172
Server IP: 134.58.127.4
Gateway IP: 10.0.65.254
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:32:46.703592 00:12:17:b7:86:a3 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 331: (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto: UDP (17), length: 317) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:12:17:b7:86:a3, length: 289, xid:0xcdc8ff73, flags: [none]

Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:32:46.726308 00:0f:1f:6f:ea:f5 > 00:12:17:b7:86:a3, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: UDP (17), length: 335) 10.0.65.254.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 307, hops:2, xid:0xcdc8ff73, flags: [none]

Your IP: 10.0.65.172
Server IP: 134.58.127.4
Gateway IP: 10.0.65.254
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

[ It received it's IP, time passes, now I forced it to renew ]

00:33:27.389614 00:12:17:b7:86:a3 > 00:0f:1f:6f:ea:f5, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 4130, offset 0, flags [DF], proto: UDP (17), length: 305) 10.0.65.172.68 > 134.58.127.4.67: BOOTP/DHCP, Request from 00:12:17:b7:86:a3, length: 277, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:33:27.408126 00:0f:1f:6f:ea:f5 > 00:12:17:b7:86:a3, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto: UDP (17), length: 335) 134.58.127.1.67 > 10.0.65.172.68: BOOTP/DHCP, Reply, length: 307, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Your IP: 10.0.65.172
Server IP: 134.58.127.4
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:33:29.390964 00:12:17:b7:86:a3 > 00:0f:1f:6f:ea:f5, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 4331, offset 0, flags [DF], proto: UDP (17), length: 305) 10.0.65.172.68 > 134.58.127.4.67: BOOTP/DHCP, Request from 00:12:17:b7:86:a3, length: 277, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:33:29.399099 00:0f:1f:6f:ea:f5 > 00:12:17:b7:86:a3, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto: UDP (17), length: 335) 134.58.127.1.67 > 10.0.65.172.68: BOOTP/DHCP, Reply, length: 307, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Your IP: 10.0.65.172
Server IP: 134.58.127.4
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:33:31.390964 00:12:17:b7:86:a3 > 00:0f:1f:6f:ea:f5, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 4531, offset 0, flags [DF], proto: UDP (17), length: 305) 10.0.65.172.68 > 134.58.127.4.67: BOOTP/DHCP, Request from 00:12:17:b7:86:a3, length: 277, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

00:33:31.399663 00:0f:1f:6f:ea:f5 > 00:12:17:b7:86:a3, ethertype IPv4 (0x0800), length 349: (tos 0x0, ttl 59, id 0, offset 0, flags [DF], proto: UDP (17), length: 335) 134.58.127.1.67 > 10.0.65.172.68: BOOTP/DHCP, Reply, length: 307, xid:0xcdc8ff73, flags: [none]

Client IP: 10.0.65.172
Your IP: 10.0.65.172
Server IP: 134.58.127.4
Client Ethernet Address: 00:12:17:b7:86:a3 [|bootp]

[ and keeps on repeating... ]

Attachments (0)

Change History (11)

comment:1 in reply to: ↑ description Changed 9 years ago by zardam@…

This bug is still present in 8.09_RC1. I've got exactly the same problem. It seems that default firewall rules are blocking the dhcp server renewal response packets. (and so this is not an udhcpc problem)

comment:2 Changed 8 years ago by jpa@…

As zardam said, the problem is apparently in the firewall rules. Adding following to /etc/firewall.user seems to fix the problem:
iptables -A input_wan -p udp --dport 68 -j ACCEPT

It seems like the default firewall rules do not detect REQUEST responses as "related", but let DISCOVER responses through for some reason.

comment:3 Changed 8 years ago by agriffis@…

Wow, this one's been killing me for months. Every 16 hours I see:

Jun 1 11:41:54 wrt2 root: removing wan (eth1) from firewall zone wan
Jun 1 11:41:56 wrt2 root: adding wan (eth1) to firewall zone wan

which is the result of this bug. Seems like any interface which is configured to use DHCP needs to have this rule applied, the most obvious being the wan interface.

comment:4 Changed 8 years ago by retracile <retracile@…>

It looks like #4781 is related.

comment:5 Changed 8 years ago by retracile <retracile@…>

This iptables change worked for me.

comment:6 Changed 8 years ago by anonymous

Please add this fix to the newest relase.
That will help many people.

comment:7 Changed 8 years ago by anonymous

Just to confirm, the addition to firewall.user worked for me as well. Thanks.

comment:8 Changed 8 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

see r17238

comment:9 Changed 3 years ago by anonymous

DHCP request (renewal) is sent to 134.58.127.4 but the DHCP reply comes from a different IP address (134.58.127.1). That's why it's not related and you need to explicitly allow incoming UDP 68. Are you sure that's not some weird DHCP server/relay misconfiguration? I don't think this patch applies in the general case.

comment:10 follow-up: Changed 3 years ago by anonymous

Actually, a DHCP client renewing it's lease will initially try to reach the server using unicast but will fall back to broadcast if that's not possible. Definitely some weird network configuration there, probably some relay involved. So in the latter case you don't have conntrack kicking in and the reply will have to be explicitly let in using the above ACCEPT rule. So it does make sense keeping the rule around.

comment:11 in reply to: ↑ 10 Changed 15 months ago by densmoke@…

Replying to anonymous:

Actually, a DHCP client renewing it's lease will initially try to reach the server using unicast but will fall back to broadcast if that's not possible. Definitely some weird network configuration there, probably some relay involved. So in the latter case you don't have conntrack kicking in and the reply will have to be explicitly let in using the above ACCEPT rule. So it does make sense keeping the rule around.

In my case udhcpc tries to sent renew to gateway, when dhcp server has another ip

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.