On 09/03/16 15:52, Björn Ketelaars wrote:
Hello,

I'm using an old Soekris as switch/access point. For this I'm using the
following /etc/hostname.*:

/etc/hostname.ath0
mediaopt hostap
nwid "rfc1918 2"
wpakey xxxxxxxx
up

/etc/hostname.bridge0
add ath0
add vr0
add vr1
add vr2
add vr3
up

/etc/hostname.vr0
dhcp

/etc/hostname.vr1
up

/etc/hostname.vr2
up

/etc/hostname.vr3
up

Until recently this worked as expected: vr0 would get an IP via a dhcp request
and was reachable via this IP address. Devices on vr{1,2,3} and ath0 would also
get an IP address via dhcp from the same dhcp server as vr0.

Today I updated to a new snapshot. It seems that something has changed as
devices on vr{1,2,3} and ath0 are unable to retrieve an IP via dhcp.  Using
tcpdump I'm able to see that these devices are sending out a request:

tcpdump -i bridge0 port 67 or port 68
tcpdump: listening on bridge0, link-type EN10MB
15:32:43.481615 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a4 [|bootp]
15:32:45.668895 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0x5dee0000 [|bootp]
15:32:54.668290 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 [|bootp]
15:32:54.668503 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 [|bootp]
15:32:56.646297 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:2 
[|bootp]
15:32:56.646507 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:2 
[|bootp]
15:32:59.505877 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:5 
[|bootp]
15:32:59.506090 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:5 
[|bootp]
15:33:03.613177 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:9 
[|bootp]
15:33:03.613387 0.0.0.0.bootpc > 255.255.255.255.bootps: xid:0xa1b766a5 secs:9 
[|bootp]

Unfortunately there is no reply. Setting up the devices on vr{1,2,3} and ath0
with a fixed address results in expected behaviour: the devices are reachable.
vr0 however still gets a reply and thus an IP address via dhcp.

I did not make any changes in my network configuration. As a test however I
disabled pf without a change in behaviour.

It seems something has changed in the bridge functionality.

Something changed to the network stack. Packets dropped by bpf filters are now dropped before entering the stack.

Now dhclient(4) is lazy and the bpf filter it installs drop *any* answer, not only the ones for its interface. krw@ tried to fix that
but it broke setup with lazy dhcp servers.

If you don't use dhclient(4) inside your bridge you should see the replies.

Reply via email to