IPv6 neighbour solicitations being sent from wrong address?
hi, running: FreeBSD 15.0-CURRENT #35 lf/main-n269047-3466614a5454: Tue Apr 30 03:48:53 BST 2024 srcma...@daphne.eden.le-fay.org:/src/obj/src/freebsd/lf/main/amd64.amd64/sys/LF i have a host with a single vnet jail. the host has an epair interface: # ifconfig epair0a epair0a: flags=1008843 metric 0 mtu 1500 options=8 ether 020c.2a51.7a0a inet6 fe80::1%epair0a/64 scopeid 0x6 groups: epair media: Ethernet 10Gbase-T (10Gbase-T ) status: active nd6 options=1 the jail has the other end of the epair interface: # ifconfig epair0b epair0b: flags=1008843 metric 0 mtu 1500 options=8 ether 020c.2a51.7a0b inet 185.73.44.139/32 broadcast 185.73.44.139 inet6 fe80::2%epair0b/64 scopeid 0x7 inet6 2001:ba8:4015:::1/128 groups: epair media: Ethernet 10Gbase-T (10Gbase-T ) status: active nd6 options=1 the host has a route to 2001:ba8:4015:::1/128 via the epair interface: Internet6: Destination Gateway Flags Nhop# MtuNetif Expire 2001:ba8:4015:::1 link#6UH 22 1500 epair0a looking at tcpdump, it seems like the host is sending ICMP neighbour solicitation over the epair interface from a strange IP address, and the jail ignores the requests until the host sends from fe80::1 instead: 11:03:13.418029 02:0c:2a:51:7a:0a > 02:0c:2a:51:7a:0b, ethertype IPv6 (0x86dd), length 86: 2001:ba8:4015:1::1 > 2001:ba8:4015:::1: ICMP6, neighbor solicitation, who has 2001:ba8:4015:::1, length 32 11:03:14.417986 02:0c:2a:51:7a:0a > 02:0c:2a:51:7a:0b, ethertype IPv6 (0x86dd), length 86: 2001:ba8:4015:1::1 > 2001:ba8:4015:::1: ICMP6, neighbor solicitation, who has 2001:ba8:4015:::1, length 32 11:03:16.527722 02:0c:2a:51:7a:0a > 33:33:ff:00:00:01, ethertype IPv6 (0x86dd), length 86: fe80::1 > ff02::1:ff00:1: ICMP6, neighbor solicitation, who has 2001:ba8:4015:::1, length 32 11:03:16.527746 02:0c:2a:51:7a:0b > 02:0c:2a:51:7a:0a, ethertype IPv6 (0x86dd), length 86: fe80::2 > fe80::1: ICMP6, neighbor advertisement, tgt is 2001:ba8:4015:::1, length 32 2001:ba8:4015:1::1 is configured on a different interface on the host, xn0. is this expected behaviour? i would have expected the host to send these from the IP addressed configured on the relevant interface, which is fe80::1. signature.asc Description: PGP signature
[Bug 271366] Invoking IPv6 network device address event may sleep with the following non-sleepable locks held
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366 Ricardo Branco changed: What|Removed |Added CC||rbra...@suse.com --- Comment #3 from Ricardo Branco --- Same here on QEMU VM: Invoking IPv6 network device address event may sleep with the following non-sleepable locks held: exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xf80002988600) locked @ /usr/src/sys/dev/virtio/network/if_vtnet.c:2212 stack backtrace: #0 0x804a587c at witness_debugger+0x6c #1 0x804a6a59 at witness_warn+0x3e9 #2 0x805d1f41 at in6_update_ifa+0xc81 #3 0x805fd6cf at in6_ifadd+0x1ef #4 0x805f9db0 at nd6_ra_input+0x1030 #5 0x805cbbba at icmp6_input+0x5ea #6 0x805e4241 at ip6_input+0xd41 #7 0x805618fd at netisr_dispatch_src+0xad #8 0x8055bf9a at ether_demux+0x16a #9 0x8055d67a at ether_nh_input+0x3ea #10 0x805618fd at netisr_dispatch_src+0xad #11 0x8055c3f5 at ether_input+0xe5 #12 0x8035b594 at vtnet_rx_vq_process+0x7b4 #13 0x803f5b16 at ithread_loop+0x266 #14 0x803f1f32 at fork_exit+0x82 #15 0x80724a4e at fork_trampoline+0xe lock order reversal: (sleepable after non-sleepable) 1st 0xf80002988600 vtnet0-rx0 (vtnet0-rx0, sleep mutex) @ /usr/src/sys/dev/virtio/network/if_vtnet.c:2212 2nd 0x80faf7c8 in6_multi_sx (in6_multi_sx, sx) @ /usr/src/sys/netinet6/in6_mcast.c:1217 lock order vtnet0-rx0 -> in6_multi_sx attempted at: #0 0x804a544b at witness_checkorder+0xb7b #1 0x8043e2ed at _sx_xlock+0x5d #2 0x805d9001 at in6_joingroup+0x31 #3 0x805d22f4 at in6_update_ifa+0x1034 #4 0x805fd6cf at in6_ifadd+0x1ef #5 0x805f9db0 at nd6_ra_input+0x1030 #6 0x805cbbba at icmp6_input+0x5ea #7 0x805e4241 at ip6_input+0xd41 #8 0x805618fd at netisr_dispatch_src+0xad #9 0x8055bf9a at ether_demux+0x16a #10 0x8055d67a at ether_nh_input+0x3ea #11 0x805618fd at netisr_dispatch_src+0xad #12 0x8055c3f5 at ether_input+0xe5 #13 0x8035b594 at vtnet_rx_vq_process+0x7b4 #14 0x803f5b16 at ithread_loop+0x266 #15 0x803f1f32 at fork_exit+0x82 #16 0x80724a4e at fork_trampoline+0xe pflog0: promiscuous mode enabled -- You are receiving this mail because: You are the assignee for the bug.
[Bug 253888] exclusive sleep mutex vtnet0-rx0 (vtnet0-rx0) r = 0 (0xfffff800035d4780) locked
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253888 Ricardo Branco changed: What|Removed |Added CC||rbra...@suse.com --- Comment #6 from Ricardo Branco --- Perhaps related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271366 ? -- You are receiving this mail because: You are the assignee for the bug.
review request: changing the default ifconfig(8) address format to CIDR
hi, i've just submitted this PR: https://github.com/freebsd/freebsd-src/pull/1216 which contains this commit: commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main, hemlock/lf/main) Author: Lexi Winter Date: Sat May 4 16:11:21 2024 +0100 ifconfig(8): change default IP address format to 'cidr' 'netmasks' haven't been used in IP networking for decades. Change the default address format for both IPv4 and IPv6 addreses in ifconfig(8) to 'cidr', which prints addreses in the format most users will be more familiar with. The previous format is still available using -finet:hex or -finet6:numeric. imp@ suggested i should ask arch@ and net@ about this, so here i am! i understand there might be some backward-compat concerns with scripting here, but it's well past time this change was made, and anyone who really can't update their scripts can use ifconfig -f or $IFCONFIG_FORMAT to retain the old behaviour. signature.asc Description: PGP signature
How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD
Hello. I've just installed the CloudFlare client + GUI on Ubuntu,that I have virtualized with bhyve. Cloudflare does not work on FreeBSD. The instructions that I have followed are located here : https://youtu.be/4JuOUjCSj44 Installing it in this way,it will run only on the IP assigned to Ubuntu inside the VM. For me the IP of FreeBSD is different from the IP assigned to Ubuntu. Configured in this way it's not useful. I want Cloudflare to take the IP address of FreeBSD. To achieve this goal,I should change my network configuration,in a way that I use the same IP for FreeBSD and Ubuntu. That's what I want to do,but I don't know how to do it. But I'm sure that I will be able to do it if someone can give me some advice. I can explain how I have configured my network,so you can explain what I should change to have the same IP. For example,to boot Ubuntu with bhyve,I use the following parameter : -s 13,virtio-net,tap19 \ /etc/rc.conf : ifconfig_em0="DHCP" local_unbound_enable="YES" cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19 tap20 em0" ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm tap4 addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10 addm tap11 addm tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm tap19 addm tap20" /boot/loader.conf if_tap_load="YES" if_bridge_load="YES" bridgestp_load="YES" /etc/sysctl.conf net.link.tap.up_on_open=1 net.inet.ip.forwarding=1 net.inet.ip.random_id=1 So,ok. I think you have understood what I want to do. Please help me. Thanks. -- Mario.
Re: How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD
Hi Mario You can set the ip if the Ubuntu machine as the default route on the freeBSD host. This will take all the traffic oroginating in freeBSD host through the warp-tunnel. And configure a DNAT iptables rule in the Ubuntu machine to return the traffic back to freeBSD machine. This way you could utilise the warp-cloud flare tunnel from the freeBSD host even though it runs on the Ubuntu guest. And both have different IPs. On Sun, 5 May 2024 at 12:23 AM, Mario Marietto wrote: > Hello. > > I've just installed the CloudFlare client + GUI on Ubuntu,that I have > virtualized with bhyve. Cloudflare does not work on FreeBSD. The > instructions that I have followed are located here : > > https://youtu.be/4JuOUjCSj44 > > Installing it in this way,it will run only on the IP assigned to Ubuntu > inside the VM. For me the IP of FreeBSD is different from the IP assigned > to Ubuntu. Configured in this way it's not useful. > > I want Cloudflare to take the IP address of FreeBSD. > > To achieve this goal,I should change my network configuration,in a way > that I use the same IP for FreeBSD and Ubuntu. > > That's what I want to do,but I don't know how to do it. But I'm sure that > I will be able to do it if someone can give me some advice. > > I can explain how I have configured my network,so you can explain what I > should change to have the same IP. > > For example,to boot Ubuntu with bhyve,I use the following parameter : > > -s 13,virtio-net,tap19 \ > > > /etc/rc.conf : > > ifconfig_em0="DHCP" > local_unbound_enable="YES" > cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 > tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19 tap20 em0" > ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm tap4 > addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10 addm tap11 addm > tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm > tap19 addm tap20" > > > /boot/loader.conf > > if_tap_load="YES" > if_bridge_load="YES" > bridgestp_load="YES" > > > /etc/sysctl.conf > > net.link.tap.up_on_open=1 > net.inet.ip.forwarding=1 > net.inet.ip.random_id=1 > > > So,ok. I think you have understood what I want to do. Please help me. > Thanks. > > -- > Mario >
Re: How to configure the networking on FreeBSD to assign the same IP between host and guest in order to make work CloudFlare Warp on FreeBSD
So. Please help me further... Let's say that the IP number assigned to Ubuntu is 192.168.1.9,on FreeBSD I do : /etc/rc.conf : defaultrouter="192.168.1.9" ? even if the VM starts after the booting of FreeBSD ? About configuring the DNAT iptables rule I have no idea. Please help me to understand how to do it. On Sat, May 4, 2024 at 9:22 PM Apoorv Sachan wrote: > Hi Mario > > You can set the ip if the Ubuntu machine as the default route on the > freeBSD host. > This will take all the traffic oroginating in freeBSD host through the > warp-tunnel. > > And configure a DNAT iptables rule in the Ubuntu machine to return the > traffic back to freeBSD machine. > > This way you could utilise the warp-cloud flare tunnel from the freeBSD > host even though it runs on the Ubuntu guest. And both have different IPs. > > On Sun, 5 May 2024 at 12:23 AM, Mario Marietto > wrote: > >> Hello. >> >> I've just installed the CloudFlare client + GUI on Ubuntu,that I have >> virtualized with bhyve. Cloudflare does not work on FreeBSD. The >> instructions that I have followed are located here : >> >> https://youtu.be/4JuOUjCSj44 >> >> Installing it in this way,it will run only on the IP assigned to Ubuntu >> inside the VM. For me the IP of FreeBSD is different from the IP assigned >> to Ubuntu. Configured in this way it's not useful. >> >> I want Cloudflare to take the IP address of FreeBSD. >> >> To achieve this goal,I should change my network configuration,in a way >> that I use the same IP for FreeBSD and Ubuntu. >> >> That's what I want to do,but I don't know how to do it. But I'm sure that >> I will be able to do it if someone can give me some advice. >> >> I can explain how I have configured my network,so you can explain what I >> should change to have the same IP. >> >> For example,to boot Ubuntu with bhyve,I use the following parameter : >> >> -s 13,virtio-net,tap19 \ >> >> >> /etc/rc.conf : >> >> ifconfig_em0="DHCP" >> local_unbound_enable="YES" >> cloned_interfaces="bridge0 tap0 tap1 tap2 tap3 tap4 tap5 tap6 tap7 tap8 tap9 >> tap10 tap11 tap12 tap13 tap14 tap15 tap16 tap17 tap18 tap19 tap20 em0" >> ifconfig_bridge0="addm em0 addm tap0 addm tap1 addm tap2 addm tap3 addm tap4 >> addm tap5 addm tap6 addm tap7 addm tap8 addm tap9 addm tap10 addm tap11 addm >> tap12 addm tap13 addm tap14 addm tap15 addm tap16 addm tap17 addm tap18 addm >> tap19 addm tap20" >> >> >> /boot/loader.conf >> >> if_tap_load="YES" >> if_bridge_load="YES" >> bridgestp_load="YES" >> >> >> /etc/sysctl.conf >> >> net.link.tap.up_on_open=1 >> net.inet.ip.forwarding=1 >> net.inet.ip.random_id=1 >> >> >> So,ok. I think you have understood what I want to do. Please help me. >> Thanks. >> >> -- >> Mario >> > -- Mario.
Re: review request: changing the default ifconfig(8) address format to CIDR
On 4 May 2024, at 16:34, Lexi Winter wrote: > hi, > > i've just submitted this PR: > > https://github.com/freebsd/freebsd-src/pull/1216 > > which contains this commit: > > commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main, > hemlock/lf/main) > Author: Lexi Winter > Date: Sat May 4 16:11:21 2024 +0100 > >ifconfig(8): change default IP address format to 'cidr' > >'netmasks' haven't been used in IP networking for decades. Change the >default address format for both IPv4 and IPv6 addreses in ifconfig(8) to >'cidr', which prints addreses in the format most users will be more >familiar with. > >The previous format is still available using -finet:hex or -finet6:numeric. > > imp@ suggested i should ask arch@ and net@ about this, so here i am! > > i understand there might be some backward-compat concerns with scripting > here, but it's well past time this change was made, and anyone who > really can't update their scripts can use ifconfig -f or > $IFCONFIG_FORMAT to retain the old behaviour. Do we need to care about supporting (/ do we currently support) historical non-contiguous netmasks? At a glance the CIDR code doesn’t handle that and will stop at the first 0, so changing to that by default would break such setups. Jess
Re: review request: changing the default ifconfig(8) address format to CIDR
Jessica Clarke: > On 4 May 2024, at 16:34, Lexi Winter wrote: > Do we need to care about supporting (/ do we currently support) > historical non-contiguous netmasks? At a glance the CIDR code doesn’t > handle that and will stop at the first 0, so changing to that by > default would break such setups. i have never had a need to try this, but i just tested it and it does not appear to be supported at least in 15.0: # ifconfig bridge2 create # ifconfig bridge2 192.0.2.1 netmask 255.0.255.0 # ifconfig bridge2 bridge2: flags=1008843 metric 0 mtu 1500 options=0 ether 58:9c:fc:00:16:69 inet 192.0.2.1 netmask 0x broadcast 192.0.255.255 [snip] # ifconfig bridge2 destroy # ifconfig bridge2 create # ifconfig bridge2 192.0.2.1 netmask 255.255.255.88 # ifconfig bridge2 bridge2: flags=1008843 metric 0 mtu 1500 options=0 ether 58:9c:fc:00:16:69 inet 192.0.2.1 netmask 0xffe0 broadcast 192.0.2.31 [snip] (0xffe0 = 255.255.255.224) a quick Internet search suggests that non-contiguous netmasks were deprecated when CIDR was introduced, so around 1993. signature.asc Description: PGP signature
[Bug 275920] Kernel crash in sys/netlink/route/iface.c:124
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275920 --- Comment #5 from Mike Cui --- Any chance we can get this fixed for 14.1? It would be nice if 14.1 worked out of the box without having to cross compile my own custom kernel. -- You are receiving this mail because: You are the assignee for the bug.
