[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #8 from Richard Scheffenegger --- Rescue Retransmission for SACK is not in releng/13.0, thus D29315 is unlikely to be the problem here. There was another known panic (but with a KASSERT giving it away), fixed with D29083, but that is fixed in RC3. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #9 from Richard Scheffenegger --- The two cores look vastly different - and the 2nd one would be interesting to me to see what is going on in detail. There is no trace of TCP stack involvement in the original (BETA3) core dump. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #10 from shamaz.ma...@gmail.com --- I think, the main search vector is why there are no panics when net.link.ether.ipfw sysctl is set to 0 and there are panics when it is set to 1. I pasted my ipfw rules earlier, so you can see how I filter layer2 frames. Unfortunately, debugging is even more difficult because I cannot shut down my computer with FreeBSD13. But this is for another PR. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 Kevin Bowling changed: What|Removed |Added CC||kbowl...@freebsd.org --- Comment #11 from Kevin Bowling --- Can you try the 'net/realtek-re-kmod' port instead of the in tree re(4) driver? The in tree driver is missing microcode/phy fixups that seem mandatory for many RealTek cards. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp-testsuite into src?
On 22 Mar 2021, at 22:45, Alan Somers wrote: > On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling > wrote: > >> Hi, >> >> I was talking with gnn and kevans on IRC about the tcp testsuite >> (https://github.com/freebsd-net/tcp-testsuite). >> >> Currently we maintain this in ports, although the way the port is set >> up doesn't make a lot of sense because the tests are stack specific >> and we don't account for different FreeBSD versions let alone vendor >> trees. It seems reasonable to me to pull the tests themselves (i.e. >> https://github.com/freebsd-net/tcp-testsuite) into src where they can >> follow along with the tree they are running on, and provide vendors a >> natural point of extension. >> >> /usr/tests has some existing examples of relying on out of tree >> binaries to run so I am not convinced we need to import packetdrill >> itself but I don't have a strong preference. tuexen, do you have any >> preference? >> >> Regards, >> Kevin >> ___ >> freebsd-net@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >> > > Yeah, it's not a problem to use binaries from ports in /usr/tests. As long > as the tests can compile they can live in the base system. Is there a > strong incentive to import them? Do they need to be adjusted for each > release? I found out this morning that moving the tests into base is indeed the plan: https://wiki.freebsd.org/TransportProtocols/11March2021 I'm happy to see this happen. The next step will be documentation of how to add new/good tests to the suite. Best, George ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254303] Fatal trap 12: page fault while in kernel mode ((frr 7.5_1 + Freebsd 13 Beta3) zebra crashes server when routes are populated)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254303 --- Comment #12 from Aleks --- (In reply to Alexander V. Chernikov from comment #9) I've sent you what you asked for (in email). -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp-testsuite into src?
> On 23. Mar 2021, at 02:31, Kevin Bowling wrote: > > Hi, > > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense because the tests are stack specific > and we don't account for different FreeBSD versions let alone vendor Just to be clear: * The tests only work with FreeBSD head/master/main. * The current tests should work with the freebsd, the rack and bbr stack. However, the tests sometimes need updates to reflect code changes. > trees. It seems reasonable to me to pull the tests themselves (i.e. > https://github.com/freebsd-net/tcp-testsuite) into src where they can > follow along with the tree they are running on, and provide vendors a > natural point of extension. I'm happy to have them in the src repo. That way it would be possible to also support stable/13 and (possibly) stable/12. > > /usr/tests has some existing examples of relying on out of tree > binaries to run so I am not convinced we need to import packetdrill > itself but I don't have a strong preference. tuexen, do you have any > preference? No. Just as a note. There do also exist SCTP tests and I had sometime ago some UDP lite tests. So we might want to have a directory layout supporting multiple protocols. Best regards Michael > > Regards, > Kevin ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp-testsuite into src?
> On 23. Mar 2021, at 03:45, Alan Somers wrote: > > On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling > wrote: > Hi, > > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense because the tests are stack specific > and we don't account for different FreeBSD versions let alone vendor > trees. It seems reasonable to me to pull the tests themselves (i.e. > https://github.com/freebsd-net/tcp-testsuite) into src where they can > follow along with the tree they are running on, and provide vendors a > natural point of extension. > > /usr/tests has some existing examples of relying on out of tree > binaries to run so I am not convinced we need to import packetdrill > itself but I don't have a strong preference. tuexen, do you have any > preference? > > Regards, > Kevin > ___ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" > > Yeah, it's not a problem to use binaries from ports in /usr/tests. As long > as the tests can > compile they can live in the base system. Is there a strong incentive to > import them? Do The tests are just scripts, which can be executed by packetdrill, which is available in the ports tree. > they need to be adjusted for each release? It depends. If things like default timeouts or so change, then the tests need to be adapted. If we would have (and I guess we will) tests for loss recovery, then improvements to the code might also require changes to the tests. Best regards Michael ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp-testsuite into src?
> On 23. Mar 2021, at 12:26, George Neville-Neil wrote: > > > > On 22 Mar 2021, at 22:45, Alan Somers wrote: > >> On Mon, Mar 22, 2021 at 7:31 PM Kevin Bowling >> wrote: >> >>> Hi, >>> >>> I was talking with gnn and kevans on IRC about the tcp testsuite >>> (https://github.com/freebsd-net/tcp-testsuite). >>> >>> Currently we maintain this in ports, although the way the port is set >>> up doesn't make a lot of sense because the tests are stack specific >>> and we don't account for different FreeBSD versions let alone vendor >>> trees. It seems reasonable to me to pull the tests themselves (i.e. >>> https://github.com/freebsd-net/tcp-testsuite) into src where they can >>> follow along with the tree they are running on, and provide vendors a >>> natural point of extension. >>> >>> /usr/tests has some existing examples of relying on out of tree >>> binaries to run so I am not convinced we need to import packetdrill >>> itself but I don't have a strong preference. tuexen, do you have any >>> preference? >>> >>> Regards, >>> Kevin >>> ___ >>> freebsd-net@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" >>> >> >> Yeah, it's not a problem to use binaries from ports in /usr/tests. As long >> as the tests can compile they can live in the base system. Is there a >> strong incentive to import them? Do they need to be adjusted for each >> release? > > I found out this morning that moving the tests into base is indeed the plan: > > https://wiki.freebsd.org/TransportProtocols/11March2021 Well, it was discussed, and no-one objected up to now. I'm not familiar with the test infrastructure used by FreeBSD. I'm running the TCP tests using shell scripts which are part of the repository. To get it into the source tree, it would be great to have someone to talk to, who has some experience with test infrastructure used by FreeBSD. Anyone volunteering? > > I'm happy to see this happen. > > The next step will be documentation of how to add new/good tests to the suite. Up to now, the test groups are written around specifications. So can you list which specifications you would like to have covered? Best regards Michael > > Best, > George ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #12 from Richard Scheffenegger --- Can you share the 2nd core dump and kernel? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
AW: tcp-testsuite into src?
>> Yeah, it's not a problem to use binaries from ports in /usr/tests. As >> long as the tests can compile they can live in the base system. Is >> there a strong incentive to import them? > > The tests are just scripts, which can be executed by packetdrill, which is > available in the ports tree. > >> Do they need to be adjusted for each release? > > It depends. If things like default timeouts or so change, then the tests need > to be adapted. > > If we would have (and I guess we will) tests for loss recovery, then > improvements to the code might also require changes to the tests. Yes, I would really like to have the packetdrill scripts in the source tree. And a recipe, how to run a subtree from the test (e.g. the TCP tests) as part of a kernel build... As I work on adding newer mechanisms into base stack TCP, I would be documenting these changes in microscopic timing etc in terms of test cases... Right now, the test suite is organized in a similar layout of the source files. However, as UDP, TCP and SCTP all live in /sys/netinet, and the existing packetdrill scripts cover a lot of ground in various scenarios, I am wondering if it wouldn't be easier to have a subdirectory under /tests/sys/netinet/packetdrill/tcp which mirrors freebsd-net/tcp-testsuite > > Best regards > Michael ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: tcp-testsuite into src?
Kevin Bowling wrote this message on Mon, Mar 22, 2021 at 18:31 -0700: > I was talking with gnn and kevans on IRC about the tcp testsuite > (https://github.com/freebsd-net/tcp-testsuite). > > Currently we maintain this in ports, although the way the port is set > up doesn't make a lot of sense because the tests are stack specific > and we don't account for different FreeBSD versions let alone vendor > trees. It seems reasonable to me to pull the tests themselves (i.e. > https://github.com/freebsd-net/tcp-testsuite) into src where they can > follow along with the tree they are running on, and provide vendors a > natural point of extension. Yes, please. > /usr/tests has some existing examples of relying on out of tree > binaries to run so I am not convinced we need to import packetdrill > itself but I don't have a strong preference. tuexen, do you have any > preference? It looks like packetdrill is large enough that it should remain out of tree, and installed via ports. Also, packetdrill is GPLv2, which is another reason to not import the code. What I did for the crypto tests (which use python), was to only run them if the necessary binaries are installed, and skip them if not present. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254303] Fatal trap 12: page fault while in kernel mode ((frr 7.5_1 + Freebsd 13 Beta3) zebra crashes server when routes are populated)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254303 Alexander V. Chernikov changed: What|Removed |Added Status|New |In Progress --- Comment #13 from Alexander V. Chernikov --- Awesome! Could you also share other panics backtraces (if any)? -- You are receiving this mail because: You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #13 from shamaz.ma...@gmail.com --- Can you reproduce by it yourself by adding net.link.ether.ipfw = 0 to /etc/sysctl.conf and writing firewall rules like these: #!/bin/sh IPFW="/sbin/ipfw -q" IFACE="wg0" PUB_IFACE="re1" SKIP_IP="skipto 2" SKIP_ETHER="skipto 3" # Ports list: SSH="22" TELNET="23" SMTP="25" WHOIS="43" WWW="80" HTTPS="443" POP3="110" SSMTP="465" POP3S="995" GIT="9418" FTPC="21" FTPD="20" IRC="6660-7000" NTP="123" OPENPORTS="$WWW,$HTTPS" OPENPORTS="$OPENPORTS,$SSH,$WHOIS,$GIT" GOODMACS="cc:af:78:58:73:a2 60:45:cb:64:2a:65 3c:7c:3f:3c:52:5b" GOODMACS_TAG="100" SUBNET="192.168.20.0/24" LOCALIFACES="re0 wlan0 bridge0 lo0 tap0" $IPFW -f flush $IPFW -f nat flush # Start NAT $IPFW nat 1 config if $IFACE log same_ports reset # Deny fragmented packets $IPFW add reass ip from any to any frag in #$IPFW add $SKIP_ETHER ip from any to any layer2 $IPFW add check-state :before-nat # Drop connections to LAN from untrusted macs #$IPFW add allow ip from any to any tagged $GOODMACS_TAG via bridge0 # Allow DHCP #$IPFW add allow udp from any 68 to me dst-port 67 in via bridge0 keep-state :before-nat # And ICMP #$IPFW add allow icmp from any to any via bridge0 # Drop everything else #$IPFW add deny ip from any to $SUBNET in via bridge0 # Enable LAN traffic for lan_iface in $LOCALIFACES; do $IPFW add allow ip from any to any via $lan_iface done # Public iface setup # Wireguard $IPFW add allow udp from me to 185.213.155.130 dst-port 51820 out via $PUB_IFACE keep-state :before-nat # OpenVPN #$IPFW add allow udp from me to any dst-port 1197 out via $PUB_IFACE keep-state :before-nat $IPFW add allow icmp from any to any via $PUB_IFACE $IPFW add deny ip from any to any via $PUB_IFACE $IPFW add nat 1 ip from any to any in via $IFACE $IPFW add check-state :after-nat # Allow DNS for this machine $IPFW add $SKIP_IP tcp from me to any 53 out via $IFACE setup keep-state :after-nat $IPFW add $SKIP_IP udp from me to any 53 out via $IFACE keep-state :after-nat # All common open ports $IPFW add $SKIP_IP tcp from me to any $OPENPORTS out \ via $IFACE setup keep-state :after-nat # DHCP $IPFW add $SKIP_IP udp from any 68 to any dst-port 67 out via $IFACE keep-state :after-nat # NTP $IPFW add $SKIP_IP udp from me to any $NTP out via $IFACE keep-state :after-nat # Allow ICMP $IPFW add $SKIP_IP icmp from any to any via $IFACE $IPFW add deny all from me to any out via $IFACE $IPFW add deny all from any to me in via $IFACE $IPFW add 2 nat 1 ip from any to any out via $IFACE $IPFW add allow ip from any to any via $IFACE $IPFW add deny ip from any to any # Ethernet-layer processing $IPFW add 3 allow ip from any to any mac-type arp for mac in $GOODMACS; do $IPFW add allow tag $GOODMACS_TAG ip from any to any mac any $mac in $IPFW add allow tag $GOODMACS_TAG ip from any to any mac $mac any out done $IPFW add allow ip from any to any You can drop all rules about VPN, home VLAN, etc. Just leave layer2 filtering. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Bug 254015] Panic when using bridge interface on 13.0-BETA4
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254015 --- Comment #14 from shamaz.ma...@gmail.com --- Disregard my last message. Tryed layer2 filtering on my second machine. All works fine. It causes trouble only at the first one. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
