[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: About bridges
Jason Mitchell wrote:
On 5/30/21 11:29 AM, Robert Swindells wrote:
Staffan Thomén <staffan%shangtai.net@localhost> wrote:
Robert Swindells wrote:
Staffan Thomén<staffan%shangtai.net@localhost> wrote:
No takers for this? Can someone at least check that I'm not crazy?
Which bit of "this" ?
Your last message suggests to me that you have a working bridged
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
Do you need to use DHCP to get an address ?
I have a theory that the MAC address learning feature of bridge(4)
doesn't work well with BOOTP/DHCP, I have a local change to explicitly
add the MAC address of each interface. You could look at the state of the
address cache by running 'brconfig -a'.
People use tap(4) in two ways:
1) To add an extra IP address for the host machine. 2) To connect a
software emulator like qemu to the host.
In usage 2, you don't setup an IP address for the tap(4) device, the
virtual network device in the emulator has a different MAC address to the
tap(4) device and can get an IP address using DHCP.
Also, there is a shortcut in bridge(4) if it detects that a packet is for
an "internal" address.
If you do add an IP address for the tap(4) device then that will be
treated as an internal one.
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
I think that usage will be hitting the shortcut I described above, the
packets are treated as being for the host machine so don't get sent to
the tap interface.
Okay, I got this working with a wired interface but only by adding an IP
address to the physical nic (in my case axe0). The address wasn't in the
same subnet as the address for tap1 (I used 169.254.169.254). Here are my
commands (below). At some point I'll try to get DHCP up and running.
Thanks for looking into this, but I think the original premise got lost
somewhere. I know what tap is for, but it was what was hinted to me to use
instead of dedicated psedo-interface for the host system like OpenBSD's (or
NetBSD-current:s) vether(4) interface.
The scenario here is a system with multiple NICs deployed on premise
somewhere, the physical interfaces are bridged together so that the users
don't have to worry about plugging into the right one, they can just pick one
and it will Just Work(tm).
The problem that I ran into when trying to set this up was that if an address
is configured on one of the physical interfaces, it will work with a bridge
_so long as it is one of those with a cable connected_. The workaround I was
given for this was not to try to force the interface to be up so that the
address wouldn't be set to <detached> and effectively disabled, but to use
tap(4) or the new vehter(4) device from current for the host address.
DHCP and broadcast packets not arriving only came in later when I tried using
tap(4) and found that it didn't quite work as I would have expected.
I also have to apologise for muddling the issue, last night when I tried
fidding with bridges again I could not make things work by manually assignin
an address to the tap interface. I have a sneaking suspicion that there were
still addresses in my ARP table last time from when the system had been
configured normally on one of the physical interfaces that made manual
configuration work on tap (but no proof that this is even possible).
This whole issue is mostly academic in that it's not a big deal for me that
one cable must always be connected to a particular port, but I feel like
there's a problem worth solving here.
If I didn't already have too may hobby projects I'd dive in and to to track it
down myself, but I have very little experience with kernel hacking and a vague
idea that normal rules might not apply so I was hoping that someone would wake
up and go "oh damn, I know why that happens!" and fix it :-)
Neat trick of using a LL address, but it's kind of moot if a cable must be
attached to a particular interface.
Main Index |
Thread Index |