[44net] Re: Fw: Re: UCSD gateway not responding after router reboot?

So, for what it's worth, the behavior I'm experiencing is that the delay I was seeing was limited to traffic to/from external IP addresses. After rebooting, still getting those RIP packets right away, able to ping 44net IPs and the 44net whatismyip.ampr.org, & nettools hosted by Marius all working right away but its 45-60 minutes before I can ping to 8.8.8.8 or curl to ifconfig.me via the ucsd gateway. I wouldn't be surprised if there was a misconfiguration on my end however, a while ago & just for fun I also tried a 'hot swap' where I brought up a second RPi running debian, changed the DMZ on my router to the internal ip address of that second RPi & seem to recall that I was able to bring up the tunnel & daemon on the second RPi and able route traffic over the UCSD gateway without that initial delay. Best, -Steve ________________________________ From: Dan Cross <crossd(a)gmail.com> Sent: Thursday, May 2, 2024 4:42:58 PM To: Steve L <kb9mwr(a)gmail.com> Cc: Barry Bahrami <barrybahrami(a)gmail.com>om>; kc8qba <kc8qba(a)wildtky.com>om>; kc8qba--- via 44net <44net(a)mailman.ampr.org> Subject: Re: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot? On Thu, May 2, 2024 at 3:52 PM Steve L <kb9mwr(a)gmail.com> wrote: That's the funny part: I get the multicast RIP packets just fine. It's unicast data transiting the UCSD gateway that seems to get squelched. That certainly makes perfect sense. If it's what's going on, though, I'd like to know how not to run afoul of this logic. Temporary dips in connectivity are, I imagine, expected; what's the threshold for how long one has to be offline before it kicks in? It takes my router about two minutes to reboot, as it spends an inordinate amount of time reordering code in shared libraries as a security measure when it boots and it's not a super fast machine. While that's happening, I suspect some amount of traffic is sent to my subnet (not because I'm so popular, but just because of all those random machines scanning the Internet all the time and stuff). On a hunch, I just rebooted again and sent some traffic to my gateway's external address from elsewhere on the network; sure enough, after a minute or so I saw ICMP Host Unreachable messages in response to `traceroute` as the router was still coming back up. I suspect UCSD sees the same thing and decides to throttle an endpoint based on that. As I recall, the UCSD gateway was running code written by Brian Kantor (SK). If that's still the case, I wonder if it could be updated to remove the throttle if it sees an _inbound_ datagram from a recognized tunnel, or perhaps start with a shorter timeout, and exponentially increase up to some maximum if the interface doesn't come back up? I'd be interested to see that, if you find it. - Dan C.