2 May
2024
2 May
'24
2:02 p.m.
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