OpenWrt Forum Archive

Topic: udhcpc breaks nat!

The content of this topic has been archived on 2 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello forum,

I'm having problems with the way udhcpc handles a renewed dhcp lease on my wan interface. Every time the lease is renewed (but without the ip being changed), all existing nat:ed tcp connections seem to break! This is more than slightly frustrating, since all my irc and msn connections reconnect. But what's even more frustrating is that I just can't seem to find out why this is happening! I've been digging around the hotplug system but I don't really get where anything would involve the nat tables.

Anyone else have a suggestion on where to continue?

edit:

This actually seems to be a problem with dnsmasq rather than with udhcpc. Since the udhcpc script creates a new resolv.conf every time the lease is renewed, dnsmasq detects this and reloads. This is strangely enough causing my Windows client to renew it's lease and drop all tcp connections. I haven't seen this behaviour using any other dhcp-server.

A working solution and improvement to this was to create a static /etc/resolv.conf containing only 127.0.0.1 and add resolv-file=/tmp/resolv.conf to dnsmasq.conf.

edit2:

I have also noticed that dnsmasq is unable to provide an address to a linux box of mine running gentoo with dhclient. Dhclient keeps complaining over udp checksum errors. If I switch to udhcpc on the gentoo box, everthing works out fine. There seems to be a problem with the OpenWRT dnsmasq binary in combination with my Asus WL-500gP hardware.

(Last edited by term on 13 Jul 2006, 11:49)

I've noticed the same. It calls /usr/share/udhcpc/default.script with a deconfig, then calls it again with a renew/bound. I've checked this by editing the default default.script (!!!) and writing to the log for every action.

I don't know why it does this but unless you're sending your link up/down all the time I think it should be safe enough to edit the script and disable the bits for deconfig, so it doesn't change the ip address. If you want to do it well you'd have to check if this is really a deconfig or simply renewing the same address... and the only way to know it is after it calls the renew. Maybe any solutions to this would be a tad too complicated and just disabling the part for deconfig is fine.

After doing the steps in the default.script manually (with ifconfig and route) I came to the conclusion that the problem was with dnsmasq instead. I really cannot understand how dnsmasq can be causing clients to drop their tcp connections, but I will fire up ethereal to investigate this.

(Last edited by term on 12 Jul 2006, 00:34)

The problem is indeed in "udhcpc". On every DHCP renewal, it calls an external script to do some stuff. Here is a snippet from "udhcpc --help":

-s,--script=file        Run file at DHCP events (default /usr/share/udhcpc/default.script)

So this file is run twice on DHCP renewal which triggers the following two events:
* deconfig - the wan interface is brought down
* renew|bond - the wan interface is brought up and IP configured

The above happens even if the IP does not change (which is not very clever).

All connections drop because OpenWRT uses MASQUERADE by default for NAT - MASQUERADE forgets old connections when interface goes down.

If your IP address does not change often, it's better to use SNAT which does not drop connections if the interface goes up/down for a short period of time and your IP address is still the same.

My solution was to use the hook which OpenWRT developers left in "/usr/share/udhcpc/default.script". On "renew|bond" if a user script named "/etc/udhcpc.user" exists, it is called. So here is what I put in "/etc/udhcpc.user":

#!/bin/bash

echo 'Custom SNAT (disabling default MASQUERADE which drops connections on every DHCP renewal)'
/usr/sbin/iptables -t nat -F zone_wan_nat
/usr/sbin/iptables -t nat -I zone_wan_nat -o "$interface" -j SNAT --to-source "$ip"

The discussion might have continued from here.