IRC channel logs
2026-06-05.log
back to list of logs
<rsmarples>solid_black: you would still need to bridge interfaces. one easy mechanism would be to have a bridge device being a directory and a symlink to each bridge port to the relevant interface device <rsmarples>for the case of lwip i would imagine it understands the concept for a bridge interface and just copy the packets around <rsmarples>if i understand how hurd works correctly this could be done as a separate process? <solid_black>let me try to remember what bridge interfaces are in the first place <solid_black>it was something like emulating hardware bridges in software, right? <solid_black>for tying multiple other interfaces together, so any packet coming *from* one of the interfaces attached to the bridge is received *on* other interfaces on the same bridge <solid_black>yeah, that also sounds like it could be a rather simple multi-echo transaltor <solid_black>but also maybe you don't want to physically copy packets around? <solid_black>why is such a thing called an netwrok interface in the first place? <solid_black>and not some other entity, like a group of interfaces <rsmarples>some bridge implementations allow it to work like an interface so you can assign it an address <rsmarples>but that's meh really - you could create a virtual interface and assign it to the bridge to get the same effect. <solid_black>it sounds like something that could be implemented either internally inside a network stack (in which case as said I don't see why it needs to be even considered to be its own network interface, it's a grouping of ones), or externally in case the network stack doesn't want to care <rsmarples>from a pure technical perspective i don't think the network stack iself would care <solid_black>what sense does the bridge interface having an address have? doesn't it just forward packets at the link layer? <damo22>its useful if the bridge can be assigned an address so you can basically send packets to the bridge? <rsmarples>so services such as httpd can bind to the bridge? <rsmarples>solid_black: bridge being an interface i see as a bad design decision on some platforms <solid_black>what does it mean to bind to the bridge? what does it mean to send packets to the bridge? <rsmarples>solid_black: you would ideally bind to an interface on the bridge, not the bridge itself <rsmarples>some platforms such as freebsd treat the bridge as a real interface, which imo is bad. <damo22>but supposing two nics are bridged, if you send to one of them does the other one also see the packets? <rsmarples>netbsd lists a bridge interface via ifconfig, but its not an interface that could be used as such - it exists just as a name for grouping <damo22>in that case there is no real need for an address for the bridge <solid_black>that is what I'm saying, if that mental model of what a bridge is is correct, it doesn't really make sense for it to be an interface or have its own address, it's just a grouping of other interfaces; but it's also not surprising that networking people would implement/expose it as a special interface <damo22>what happens if one nic is on one subnet and the other nic is on a different subnet, and you bridge them? how would the packets flow between subnets? <youpi>they're suppsoed to use a gateway in that case <youpi>even if that's silly since they're on the same L2 <solid_black>so according to my mental model above, the bridge would just forward the packets without regard for L3 concepts such as subnets <youpi>it just works at the L2 level <damo22>maybe youre right solid_black but the packets will be lost on the other net? <youpi>the fact that an ip can be put on the bridge interface is just an artifact <solid_black>damo22: well, they are effectively the same subnet then <youpi>damo22: they won't even be emitted <rsmarples>damo22: easier not to think of subnets, that happens at L3 <youpi>say host A is on 10.0.1.1/8 and B on 10.0.2.1/8 <youpi>say host A is on 10.0.1.1/24 and B on 10.0.2.1/24 <youpi>either A has a gatewa on 10.0.1.255 and can thus give it the packets, or it won't be able to reach 10.0.2.1 at all <youpi>in both cases, it won't try to send packets directly to 10.0.2.1 <youpi>since it doesn't know it's on the same L2 <solid_black>if A just emits a packet with 10.0.2.1 as the destination, and the bridge would echo it over to the other side, B will receive it, no? <solid_black>or are you saying that A has no idea it can even reach 10.0.2.x this way? <youpi>but A will never do such a thing <youpi>unless you add an explicit route <youpi>in which case it will use arp and find out the mac to be used as destination <youpi>you usually don't set a default route on the lan <youpi>and then it's to the gateway that you send the frame, not the final ip destination <rsmarples>eh? every node should have a gateway unless it only talks to the lan <youpi>the ip destination address will be the destination, but the mac destionation address witll be the gateway <youpi>solid_black: as in: you don't usually have the whole internet directly connected on your lan, directly reachable with arp :) <youpi>thus having to go through a gateway <rsmarples>a common case for bridging is to join your wireless access point with your physical cables. <rsmarples>the protocol that runs on top, such as TCP or UDP or ARP the bridge cares not <rsmarples>youpi: that's my use case for sure. i have scripts that add taps to my bridge dynamically, hurd being one <rsmarples>one of the reasons i wrote my own dhcp server as not a single one works well on NetBSD with bridges <damo22>i found hurd doesnt like sending packets to 255.255.255.255 <rsmarples>the only issue with using sockets to send DHCP discover is you can't tell it which interface to use <damo22>my implementation of "rumpnet" translator uses rump's /dev/bpf <rsmarples>so if you have >1 interface to run DHCP on it's an issue <damo22>maybe you should take a look what i did in rumpnet, its basically using netbsd's bpf to tx and rx packets <rsmarples>mmm, how does one start lwip in place if pfinet? <rsmarples>damo22: for some reason savannah doesn't load for me <damo22>unfortunately it only currently works on wm devices because the rump makefiles are in disarray and only one driver has been compiled <damo22>but in theory, this use of device driver could be extended to all netbsd NICs if someone fixes some makefiles in rump <rsmarples>damo22: sending to 255.255.255.255 while useful for DHCP, a good client really needs BPF so it can do ARP as well. otherwise dealing with raw sockets is too painful. <rsmarples>so while a bug (and I have an idea why) I'm not too bothered about fixing it either <azert>I think it would have been a better design if it was decided that the network interfaces drivers (and bridges and such) all talk the /dev/bpf language instead of raw packets <sneek>azert, gnucode says: I think we should change libnetfs -> libdirfs <azert>this would have allowed filtering at the driver level <azert>that in turn sometimes is hardware optimized <azert>with all the other goodies that bpf provides <azert>of course that was an issue with in-kernel drivers! But now that it was mostly moved to userspace we have more options <rsmarples>ok, putting hurd BPF directly into dhcpcd wasn't too hard. just need to make it less crashy <rsmarples>does valgrind or libasan work on hurd? I'm guessing no? <rsmarples>ok, hurd bpf is now stable in dhcpcd. no more reliance on libpcap <rsmarples>damo22: you seem to know a fair bit about rumpnet and hurd. how much do you know about if_link_status and how it will be handled in hurd? <rsmarples>gfff, net_recv_msg always returns the mtu + frame length as the packet size which smells wrong <rsmarples>no matter, the buffers are big enough but it's not optimal