Staffan Thomén <staffan%shangtai.net@localhost> writes: > It works partially; DHCP replies don't seem to show up on the tap device so it > does not configure an address. I kept a tcpdump on the tap while running > dhcpcd and I can see dhcpcd retrying the sending to no avail. > > Naturally I checked that my DHCP server sends the replies and it does. They > arrive on the real interface on the bridge under test (another simultaneous > tcpdump) but do not seem to pass through to the tap interface. As I > understand it, broadcast packets should be sent to every interface on the > bridge. At this point I think it's probably time for you to dig into debugging the kernel. It sounds like there might be a problem > Additionally, even if I manually configure an address on the tap interface and > I can use it to connect using ssh, tcpdump on the tap device doesn't show the > unicast packets, which I don't think is right either. The problem could be about the bpf_tap calls as well as forwarding. > What I did to test this was: > > /etc/rc.d/dhcpcd stop, remove all addresses from all interfaces. > > ifconfig tap0 create up > ifconfig bridge0 create up > brconfig bridge0 add iwn0 stp iwn0 add tap0 > <wait until bridge settles into forwarding> > <in another terminal, start tcpdump -i tap0> > dhcpcd -1 tap0 I am unclear on the details, but it's not immediately obvious what running STP on one interface and not another interface of a bridge means. I think it's just that the protocol is spoken on one and thus it's eligible to be disabled, and that isn't true of the other. A bridge with tap0 and physical0 can't have a loop (unless you make a second bridge or something) so you could leave that out to simplify. > Watch dhcpcd properly configure IPv6 and finally add a zeroconf address as no > IPv4 broadcast reply from the server arrived. > > In my initial test I used the wired wm0 interface, and it acts the same as with > the wireless. > > It's entirely possible that I've fudged up something else in my network, I'd be > the first to say I don't know what I'm doing but I find that unlikely as the same > DHCP server servs a dozen or so clients on this network, some of which are > Xen domU:s that also live behind a bridge. My only hint is don't assume that you must be doing something wrong. It's possible that bridge support has gotten broken somehow. I had trouble with it under I think 7 and 8 with vr0 (net5501) and I just stopped using it. There, it was about which mac address was used for NDP and I would get broken v6 connectivity because hosts on e.g. vr0 were using the ethernet address of vr2 in the IPv6 NDP tables, or something like that. One issue is that tap0 will show "status: no carrier", presumably because the controlling device isn't open. That tends to cause various things to behave differently. So maybe you want something like tap, but that thinks it is connected to an ethernet that is valid but has nothing else. That may be doable by opening /dev/tap0 and just throwing away read data, and it might be that tap should have link0 flag that means 'pretend there is carrier'.
Attachment:
signature.asc
Description: PGP signature