Re: 13.1R problems on Pi3
- Reply: bob prohaska : "Re: 13.1R problems on Pi3"
- In reply to: Mark Millard : "Re: 13.1R problems on Pi3"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Mon, 04 Jul 2022 02:36:35 UTC
On 7/3/2022 22:22, Mark Millard wrote: > On 2022-Jul-3, at 17:36, bob prohaska<fbsd@www.zefox.net> wrote: > >> Inbound ping requests are not answered except for a few >> seconds around the time ntp runs. >> >> Inbound ssh connects prompt for a password and then time out. >> >> The ping and ssh problems can be worked around by starting an >> outbound ping process. A few seconds after doing so both ping >> and ssh are answered, erratically but usably. >> >> The problem seems to be confined to the Pi3s. Four Pi2s and a Pi4 >> on the same network branch exhibit no such problems. Only the >> pair of Pi3s seem to be affected, under 13.1 and -current. >> >> The network is started with these lines in /etc/rc.conf: >> >> hostname="www.zefox.org" >> ifconfig_ue0="inet 50.1.20.28 netmask 255.255.255.0" >> defaultrouter="50.1.20.1" >> sshd_enable="YES" > Is that only one of the RPi3*'s? Multiple machines with > that exact text would conflict with each other, all > such trying to use 50.1.20.28 andwww.zefox.org as > identification. > > Has whatever provides DHCP and such been configured to > reserve 50.1.20.28 and to associate that with the right > ethernet address? If you do not have control of such, > then, as far as I know, you should not be trying to use > what are effectively static IP addresses --unless you > have been assigned the static IP addresses by your ISP. > >> Reference to DHCP has been removed. > Why? If you use DHCP on the others, can you check the > behavior of using DHCP on these? Does it match the > others --or does end up being distinct/problematical? > > (This testing may not be able to cover the intended > use, depending on why you avoid DHCP.) > > Reminder: I'm no networking expert. >> Could that be a source >> of mischief? It seems not to cause problems on other hosts. >> >> >> That reads like you might have tried not using DHCP on >> the RPi2*'s and RPi4* . Did you? This is crossbuilt but... $ uname -v FreeBSD 13.1-STABLE #0 stable/13-n250683-e44e611e31c: Fri May 6 10:47:17 EDT 2022 karl@NewFS.denninger.net:/work/OBJ/ARM64-13/obj/work/CrossBuild-13.1STABLE/arm64.aarch64/sys/GENERIC $ uptime 10:27PM up 49 days, 7:10, 1 user, load averages: 0.14, 0.15, 0.13 Ping both for Ipv4 and v6 (along with everything else) works fine. /etc/rc.conf: ifconfig_ue0="192.168.10.214 netmask 255.255.255.0" ifconfig_ue0_ipv6="inet6 accept_rtadv" defaultrouter="192.168.10.200" sshd_enable="YES" ipv6_activate_all_interfaces="YES" ip6addrctl_enable="YES" # Set to YES to enable default address selection ip6addrctl_verbose="NO" # Set to YES to enable verbose configuration messages ip6addrctl_policy="ipv4_prefer" # A pre-defined address selection policy # (ipv4_prefer, ipv6_prefer, or AUTO) Ipv4 is fixed-address, v6 is autoconfigured off my router here. No issues and it is a Pi3; it is running a somewhat-customized Crochet build (boots from SD, runs using ram for volatile things on tmpfs, SD is mounted r/o) and a software package that is online and providing services 24x7. hw.fdt.model: Raspberry Pi 3 Model B Rev 1.2 I have "prefer v4" set due to it being dual-address and it has to register the gateway's public address, which it doesn't and can't know for IPv4 (as its dynamically assigned) thus it must send a message to a server which then can getpeername() on it to figure out where it can be reached. Removing that doesn't change anything other than prohibiting that registration from working since it will then find said server on its v6 address instead. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/