I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
``` marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi# ```
But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
``` tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel ```
(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
``` tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernel ```
However, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
On Thu, May 2, 2024 at 12:01 PM Dan Cross crossd@gmail.com wrote:
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior? [snip]
...and now it's working. Odd. I certainly didn't change anything.
- Dan C.
Yes Just my opinion
Hello George Kirn had contact with this data.
On Thu, May 2, 2024 at 11:02 AM Dan Cross via 44net 44net@mailman.ampr.org wrote:
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi#But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernelHowever, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I have similar experience with the gateway recently. Once I reboot my machine, the gateway will stop forwarding Internet traffic. But it will resume traffic in about an hour. Kun ________________________________ From: Dan Cross via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 9:01 To: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] UCSD gateway not responding after router reboot?
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
``` marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi# ```
But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
``` tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel ```
(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
``` tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernel ```
However, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X) _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Thu, May 2, 2024 at 12:46 PM KUN LIN dnwk@linkun.info wrote:
I have similar experience with the gateway recently. Once I reboot my machine, the gateway will stop forwarding Internet traffic. But it will resume traffic in about an hour.
That matches the behavior I observed earlier; it took about an hour for the gateway to begin passing traffic again. I looked on the wiki, but didn't see anything documenting this behavior; perhaps I missed it?
- Dan C.
From: Dan Cross via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 9:01 To: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] UCSD gateway not responding after router reboot?
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi#But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernelHowever, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
I've also seen this behavior & was able to replicate at two different locations - it drove me pretty crazy trying to figure it out.
I've submitted a ticket requesting a wiki account because I definitely think it should be documented.
Best, -Steve KC8QBA ________________________________ From: Dan Cross via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 5:22 PM To: KUN LIN dnwk@linkun.info Cc: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] Re: UCSD gateway not responding after router reboot?
On Thu, May 2, 2024 at 12:46 PM KUN LIN dnwk@linkun.info wrote:
I have similar experience with the gateway recently. Once I reboot my machine, the gateway will stop forwarding Internet traffic. But it will resume traffic in about an hour.
That matches the behavior I observed earlier; it took about an hour for the gateway to begin passing traffic again. I looked on the wiki, but didn't see anything documenting this behavior; perhaps I missed it?
- Dan C.
From: Dan Cross via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 9:01 To: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] UCSD gateway not responding after router reboot?
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi#But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernelHowever, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
_______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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
Barry Bahrami NB7V
On Thu, May 2, 2024, 11:02 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
I've also seen this behavior & was able to replicate at two different locations - it drove me pretty crazy trying to figure it out.
I've submitted a ticket requesting a wiki account because I definitely think it should be documented.
Best, -Steve KC8QBA
*From:* Dan Cross via 44net 44net@mailman.ampr.org *Sent:* Thursday, May 2, 2024 5:22 PM *To:* KUN LIN dnwk@linkun.info *Cc:* AMPRNet working group 44net@mailman.ampr.org *Subject:* [44net] Re: UCSD gateway not responding after router reboot?
On Thu, May 2, 2024 at 12:46 PM KUN LIN dnwk@linkun.info wrote:
I have similar experience with the gateway recently. Once I reboot my
machine, the gateway will stop forwarding Internet traffic. But it will resume traffic in about an hour.
That matches the behavior I observed earlier; it took about an hour for the gateway to begin passing traffic again. I looked on the wiki, but didn't see anything documenting this behavior; perhaps I missed it?
- Dan C.
From: Dan Cross via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 9:01 To: AMPRNet working group 44net@mailman.ampr.org Subject: [44net] UCSD gateway not responding after router reboot?
I rebooted my AMPRNet router after an upgrade earlier today, and now IPENCAP traffic doesn't seem to be flowing through the UCSD gateway. I wonder if this is expected behavior?
I've verified that all interfaces on the router are working as expected: I can ping the _external_ address of the UCSD gateway from my router's external interface:
marconi# ping -V 23 -I 23.30.150.141 169.228.34.84 PING 169.228.34.84 (169.228.34.84): 56 data bytes 64 bytes from 169.228.34.84: icmp_seq=0 ttl=48 time=86.937 ms 64 bytes from 169.228.34.84: icmp_seq=1 ttl=48 time=85.409 ms 64 bytes from 169.228.34.84: icmp_seq=2 ttl=48 time=90.166 ms 64 bytes from 169.228.34.84: icmp_seq=3 ttl=48 time=90.180 ms 64 bytes from 169.228.34.84: icmp_seq=4 ttl=48 time=82.058 ms 64 bytes from 169.228.34.84: icmp_seq=5 ttl=48 time=83.595 ms ^C --- 169.228.34.84 ping statistics --- 6 packets transmitted, 6 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 82.058/86.391/90.180/3.067 ms marconi#But suppose I try to `ping` an external IPv4 address from a machine inside of my subnet. Then those messages seem to be dropped. E.g., dumping on the encap interface:
tcpdump: listening on gif1, link-type LOOP 15:51:46.955189 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:507) [icmp cksum ok] (ttl 254, id 62634, len 84) 15:51:46.975585 44.44.48.29.34992 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt -501608111.378157913 [tos 0x10] (ttl 63, id 42418, len 76) 15:51:47.955108 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:508) [icmp cksum ok] (ttl 254, id 6160, len 84) 15:51:48.953556 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:509) [icmp cksum ok] (ttl 254, id 5705, len 84) 15:51:49.955095 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:510) [icmp cksum ok] (ttl 254, id 38617, len 84) 15:51:50.955135 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:511) [icmp cksum ok] (ttl 254, id 13652, len 84) 15:51:51.953550 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:512) [icmp cksum ok] (ttl 254, id 15767, len 84) ^C 8 packets received by filter 0 packets dropped by kernel(Note: the UDP packet is just an NTP request on the machine that happens to be running `ping`, but it's unrelated.)
I can see that such packets are being routed out of my external interface, while properly encapsulated. e.g.,
tcpdump: listening on cnmac1, link-type EN10MB 15:52:14.955137 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:535) (ttl 254, id 35282, len 84) (ttl 64, id 61599, len 104) 15:52:15.335038 35.203.211.24.57286 > 23.30.150.141.999: S [tcp sum ok] 4102707815:4102707815(0) win 65535 <mss 1460> [tos 0x20] (ttl 56, id 54321, len 44) 15:52:15.335165 23.30.150.141.999 > 35.203.211.24.57286: R [bad tcp cksum a4a9! -> d8a0] 0:0(0) ack 4102707816 win 0 (DF) [tos 0x10] (ttl 64, id 61784, len 40) 15:52:15.955143 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:536) (ttl 254, id 27600, len 84) (ttl 64, id 37135, len 104) 15:52:16.955121 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:537) (ttl 254, id 62216, len 84) (ttl 64, id 5987, len 104) 15:52:17.025154 23.30.150.141 > 169.228.34.84: 44.44.48.29.6711 > 152.70.159.102.123: [udp sum ok] v4 client strat 0 poll 0 prec 0 dist 0.000000 disp 0.000000 ref (unspec)@0.000000000 orig 0.000000000 rec -0.000000000 xmt +824494743.794610023 [tos 0x10] (ttl 63, id 64906, len 76) [tos 0x10] (ttl 64, id 14623, len 96) 15:52:17.955195 23.30.150.141 > 169.228.34.84: 44.44.48.29 > 142.250.80.4: icmp: echo request (id:cf3d seq:538) (ttl 254, id 59942, len 84) (ttl 64, id 39191, len 104) ^C 20 packets received by filter 0 packets dropped by kernelHowever, if I try to `ping` a machine I own elsewhere on the network where I can run `tcpdump`, the traffic never seems to get there.
Further, I can `ping` my external interface from elsewhere on the network. That all appears to be working. IPv6 works, so I'm fairly confident in e.g. my firewall rules and so on.
Curiously, I am receiving RIP packets from 44.0.0.1 on the multicast group, and I can `ping` other machines inside the AMPRNet mesh, but this all strongly implies that the UCSD gateway is dropping traffic to and from my subnet.
Is that expected? Thanks!
- Dan C. (KZ2X)
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
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.
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
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
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
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
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
Kun ________________________________ From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
On Thu, May 2, 2024, 2:18 PM Dan Cross via 44net <44net@mailman.ampr.orgmailto:44net@mailman.ampr.org> wrote: On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net <44net@mailman.ampr.orgmailto: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.orgmailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.orgmailto:44net-leave@mailman.ampr.org
On Thu, May 2, 2024 at 5:12 PM KUN LIN dnwk@linkun.info wrote:
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)
From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
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
I'd say what you are experiencing is normal. It's been a while since I've done much with my gateway, but I do recall waiting almost an hour for things to return to normal after bringing mine back up.
I assume there is likely some cron job on the UCSD gateway that rebuilds the list of active gateways for ingress/ egress purposes. The ampr gw stats page might provide clues when your not able to pass traffic.
gw.ampr.org/private
It was one of the last things Brian added to the UCSD gw.
On Thu, May 2, 2024, 5:40 PM Dan Cross crossd@gmail.com wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN dnwk@linkun.info wrote:
I did not witness this delay when rebooting the server previous when I
use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com;
kc8qba--- via 44net 44net@mailman.ampr.org
Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router
reboot?
If I recall Brian set up the rip announcements to be less frequent to a
host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic
from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to
look to see if I still have that.
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
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
As someone who was recently brand new to this entire space, I distinctly remember a cycle of (a) tinkering with and documenting settings until things started to work, (b) rebooting to test if boot-time configurations were being properly applied, followed by (c) disappointment and frustration.
In my opinion, that delay is neither obvious nor intuitive and (along with, perhaps, annotating that the OH7LZB VPN is no longer working) is something that should be documented.
Best, -Steve
________________________________ From: Steve L kb9mwr@gmail.com Sent: Friday, May 3, 2024 2:59 AM To: Dan Cross crossd@gmail.com Cc: KUN LIN dnwk@linkun.info; 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?
I'd say what you are experiencing is normal. It's been a while since I've done much with my gateway, but I do recall waiting almost an hour for things to return to normal after bringing mine back up.
I assume there is likely some cron job on the UCSD gateway that rebuilds the list of active gateways for ingress/ egress purposes. The ampr gw stats page might provide clues when your not able to pass traffic.
gw.ampr.org/privatehttp://gw.ampr.org/private
It was one of the last things Brian added to the UCSD gw.
On Thu, May 2, 2024, 5:40 PM Dan Cross <crossd@gmail.commailto:crossd@gmail.com> wrote: On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk@linkun.infomailto:dnwk@linkun.info> wrote:
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)
From: Steve L via 44net <44net@mailman.ampr.orgmailto:44net@mailman.ampr.org> Sent: Thursday, May 2, 2024 12:52 To: Dan Cross <crossd@gmail.commailto:crossd@gmail.com> Cc: Barry Bahrami <barrybahrami@gmail.commailto:barrybahrami@gmail.com>; kc8qba <kc8qba@wildtky.commailto:kc8qba@wildtky.com>; kc8qba--- via 44net <44net@mailman.ampr.orgmailto:44net@mailman.ampr.org> Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
On Thu, May 2, 2024, 2:18 PM Dan Cross via 44net <44net@mailman.ampr.orgmailto:44net@mailman.ampr.org> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net <44net@mailman.ampr.orgmailto: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.orgmailto:44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.orgmailto:44net-leave@mailman.ampr.org
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
Agreed. I was hoping someone who's actually familiar with the operation of amprgw would weigh in, but I took a stab at drafting something on the wiki. I mentioned it in the FAQ as well as the page about AMPRGW itself.
As someone who was recently brand new to this entire space, I distinctly remember a cycle of (a) tinkering with and documenting settings until things started to work, (b) rebooting to test if boot-time configurations were being properly applied, followed by (c) disappointment and frustration.
In my opinion, that delay is neither obvious nor intuitive and (along with, perhaps, annotating that the OH7LZB VPN is no longer working) is something that should be documented.
I put a disclaimer at the top of this page.
- Dan C.
Best, -Steve
From: Steve L kb9mwr@gmail.com Sent: Friday, May 3, 2024 2:59 AM To: Dan Cross crossd@gmail.com Cc: KUN LIN dnwk@linkun.info; 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?
I'd say what you are experiencing is normal. It's been a while since I've done much with my gateway, but I do recall waiting almost an hour for things to return to normal after bringing mine back up.
I assume there is likely some cron job on the UCSD gateway that rebuilds the list of active gateways for ingress/ egress purposes. The ampr gw stats page might provide clues when your not able to pass traffic.
gw.ampr.org/private
It was one of the last things Brian added to the UCSD gw.
On Thu, May 2, 2024, 5:40 PM Dan Cross crossd@gmail.com wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN dnwk@linkun.info wrote:
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
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
44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Fri, 3 May 2024, Dan Cross via 44net wrote:
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
IIRC is it something like 60 minutes depending on when your station last flapped, and you will see RIP traffic distributed over the IPIP tunnel. Note that as far as it is concerned, the flap is when amprripd exits and restarts. 1 hr does sound familiar, which is why I tried to avoid rebooting the virtual server. I was using a full KVM virtualized server, because it was required to load the IPIP module. Then I connected a VPS using OpenVPN to the IPIP end-point I'd established. Under OpenVPN, "none" is a valid cryptographic protocol, however you need to be aware of replay attacks, etc. In my case, there was still a lot of jitter on the VPN links due to the changing workloads of the VPS(s).
Agreed. I was hoping someone who's actually familiar with the operation of amprgw would weigh in, but I took a stab at drafting something on the wiki. I mentioned it in the FAQ as well as the page about AMPRGW itself.
My challenge was getting traffic to move at all, which was first amprripd, then DNS entries.
Policy Based Routing didn't make it much easier on Linux.
In my opinion, that delay is neither obvious nor intuitive and (along with, perhaps, annotating that the OH7LZB VPN is no longer working) is something that should be documented.
-- Kris Kirby, KE4AHR Disinformation Architect, Systems Mangler, & Network Mismanager
[Trim Cc: list, add 44net@ardc.groups.io and G1FEF directly]
On Tue, May 7, 2024 at 12:31 AM Kris Kirby kris@catonic.us wrote:
On Fri, 3 May 2024, Dan Cross via 44net wrote:
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
IIRC is it something like 60 minutes depending on when your station last flapped, and you will see RIP traffic distributed over the IPIP tunnel. Note that as far as it is concerned, the flap is when amprripd exits and restarts.
I don't use Linux, or ampr-ripd, on my gateway, but I find this mildly surprising.
The data I've observed suggests that if an upstream router returns some kind of error for a gateway --- specifically, I've observed ICMP Host Unreachable messages --- that induces AMPRGW to stop forwarding for an endpoint for ~1 hour. I haven't looked at the internals of `ampr-ripd` that closely, but it seems sort of strange that just stopping it would induce that behavior. Perhaps it has to do with tearing down tunnels and/or routes when `ampr-ripd` starts/stops.
Chris, do you have any insight into this behavior?
- Dan C.
It took approximately 27 minutes for me to begin receiving IPENCAP from AMPRGW after manually changing the IP on the Portal from an invalid IP. Just FYI. ---73,
LynwoodKB3VWG
On Tuesday, May 7, 2024 at 05:48:23 PM EDT, Dan Cross via 44net 44net@mailman.ampr.org wrote:
[Trim Cc: list, add 44net@ardc.groups.io and G1FEF directly]
On Tue, May 7, 2024 at 12:31 AM Kris Kirby kris@catonic.us wrote:
On Fri, 3 May 2024, Dan Cross via 44net wrote:
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net 44net@mailman.ampr.org wrote:
If there's a consensus that a 45-60 minute delay in passing traffic across the ucsd gateway is the expected behavior, I think we should update the wiki to reflect this fact.
IIRC is it something like 60 minutes depending on when your station last flapped, and you will see RIP traffic distributed over the IPIP tunnel. Note that as far as it is concerned, the flap is when amprripd exits and restarts.
I don't use Linux, or ampr-ripd, on my gateway, but I find this mildly surprising.
The data I've observed suggests that if an upstream router returns some kind of error for a gateway --- specifically, I've observed ICMP Host Unreachable messages --- that induces AMPRGW to stop forwarding for an endpoint for ~1 hour. I haven't looked at the internals of `ampr-ripd` that closely, but it seems sort of strange that just stopping it would induce that behavior. Perhaps it has to do with tearing down tunnels and/or routes when `ampr-ripd` starts/stops.
Chris, do you have any insight into this behavior?
- Dan C. _______________________________________________ 44net mailing list -- 44net@mailman.ampr.org To unsubscribe send an email to 44net-leave@mailman.ampr.org
On Thu, May 2, 2024 at 11:00 PM Steve L kb9mwr@gmail.com wrote:
I'd say what you are experiencing is normal. It's been a while since I've done much with my gateway, but I do recall waiting almost an hour for things to return to normal after bringing mine back up.
To quibble just a bit, I'd say that while it may be expected, it's not something I'd consider normal. 45 minutes to an hour is a good chunk of time.
I assume there is likely some cron job on the UCSD gateway that rebuilds the list of active gateways for ingress/ egress purposes. The ampr gw stats page might provide clues when your not able to pass traffic.
gw.ampr.org/private
It was one of the last things Brian added to the UCSD gw.
It took a while to hunt down the credentials to see this, but I can see this being very useful. Thanks for posting!
- Dan C.
On Thu, May 2, 2024, 5:40 PM Dan Cross crossd@gmail.com wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN dnwk@linkun.info wrote:
I did not witness this delay when rebooting the server previous when I use Debian. I recently switch to Ubuntu and noticed this issue where gateway will stop sending traffic after a reboot. When I was using Debian, reboot wasn't an issue. But I guess maybe it has to do with how long the reboot take. With Debian, reboot only takes a few seconds while Ubuntu takes much longer. Maybe the longer reboot time triggered something on the gateway side.
A longer timeout implies more opportunity for an intermediate router to generate e.g. host unreachable messages and send them to the UCSD gateway. IP is, by design, an unreliable protocol so some number of datagrams are "expected" to be lost in the normal course of things; a router will only consider a host unreachable if there's a repeated pattern of unreachability. If a reboot only takes a short time, there's less of an opportunity; if a reboot takes much longer, a greater opportunity. And indeed, I see ARP requests on my external network all the time; I suspect that's how the upstream router determines whether I'm reachable or not.
To test this, I did an experiment: I set up another machine on the same ethernet segment that connects my AMPRNet gateway to my ISP's router, and configured that machine to provide proxy ARP for the AMPRNet gateway machine. I then rebooted the AMPRNet gateway and repeatedly ran `traceroute` to it from another machine elsewhere on the Internet while it rebooted. I never saw an ICMP Host Unreachable message come back, while I did when the ARP proxy was not in place; running `tcpdump` on the machine running proxy ARP, I _did_ see it answer for the AMPR gateway's external IP address. Once the router came back online, I was able to connect to and from my subnet normally, with no additional delay.
What I believe this shows is that configuring proxy ARP for the AMPRNet gateway was enough to convince my ISP's router that the AMPRNet gateway remained up, which in turn was sufficient to prevent it from returning errors to the UCSD gateway.
At this point, the proposed explanation for all of this -- that ICMP Host Unreachable messages sent to the UCSD gateway cause the gateway to throttle traffic to the affected tunnel endpoint for ~1 hour -- match the observed phenomena sufficiently well that I feel comfortable calling it a hypothesis. RIP packet delivery seems to ignore these throttles, though (presumably it's unnecessary, given the way that IP multicast works). So far, experimental evidence appears to support this hypothesis. Regardless, it would be nice to get some confirmation if this is, in fact, what's actually going on. If it's confirmed, I'd be happy to document it on the Wiki.
- Dan C. (KZ2X)From: Steve L via 44net 44net@mailman.ampr.org Sent: Thursday, May 2, 2024 12:52 To: Dan Cross crossd@gmail.com Cc: Barry Bahrami barrybahrami@gmail.com; kc8qba kc8qba@wildtky.com; kc8qba--- via 44net 44net@mailman.ampr.org Subject: [44net] Re: Fw: Re: UCSD gateway not responding after router reboot?
If I recall Brian set up the rip announcements to be less frequent to a host if it has previously returned an unreachable code.
Else if ones public IP changes, it seems like unfriendly ddos traffic from UCSD to now, some non hams IP address.
A lot of the UCSD gw was documented in a flowchart image. I'd have to look to see if I still have that.
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
-
Barry Bahrami -
Dan Cross -
g -
kc8qba -
Kris Kirby -
KUN LIN -
lleachii＠aol.com -
Steve L