Subject: Re: A strange problem involving PF and DHCP and an ethernet ADSL modem
To: Mark Cullen <mark.r.cullen@gmail.com>
From: matthew sporleder <msporleder@gmail.com>
List: netbsd-users
Date: 06/16/2006 10:03:33
On 6/15/06, Mark Cullen <mark.r.cullen@gmail.com> wrote:
> Mark Cullen wrote:
> > Hi all,
> >
> > I have switched to NetBSD, with only one hiccup ( which was my own silly
> > mistake ;) ).
> >
> > I am having a slight problem with PF and dhclient, and my ADSL modem. I
> > can't really explain it to well, so the low down is: every so often
> > (once a day?!) my connection dies. The ADSL modem sends a 'DHCPNAK'
> > (don't know why exactly yet):
> >
> > ---
> > Jun 16 00:27:15 bone dhclient: DHCPREQUEST on fxp1 to 192.168.0.1 port 67
> > Jun 16 00:27:15 bone dhclient: DHCPACK from 192.168.0.1
> > Jun 16 00:27:15 bone dhclient: bound to 88.96.18.86 -- renewal in 52
> > seconds.
> > Jun 16 00:28:07 bone dhclient: DHCPREQUEST on fxp1 to 192.168.0.1 port 67
> > Jun 16 00:28:07 bone dhclient: DHCPNAK from 192.168.0.1
> > Jun 16 00:28:07 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> > port 67 interval 4
> > ---
> >
> > and then dhclient will sit forever in a loop of:
> >
> > ---
> > Jun 16 00:53:51 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> > port 67 interval 8
> > Jun 16 00:53:59 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> > port 67 interval 3
> > Jun 16 00:54:02 bone dhclient: No DHCPOFFERS received.
> > Jun 16 00:54:02 bone dhclient: No working leases in persistent database
> > - sleeping.
> > ---
> >
> > over and over and over. It won't pick up an address again unless I do a
> > `dhclient -r` followed by a `dhclient fxp1`.
> >
> > What's weird about this is that PF is logging the following at the same
> > times as DHCP stops working (192.168.0.1 is the modem's ip address):
> >
> > ---
> > 00:28:07.015564 rule 0/0(match): block in on fxp1: IP 192.168.0.1.67 >
> > 255.255.255.255.68: BOOTP/DHCP, Reply, length: 548
> > ---
> >
> > even though I have a rule in pf which should be allowing this to pass
> > through, or at least I think:
> >
> > ---
> > pass quick on $ext_if proto tcp from 192.168.0.1 port 67 to any port 68
> > keep state
> > ---
>
> Ok, silly me. DHCP is UDP not TCP. I have changed this rule to udp
> instead, and it is no longer being blocked in the logs and is now being
> matched by this rule. However, I am still seeing the same looping
> DHCPDISCOVER forever.
>

I think it's actually both udp and, possibly, tcp.

> I can trigger this at will by just killing off dhclient (not `dhclient
> -r`) and trying to restart it again by running `dhclient fxp1`. I get a
> NAK from the modem and it then gets stuck:
>
> ---
> Jun 16 01:07:09 bone dhclient: DHCPREQUEST on fxp1 to 255.255.255.255
> port 67
> Jun 16 01:07:14 bone dhclient: DHCPREQUEST on fxp1 to 255.255.255.255
> port 67
> Jun 16 01:07:14 bone dhclient: DHCPNAK from 192.168.0.1
> Jun 16 01:07:14 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> port 67 interval 8
> Jun 16 01:07:22 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> port 67 interval 3
> Jun 16 01:07:25 bone dhclient: No DHCPOFFERS received.
> Jun 16 01:07:25 bone dhclient: No working leases in persistent database
> - sleeping.
> Jun 16 01:07:27 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> port 67 interval 6
> Jun 16 01:07:33 bone dhclient: DHCPDISCOVER on fxp1 to 255.255.255.255
> port 67 interval 5
> Jun 16 01:07:38 bone dhclient: No DHCPOFFERS received.
> Jun 16 01:07:38 bone dhclient: No working leases in persistent database
> - sleeping.
> ---
>
> Any thoughts / suggestions?
>
> >
> > Is there anything wrong with this rule that I am missing? Perhaps PF
> > isn't allowing 255.255.255.255 'by default' and there is some option to
> > change the behaviour? Obviously I don't particularly want to have to
> > restart dhclient every single day when it dies, so any help would be
> > really hugely appreciated!!
> >
> > Thanks in advance,
> > Mark
> >

Try running dhcpd in verbose mode or tcpdump-ing the server's
interface and look for broadcasts.  Your server definitely saw the
unicast because it sent you the NAK.