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@gmail.com Sent: Thursday, May 2, 2024 4:42:58 PM To: Steve L kb9mwr@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@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@gmail.com wrote:
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
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.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
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?
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
I'd be interested to see that, if you find it.
- Dan C.
On Thu, May 2, 2024, 2:18 PM Dan Cross via 44net 44net@mailman.ampr.org wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net 44net@mailman.ampr.org wrote:
This is common to prevent flapping interfaces from causing problems with the routing table through constant updates. Although an hour is a bit high. I wonder if there is a typo in the config. Just a thought
That's reasonable. I wonder how it's implemented? As far as I know, creation or tear-down of an IPENCAP tunnel does not, by itself, generate any traffic: an interface could conceivably flap and nothing on the distant end would notice. I suppose if the interface flaps, an upstream router could send an ICMP host unreachable message to the UCSD router for anything being sent through the tunnel regularly? I could see that triggering some kind of quenching logic, though an hour-ish timeout seems excessive.
- Dan C.
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org