Re: FRR on FreeBSD 12 - problems with OSPFv3
Thanks for the questions, good for me to think about it some more. Short response: I don't think it is the FRR config, but the routes received that are crashing it or ospf6d has some other issue. On 10/11/19 2:12 PM, Rodney W. Grimes wrote: I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at the same time. I've tried frr6 and frr7 and get the same errors. bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm going wrong. If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. What if you comment out just lo0? Running OSPF on a loopback interface makes no since, your not going to be able to establish a DR/BDR pair so OSPF can never really come up on that interface, and if it did injecting any route from 127/8 into the OSPF lsdb would be very bad! Though I doubt this is the source of the illegal instuction trap it is none the less a configuration issue. Personally, I always put a 172.17.x.x IP on my lo0 and then advertise that into my network. I don't make it part of the router config, but I wanted a 'test device' to boot ospf6d and see it crash. Also, the docs on FRR have an lo0. I do advertise my 172.17.x.x IP on the loobpback: This is how I verify OSPF is up -- the IPwill ping from other devices on the network when OSPF is up. For IPv6, I put a whole /64 on the lo0. So many IPs in v6. :) *** LOGS *** 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 5 usec, Reason: L+ 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 109 usec, Reason: R+, R-, L+ 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 116 usec, Reason: R+, N+, L+ 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 99 usec, Reason: R+, R- 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Loading]->[Full] (LoadingDone) 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to announce only ospf6 routes vrf=0 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an error and is shutting down. 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table chunks 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label chunks 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes removed from the rib *** CRASH *** Zebra process crashes after the ospf6 process has encountered some error and shut down or are you indicatong that the OSPF6D process has crashed? OSPF6d crashes, zebra just notes the client #32, the ospf6 process, saying hello and goodbye. If I run on the command line and don't background, it bombs after 7 seconds: # ospf6d Illegal instruction ... What happens if you remove this lo0 section? Still crashes, usually don't have lo0 in an a Does ospf6 come up and run if you remove all the route-map stuff your trying to do? Sure, I can try a minimal setup. This config crashes in the same way: ! Zebra configuration saved from vty ! 2019/10/10 23:58:21 ! frr version 7.1 ! hostname orange-ospf6 password sluggo service advanced-vty ! ! ! interface cxl1 ipv6 ospf6 cost 1 ipv6 ospf6 network point-to-point ! router ospf6 ospf6 router-id 208.69.43.198 interface cxl1 area 0.0.0.0 auto-cost reference-bandwidth 1 ! line vty exec-timeout 0 0 ___ 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: DHCPv6 client in base
On 11/10/2019 20:40, Hiroki Sato wrote: I do not have a strong objection on dhcpcd (I am using it on some of my FreeBSD boxes actually) but let me explain the reason why I chose wide-dhcp as the candidate. That is because it is a small, functional DHCPv6-only implementation. I am planning to rewrite it to add the missing bits and adjust it for a tighter integration with kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I feel dhcpcd (or others) is too big for that purpose. How are you measuring that dhcpcd is too big? On my FreeBSD box $ size /usr/sbin/rtsold /sbin/dhclient /usr/local/sbin/dhcp6c /sbin/dhcpcd textdata bss dec hex filename 32327 9843352366630x8f37 /usr/sbin/rtsold 86752 10144 82696 179592 0x2bd88 /sbin/dhclient 1453221396 11304 158022 0x26946 /usr/local/sbin/dhcp6c 25325815321184 255974 0x3e7e6 /sbin/dhcpcd Taken by itself, yes dhcpcd is larger. But as a whole dhcpcd is quite smaller. 24k of dhcpcd is just a text file with decoding instructions for all DHCP/DHCP6/ND6 RFC's I can find. What's more, dhcpcd can be compiled with things turned on or all, such as DHCP, ARP, etc. It's quite flexable. To demonstrate, the above dhcpcd size is the full fat dhcpcd. Here is it with the stock small config and full IPv6 stack support, which is the equivalent of dhcp6c and rtsold above + the extra goodies you get with dhcpcd. $ size dhcpcd text databss dec hex filename 176605 1452 1168 179225 0x2bc19 dhcpcd But wait, there's more. Lets see how dhcpcd weighs up as just a DHCP client + the extra dhcpcd goodies? $ size dhcpcd text databss dec hex filename 144163 1420 1136 146719 0x23d1f dhcpcd I don't consider dhcpcd to be big at all, and would love to know your rationale for calling it so. IMHO, the directions of further developments of IPv6 functionality on FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly BSD (dhcpcd) have already been diverged. For RFC 7217 I already have an in-kernel implementation (not committed yet), and I am also working on SeND (RFC 3971, not directly related to DHCPv6 though). My goal is to integrate these small implementations into the base system and make them possible to work together. So for DHCPv6, I think an implementation of only DHCPv6 is the best. If people want a more feature-rich implementation or the same one on other systems, they can still use dhcpcd or ISC's dhclient even after the import. Of course this assumes that wide-dhcp works to some degree. If it does not, importing it to the base system does not make sense. I have used it in various scenarios for a long time such as RA + O flag on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others which are complex enough, and understand what works and what is missing (poor DUID format support, for example). The popular way to use DHCPv6 is IA_PD, and wide-dhcp works well with it. So I have a question. What is missing feature in wide-dhcp which you are concerned about? I know some, but it has most of the basic functionality of DHCPv6 and I think it is enough as a minimal implementation for the base system. My primary reason is that it is just for DHCPv6 as mentioned earlier and I believe it is maintainable in the base system. I would like to know other people's opinion if there is something critical. This isn't a question about wide-dhcp specifically, but I feel it's a good question. Do you plan on supporting a multihomed system with hotpluggable interfaces all auto configured? I'm looking at the BUGS section for rtsold and these bugs https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191 This is one of dhcpcd's killer features and allows me to use my pinebook on the sofa, but hotplug in ethernet to take over so I can compile my sources from NFS over distcc much faster. Roy ___ 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: FRR on FreeBSD 12 - problems with OSPFv3
> I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > the same time. I've tried frr6 and frr7 and get the same errors. > > bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm > going wrong. > > If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. What if you comment out just lo0? Running OSPF on a loopback interface makes no since, your not going to be able to establish a DR/BDR pair so OSPF can never really come up on that interface, and if it did injecting any route from 127/8 into the OSPF lsdb would be very bad! Though I doubt this is the source of the illegal instuction trap it is none the less a configuration issue. > router ospf6 > ?ospf6 router-id 172.17.18.98 > ?redistribute connected route-map MONKEY-ospf6 > ?redistribute static route-map MONKEY-AND-MORE-ospf6 > ?!interface cxl1 area 0.0.0.0 > ?!interface cxl2 area 0.0.0.0 > ?!interface cxl3 area 0.0.0.0 > ?interface lo0 area 0.0.0.0 > > As soon as I get routes from my network, ospf6d tanks. By tanks I take it you mean gets the trap you show below? > Any thoughts? > > > Here is the output from zebra and ospf6. > > *** LOGS *** > > 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 5 usec, Reason: L+ > > 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec > 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Down]->[Init] (HelloReceived) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Init]->[ExStart] (2-WayReceived) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [ExStart]->[ExChange] (NegotiationDone) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [ExChange]->[Loading] (ExchangeDone) > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 109 usec, Reason: R+, R-, L+ > > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 116 usec, Reason: R+, N+, L+ > > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [Down]->[Init] (HelloReceived) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [Init]->[ExStart] (2-WayReceived) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [ExStart]->[ExChange] (NegotiationDone) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [ExChange]->[Loading] (ExchangeDone) > 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 99 usec, Reason: R+, R- > > 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Loading]->[Full] (LoadingDone) > 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to > announce only ospf6 routes vrf=0 > 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an > error and is shutting down. > 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table > chunks > 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label > chunks > 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes > removed from the rib > > *** CRASH *** Zebra process crashes after the ospf6 process has encountered some error and shut down or are you indicatong that the OSPF6D process has crashed? > If I run on the command line and don't background, it bombs after 7 > seconds: > # ospf6d > Illegal instruction > > > Here is the end of truss: > # truss ospf6d > ... > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863378432 (0x81e04f000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863382528 (0x81e05) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863386624 (0x81e051000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863390720 (0x81e052000) > SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdff8 > process killed, signal = 4 > > I wasn't seeing any CORE files when the process dumped, so I turned this > knob: > sysctl kern.sugid_coredump=1 > > Now there is a 1 GByte core file! > > # /usr/obj/usr/src/amd64.amd64/gnu/usr.bin/gdb/gdb/gdb > /usr/local/sbin/ospf6d ospf6d.core > > (gdb) bt > #0? 0x00080030678c in hash_get () from /usr/local/lib/libfrr.so.0 > #1? 0x00080033a9b2 in route_node_lookup () from > /usr/local/lib/libfrr.so.0 > #2? 0x00241345 in ospf6_route_lookup () > #3? 0x0022e718 in ospf6_abr_examin_summary () > #4? 0x0022f13b in ospf6_abr_examin_brouter () > #5? 0x002473ad in ospf6_top_init () > #6? 0x0022efda in
[Bug 241088] netinet: Move request window scaling computation to tcp_output()
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241088 Neel Chauhan changed: What|Removed |Added Resolution|--- |Not A Bug Status|Open|Closed -- 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: DHCPv6 client in base
Ben Woods wrote in : wo> On Thu, 16 May 2019 at 2:25 am, Hiroki Sato wrote: wo> wo> > wrote wo> > in <001e01d50b49$176104d0$46230e70$@gmail.com>: wo> > wo> > dr> Has anyone ever thought or considered integrating an IPv6 DHCP client wo> > in wo> > dr> base? wo> > wo> > I have a plan to import wide-dhcp6 into the base system because it is wo> > simple enough. wo> > wo> > dr> net/dhcp6 isn't really maintained anymore from the KAME days it works wo> > for wo> > dr> basic functionality but fails when a more complex config is required. wo> > wo> > More specifics about the complex configuration? wo> > wo> > -- Hiroki wo> wo> wo> I would like to discuss whether dhcpcd is a better option to import into wo> FreeBSD base, rather than wide-dhcp6. wo> wo> dhcpcd has the following benefits that I can see: wo> - Actively maintained [1] (wide-dhcp6 seems to be stale for 11 years?) wo> - Used in NetBSD and DragonflyBSD (code sharing amongst the BSDs will wo> facilitate collective progress and lesson sharing). Roy, the upstream wo> maintainer, has committer on both NetBSD and DragonFlyBSD. wo> - more feature rich [2] wo> wo> [1] https://roy.marples.name/projects/dhcpcd/history wo> [2] https://roy.marples.name/projects/dhcpcd/features wo> wo> hrs - what are your thoughts? I do not have a strong objection on dhcpcd (I am using it on some of my FreeBSD boxes actually) but let me explain the reason why I chose wide-dhcp as the candidate. That is because it is a small, functional DHCPv6-only implementation. I am planning to rewrite it to add the missing bits and adjust it for a tighter integration with kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I feel dhcpcd (or others) is too big for that purpose. IMHO, the directions of further developments of IPv6 functionality on FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly BSD (dhcpcd) have already been diverged. For RFC 7217 I already have an in-kernel implementation (not committed yet), and I am also working on SeND (RFC 3971, not directly related to DHCPv6 though). My goal is to integrate these small implementations into the base system and make them possible to work together. So for DHCPv6, I think an implementation of only DHCPv6 is the best. If people want a more feature-rich implementation or the same one on other systems, they can still use dhcpcd or ISC's dhclient even after the import. Of course this assumes that wide-dhcp works to some degree. If it does not, importing it to the base system does not make sense. I have used it in various scenarios for a long time such as RA + O flag on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others which are complex enough, and understand what works and what is missing (poor DUID format support, for example). The popular way to use DHCPv6 is IA_PD, and wide-dhcp works well with it. So I have a question. What is missing feature in wide-dhcp which you are concerned about? I know some, but it has most of the basic functionality of DHCPv6 and I think it is enough as a minimal implementation for the base system. My primary reason is that it is just for DHCPv6 as mentioned earlier and I believe it is maintainable in the base system. I would like to know other people's opinion if there is something critical. -- Hiroki pgpU6SHrgg0WX.pgp Description: PGP signature
Re: DHCPv6 client in base
Roy Marples wrote in : ro> > A dhcp Client is a necessary part of the OS (though a bit less so with ro> > IPV6) but the serer side can be a port. (as it is). ro> ro> How is FreeBSD handling DNSSL + RDNSS over IPv6RA? That's pretty ro> standard now and I don't see a userland compoenent for it. rtsold(8) handles it. It is also responsible for invoking a DHCPv6 client when receiving an O-flag RA. -- Hiroki pgppejs0SrGoA.pgp Description: PGP signature
[Bug 234442] libnetgraph race condition
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234442 Mark Johnston changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed --- Comment #8 from Mark Johnston --- I don't have the means to test this on stable/11, but please feel free to MFC the change there if you can verify that it works. --- Comment #9 from commit-h...@freebsd.org --- A commit references this bug: Author: eugen Date: Fri Oct 11 18:05:06 UTC 2019 New revision: 353445 URL: https://svnweb.freebsd.org/changeset/base/353445 Log: MFC r347439 by markj: Atomically update the global gMsgId in libnetgraph. Otherwise concurrently running threads may inadvertently use the same token for different messages. Preserve the behaviour of disallowing negative message tokens, but allow a message token value of zero since this simplifies the code a bit and tokens are documented to be non-negative. PR: 234442 Changes: _U stable/11/ stable/11/lib/libnetgraph/msg.c -- 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: DHCPv6 client in base
On Fri, Oct 11, 2019 at 08:32:59AM +0800, Ben Woods wrote: > On Mon, 7 Oct 2019 at 8:53 am, Ben Woods wrote: > > > On Thu, 16 May 2019 at 2:25 am, Hiroki Sato wrote: > > > >> wrote > >> in <001e01d50b49$176104d0$46230e70$@gmail.com>: > >> > >> dr> Has anyone ever thought or considered integrating an IPv6 DHCP client > >> in > >> dr> base? > >> > > > > I would like to discuss whether dhcpcd is a better option to import into > > FreeBSD base, rather than wide-dhcp6. > > > > Hi everyone, > > I have been working on importing dhcpcd into FreeBSD base over the last few > days, and should be ready to share something on phabricator for review this > weekend. > > In addition to the normal review cycle, given I am a ports committer (I > don???t have a src commit bit), I would need this to be endorsed and approved > by a src committer. > > I have heavily utilised the Makefile and rc scripts from DragonFly BSD. > > I don???t intend to include any changes to the kernel for improved dhcpcd > functionality as a part of this review - these could be made subsequently > if dhcpcd is committed. For now it would just be the same functionality as > if you used the net/dhcpcd port. DHCP is one of the most exposed attack surfaces in existence. We expect it to take input from explicitly untrustworthy networks and perform actions as root. It might be OK to import this as a stopgap only supporting IPv6, but without capsicum or privilege separation (as noted elsewhere in the thread) it seems unlikely to be a good idea enable it by default or replace the existing IPv4 dhclient. -- Brooks signature.asc Description: PGP signature
[Bug 236309] [axe] pf/nat/txcsum broken on 12
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236309 Jorge Schrauwen changed: What|Removed |Added CC||sjorge+sig...@blackdot.be --- Comment #3 from Jorge Schrauwen --- Sounds similar to 235607 -- You are receiving this mail because: 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"
Re: FRR on FreeBSD 12 - problems with OSPFv3
On Fri, Oct 11, 2019 at 5:07 PM Rudy wrote: > > I just recompiled from ports - same error. > > > 2019/10/11 08:03:50 ZEBRA: [EC 4043309117] Client 'ospf6' encountered > an error and is shutting down. > > There is either a configuration error I am missing, or there is a bug in > handling IPv6 in Freebsd or FFR. > > Hi, I don't use 11.0 neither 12.0, but on 12-stable and I don't reach to reproduce this opsf6 problem. I've tested different setups documented here: https://bsdrp.net/documentation/examples/simple_bgp-rip-ospf_lab (with virtIO and em emulated NIC). https://bsdrp.net/documentation/examples/maximum_bsdrp_features_lab (with em emulated NIC) Do you have specific configuration on your interface, like non-default MTU or other ? ___ 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: FRR on FreeBSD 12 - problems with OSPFv3
On 10/11/19 2:22 AM, Andrey V. Elsukov wrote: On 11.10.2019 12:09, Rudy wrote: I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at the same time. I've tried frr6 and frr7 and get the same errors. *** CRASH *** If I run on the command line and don't background, it bombs after 7 seconds: # ospf6d Illegal instruction Here is the end of truss: # truss ospf6d ... mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863378432 (0x81e04f000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863382528 (0x81e05) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863386624 (0x81e051000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863390720 (0x81e052000) SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdff8 process killed, signal = 4 SIGILL usually means that a binary/library was built for specific CPU and you need to rebuild it on the local host. If it was installed from the official packages, this means that the port should be fixed to not have such specific optimization flags. I just recompiled from ports - same error. > 2019/10/11 08:03:50 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an error and is shutting down. There is either a configuration error I am missing, or there is a bug in handling IPv6 in Freebsd or FFR. Rudy ___ 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 241162] Panic in closefp() triggered by nginx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241162 rlwestl...@gmail.com changed: What|Removed |Added CC||rlwestl...@gmail.com --- Comment #2 from rlwestl...@gmail.com --- Looks like exactly the same stack trace I got here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237568 Also a crash triggered by Nginx. The bug linked by Andrey does seem related except that I don't see `soabort` anywhere in our stack traces. Is that fix deployed in 12.0-RELEASE-p10? -- 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: FRR on FreeBSD 12 - problems with OSPFv3
On 11.10.2019 12:09, Rudy wrote: > I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > the same time. I've tried frr6 and frr7 and get the same errors. > > *** CRASH *** > If I run on the command line and don't background, it bombs after 7 > seconds: > # ospf6d > Illegal instruction > > > Here is the end of truss: > # truss ospf6d > ... > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863378432 (0x81e04f000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863382528 (0x81e05) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863386624 (0x81e051000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863390720 (0x81e052000) > SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdff8 > process killed, signal = 4 > SIGILL usually means that a binary/library was built for specific CPU and you need to rebuild it on the local host. If it was installed from the official packages, this means that the port should be fixed to not have such specific optimization flags. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
[Bug 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787 Kubilay Kocak changed: What|Removed |Added Status|Closed |In Progress Resolution|FIXED |--- See Also||https://reviews.freebsd.org ||/D21961 --- Comment #19 from Kubilay Kocak --- (In reply to lutz from comment #18) Please ask the committer who intends to commit the change to reference this PR in the commit log message so it and the subsequent MFC can be tracked here -- 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 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787 --- Comment #18 from l...@donnerhacke.de --- https://reviews.freebsd.org/D21961 solves the ABI change issue. It's accepted but not committed. -- 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"
FRR on FreeBSD 12 - problems with OSPFv3
I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at the same time. I've tried frr6 and frr7 and get the same errors. bgpd and ospfd work fine, but ospf6 doesn't work. Not sure what I'm going wrong. If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. router ospf6 ospf6 router-id 172.17.18.98 redistribute connected route-map MONKEY-ospf6 redistribute static route-map MONKEY-AND-MORE-ospf6 !interface cxl1 area 0.0.0.0 !interface cxl2 area 0.0.0.0 !interface cxl3 area 0.0.0.0 interface lo0 area 0.0.0.0 As soon as I get routes from my network, ospf6d tanks. Any thoughts? Here is the output from zebra and ospf6. *** LOGS *** 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 5 usec, Reason: L+ 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 109 usec, Reason: R+, R-, L+ 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 116 usec, Reason: R+, N+, L+ 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Down]->[Init] (HelloReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [Init]->[ExStart] (2-WayReceived) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExStart]->[ExChange] (NegotiationDone) 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: [ExChange]->[Loading] (ExchangeDone) 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 sec 99 usec, Reason: R+, R- 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: [Loading]->[Full] (LoadingDone) 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to announce only ospf6 routes vrf=0 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an error and is shutting down. 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table chunks 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label chunks 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes removed from the rib *** CRASH *** If I run on the command line and don't background, it bombs after 7 seconds: # ospf6d Illegal instruction Here is the end of truss: # truss ospf6d ... mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863378432 (0x81e04f000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863382528 (0x81e05) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863386624 (0x81e051000) mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34863390720 (0x81e052000) SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdff8 process killed, signal = 4 I wasn't seeing any CORE files when the process dumped, so I turned this knob: sysctl kern.sugid_coredump=1 Now there is a 1 GByte core file! # /usr/obj/usr/src/amd64.amd64/gnu/usr.bin/gdb/gdb/gdb /usr/local/sbin/ospf6d ospf6d.core (gdb) bt #0 0x00080030678c in hash_get () from /usr/local/lib/libfrr.so.0 #1 0x00080033a9b2 in route_node_lookup () from /usr/local/lib/libfrr.so.0 #2 0x00241345 in ospf6_route_lookup () #3 0x0022e718 in ospf6_abr_examin_summary () #4 0x0022f13b in ospf6_abr_examin_brouter () #5 0x002473ad in ospf6_top_init () #6 0x0022efda in ospf6_abr_examin_summary () #7 0x0022f13b in ospf6_abr_examin_brouter () #8 0x002473ad in ospf6_top_init () #9 0x0022efda in ospf6_abr_examin_summary () #10 0x0022f13b in ospf6_abr_examin_brouter () #11 0x002473ad in ospf6_top_init () lines #3 - #5 repeat to over #8500 ... I stopped hitting ENTER around there and quit. *** The CONFIG *** ! ! Zebra configuration saved from vty ! 2019/10/10 23:58:21 ! frr version 7.1 frr defaults traditional ! hostname red-ospf6 password r3moved log file /var/log/frr/ospf6d.log service advanced-vty ! debug ospf6 neighbor state ! ! interface cxl1 ipv6 ospf6 cost 1 ipv6 ospf6 priority 0 ipv6 ospf6 network point-to-point ! interface cxl2 ipv6 ospf6 cost 1 ipv6 ospf6 priority 0 ipv6 ospf6 network point-to-point ! interface cxl3 ipv6
[Bug 241162] Panic in closefp() triggered by nginx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241162 Andrey V. Elsukov changed: What|Removed |Added CC||a...@freebsd.org --- Comment #1 from Andrey V. Elsukov --- I think there is some chance that this problem can be related to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239893 -- 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 240787] netgraph/ng_bridge: Replace NG_BRIDGE_MAX_LINKS with auto-incrementing (Unlimited) links
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240787 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable11?, |mfc-stable11-, |mfc-stable12? |mfc-stable12- Blocks|240700 | --- Comment #17 from Kubilay Kocak --- ^Triage: - Remove block on 12.1-R issue - Decline stable/* due to ABI change (comment 15) If anyone wants to change this, just re-open and set mfc-stable* back to ? accordingly with a comment Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 [Bug 240700] [META] FreeBSD 12.1-RELEASE blockers -- 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 241162] Panic in closefp() triggered by nginx
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241162 Kubilay Kocak changed: What|Removed |Added Keywords||crash, needs-patch, ||needs-qa Status|New |Open CC||n...@freebsd.org Flags||mfc-stable11?, ||mfc-stable12? Assignee|b...@freebsd.org|n...@freebsd.org -- 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 241191] route flush panic with RADIX_MPATH
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241191 Kubilay Kocak changed: What|Removed |Added Status|New |Open CC||gleb...@freebsd.org, ||melif...@freebsd.org, ||n...@freebsd.org Flags||maintainer-feedback?(melifa ||r...@freebsd.org), ||maintainer-feedback?(glebiu ||s...@freebsd.org), ||mfc-stable11?, ||mfc-stable12? Blocks||240700 Keywords|panic, patch|needs-qa Assignee|b...@freebsd.org|n...@freebsd.org --- Comment #4 from Kubilay Kocak --- Crash report with patch on stable/12, potential 12.1-R candidate CC recent committers around that section of code Referenced Bugs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240700 [Bug 240700] [META] FreeBSD 12.1-RELEASE blockers -- 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"
