2 May
2024
2 May
'24
11:01 p.m.
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)(a)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)(a)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)
2 May
2 May
11:19 p.m.
On Thu, May 2, 2024 at 12:01 PM Dan Cross <crossd(a)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.
11:20 p.m.
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(a)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)(a)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)(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
11:46 p.m.
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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 9:01
To: AMPRNet working group <44net(a)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)(a)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)(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
3 May
3 May
12:22 a.m.
On Thu, May 2, 2024 at 12:46 PM KUN LIN <dnwk(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 9:01
To: AMPRNet working group <44net(a)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)(a)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)(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
1:02 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 5:22 PM
To: KUN LIN <dnwk(a)linkun.info>
Cc: AMPRNet working group <44net(a)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(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 9:01
To: AMPRNet working group <44net(a)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)(a)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)(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
1:22 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
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(a)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(a)mailman.ampr.org>
*Sent:* Thursday, May 2, 2024 5:22 PM
*To:* KUN LIN <dnwk(a)linkun.info>
*Cc:* AMPRNet working group <44net(a)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(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 9:01
To: AMPRNet working group <44net(a)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)(a)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)(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
2:17 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net(a)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.
2:52 a.m.
New subject: 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(a)mailman.ampr.org>
wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via
44net
<44net(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
3:42 a.m.
New subject: 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:
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(a)mailman.ampr.org> wrote:
>
> On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
> <44net(a)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(a)mailman.ampr.org
> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
4:59 a.m.
New subject: 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:
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(a)mailman.ampr.org> wrote:
>
> On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
> <44net(a)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(a)mailman.ampr.org
> To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
4:12 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 12:52
To: Dan Cross <crossd(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: [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<mailto:44net@mailman.ampr.org>> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net@mailman.ampr.org<mailto: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<mailto:44net@mailman.ampr.org>
To unsubscribe send an email to
44net-leave@mailman.ampr.org<mailto:44net-leave@mailman.ampr.org>
5:39 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 12:52
To: Dan Cross <crossd(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: [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(a)mailman.ampr.org> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
9:59 a.m.
New subject: 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(a)gmail.com> wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN
<dnwk(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 12:52
To: Dan Cross <crossd(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: [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(a)mailman.ampr.org>
wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net(a)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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
9:13 p.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
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(a)gmail.com>
Sent: Friday, May 3, 2024 2:59 AM
To: Dan Cross <crossd(a)gmail.com>
Cc: KUN LIN <dnwk(a)linkun.info>fo>; 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?
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<http://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<mailto:crossd@gmail.com>> wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN
<dnwk@linkun.info<mailto: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<mailto:44net@mailman.ampr.org>>
Sent: Thursday, May 2, 2024 12:52
To: Dan Cross <crossd@gmail.com<mailto:crossd@gmail.com>>
Cc: Barry Bahrami <barrybahrami@gmail.com<mailto:barrybahrami@gmail.com>>;
kc8qba <kc8qba@wildtky.com<mailto:kc8qba@wildtky.com>>; kc8qba--- via 44net
<44net@mailman.ampr.org<mailto: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<mailto:44net@mailman.ampr.org>> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net@mailman.ampr.org<mailto: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<mailto:44net@mailman.ampr.org>
To unsubscribe send an email to
44net-leave@mailman.ampr.org<mailto:44net-leave@mailman.ampr.org>
4 May
4 May
12:24 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net <44net(a)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(a)gmail.com>
Sent: Friday, May 3, 2024 2:59 AM
To: Dan Cross <crossd(a)gmail.com>
Cc: KUN LIN <dnwk(a)linkun.info>fo>; 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?
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(a)gmail.com> wrote:
On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk(a)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(a)mailman.ampr.org>
Sent: Thursday, May 2, 2024 12:52
To: Dan Cross <crossd(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: [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(a)mailman.ampr.org> wrote:
On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
<44net(a)mailman.ampr.org> wrote:
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)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
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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org 
7 May
7 May
11:31 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
On Fri, 3 May 2024, Dan Cross via 44net wrote:
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net
<44net(a)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
8 May
8 May
4:47 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
[Trim Cc: list, add 44net(a)ardc.groups.io and G1FEF directly]
On Tue, May 7, 2024 at 12:31 AM Kris Kirby <kris(a)catonic.us> wrote:
On Fri, 3 May 2024, Dan Cross via 44net wrote:
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.
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net
<44net(a)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. 
10 May
10 May
4:25 p.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
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(a)mailman.ampr.org> wrote:
[Trim Cc: list, add 44net(a)ardc.groups.io and G1FEF directly]
On Tue, May 7, 2024 at 12:31 AM Kris Kirby <kris(a)catonic.us> wrote:
On Fri, 3 May 2024, Dan Cross via 44net wrote:
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(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
On Fri, May 3, 2024 at 10:13 AM kc8qba via 44net
<44net(a)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.
4 May
4 May
12:07 a.m.
New subject: Fw: Re: UCSD gateway not responding after router reboot?
On Thu, May 2, 2024 at 11:00 PM Steve L <kb9mwr(a)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(a)gmail.com> wrote:
>
> On Thu, May 2, 2024 at 5:12 PM KUN LIN <dnwk(a)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(a)mailman.ampr.org>
> > Sent: Thursday, May 2, 2024 12:52
> > To: Dan Cross <crossd(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: [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(a)mailman.ampr.org>
wrote:
> >
> > On Thu, May 2, 2024 at 2:23 PM Barry Bahrami via 44net
> > <44net(a)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(a)mailman.ampr.org
> > To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
226
days inactive
234
days old
19 comments
8 participants
participants (8)
-
Barry Bahrami -
Dan Cross -
g -
kc8qba -
Kris Kirby -
KUN LIN -
lleachii＠aol.com -
Steve L