Re: DHCPv6 IA_PD - how-to
[Long message, apologies. Thoughts mostly after the log output.] > On Jul 24, 2024, at 04:12, Roy Marples wrote: > dhcpcd can indeed setup the internal networks within the PD for you. > If my answer to Kar's question is not enough, then please let me know. Alright. Time passes, and I have a new system (FreeBSD 14.1) reach to slot in in place of my old router (FreeBSD 11.4). With Roy’s help off-list, I have a config that I think will work: duid persistent vendorclassid option classless_static_routes option rapid_commit require dhcp_server_identifier slaac private noipv6rs interface vlan0 ipv6only noipv4 noipv4ll ia_pd 0/::/56 vlan1/32 vlan2/42 vlan3/52 vlan4/62 vlan5/72 vlan6/82 vlan7/92 I brought the system up as an IPv4 router with no IPv6 configured, then ran “dhcpcd --noconfigure -d -B”. Output is long, but select bits (including top and bottom) show: ——8<——8<——8<——8< main: control_open: Connection refused dhcpcd-10.0.8 starting spawned privileged proxy on PID 43738 spawned network proxy on PID 43930 spawned controller proxy on PID 44915 DUID 00:01:00:01:2e:3e:5e:7f:a4:53:0e:79:b9:82 sandbox unavailable: capsicum lo0: ignoring due to interface type and no config pflog0: unsupported interface type 0xf6 ix0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT ix0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER ix1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER vlan3: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT […] vlan0: IAID ff:00:00:06 vlan0: IA type 25 IAID 00:00:00:00 vlan0: reading lease: /var/db/dhcpcd/vlan0.lease6 vlan0: rebinding prior DHCPv6 lease vlan0: delaying REBIND6 (xid 0x329d93), next in 1.0 seconds vlan0: multicasting REBIND6 (xid 0x329d93), next in 1.1 seconds vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4dce vlan0: renew in 3600, rebind in 5760, expire in 7200 seconds vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6 vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks REBIND6 […] vlan6: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND vlan5: DAD completed for 192.168.123.46 vlan5: leased 192.168.123.46 for 3105 seconds vlan5: renew in 1552 seconds, rebind in 2716 seconds vlan5: writing lease: /var/db/dhcpcd/vlan5.lease vlan5: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND vlan2: DAD completed for 172.31.83.42 vlan2: leased 172.31.83.42 for 755 seconds vlan2: renew in 377 seconds, rebind in 660 seconds vlan2: writing lease: /var/db/dhcpcd/vlan2.lease vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND ix0: ARP probing 169.254.156.162 (2 of 3), next in 1.8 seconds ix1: ARP probing 169.254.188.53 (2 of 3), next in 1.7 seconds ps_bpf_recvmsg: Network is down vlan1: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds ix0: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds ix1: ARP probing 169.254.188.53 (3 of 3), next in 2.0 seconds ps_bpf_recvmsg: Network is down vlan1: using IPv4LL address 169.254.156.162 zsh: segmvlan3ation fault sudo dhcpcd --noconfigure -d -B ———8<———8<—-—8< I’m sure there are “stupid user tricks” here. I think the primary problem is that it’s using more than the one interface I want it to. It also looks like it’s picking up IPv4 addresses from the local ISC dhcpd on all of the other interfaces. I’m glad it wasn’t trying to configure them! Then, of course, the SEGV. So, first I guess I need to tell it to not try interfaces other than the one I want. For my case. However there are a few things I think may want to be worked on: 1. The SEGV, obviously 2. It seems to be trying things on ix1, despite no carrier. I understand keeping an eye on it, but not sending DISCOVER and ARP et al. 3. It seems it shouldn’t accept a DHCP address from it’s local address. I question if it should try to _get_ an address if there’s already an address, but. Maybe this is a dhcpd problem, where it shouldn’t respond to requests from the local address? Thanks all, sorry for the long message. - Chris
Re: DHCPv6 IA_PD - how-to
On Thu, 01 Aug 2024 16:24:54 +0100 Chris Ross wrote --- > > [Long message, apologies. Thoughts mostly after the log output.] > > > On Jul 24, 2024, at 04:12, Roy Marples r...@marples.name> wrote: > > dhcpcd can indeed setup the internal networks within the PD for you. > > If my answer to Kar's question is not enough, then please let me know. > > Alright. Time passes, and I have a new system (FreeBSD 14.1) reach to > slot in in place of my old router (FreeBSD 11.4). With Roy’s help > off-list, I have a config that I think will work: > > duid > persistent > vendorclassid > option classless_static_routes > option rapid_commit > require dhcp_server_identifier > slaac private > noipv6rs > interface vlan0 > ipv6only > noipv4 > noipv4ll > ia_pd 0/::/56 vlan1/32 vlan2/42 vlan3/52 vlan4/62 vlan5/72 vlan6/82 > vlan7/92 > > I brought the system up as an IPv4 router with no IPv6 configured, > then ran “dhcpcd --noconfigure -d -B”. Output is long, but select > bits (including top and bottom) show: > > ——8<——8<——8<——8< > main: control_open: Connection refused > dhcpcd-10.0.8 starting > spawned privileged proxy on PID 43738 > spawned network proxy on PID 43930 > spawned controller proxy on PID 44915 > DUID 00:01:00:01:2e:3e:5e:7f:a4:53:0e:79:b9:82 > sandbox unavailable: capsicum OK, that's bad. This means that the cap_enter(3) failed so your kernel was not built with CAPABILITY_MODE enabled. > lo0: ignoring due to interface type and no config > pflog0: unsupported interface type 0xf6 > ix0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > ix0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER > ix1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER > vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > vlan1: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER > vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks CARRIER > vlan3: executing: /usr/local/libexec/dhcpcd-run-hooks PREINIT > […] > vlan0: IAID ff:00:00:06 > vlan0: IA type 25 IAID 00:00:00:00 > vlan0: reading lease: /var/db/dhcpcd/vlan0.lease6 > vlan0: rebinding prior DHCPv6 lease > vlan0: delaying REBIND6 (xid 0x329d93), next in 1.0 seconds > vlan0: multicasting REBIND6 (xid 0x329d93), next in 1.1 seconds > vlan0: REPLY6 received from fe80::3e8a:b0ff:fe3e:4dce > vlan0: renew in 3600, rebind in 5760, expire in 7200 seconds > vlan0: writing lease: /var/db/dhcpcd/vlan0.lease6 > vlan0: executing: /usr/local/libexec/dhcpcd-run-hooks REBIND6 > […] > vlan6: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND > vlan5: DAD completed for 192.168.123.46 > vlan5: leased 192.168.123.46 for 3105 seconds > vlan5: renew in 1552 seconds, rebind in 2716 seconds > vlan5: writing lease: /var/db/dhcpcd/vlan5.lease > vlan5: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND > vlan2: DAD completed for 172.31.83.42 > vlan2: leased 172.31.83.42 for 755 seconds > vlan2: renew in 377 seconds, rebind in 660 seconds > vlan2: writing lease: /var/db/dhcpcd/vlan2.lease > vlan2: executing: /usr/local/libexec/dhcpcd-run-hooks BOUND > ix0: ARP probing 169.254.156.162 (2 of 3), next in 1.8 seconds > ix1: ARP probing 169.254.188.53 (2 of 3), next in 1.7 seconds > ps_bpf_recvmsg: Network is down > vlan1: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds > ix0: ARP probing 169.254.156.162 (3 of 3), next in 2.0 seconds > ix1: ARP probing 169.254.188.53 (3 of 3), next in 2.0 seconds > ps_bpf_recvmsg: Network is down > vlan1: using IPv4LL address 169.254.156.162 > zsh: segmvlan3ation fault sudo dhcpcd --noconfigure -d -B eek, that's worse! Fixed here: https://github.com/NetworkConfiguration/dhcpcd/commit/c6a8fa1e6a68e46e89fef0f953f4c7bf4915e257 You can work around the issue by adding noipv4ll to your config. > I’m sure there are “stupid user tricks” here. I think the > primary problem is that it’s using more than the one interface > I want it to. It also looks like it’s picking up IPv4 addresses > from the local ISC dhcpd on all of the other interfaces. I’m > glad it wasn’t trying to configure them! Yes. You can limit what interfaces dhcpcd works with using a combination of allowinterfaces and denyinterfaces directives as described in dhcpcd.conf(5). Or you can give the explicit list of interfaces on the command line. If only one interface, you should use the -M option until dhcpcd-11 is finished. If PD needs any interfaces you have denied, they will be activated solely for PD. > Then, of course, the SEGV. So, first I guess I need to tell > it to not try interfaces other than the one I want. For my > case. However there are a few things I think may want to > be worked on: > > 1. The SEGV, obviously > 2. It seems to be trying th
[Bug 280097] Warning printed when FIBs are expanded is unhelpful and confusing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280097 --- Comment #9 from commit-h...@freebsd.org --- A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=a48f7a2eb90b0812281e6d69bb05eb61433ea247 commit a48f7a2eb90b0812281e6d69bb05eb61433ea247 Author: Zhenlei Huang AuthorDate: 2024-08-01 17:48:58 + Commit: Zhenlei Huang CommitDate: 2024-08-01 17:48:58 + fibs: Suppress the WARNING message for setups with multiple fibs Change 2d3982419593 switched net.add_addr_allfibs default to 0. The warning message is for potential users of the feature. Well since all supported releases have 0 as default, those potential users may have already gotten the notification, emitting this WARNING every time increasing the fib number is less useful but rather confusing to other users. So let's suppress it right now. PR: 280097 Reviewed by:markj Differential Revision: https://reviews.freebsd.org/D45971 sys/net/route/route_tables.c | 5 - 1 file changed, 5 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280097] Warning printed when FIBs are expanded is unhelpful and confusing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280097 --- Comment #10 from commit-h...@freebsd.org --- A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=352dd826ffdd88d26744023fe8bcff795bdf64d8 commit 352dd826ffdd88d26744023fe8bcff795bdf64d8 Author: Zhenlei Huang AuthorDate: 2024-08-01 18:00:45 + Commit: Zhenlei Huang CommitDate: 2024-08-01 18:00:45 + fibs: Limit the WARNING message to only once when setting up with multiple fibs In main [1] this warning message is suppressed but no plans to MFC the change as the message may be still useful for users that upgrade from older releases to 14.x or 13.x. Well emitting this warning message every time increasing the fib number is confusing for users not for the feature `net.add_addr_allfibs`, let's limit it to be printed only once. 1. a48f7a2eb90b fibs: Suppress the WARNING message for setups with multiple fibs This is a direct commit to stable/14 and stable/13. PR: 280097 Reviewed by:markj Differential Revision: https://reviews.freebsd.org/D46204 sys/net/route/route_tables.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280097] Warning printed when FIBs are expanded is unhelpful and confusing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280097 --- Comment #11 from commit-h...@freebsd.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=7797719d3a8b1eb50e57c6652f744a6bffc91599 commit 7797719d3a8b1eb50e57c6652f744a6bffc91599 Author: Zhenlei Huang AuthorDate: 2024-08-01 18:00:45 + Commit: Zhenlei Huang CommitDate: 2024-08-01 18:04:54 + fibs: Limit the WARNING message to only once when setting up with multiple fibs In main [1] this warning message is suppressed but no plans to MFC the change as the message may be still useful for users that upgrade from older releases to 14.x or 13.x. Well emitting this warning message every time increasing the fib number is confusing for users not for the feature `net.add_addr_allfibs`, let's limit it to be printed only once. 1. a48f7a2eb90b fibs: Suppress the WARNING message for setups with multiple fibs This is a direct commit to stable/14 and stable/13. PR: 280097 Reviewed by:markj Differential Revision: https://reviews.freebsd.org/D46204 (cherry picked from commit 352dd826ffdd88d26744023fe8bcff795bdf64d8) sys/net/route/route_tables.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 280097] Warning printed when FIBs are expanded is unhelpful and confusing
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280097 Zhenlei Huang changed: What|Removed |Added Status|Open|Closed Resolution|--- |FIXED --- Comment #12 from Zhenlei Huang --- (In reply to Jeremy Cooper from comment #5) Suppressed the warning message in main. Limited the warning message to be printed only once in stable/14 and stable/13. -- You are receiving this mail because: You are the assignee for the bug.
[Bug 252725] Realtek RTL8821AU/TP-Link T2U Nano: Frequent disconnects on Intel Tiger Lake
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252725 Michael Zhilin changed: What|Removed |Added CC||miz...@freebsd.org --- Comment #1 from Michael Zhilin --- Hi, I would like to confirm that the problem is still present. Tongle: TP-Link T2U Nano, RTL8821AU Kernel: FreeBSD 15.0-CURRENT #0 main-n268901-2b28c8ff I guess that overheating may be cause of issue. Is it possible to gather temp from usb tongle except external sensor? Thanks! -- You are receiving this mail because: You are the assignee for the bug.
