March 2026 - Bird-users - Mailing Lists

Example configuration for ASPA with rpki-client?
by Robert Scheck 26 Jun '26

26 Jun '26

Hello, does somebody have an example configuration snippet for ASPA in BIRD with rpki-client? I've read https://bird.network.cz/?get_doc&v=20&f=bird-6.html but I'm still not sure how the configuration in BIRD for an AS with two transit providers (just upstreams, no downstreams) would look like... Regards, Robert

6 11

Several assertion failures in 3.2.0
by Matt Corallo 02 May '26

02 May '26

Figured I'd give 3.2.0 a whirl, but sadly it still seems quite assertion-failure-prone. It seems to hit quite a few assertions, sadly, so not sure if the underlying issue isn't something less than deterministic. I have core dumps that I can provide against the debian forky 3.2.0 package. I saw at least the following: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007fa1b85289ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007fa1b84d3cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007fa1b84bc4ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000555dddb0a1bc in bug (msg=msg@entry=0x555dddb1ace8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000555ddda7ad4c in proto_announce_state_locked (ts=0x555dddb9a260 <proto_state_table_pub>, p=0x555e06438c70, new_state=0x7fa111f18208) at nest/proto.c:3069 #6 proto_announce_state (p=0x555e06438c70, attr=0x7fa111f18208) at nest/proto.c:3129 #7 0x0000555ddda58cb6 in defer_execute (_ld=<optimized out>) at lib/defer.c:22 #8 0x0000555ddda590a6 in ev_run_list_limited (l=l@entry=0x555dddb94578 <main_birdloop+216>, limit=4294967294, limit@entry=0) at lib/event.c:336 #9 0x0000555dddb007a4 in io_loop () at sysdep/unix/io.c:2648 #10 0x0000555ddda1632e in main (argc=<optimized out>, argv=<optimized out>) at sysdep/unix/main.c:1106 and this twice: (gdb) bt #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x00007facbfb6c9ff in __pthread_kill_internal (threadid=<optimized out>, signo=6) at ./nptl/pthread_kill.c:89 #2 0x00007facbfb17cc2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x00007facbfb004ac in __GI_abort () at ./stdlib/abort.c:77 #4 0x0000557b139b21bc in bug (msg=msg@entry=0x557b139c2ce8 "Assertion '%s' failed at %s:%d") at sysdep/unix/log.c:412 #5 0x0000557b13934353 in rt_notify_basic (c=c@entry=0x557b1d7e2e10, new=<optimized out>, new@entry=0x7fac024adfb8, old=old@entry=0x7fac8828a938) at nest/rt-table.c:1192 #6 0x0000557b139385cb in channel_notify_basic (_channel=0x557b1d7e2e10) at nest/rt-table.c:1627 #7 0x0000557b139010a6 in ev_run_list_limited (l=l@entry=0x557b1d7e37d8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #8 0x0000557b139af4ff in birdloop_run (_loop=0x557b1d7e3700) at sysdep/unix/io-loop.c:1836 #9 0x0000557b139010a6 in ev_run_list_limited (l=0x557b1d898fb8, limit=4294967294, limit@entry=4294967295) at lib/event.c:336 #10 0x0000557b139ad392 in bird_thread_main (arg=0x557b1d899210) at sysdep/unix/io-loop.c:952 #11 0x00007facbfb6ab7b in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:448 #12 0x00007facbfbe87b8 in __GI___clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:78 I also got a Assertion '!new || rte_is_valid(new)' failed at nest/rt-table.c:1416 once but don't have a coredump for that one.

1 2

BGP reload routes issue
by Derco Sportel 02 Apr '26

02 Apr '26

Hello, We've been relying on bird heavily in our DC and basically all of our servers use bird. All server advertise /32 addresses using BGP toward the network and we use BFD for fast-fail. Lately we have observed some issues with bird reloads where some neighbors report reload failed. After investigation it looks as if the reload fails if the following conditions have been met: 1. BGP sessions were established 2. BGP flapped for $reason (router reload, BFD flap, other) After this, even though the BGP sessions are there, the Route refresh capability is no longer possible. A restart of bird solves the problem. After investigation we suspect this is caused by the combination of these parts of the code: https://github.com/CZ-NIC/bird/blob/9d509f232eaf04f707f51fd2368841d899ab8af… and https://github.com/CZ-NIC/bird/blob/9d509f232eaf04f707f51fd2368841d899ab8af… Our current install is version 3.2.0, though we have also observed route refresh issues with prior 3.x versions. The bgp_init creates the object with reload routes, but a bgp_stop makes it NULL. A bgp_start just starts the BGP session, but as the reload_routes is NULL we loose the Route refresh capability. We might be completely off track here, and this might very well be intended behavior, though we do suspect this to be wrong. Can someone have a look at this and tell us if this is a bug or a feature? Regards, Derco Sportel | System Engineer Networking | https://bol.com<https://bol.com/>

2 1

Subject: Bird3 - Establishing a BGP session over IPv6 LL addresses
by Lucas da Vila 31 Mar '26

31 Mar '26

Hi! I'm a member of the DN42 network, and I have a mikrotik router connected to it, I've only have 1 peer and I'm receiving over MP-BGP IPv4 and IPv6 prefixes. Also on the mikrotik I'm running a route-reflector. With my bird3 (3.2.0 from debian repo) instance I'm trying to connect to the route reflector over a couple of IPv6 LL addresses. But it doesn't seem to be working. This is my bird3 config: ``` router id 192.168.1.200; log "/var/log/bird/bird.log" all; protocol bgp mkt01_dn42_rr { description "mkt01 dn42 RR"; # local 192.168.1.200 as 64512; local fe80::42e2:30ff:fe60:edbb%wlp2s0 as 64512; # neighbor 192.168.1.201 as 64512; neighbor fe80::2805%wlp2s0 as 64512; interface "wlp2s0"; direct; strict bind yes; ipv4 { import all; }; ipv6 { import all; }; } protocol bmp { station address ip 127.0.0.1 port 5000; monitoring rib in pre_policy; monitoring rib in post_policy; } ``` After trying adding and removing params liks strict bind, interface, etc I was not able to land a configuration that finally worked. I must say that over IPv4 the session was established, but over IPv6 stills in Idle. Is anyone out there with a similar config? Any ideas why this happens? Regards, Lucas

3 8

Bird 3.2.0 crashing with "Assertion 'DG_IS_LOCKED(orig->domain)' failed at lib/resource.c:208"
by Buchberger, Carsten (WiTCOM) 27 Mar '26

27 Mar '26

Hi, after upgrading from Bird 3.1.4 to 3.2.0 (EPEL RPM package) bird is crashing shortly after starting it with the following error Assertion 'DG_IS_LOCKED(orig->domain)' failed at lib/resource.c:208 The issue was reported back in january on this list (https://bird.network.cz/pipermail/bird-users/2026-January/018551.html) but there was no real follow-up. We confirm the behaviour - bird crashes shortly after processing the first BGP requests and generates he following core-dump Stack trace of thread 6573: #0 0x00007f191f08d02c __pthread_kill_implementation (libc.so.6 + 0x8d02c) #1 0x00007f191f03fb86 raise (libc.so.6 + 0x3fb86) #2 0x00007f191f029873 abort (libc.so.6 + 0x29873) #3 0x0000559400a21d5f bug (bird + 0xe9d5f) #4 0x0000559400978bd7 rmove (bird + 0x40bd7) #5 0x00005594009d3809 bgp_start.lto_priv.0 (bird + 0x9b809) #6 0x000055940098b48e proto_rethink_goal.lto_priv.0 (bird + 0x5348e) #7 0x000055940097611e defer_execute (bird + 0x3e11e) #8 0x0000559400972323 ev_run_list_limited (bird + 0x3a323) #9 0x0000559400950556 main (bird + 0x18556) #10 0x00007f191f02a610 __libc_start_call_main (libc.so.6 + 0x2a610) #11 0x00007f191f02a6c0 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a6c0) #12 0x0000559400950c75 _start (bird + 0x18c75) Stack trace of thread 6574: #0 0x00007f191f088540 __GI___lll_lock_wait (libc.so.6 + 0x88540) #1 0x00007f191f08e6d2 __pthread_mutex_lock@GLIBC_2.2.5<mailto:__pthread_mutex_lock@GLIBC_2.2.5> (libc.so.6 + 0x8e6d2) #2 0x0000559400a22a92 do_lock (bird + 0xeaa92) #3 0x0000559400a1c0e0 bird_thread_main (bird + 0xe40e0) #4 0x00007f191f08b2ea start_thread (libc.so.6 + 0x8b2ea) #5 0x00007f191f1103d0 __clone3 (libc.so.6 + 0x1103d0) Stack trace of thread 6575: #0 0x00007f191f1030cf __poll (libc.so.6 + 0x1030cf) #1 0x0000559400a1c436 bird_thread_main (bird + 0xe4436) #2 0x00007f191f08b2ea start_thread (libc.so.6 + 0x8b2ea) #3 0x00007f191f1103d0 __clone3 (libc.so.6 + 0x1103d0) ELF object binary architecture: AMD x86-64 We reverted to Bird 3.1.5 - no issues here. The issue occurs with the following configuration (slightly anonymized) Bird.conf # Configure logging log syslog all; # Include constants include "/etc/bird/constants.conf"; router id rs_ipv4; protocol bfd BFD_DCFABRIC { multihop { interval 300 ms; multiplier 3; }; } protocol direct { disabled; # Disable by default ipv4; # Connect to default IPv4 table ipv6; # ... and to default IPv6 table } protocol kernel { ipv4 { }; } protocol kernel { ipv6 { }; } protocol static { disabled; ipv4; # Again, IPv4 channel with default options } include "/etc/bird/rs-peerings.conf"; constants.conf define rs_ipv4 = x.y.y.z; rs-peerings.conf # FILTER filter only_serviceips { if net ~ [ 192.168.20.0/24{32,32} ] then accept; if net ~ [ 10.127.64.0/19{32,32} ] then accept; reject; } # HOSTS template bgp SERVICENODE { local as 4200010004; ipv4 { import filter only_serviceips; export none; }; rs client; hold time 6; multihop 10; bfd on; source address rs_ipv4; } protocol bgp rack_XYZ from SERVICENODE { neighbor range 192.168.y.y/26 as 4200010003; dynamic name "rack_XYZ_"; } template bgp DCFABRIC { ipv4 { import none; export all; add paths tx; }; local as 4200010004; rs client; multihop 10; bfd on; source address rs_ipv4; } # DC-Fabric nodes protocol bgp R_DCI_01 from DCFABRIC { neighbor x.x.x.x as 4200001201; }

2 1

Bird and keepalived.
by Mike Neo 26 Mar '26

26 Mar '26

Hi all, I’m looking for best practices and design recommendations for using Keepalived (VRRP) in a setup with two BIRD-based routers running iBGP between each other. Setup overview - Two routers (R1 and R2), both running BIRD based on debian repo - Direct interconnection via eno1 (1GE Base-T) used for iBGP session - Each router has its own uplink and independent eBGP session - There is a single IX service currently connected to R1 - Goal: ensure failover to R2 (via Keepalived/VRRP) if R1 goes down Questions 1. VRRP traffic design What is the recommended approach for VRRP packets in this kind of setup? - Should VRRP run over a dedicated VLAN on the inter-router link (eno1)? - Or is it better to run VRRP on the same interface where the VIP is configured (e.g., gateway interface for downstream hosts), possibly using a separate VLAN there? I’m trying to understand what is considered cleaner and more robust in production environments. 2. Track scripts – best practices What are the best practices when using track_script in Keepalived? - What should be monitored in a BGP/BIRD context? - BGP session state? - Reachability (e.g., upstream via ping)? - Interface/link state? - IX availability? - How do you typically avoid false positives / flapping? - Any recommended patterns for integrating BIRD state with Keepalived? 3. Failover strategy for IX service Given that: - Only R1 is physically connected to the IX - Both routers participate in BGP and exchange routes via iBGP What is the recommended way to ensure that: • Traffic and VIP failover cleanly to R2 • And ideally, the IX connectivity (logically) follows to R2 during failure? Is this typically handled purely via VRRP + routing changes, or are there additional mechanisms commonly used? Any real-world examples, configuration snippets, or design insights would be greatly appreciated. Thanks! Mike

4 3

Half-Off-Topic: `wrtlab` - An educational(?) network lab using OpenWrt and BIRD only
by Bernd Naumann 25 Mar '26

25 Mar '26

Dear BIRDies, Hey all! I hope it's cool and OK with everyone, that I'd like to share something with you, which is only kinda half BIRD related. Half BIRD related? Because back then, the initially idea came out of a personal need of an BIRD test lab, which "scales" and is actually usable (for me)... And existing one...? They didn't float my boat... So, what's `wrtlab`[1]? > `wrtlab`, is a framework to build and run virtual OpenWrt network > environments locally on your GNU/Linux x86/64 within minutes. > > It builds virtual x86/64 machine images from scratch using > the OpenWrt Image Builder; or it just modifies a copy of another > disk image, using guestfish from libguestfs. > > It runs its virtual machines with kvm, via libvirt, using Vagrant and > its plugin vagrant-libvirt, because its a user friendly wrapper around > linux kernel virtualisation. It's written in simple clean pure `bash`. Easy to follow. No crude hacks or something. Batteries and (non trivial) examples included: https://codeberg.org/fde6-a09a-b373/wrtlab/ /Project-Files/ The whole configuration of an "lab environment" is done only via directory structure and file overwrites. No fancy or silly stuff. No ansible or puppet, no shell provisioner. Build and run. (A user might choose to make heavy use of `uci` firstboot scripts, but that's in the freedom of the user.) I've have chosen and restricted this tool to OpenWrt (and Linux as an host OS) only, because I think there is some void to fill... I wanted to see an "easy to use"/"it just works" environment (that's why `vagrant`), which teaches networking in general, on OpenWrt as a specific platform, but mainly while using BIRD.[2] Easy to use **and** easy to modify and extend.[3] Why I'm writing you all about this? 1. I hope to find some /proof readers/ and *first time users*. Maybe someone even has a bored trainee, who needs something to do ;) 2. I'd like to get some kind of feedback, or even happy users others then myself :D I hope one or another found it informational. Thanks for your time. Have a good time! Best, Bernd [1] https://codeberg.org/fde6-a09a-b373/wrtlab [2] Yes, BIRD3 is available on OpenWrt 25.10 [4] I'm under the impression that a student should be able to break its tools and be able to understand how they actually work without digging through 18 layers of abstractions and distractions. I hope that with simple file and directory structures there is no room for distraction.

1 0

[EVPN] BIRD does not handle multihomed host
by Tomáš Matuš 25 Mar '26

25 Mar '26

Hello BIRDs! Hello Ondra. In my lab I have an all-active multihomed host to PE1 and PE2, BIRD is there as a PE3. I noticed that when both PE1 and PE2 announce a Type 2 route for the multihomed MAC (b8:69:f4:e0:4e:04) BIRD only uses one and does not fallback to the other when the first is withdrawn. I understand that this is starting to touch unsupported EVPN parts and BIRD doesn't do much with Type 1 and Type 4 routes apart of adding them to the evpn table, but it should at least handle multiple Type 2 routes for the same MAC. With ESI and LAG configured on PE1&PE2 BIRD accepts and shows all relevant routes and both Type 2s are there: ``` bird> sh route table evpntab Table evpntab: evpn mac 10.10.10.1:10010 0 b8:69:f4:e0:4e:04 * unicast [bgp_Arista 22:25:26.352 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 10010 evpn mac 10.10.10.2:10010 0 b8:69:f4:e0:4e:04 * unicast [bgp_Huawei 22:25:45.280 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 10010 evpn ead 10.10.10.1:1 4294967295 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Arista 22:24:58.357 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 0 evpn ead 10.10.10.1:10010 0 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Arista 22:25:08.352 from 10.10.10.1] * (100/12) [i] via 100.90.109.98 on ens192 mpls 10010 evpn ead 10.10.10.2:0 4294967295 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Huawei 22:25:51.723 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 0 evpn ead 10.10.10.2:10010 0 00:00:00:00:11:11:22:22:33:33 unicast [bgp_Huawei 17:29:05.249 from 10.10.10.2] * (100/1) [?] via 100.90.109.98 on ens192 mpls 10010 evpn es 10.10.10.2:0 00:00:00:00:11:11:22:22:33:33 10.10.10.2 [bgp_Huawei 22:26:06.724 from 10.10.10.2] * (100) [?] evpn es 10.10.10.1:1 00:00:00:00:11:11:22:22:33:33 10.10.10.1 [bgp_Arista 22:24:58.357 from 10.10.10.1] * (100) [i] ``` When I inspect the ethernet table inside BIRD only one of these Type 2 routes is added (omitting flood entries to keep it short) and this route is also added to the kernel: ``` bird> sh route table etab10010 all ... b8:69:f4:e0:4e:04 mpls 10010 unicast [evpn10010 22:25:45.280] * (80) via 10.10.10.2 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010``` Once one link from the LAG goes down and one of PE1 or PE2 withdraws its routes (does not matter which one) BIRD then receives withdraw for Type 2 route with MAC b8:69:f4:e0:4e:04 and removes it from ethernet table and from the bridge fdb without checking if any other route is still available in the evpntab to replace it with. As a result the traffic is flooded. I am somewhat convinced that this is partially caused by the channel being RA_ANY rather than RA_OPTIMAL for the non-BUM entries and because multiple routes are not considered in the BIRD eth table. To at least hack around this and make sure BIRD falls back to another available route I came up with the attached patch. - similarly to IMET routes it uses RD to create unique sources for received Type 2 routes and adds all to the eth table - uses first route from net->routes in kbr_rt_notify to install it to the kernel Using the first route likely is not optimal right now as kbr_rte_better isn't implemented to do BGP-style comparison. With my patch i see both routes in eth table and only one is installed to fdb: ``` bird> sh route table etab10010 all ... b8:69:f4:e0:4e:04 mpls 10010 unicast [evpn10010 11:04:26.321] * (80) via 10.10.10.1 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010 unicast [evpn10010 11:04:48.048] (80) via 10.10.10.2 on vxlan10010 mpls 10010 Type: EVPN univ mpls_label: 10010 [root@col ~]# bridge fdb show br br10010 b8:69:f4:e0:4e:04 dev vxlan10010 vlan 1 extern_learn master br10010 b8:69:f4:e0:4e:04 dev vxlan10010 extern_learn master br10010 00:00:00:00:00:00 dev vxlan10010 dst 10.10.10.1 self extern_learn permanent 00:00:00:00:00:00 dev vxlan10010 dst 10.10.10.2 self extern_learn permanent b8:69:f4:e0:4e:04 dev vxlan10010 dst 10.10.10.1 self extern_learn permanent ```and when the route from 10.10.10.1 is withdrawn it gets immediately replaced by the route from 10.10.10.2. I'm curious to hear your opinion how you feel about having multiple routes for same MAC in the eth bridge protocol. Would it be cleaner to do this between EVPN table and the eth table rather than eth table and kernel? As in install optimal route from evpn table into eth table, if route is withdrawn put the next best route from evpn table into eth table. And 1:1 sync eth table to kernel. I don't plan to further adjust my "patch" so feel free to treat this as a bug report but I would appreciate to hear what you think if I may steal some of your time. Thanks for the fun, Tomáš

2 1

Documentation typo in filter example (bird-2.17.1.html#filters)
by Evgeniy Gaydarenko 19 Mar '26

19 Mar '26

Hello, I noticed a small typo in the HTML documentation for BIRD 2.17.1, in the Filters section: https://bird.nic.cz/doc/bird-2.17.1.html#filters In the example filter *not_too_far*, the comparison uses the HTML entity *&g* t instead of the literal *>* character. If you copy the example as-is into a BIRD configuration file, the line *if rip_metric &gt 10 then* causes a “Unknown character” error when BIRD parses the configuration. Replacing &gt with > fixes the problem: *if rip_metric > 10 then* It would be helpful if the documentation could be updated so the example uses the correct > character, to avoid confusing users who copy the example directly. Best regards, Evgeniy Gaydarenko gaydarenko(a)mail.ru

2 1

bird 3.2.0 crashes: "Attempted to start channel's already started export"
by Arkadiusz Miśkiewicz 18 Mar '26

18 Mar '26

Upgraded to 3.2.0 (from 1.x) on ancient i686 machine, running bird with -R and #0 0xb7ef9569 in __kernel_vsyscall () #1 0xb7cc7ab7 in ?? () from /lib/libc.so.6 #2 0xb7c71171 in raise () from /lib/libc.so.6 #3 0xb7c59216 in abort () from /lib/libc.so.6 #4 0x08148c71 in bug (msg=msg@entry=0x815e7b8 "%s.%s: Attempted to start channel's already started export") at sysdep/unix/log.c:412 #5 0x080af197 in channel_start_export (c=c@entry=0x9ab5e60) at nest/proto.c:780 #6 0x080b2d0b in graceful_recovery_done (_=0x81d30d0 <_graceful_recovery_context+16>) at nest/proto.c:2082 #7 0x08090182 in ev_run_list_limited (l=<optimized out>, limit=4294967293, limit@entry=4294967295) at lib/event.c:338 #8 0x0813eb77 in io_loop () at sysdep/unix/io.c:2646 #9 0x0804b32e in main (argc=2, argv=0xbfea0d24) at sysdep/unix/main.c:1111 Fed claude with the problem and its "findings" were like this below (bird doesn't crash with this "fix" but I can't tell if this is the right fix or papering of the real bug) Kernel: skip export start in krt_init_scan() when gr_wait is set When graceful restart recovery is active (-R), krt_start() sets gr_wait=1 on the kernel channel to defer export until recovery completes (via graceful_recovery_done()). However, krt_init_scan() unconditionally calls channel_start_export() when transitioning from KPS_INIT, without checking gr_wait. When graceful_recovery_done() later runs, it finds gr_wait=1 and tries to start the export again, triggering: bug("%s.%s: Attempted to start channel's already started export") Reported on bird-users by Christoph (Jan 2026) for BIRD 3.1.5. Still present in 3.2.0 despite bda2178e ("Kernel: pause exports also on restart until scan is done") which set rt_notify=NULL in krt_start() but didn't address the krt_init_scan() path. Skip channel_start_export() in krt_init_scan() when gr_wait is set, letting graceful_recovery_done() handle it instead. --- a/sysdep/unix/krt.c +++ b/sysdep/unix/krt.c @@ -449,7 +449,9 @@ krt_init_scan(struct krt_proto *p) case KPS_INIT: /* Allow exports now */ p->p.rt_notify = krt_rt_notify; - channel_start_export(p->p.main_channel); + /* When gr_wait is set, graceful_recovery_done() will start the export */ + if (!p->p.main_channel->gr_wait) + channel_start_export(p->p.main_channel); rt_refresh_begin(&p->p.main_channel->in_req); p->sync_state = KPS_FIRST_SCAN; return 1; - The upstream fix bda2178e / 47ed4aa0 is already in 3.2.0 — it sets rt_notify = NULL in krt_start() to defer exports - But it's incomplete — krt_init_scan() still unconditionally calls channel_start_export() on first scan timer, without checking gr_wait - This is a new bug in the 3.2.0 release, not present in older code (since 91c98efe introduced the KPS_INIT state machine) - The fix on the 372-release-v3.2.1 branch has the same code — the bug will still be in 3.2.1 unless they pick up a further fix - Our patch is the correct minimal fix for this -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

1 1