[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 Kubilay Kocak changed: What|Removed |Added Summary|crash after updating to |crash in_cksumdata |FreeBSD 13.0 p5 |(sys/amd64/amd64/in_cksum.c ||:113) via in4_cksum ||(sys/netpfil/pf/in4_cksum.c ||:117) after FreeBSD 13.0 p5 ||update Keywords||crash, needs-qa Assignee|b...@freebsd.org|n...@freebsd.org Version|13.0-STABLE |13.0-RELEASE CC||k...@freebsd.org, ||m...@freebsd.org, ||n...@freebsd.org Flags||maintainer-feedback?(mjg@Fr ||eeBSD.org), ||maintainer-feedback?(kp@fre ||ebsd.org), mfc-stable13?, ||mfc-stable12? Status|New |Open --- Comment #1 from Kubilay Kocak --- Thank you for your report. Could you include additional information, including: - /var/run/dmesg.boot output (as an attachment) - /etc/rc.conf network configuration (as an attachment) - pciconf -lv output (as an attachment) - firewall (pf) configuration (as an attachment, sanitized where necessary) -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.
Re: netmask for loopback interfaces
"Rodney W. Grimes" wrote:
> > Note, the default FreeBSD firewall rules already have:
> >
> > ${fwcmd} add 100 pass all from any to any via lo0
> > ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
>
> Which no longer work correctly since the "to 127.0.0.0/8"
> packets SHALL go out what ever interface the route table
> tells them to (often the default route), AND NOT lo0.
>
> oot {1003}# route -n get 127.1.1.1
>route to: 127.1.1.1
> destination: 0.0.0.0
>mask: 0.0.0.0
> gateway: 192.168.32.8
> fib: 0
> interface: em0
Hi!
I'm not sure what you mean. The current default rules will stop
anything to 127.0.0.0/8 going anywhere other than via lo0 -
which preserves "current expected behaviour" - I was pointing
out that in reply to Oleksandr's comment:
| /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
| outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
His argument was that putting an /8 on the localhost address would
neatly stop 127/8 traffic going to the LAN - I was pointing out there
are other ways to do this, i.e. routing, and the firewall.
Of course, if FreeBSD relaxes to allow the use of 128/8 outside 128/16,
then these rules will need to be changed..
Re: netmask for loopback interfaces
Rod wrote:
> > Jamie wrote:
> >
> > > Oleksandr Kryvulia wrote:
> >
> > > > 04.11.21 01:01, Mike Karels wrote:
> > > > > I have a pending change to stop using class A/B/C netmasks when
> > > > > setting
> > > > > an interface address without an explicit mask, and instead to use a
> > > > > default
> > > > > mask (24 bits). A question has arisen as to what the default mask
> > > > > should
> > > > > be for loopback interfaces. The standard 127.0.0.1 is added with an
> > > > > 8 bit
> > > > > mask currently, but additions without a mask would default to 24 bits.
> > > > > There is no warning for missing masks for loopback in the current
> > > > > code.
> > > > > I'm not convinced that the mask has any meaning here; only a host
> > > > > route
> > > > > to the assigned address is created. Does anyone know of any meaning
> > > > > or
> > > > > use of the mask on a loopback address?
> > > > >
> > > > > Thanks,
> > > > > Mike
> > > > >
> > > >
> > > > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > > > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> > > >
> > > > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > > > [2] https://datatracker.ietf.org/doc/html/rfc1122
> >
> > It's true that 127/8 is currently reserved, but that isn't enforced
> > by FreeBSD using the mask on the interface. Such packets are prevented
> > from forwarding by in_canforward(), which in turn uses IN_LOOPBACK().
> > The latter uses a compiled-in 8-bit mask.
> I have a review up that "relaxes" the restrictions on this (127/8)
> and other ranges.
> https://reviews.freebsd.org/D19316
> >
> > > There is a push by some people to release 127.0.0.0/8 address space,
> > > leaving only 127.0.0.0/16 as reserved for localhost.
> >
> > > https://www.spinics.net/lists/netdev/msg598545.html
> >
> > > https://github.com/schoen/unicast-extensions/blob/master/127.md
> >
> > > https://github.com/schoen/unicast-extensions/
> >
> > > I make no comment on the feasability of doing this!
> >
> > > However, that aside, aren't you just confusing the mask with routing?
> >
> > The two masks (interface and route) are separate, but the routing mask
> > is set from the interface mask for most interfaces (broadcast or NBMA,
> > but not loopback or point-to-point). The interface mask is visible to
> > user level, including routing daemons. But I think it would be wrong
> > for a routing daemon to infer anything from the mask on a loopback
> > route. But the reason for my question was to find out if there is
> ^ I think you meant interface here?
Yes, thanks. (Although it may be true of loopback routes too.)
> > anything that uses the interface mask in this case, and thus whether
> > a change in the default matters.
> I actually do believe routing daemons pay very close attention to
> the netmask on and interfaces. It is how CIDR routes to interfaces
> are created and maintained by most of them. Even ancient gated
> used this information.
Yes, but do they use information for the loopback for routing? Certainly
they don't advertise the loop back by default; it isn't reachable externally.
> >
> > > I think the mask on any IP on a loopback interface should be /32
> > > (if you want to add a "127.0.0.0/8 -local" route even if done
> > > automatically", then so be it)
> >
> > Using /32 on loopback is not a bad idea. /etc/network.subr is wired
> > to 127.0.0.1/8 currently. I don't think I'll change it in this pass
> > though.
> >
> > > Note, the default FreeBSD firewall rules already have:
> >
> > > ${fwcmd} add 100 pass all from any to any via lo0
> > > ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> > > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
> >
> > If you use the default rules...
> The default rules should work with a fresh install that
> is left with defaults in place. Due to loss of 127/8
> routes the firewall code is borked and we only do not
> leak 127/8 packets because of other code in the kernel
> that prevents them from leaking.
A fresh install does not enable the firewall rules by default.
We could change /etc/network.subr to add a reject route for the loopback
"net". When BSD last had a 127/8 route, it was not a reject route, so
didn't make sense.
Mike
Re: netmask for loopback interfaces
> Jamie wrote:
>
> > Oleksandr Kryvulia wrote:
>
> > > 04.11.21 01:01, Mike Karels wrote:
> > > > I have a pending change to stop using class A/B/C netmasks when setting
> > > > an interface address without an explicit mask, and instead to use a
> > > > default
> > > > mask (24 bits). A question has arisen as to what the default mask
> > > > should
> > > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8
> > > > bit
> > > > mask currently, but additions without a mask would default to 24 bits.
> > > > There is no warning for missing masks for loopback in the current code.
> > > > I'm not convinced that the mask has any meaning here; only a host route
> > > > to the assigned address is created. Does anyone know of any meaning or
> > > > use of the mask on a loopback address?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > >
> > > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> > >
> > > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > > [2] https://datatracker.ietf.org/doc/html/rfc1122
>
> It's true that 127/8 is currently reserved, but that isn't enforced
> by FreeBSD using the mask on the interface. Such packets are prevented
> from forwarding by in_canforward(), which in turn uses IN_LOOPBACK().
> The latter uses a compiled-in 8-bit mask.
I have a review up that "relaxes" the restrictions on this (127/8)
and other ranges.
https://reviews.freebsd.org/D19316
>
> > There is a push by some people to release 127.0.0.0/8 address space,
> > leaving only 127.0.0.0/16 as reserved for localhost.
>
> > https://www.spinics.net/lists/netdev/msg598545.html
>
> > https://github.com/schoen/unicast-extensions/blob/master/127.md
>
> > https://github.com/schoen/unicast-extensions/
>
> > I make no comment on the feasability of doing this!
>
> > However, that aside, aren't you just confusing the mask with routing?
>
> The two masks (interface and route) are separate, but the routing mask
> is set from the interface mask for most interfaces (broadcast or NBMA,
> but not loopback or point-to-point). The interface mask is visible to
> user level, including routing daemons. But I think it would be wrong
> for a routing daemon to infer anything from the mask on a loopback
> route. But the reason for my question was to find out if there is
^ I think you meant interface here?
> anything that uses the interface mask in this case, and thus whether
> a change in the default matters.
I actually do believe routing daemons pay very close attention to
the netmask on and interfaces. It is how CIDR routes to interfaces
are created and maintained by most of them. Even ancient gated
used this information.
>
> > I think the mask on any IP on a loopback interface should be /32
> > (if you want to add a "127.0.0.0/8 -local" route even if done
> > automatically", then so be it)
>
> Using /32 on loopback is not a bad idea. /etc/network.subr is wired
> to 127.0.0.1/8 currently. I don't think I'll change it in this pass
> though.
>
> > Note, the default FreeBSD firewall rules already have:
>
> > ${fwcmd} add 100 pass all from any to any via lo0
> > ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
>
> If you use the default rules...
The default rules should work with a fresh install that
is left with defaults in place. Due to loss of 127/8
routes the firewall code is borked and we only do not
leak 127/8 packets because of other code in the kernel
that prevents them from leaking.
> Mike
--
Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
> Oleksandr Kryvulia wrote:
>
> > 04.11.21 01:01, Mike Karels ?:
> > > I have a pending change to stop using class A/B/C netmasks when setting
> > > an interface address without an explicit mask, and instead to use a
> > > default
> > > mask (24 bits). A question has arisen as to what the default mask should
> > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit
> > > mask currently, but additions without a mask would default to 24 bits.
> > > There is no warning for missing masks for loopback in the current code.
> > > I'm not convinced that the mask has any meaning here; only a host route
> > > to the assigned address is created. Does anyone know of any meaning or
> > > use of the mask on a loopback address?
> > >
> > > Thanks,
> > > Mike
> > >
> >
> > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> >
> > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > [2] https://datatracker.ietf.org/doc/html/rfc1122
>
> There is a push by some people to release 127.0.0.0/8 address space,
> leaving only 127.0.0.0/16 as reserved for localhost.
>
> https://www.spinics.net/lists/netdev/msg598545.html
>
> https://github.com/schoen/unicast-extensions/blob/master/127.md
>
> https://github.com/schoen/unicast-extensions/
>
> I make no comment on the feasability of doing this!
>
> However, that aside, aren't you just confusing the mask with routing?
>
> I think the mask on any IP on a loopback interface should be /32
> (if you want to add a "127.0.0.0/8 -local" route even if done
> automatically", then so be it)
>
> Note, the default FreeBSD firewall rules already have:
>
> ${fwcmd} add 100 pass all from any to any via lo0
> ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
Which no longer work correctly since the "to 127.0.0.0/8"
packets SHALL go out what ever interface the route table
tells them to (often the default route), AND NOT lo0.
oot {1003}# route -n get 127.1.1.1
route to: 127.1.1.1
destination: 0.0.0.0
mask: 0.0.0.0
gateway: 192.168.32.8
fib: 0
interface: em0
flags:
recvpipe sendpipe ssthresh rtt,msecmtuweightexpire
0 0 0 0 1500 1 0
> Cheers, Jamie
--
Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
> 04.11.21 01:01, Mike Karels ?: > > I have a pending change to stop using class A/B/C netmasks when setting > > an interface address without an explicit mask, and instead to use a default > > mask (24 bits). A question has arisen as to what the default mask should > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit > > mask currently, but additions without a mask would default to 24 bits. > > There is no warning for missing masks for loopback in the current code. > > I'm not convinced that the mask has any meaning here; only a host route > > to the assigned address is created. Does anyone know of any meaning or > > use of the mask on a loopback address? > > > > Thanks, > > Mike > > > > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere > outside of the localhost. This described in RFC 5735 [1] and 1122 [2] > > [1] https://datatracker.ietf.org/doc/html/rfc5735 > [2] https://datatracker.ietf.org/doc/html/rfc1122 Saddly that no longer works correctly since there is no longer a 127/8 route in the table. Which, IMHO, is a mistake. -- Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
Jamie wrote:
> Oleksandr Kryvulia wrote:
> > 04.11.21 01:01, Mike Karels wrote:
> > > I have a pending change to stop using class A/B/C netmasks when setting
> > > an interface address without an explicit mask, and instead to use a
> > > default
> > > mask (24 bits). A question has arisen as to what the default mask should
> > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit
> > > mask currently, but additions without a mask would default to 24 bits.
> > > There is no warning for missing masks for loopback in the current code.
> > > I'm not convinced that the mask has any meaning here; only a host route
> > > to the assigned address is created. Does anyone know of any meaning or
> > > use of the mask on a loopback address?
> > >
> > > Thanks,
> > > Mike
> > >
> >
> > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> >
> > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > [2] https://datatracker.ietf.org/doc/html/rfc1122
It's true that 127/8 is currently reserved, but that isn't enforced
by FreeBSD using the mask on the interface. Such packets are prevented
from forwarding by in_canforward(), which in turn uses IN_LOOPBACK().
The latter uses a compiled-in 8-bit mask.
> There is a push by some people to release 127.0.0.0/8 address space,
> leaving only 127.0.0.0/16 as reserved for localhost.
> https://www.spinics.net/lists/netdev/msg598545.html
> https://github.com/schoen/unicast-extensions/blob/master/127.md
> https://github.com/schoen/unicast-extensions/
> I make no comment on the feasability of doing this!
> However, that aside, aren't you just confusing the mask with routing?
The two masks (interface and route) are separate, but the routing mask
is set from the interface mask for most interfaces (broadcast or NBMA,
but not loopback or point-to-point). The interface mask is visible to
user level, including routing daemons. But I think it would be wrong
for a routing daemon to infer anything from the mask on a loopback
route. But the reason for my question was to find out if there is
anything that uses the interface mask in this case, and thus whether
a change in the default matters.
> I think the mask on any IP on a loopback interface should be /32
> (if you want to add a "127.0.0.0/8 -local" route even if done
> automatically", then so be it)
Using /32 on loopback is not a bad idea. /etc/network.subr is wired
to 127.0.0.1/8 currently. I don't think I'll change it in this pass
though.
> Note, the default FreeBSD firewall rules already have:
> ${fwcmd} add 100 pass all from any to any via lo0
> ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
If you use the default rules...
Mike
Re: netmask for loopback interfaces
Oleksandr Kryvulia wrote:
> 04.11.21 01:01, Mike Karels пишет:
> > I have a pending change to stop using class A/B/C netmasks when setting
> > an interface address without an explicit mask, and instead to use a default
> > mask (24 bits). A question has arisen as to what the default mask should
> > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit
> > mask currently, but additions without a mask would default to 24 bits.
> > There is no warning for missing masks for loopback in the current code.
> > I'm not convinced that the mask has any meaning here; only a host route
> > to the assigned address is created. Does anyone know of any meaning or
> > use of the mask on a loopback address?
> >
> > Thanks,
> > Mike
> >
>
> /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
>
> [1] https://datatracker.ietf.org/doc/html/rfc5735
> [2] https://datatracker.ietf.org/doc/html/rfc1122
There is a push by some people to release 127.0.0.0/8 address space,
leaving only 127.0.0.0/16 as reserved for localhost.
https://www.spinics.net/lists/netdev/msg598545.html
https://github.com/schoen/unicast-extensions/blob/master/127.md
https://github.com/schoen/unicast-extensions/
I make no comment on the feasability of doing this!
However, that aside, aren't you just confusing the mask with routing?
I think the mask on any IP on a loopback interface should be /32
(if you want to add a "127.0.0.0/8 -local" route even if done
automatically", then so be it)
Note, the default FreeBSD firewall rules already have:
${fwcmd} add 100 pass all from any to any via lo0
${fwcmd} add 200 deny all from any to 127.0.0.0/8
${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
Cheers, Jamie
Re: Broadcom bnxt driver issue with promisc mode
> After survey about solution for Broadcom bnxt driver issue with promiscous > mode. I am not found any normal solution with that situation. > Only workaround to using promiscous mode to have normal operations with these > cards. This isn't normal by me! > > I look and do some debug on bnxt driver. Issue came from hardware filter in > ASIC. On init driver and its ring buffers default states of filter are all > block. Also I saw that we have not ability to append configured VLANs on the > host into broadcom vlan tag list to be allowed for further processing from > network stack. > Then my solution is simple and effective in such situation. I append to > filter mask bit for passing further for processing all tagged vlans and > native/primary vlan too. > > This is enough to have normal packet processing for bnxt driver. > We have such BCM57414 NetXtreme-E 10Gb/25Gb RDMA Ethernet Controller. I > tested patch on them. > > Patch is make on FreeBSD 14.0-CURRENT #3 main-n244973-c02a28754bc-dirty: Tue > Nov 2 20:53:08 EET 2021 > > If you are thinking it is ok. You can feel free to merge it to FreeBSD > existing driver. This patch solved a big problem for me also. My environment is FreeBSD 12.2-STABLE (r370686), with a 2 port BCM57412. The bnxt interfaces work fine as long as I configure IP address on the main (physical) interface - no VLANs. If I configure a VLAN interface (e.g. bnxt1.91), this only works if I put the main interface in promiscuous mode. After updating if_bnxt.c with the patch from Michael Pounov, I am now able to use VLAN interfaces without putting the main interface in promiscuous mode. This is the output from pciconf -lv: bnxt0@pci0:24:0:0: class=0x02 card=0x412014e4 chip=0x16d614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Inc. and subsidiaries' device = 'BCM57412 NetXtreme-E 10Gb RDMA Ethernet Controller' class = network subclass = ethernet bnxt1@pci0:24:0:1: class=0x02 card=0x412014e4 chip=0x16d614e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Inc. and subsidiaries' device = 'BCM57412 NetXtreme-E 10Gb RDMA Ethernet Controller' class = network subclass = ethernet Below I have enclosed the patch I used for 12.2-STABLE - the only difference, as far as I can see, is slightly different line numbers. Thank you Michael Pounov! Steinar Haug, Nethelp consulting, sth...@nethelp.no -- --- sys/dev/bnxt/if_bnxt.c.orig 2021-09-28 21:25:17.0 +0200 +++ sys/dev/bnxt/if_bnxt.c 2021-11-04 07:59:24.720236000 +0100 @@ -587,7 +587,8 @@ softc->vnic_info.def_ring_grp = (uint16_t)HWRM_NA_SIGNATURE; softc->vnic_info.cos_rule = (uint16_t)HWRM_NA_SIGNATURE; softc->vnic_info.lb_rule = (uint16_t)HWRM_NA_SIGNATURE; - softc->vnic_info.rx_mask = HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_BCAST; + softc->vnic_info.rx_mask = HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_BCAST | + HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_ANYVLAN_NONVLAN; softc->vnic_info.mc_list_count = 0; softc->vnic_info.flags = BNXT_VNIC_FLAG_DEFAULT; rc = iflib_dma_alloc(ctx, BNXT_MAX_MC_ADDRS * ETHER_ADDR_LEN, @@ -1384,8 +1385,7 @@ HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_ANYVLAN_NONVLAN; else softc->vnic_info.rx_mask &= - ~(HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_PROMISCUOUS | - HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_ANYVLAN_NONVLAN); + ~(HWRM_CFA_L2_SET_RX_MASK_INPUT_MASK_PROMISCUOUS); rc = bnxt_hwrm_cfa_l2_set_rx_mask(softc, >vnic_info);
Re: netmask for loopback interfaces
04.11.21 01:01, Mike Karels пишет: I have a pending change to stop using class A/B/C netmasks when setting an interface address without an explicit mask, and instead to use a default mask (24 bits). A question has arisen as to what the default mask should be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit mask currently, but additions without a mask would default to 24 bits. There is no warning for missing masks for loopback in the current code. I'm not convinced that the mask has any meaning here; only a host route to the assigned address is created. Does anyone know of any meaning or use of the mask on a loopback address? Thanks, Mike /8 mask on loopback prevetnts using of 127.x.x.x network anywhere outside of the localhost. This described in RFC 5735 [1] and 1122 [2] [1] https://datatracker.ietf.org/doc/html/rfc5735 [2] https://datatracker.ietf.org/doc/html/rfc1122
