[Bug 259645] crash in_cksumdata (sys/amd64/amd64/in_cksum.c:113) via in4_cksum (sys/netpfil/pf/in4_cksum.c:117) after FreeBSD 13.0 p5 update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645 --- Comment #25 from Arnaud de Prelle --- Created attachment 229952 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229952=edit apn dmesg.boot -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 259645] crash in_cksumdata (sys/amd64/amd64/in_cksum.c:113) via in4_cksum (sys/netpfil/pf/in4_cksum.c:117) after FreeBSD 13.0 p5 update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645 --- Comment #24 from Arnaud de Prelle --- Created attachment 229951 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229951=edit apn pciconf -lv -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 259645] crash in_cksumdata (sys/amd64/amd64/in_cksum.c:113) via in4_cksum (sys/netpfil/pf/in4_cksum.c:117) after FreeBSD 13.0 p5 update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645 --- Comment #23 from Arnaud de Prelle --- Created attachment 229950 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=229950=edit apn PF Firewall configuration -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 259645] crash in_cksumdata (sys/amd64/amd64/in_cksum.c:113) via in4_cksum (sys/netpfil/pf/in4_cksum.c:117) after FreeBSD 13.0 p5 update
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259645 --- Comment #22 from Arnaud de Prelle --- Hi, I patched yesterday at around 8AM CET from 13.0-p4 to 13.0-p5 and experienced two crashes in a a few minutes at around 11PM CET. I guess it's related to this bug and will apply the workaround. I'm running on a Bare Metal server (i5-3570S). More server details in attachments (prefixed by apn). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 260260] igb(4) I35{0,4} parrent <--> vlan jumbo frame mtu mismatch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260260 --- Comment #1 from Marek Zarychta --- Last time tested on 13.0-STABLE stable/13-n248421-3b936a8c889 where the issue persists. It is also worth mentioning that turning off vlanmtu vlanhwtag vlanhwfilter vlanhwtso vlanhwcsum on parents doesn't solve it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 260260] igb(4) I35{0,4} parrent <--> vlan jumbo frame mtu mismatch
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260260 Marek Zarychta changed: What|Removed |Added CC||n...@freebsd.org Keywords||regression -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 221122] Attaching interface to a bridge stops all traffic on uplink NIC for few seconds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122 Mason Loring Bliss changed: What|Removed |Added Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug.
[Bug 221122] Attaching interface to a bridge stops all traffic on uplink NIC for few seconds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122 --- Comment #19 from Mason Loring Bliss --- I saw this issue on FreeBSD 13.0-RELEASE, and following kbowling's recommendation, also tried the most recent 13-STABLE images. This latter is where I've gathered data. Same issue: Add an epair half to a bridge and things go away for several seconds. The delay is quite possibly longer in -STABLE but I might be imagining it. Either way, documented below. Note that on literally the same hardware, the same operations cause no delay under Debian Bullseye: Have a bridge, add a vnet device to it, and everything keeps flowing without interruption, which is useful since these boxes are hypervisors and running a variety of generally network-oriented tasks. # freebsd-version -ku ; uname -a 13.0-STABLE 13.0-STABLE FreeBSD amazon.int.blisses.org 13.0-STABLE FreeBSD 13.0-STABLE #0 stable/13-n248302-2cd26a286a9: Thu Dec 2 02:40:58 UTC 2021 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 # dmesg | tail uhid0 on uhub3 uhid0: on usbus1 Security policy loaded: MAC/ntpd (mac_ntpd) epair0a: Ethernet address: 02:52:8f:32:b1:0a epair0b: Ethernet address: 02:52:8f:32:b1:0b epair0a: link state changed to UP epair0b: link state changed to UP igb0: link state changed to DOWN epair0a: promiscuous mode enabled igb0: link state changed to UP # dmesg | grep igb0 igb0: mem 0xfb72-0xfb73,0xfb7c4000-0xfb7c7fff irq 40 at device 0.0 on pci3 igb0: EEPROM V0.93-0 eTrack 0x86b2 igb0: Using 1024 TX descriptors and 1024 RX descriptors igb0: Using 6 RX queues 6 TX queues igb0: Using MSI-X interrupts with 7 vectors igb0: Ethernet address: 00:25:90:a6:a5:60 igb0: netmap queues/slots: TX 6/1024, RX 6/1024 igb0: promiscuous mode enabled igb0: link state changed to UP igb0: link state changed to DOWN igb0: link state changed to UP /home/mason$ date ; ssh root@amazon ifconfig bridge0 addm epair0a ; date Mon 06 Dec 2021 10:36:37 PM EST Mon 06 Dec 2021 10:36:41 PM EST /home/mason$ date ; ssh root@amazon ifconfig bridge0 deletem epair0a ; date Mon 06 Dec 2021 10:37:00 PM EST Mon 06 Dec 2021 10:37:05 PM EST /home/mason$ date ; ssh root@amazon date ; date Mon 06 Dec 2021 10:38:14 PM EST Mon Dec 6 22:38:14 EST 2021 Mon 06 Dec 2021 10:38:14 PM EST -- You are receiving this mail because: You are the assignee for the bug.
[Bug 221122] Attaching interface to a bridge stops all traffic on uplink NIC for few seconds
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221122 Mason Loring Bliss changed: What|Removed |Added Resolution|Not A Bug |--- CC||ma...@blisses.org Status|Closed |Open --- Comment #18 from Mason Loring Bliss --- Re-opening as this is still an issue, and shouldn't be. Details to follow. -- You are receiving this mail because: You are the assignee for the bug.
Re: Weirdness with same-host IPv6 packets
So tracing the traffic using tcpdump, the UDP packet itself is being sent, it's just not making it to the process for some reason: 19:10:23.502313 IP6 (flowlabel 0xc0e2c, hlim 64, next-header UDP (17) payload length: 16) 2001:470:bc52:4::101.56339 > 2001:470:bc52:4::101.: [bad udp cksum 0xc3b2 -> 0x9223!] UDP, length 8 Doing TCP, it looks like it takes 3 tries before it finally makes it through: 19:12:27.284049 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [S], cksum 0xc3bf (incorrect -> 0x76e0), seq 827082993, win 65535, options [mss 16324,nop,wscale 14,sackOK,TS val 194207998 ecr 0], length 0 19:12:28.284624 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [S], cksum 0xc3bf (incorrect -> 0x72f7), seq 827082993, win 65535, options [mss 16324,nop,wscale 14,sackOK,TS val 194208999 ecr 0], length 0 19:12:30.486455 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [S], cksum 0xc3bf (incorrect -> 0x6a5d), seq 827082993, win 65535, options [mss 16324,nop,wscale 14,sackOK,TS val 194211201 ecr 0], length 0 19:12:30.486525 IP6 (flowlabel 0x81949, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101. > 2001:470:bc52:4::101.55029: Flags [S.], cksum 0xc3bf (incorrect -> 0xde77), seq 3057129801, ack 827082994, win 65535, options [mss 16324,nop,wscale 14,sackOK,TS val 2005091535 ecr 194211201], length 0 19:12:30.486547 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [.], cksum 0xc3b7 (incorrect -> 0x4756), ack 1, win 5, options [nop,nop,TS val 194211201 ecr 2005091535], length 0 19:12:30.486653 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [P.], cksum 0xc3bf (incorrect -> 0x8ef3), seq 1:9, ack 1, win 5, options [nop,nop,TS val 194211201 ecr 2005091535], length 8 19:12:30.486667 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [F.], cksum 0xc3b7 (incorrect -> 0x474d), seq 9, ack 1, win 5, options [nop,nop,TS val 194211201 ecr 2005091535], length 0 19:12:30.486676 IP6 (flowlabel 0x81949, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101. > 2001:470:bc52:4::101.55029: Flags [.], cksum 0xc3b7 (incorrect -> 0x474d), ack 10, win 5, options [nop,nop,TS val 2005091535 ecr 194211201], length 0 19:12:30.486758 IP6 (flowlabel 0x81949, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101. > 2001:470:bc52:4::101.55029: Flags [F.], cksum 0xc3b7 (incorrect -> 0x474c), seq 1, ack 10, win 5, options [nop,nop,TS val 2005091535 ecr 194211201], length 0 19:12:30.722071 IP6 (flowlabel 0x81949, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101. > 2001:470:bc52:4::101.55029: Flags [F.], cksum 0xc3b7 (incorrect -> 0x4661), seq 1, ack 10, win 5, options [nop,nop,TS val 2005091770 ecr 194211201], length 0 19:12:30.722094 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 40) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [FP.], cksum 0xc3bf (incorrect -> 0x8e07), seq 1:9, ack 1, win 5, options [nop,nop,TS val 194211436 ecr 2005091535], length 8 19:12:30.722150 IP6 (flowlabel 0x9b06b, hlim 64, next-header TCP (6) payload length: 32) 2001:470:bc52:4::101.55029 > 2001:470:bc52:4::101.: Flags [.], cksum 0xc3b7 (incorrect -> 0x4577), ack 2, win 4, options [nop,nop,TS val 194211436 ecr 2005091770], length 0 Any ideas on how to further troubleshoot? -Dustin On Sat, Dec 4, 2021 at 3:54 PM Dustin Marquess wrote: > > I'm seeing a weird issue with -CURRENT that I don't recall seeing > before. It started at least a couple of weeks back and a new build > from yesterday still shows it. UDP packets inside a host using the > host's non-loopback address seems to get dropped. TCP does work, > however there's a delay, almost like the first packet or two also got > dropped. I don't have any firewalling active, and stopping the VNET > jails didn't have any effect. > > I've been using the machine's local IPv6 IP in /etc/resolv.conf for a > while. I noticed that logins were taking longer than usual and tracked > it down to unbound not responding. If I change /etc/resolv.conf to use > ::1 or the host's IPv4 IP, then it works fine. The host's IPv6 IP does > work from outside the host, however. I thought it was maybe a weird > unbound bug, so I did some testing with netcat. > > Current ifconfg (other interfaces removed for brevity): > > lo0: flags=8049 metric 0 mtu 16384 > options=680003 > inet6 ::1 prefixlen 128 > inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb > inet 127.0.0.1 netmask 0xff00 > nd6 options=21 > groups: lo
Re: if_vlan allow to set incorrect mtu
W dniu 8.11.2021 o 08:13, Zhenlei Huang pisze: On Nov 7, 2021, at 3:51 PM, Rozhuk Ivan wrote: Hi! Why if_vlan allow to set same MTU size or bigger as on parrent nic? Setup: - workstation with MTU 9000 and IPv4 on h/w nic - server with MTU 9000 on h/w nic and IPv4 on vlan nic with MTU 9000 (set by defauil on iface creation) This setup have issue: - big packets from server->wks - OK - big packets from wks->server - FAIL. Server init sequence: 1. Create vlans 2. Set MTU lower than default on parent nic Result: vlan have bigger or same MTU as parrent nic, but parrent nic reports IFCAP_VLAN_MTU. Probably this is if_em driver issue or iflib. This is rc.conf, vlan77 - where I got MTU 9000 and fail to receive packets: = vlans_igb0="vlan77 vlan86 vlan87" create_args_vlan87="vlan 87" create_args_vlan86="vlan 86" create_args_vlan77="vlan 77" ifconfig_vlan87="inet 15.44.77.2 netmask 255.255.252.0 mtu 1500 down up" ifconfig_vlan87_alias0="link 00:aa:fa:dd:44:55" ifconfig_vlan86="DHCP mtu 1500" ifconfig_vlan86_alias0="link 00:ff:fa:dd:44:55" ifconfig_vlan77="inet 192.168.0.254 netmask 255.255.255.0" ifconfig_vlan77_alias0="link 00:0f:43:48:67:fe" ifconfig_vlan77_ipv6="inet6 2001:470:2345:555::1/64 prefixlen 64 auto_linklocal" ifconfig_igb0="-lro -tso -vlanhwtso mtu 9000 down up" = Can you please disable all vlan hardware offloading features and repeat the test again? ifconfig igb0 -vlanmtu -vlanhwtag -vlanhwfilter -vlanhwtso -vlanhwcsum Disabling the capabilities listed above doesn't solve the issue, but assigning mtu 8996 to VLAN children does. Reproduced on the most recent 13-STABLE (13-n248421-3b936a8c889) while testing the fix[1] To reproduce: ifconfig_igb0="mtu 9000 up" ifconfig_igb1="mtu 9000 up" ifconfig_lagg0="laggproto lacp laggport igb0 laggport igb1 -lacp_strict" vlans_lagg0="vlan0 vlan1 ..." ifconfig_vlan0="inet x.x.x.x/y" # iperf3 -R -c y.y.y.y Connecting to host y.y.y.y, port 5201 Reverse mode, remote host y.y.y.y is sending [ 5] local x.x.x.x port 52750 connected to y.y.y.y port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.02 sec 0.00 Bytes 0.00 bits/sec [ 5] 1.02-2.02 sec 0.00 Bytes 0.00 bits/sec [ 5] 2.02-3.02 sec 0.00 Bytes 0.00 bits/sec [ 5] 3.02-3.55 sec 0.00 Bytes 0.00 bits/sec #ifconfig vlan0 mtu 8996 # iperf3 -R -c y.y.y.y Connecting to host y.y.y.y, port 5201 Reverse mode, remote host y.y.y.y is sending [ 5] local x.x.x.x port 49056 connected to y.y.y.y port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 118 MBytes 989 Mbits/sec [ 5] 1.00-2.00 sec 118 MBytes 990 Mbits/sec [ 5] 2.00-3.00 sec 118 MBytes 990 Mbits/sec [ 5] 3.00-3.69 sec 81.8 MBytes 989 Mbits/sec I am setting MTU to 8996 since early 13-BETA? or maybe PRERELEASE. 12-STABLE at the beginning of 2021 was fine with the default settings and MTU 9000 set for igb(4) on the same hardware. It looks like regression. Should the PR be submitted in this case? [1] https://reviews.freebsd.org/D30002 (commit 9c6432dc4bb936f0842d766d8b3b19dfcde15da2) Regards, -- Marek Zarychta OpenPGP_signature Description: OpenPGP digital signature
[Bug 240818] igb(4) vlanhwfilter feature generate link UP/DOWN for each new vlan created
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240818 --- Comment #26 from Marek Zarychta --- Probably fixed in https://cgit.freebsd.org/src/commit/?id=9c6432dc4bb936f0842d766d8b3b19dfcde15da2 See bug 230996. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 230996] em/igb: Intel i210/i350: ifconfig: enabling "vlanhwtag" renders VLAN on i210/i350 NICs unusable
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230996 Marek Zarychta changed: What|Removed |Added CC||zarych...@plan-b.pwste.edu. ||pl --- Comment #46 from Marek Zarychta --- Maybe bug 240818 should be closed too. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Re: Porting OpenBSD MPLS to FreeBSD
On 19.11.2021 23:16, Lutz Donnerhacke wrote: * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off doing a from-scratch implementation based on netgraph? I'd prefer a netgraph approach, if possible. It helps to concentrate on the important things. Isn't netgraph is very PPS-limited due to excessive logging? I thought, MPLS is carrier-grade stuff, and netgraph is very limited now. -- // Lev Serebryakov
Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?
> On Sun, 5 Dec 2021, Lutz Donnerhacke wrote: > > > On Sun, Dec 05, 2021 at 08:20:08PM +0200, John Hay wrote: > >> Something I have observed is that if you use FreeBSD 13 as a router with 2 > >> subnets on the same interface, it will generate redirects when hosts send > >> packets to the other subnet via the FreeBSD router. I think it is wrong. > > > > No, it's correct. > > > >> The host does not have a more direct way to get to the other subnet. > > > > The other host can arp for an address in a non-connected network on the > > interface because it's the same L2 domain. Hence the ICMP redirect is send > > out to provide the shortcut (skipping the router). > > That has always be a very Linux-y approach; FreeBSD should not ARP > for any subnet it is not connected to (at least it didn't use to). > > I think you could add a host route in the past and then it would but > with the current IPv4 I couldn't even say from quickly looking what it > would do. route add foo -direct > > > >> RFC792 > >> on page 13 does not talk about interfaces, but networks, "If G2 and the > >> host identified by the internet source address of the datagram are on the > >> same network...". > > > > "network" == "layer 2 domain". > > No, no in this context; it talks about about the "internet source > address of a datagram" and hence network == Layer 3 as that is where > internet addresses belong. No one would phrase it anymore like this > these days but in those days ... Concur, in RFC's "network" almost always refers to a layer 2 domain, the word "link" is use refers to a layer 2 domain. > Bjoern A. Zeeb r15:7 -- Rod Grimes rgri...@freebsd.org
Re: Porting OpenBSD MPLS to FreeBSD
[ Charset UTF-8 unsupported, converting... ] > Hi Alexander, > > On 2021-12-04 10:42, Alexander V. Chernikov wrote: > >> * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off > >> doing a from-scratch implementation based on netgraph? > > It depends. MPLS implementaiton can be splitted into multiple logical > > parts - dataplane (input, control, output, forward) and control plane > > (programming ip routes+mpls and mpls-only fowarding state). Some parts > > of the former can indeed be imported from OpenBSD. However, most of > > the control plane part have to be written from scratch. Finally, it > > may be desired to maintain an programming interface close to the one > > already implemented in major routing SW (frr, bird) - I guess that > > would be simpler to achieve with native, non-netgraph implementation. > > Thanks for your description. I haven't started work yet, but I'd > probably import the dataplane from OpenBSD where I can and do a new > control plane, maybe that with a FRR/Bird-compatible API. When you get to working with FRR let me know, I am a member of the CI infustructure team there and can hook you up directly with very knowledgeable FRR developers. > > I wasn't too keen on using netgraph anyways, I felt it was unnecessary > complexity. True, but with that complexity comes an ulmost unlimited flexiablity. > If I were to work on this, would I be better off starting with the > dataplane or control plane? I concur with Alexander on this, dataplace first, with an eye on how FRR/Bird interact with the dataplane. > > >> * Would some of the other committers here be willing to mentor/help me > >> if needed? > > I?d love to. Most of my the routing-related stack changes (modular > > lookup framework, nexthops, rtsock cleanups) were done to enable > > efficient kernel-based MPLS implementation. > > Thanks! > > -Neel (nc@) > > -- Rod Grimes rgri...@freebsd.org
