bwfm0 no networking when combined with trunk (Raspberry Pi 4)
Hello, I have setup a trunk combination on my Pi 4 to aggregate the ethernet port (bse0) with the wireless port (bwfm0) using the examples in the documentation: $ cat /etc/hostname.bse0 up $ cat /etc/hostname.bwfm0 join "MyAp" wpakey "blablabla" up $ cat /etc/hostname.trunk0 trunkproto failover trunkport bse0 trunkport bwfm0 inet autoconf And with the ethernet cable plugged in, I have networking through it: $ ifconfig lo0: flags=8049 mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 bse0: flags=8943 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 1 priority 0 llprio 3 trunk: trunkdev trunk0 media: Ethernet autoselect (1000baseT full-duplex) status: active enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active bwfm0: flags=8b43 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 4 priority 4 llprio 3 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (VHT-MCS0 mode 11ac) status: active ieee80211: join MyAp chan 36 bssid 30:93:bc:e3:e8:f4 -46dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp trunk0: flags=808843 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 5 priority 0 llprio 3 trunk: trunkproto failover bwfm0 port bse0 port master,active groups: trunk egress media: Ethernet autoselect status: active inet 192.168.1.16 netmask 0xff00 broadcast 192.168.1.255 pflog0: flags=141 mtu 33136 index 6 priority 0 llprio 3 groups: pflog But as soon as I remove the ethernet cable, I get no networking with the wireless access point $ ifconfig lo0: flags=8049 mtu 32768 index 3 priority 0 llprio 3 groups: lo inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 bse0: flags=8943 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 1 priority 0 llprio 3 trunk: trunkdev trunk0 media: Ethernet autoselect (none) status: no carrier enc0: flags=0<> index 2 priority 0 llprio 3 groups: enc status: active bwfm0: flags=8b43 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 4 priority 4 llprio 3 trunk: trunkdev trunk0 groups: wlan media: IEEE802.11 autoselect (VHT-MCS0 mode 11ac) status: active ieee80211: join MyAp chan 36 bssid 30:93:bc:e3:e8:f4 -45dBm wpakey wpaprotos wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp trunk0: flags=808843 mtu 1500 lladdr e4:5f:01:0e:a8:7f index 5 priority 0 llprio 3 trunk: trunkproto failover bwfm0 port active bse0 port master groups: trunk egress media: Ethernet autoselect status: active inet 192.168.1.16 netmask 0xff00 broadcast 192.168.1.255 pflog0: flags=141 mtu 33136 index 6 priority 0 llprio 3 groups: pflog Do I miss something? Nothing particular in dmesg, it's running 7.1 aarch64. I’ve tested the bwfm0 interface without being put in trunk, it works fine. -- David
Re: clang 13 space issues with KARL
On Thu, Apr 28, 2022 at 07:57:20PM +0200, Peter J. Philipp wrote: > On Thu, Apr 28, 2022 at 11:47:14AM -0600, Theo de Raadt wrote: > > >On Thu, Apr 28, 2022 at 10:44:09AM -0600, Theo de Raadt wrote: > > >> If people built properly sized machines there would be no problem. > > > > > >That's a little condescending don't you think? > > > > Not at all. > > > > If you don't use a tool as it was intended, you bear the consequences. > > > > *WE* built the tool. *WE* decided how it works. We even documented > > how much resources it typically needs. When people use it > > incorrectly, it is their own damn fault. *THEY* can make adjustments. > > > > But they cannot complain, because they did not pay and even if they > > had there is no warrantee. > > > > There is nothing condescending about telling someone their complaints > > about how something works are falling on deaf ears. I don't give a > > flying damn if KARL is hurting people who don't provide their machines > > with reasonable defaults. It is their own damn fault, and they can > > make manual accomodations for their own (completely stupid, IMHO) > > decisions. > > > > In this modern world is has become *impossible* to complain about > > any technology which doesn't work like you want, companies who take > > money don't give a damn. Here's the shocker: I will not be held > > to a higher standard than that. So Peter, your attitude stinks > > and your suggestion that anything I've said is "rude" rather than "real", > > thgat suggestion of yours is an insult. > > OK, I get it you're having a bad day. I'm sorry if I was rude. > > BTW do you know any operating systems that aren't BSD, Linux that I can > continue on? Surely you'd be in the know for this. > > -peter > This is the second time in a week someone has posted on tech or misc asking why we don't run well on ancient or ridiculously low resource machines. Your question about why KARL doesn't work well on such machines is effectively the same as "why doesn't LLVM work well on my ridiculously small machine?" I'd suggest that question should go to the llvm developer mailing list. We don't control how much RAM LLVM requires. I can totally see where theo is coming from. -ml
Re: vlan autoconf fails to conf at boot
On Fri, Apr 29, 2022 at 09:33:50PM -0700, George Morgan wrote: > I created a hostname.vlan10 file which has a single line: > > inet autoconf parent vge0 vnetid 10 lladdr ... > > At boot the interface fails to configure but after boot I can login to the > console and run "doas sh /etc/netstart" and the interface will configure. > > What am I doing wrong? Do I need to add something to rc.conf.local to force > the parent to configure first? The parent (vge0) has a static IPv4 address. The vlan has to be created and assigned parentage before autoconfiguration. Craft your hostname.vlan10 file in two lines: vnetid 10 parent vge0 addrr ... inet autoconf This information brought to my attention via Reddit: https://www.reddit.com/r/openbsd/comments/ua0wqd/no_longer_able_to_connect_to_the_internet_after/i5z24fj/
vlan autoconf fails to conf at boot
I created a hostname.vlan10 file which has a single line: inet autoconf parent vge0 vnetid 10 lladdr ... At boot the interface fails to configure but after boot I can login to the console and run "doas sh /etc/netstart" and the interface will configure. What am I doing wrong? Do I need to add something to rc.conf.local to force the parent to configure first? The parent (vge0) has a static IPv4 address. -- George Morgan gmor...@fastmail.fm
ldpd bridge question
hi
can i use veb instead of the bridge interface in the ldpd config ?
my mpw0 interface did not coming up.
the destination is reachable ( test with ping and ssh works )
mpw0 is member of my veb100 interface.
Holger
/etc 38>ldpctl sh l2vpn ps
Interface Neighbor PWID Status
mpw0 172.16.2.252 100 DOWN
/etc 39>ldpctl sh int
AF Interface State Linkstate Uptime Hello Timers ac
ipv4 em0 ACTIVE active 00:05:25 5/15 0
/etc 40>ldpctl sh nei
AF ID State Remote Address Uptime
ipv4 172.16.2.252 OPERATIONAL 172.16.2.252 00:05:40
/etc 41>ldpctl sh disco
AF ID Type Source Holdtime
ipv4 172.16.2.252 Targeted 172.16.2.252 45
peer1="172.16.2.252"
router-id 172.16.3.251
transport-preference ipv4
address-family ipv6 {}
address-family ipv4 {
interface em0
}
l2vpn vlan100 type vpls {
bridge veb100
pseudowire mpw0 {
neighbor-addr 172.16.2.252
neighbor-id 172.16.2.252
pw-id 100
}
}
Re: Font Path prompt in pkg_add
Ah, I guessed it was a feature now and I like it, it just threw me the first time. On Friday, April 29, 2022, Marc Espie wrote: > On Thu, Apr 28, 2022 at 02:37:39PM -0500, Christopher Turkel wrote: > > I'm on OpenBSD AMD64 7.1, fresh install > > I noticed when adding fonts via pkg_add it no longer prints out "You may > > wish to" after installation is finished. > > It's related to the evolution of X windows. > > Quite a few years ago, fonts were mostly handled server-side. > > Keith Packard started a large change in X fonts a few years ago. > > Most modern applications deal with X fonts client side. > > The rationale behind the change is that people who deal with > server-side font info will know about the way to change the > server path. > > Most new font directories are related to new applications, so > those messages were irrelevant. > > > Side note: there's a big focus from some people in OpenBSD > to keeping tools mostly silent (as opposed to the awfully > chatty linux thingies). Sometimes, this has disproportionate > consequences. End users do see those messages, whereas there's > a HUGE amount of churn in the tools that DON'T end in any visible > messages and has FAR MORE REACHING consequences to the quality > of those tools. ;) >
Re: Font Path prompt in pkg_add
On Thu, Apr 28, 2022 at 02:37:39PM -0500, Christopher Turkel wrote: > I'm on OpenBSD AMD64 7.1, fresh install > I noticed when adding fonts via pkg_add it no longer prints out "You may > wish to" after installation is finished. It's related to the evolution of X windows. Quite a few years ago, fonts were mostly handled server-side. Keith Packard started a large change in X fonts a few years ago. Most modern applications deal with X fonts client side. The rationale behind the change is that people who deal with server-side font info will know about the way to change the server path. Most new font directories are related to new applications, so those messages were irrelevant. Side note: there's a big focus from some people in OpenBSD to keeping tools mostly silent (as opposed to the awfully chatty linux thingies). Sometimes, this has disproportionate consequences. End users do see those messages, whereas there's a HUGE amount of churn in the tools that DON'T end in any visible messages and has FAR MORE REACHING consequences to the quality of those tools. ;)
