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