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 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
_______________________________________________
44net mailing list --
44net@mailman.ampr.org
To unsubscribe send an email to
44net-leave@mailman.ampr.org