12 Jan
2025
12 Jan
'25
11:57 p.m.
All,
I was trying to bring up an AMPRNet IPIP tunnel in my lab network, but when
I did a packet capture on the WAN side of the gateway I am setting up, I
noticed that on average, about 80% of the IPIP packets I receive from the
UCSD gateway have their inner headers corrupted. As far as I can tell, the
first 4 bytes of the inner header are being overwritten with a garbage byte
sequence (hex 00-04-00-00). I have included a packet capture showing what's
going on. At packet 63, the RIP announcement starts, and continues through
packet 100, so there's some known-good traffic in there.
Has anyone seen anything like this before?
I have another AMPRNet IPIP tunnel set up on a datacenter server, and it
has no such problem, so this is an isolated issue (i.e., not an issue with
the UCSD gateway). The only other thing I could suspect is that the
ISP-issued modem/gateway combo unit. Of course, I have no visibility into
traffic upstream of this unit, so I don't have a way to know if it is
causing the corruption. Unfortunately, my ISP doesn't let me disable the
gateway function of the unit, so I have to suspect the firmware of this
device.
Any and all help is appreciated. I am going to call my ISP tomorrow and see
if they are aware of any issues with these modem/gateway units.
Thanks,
Eric Johnson - AE0JE
13 Jan
13 Jan
12:14 a.m.
Hi Eric.
A shame you're not able to directly connect to your ISP's incoming
interface, with their modem being a mysterious blackbox it's going to be
hard. Do you have any controls at all on the ISP modem, perhaps features
like its VPN passthrough is interfering?
I just did a packet capture for a while from my link, and I'm receiving
nothing but good traffic from the USCD gateway. (although in practice it
is incredibly slow here in Australia - less than 1Mbit/sec)
If you need a far-end node to set up some packet captures with or set up
an iperf node or the like, let me know.
73
Gavin
VK6HGR
On 13/01/2025 12:57 pm, Eric Johnson via 44net wrote:
All,
I was trying to bring up an AMPRNet IPIP tunnel in my lab network, but
when I did a packet capture on the WAN side of the gateway I am setting
up, I noticed that on average, about 80% of the IPIP packets I receive
from the UCSD gateway have their inner headers corrupted. As far as I
can tell, the first 4 bytes of the inner header are being overwritten
with a garbage byte sequence (hex 00-04-00-00). I have included a packet
capture showing what's going on. At packet 63, the RIP announcement
starts, and continues through packet 100, so there's some known-good
traffic in there.
Has anyone seen anything like this before?
I have another AMPRNet IPIP tunnel set up on a datacenter server, and it
has no such problem, so this is an isolated issue (i.e., not an issue
with the UCSD gateway). The only other thing I could suspect is that the
ISP-issued modem/gateway combo unit. Of course, I have no visibility
into traffic upstream of this unit, so I don't have a way to know if it
is causing the corruption. Unfortunately, my ISP doesn't let me disable
the gateway function of the unit, so I have to suspect the firmware of
this device.
Any and all help is appreciated. I am going to call my ISP tomorrow and
see if they are aware of any issues with these modem/gateway units.
Thanks,
Eric Johnson - AE0JE
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
12:35 a.m.
Hi Gavin,
I've done everything I can think of to prevent interference by the box of
mysteries:
- WiFi is disabled and the only device connected to its LAN side is my
pfSense firewall (this, paired with DMZ should effectively make it a 1:1
NAT)
- Firewall is disabled
- DMZ is set to send all WAN traffic to my firewall
- UPNP, DNS, DHCP, NTP, DDNS services are all disabled
- VPN passthrough options are all disabled (IPSec, PPTP, L2TP)
The box does have an "IP Passthrough" mode which I think would be ideal,
but when I enable it, it stops passing any traffic at all - DHCP, ARP, etc
all go unanswered on the LAN side. At that point, I have to hold down the
reset button to factory reset it before it becomes usable again. I will
also ask if they know anything about this IP passthrough mode when I call
them.
Thanks,
Eric - AE0JE
On Sun, Jan 12, 2025 at 11:14 PM Gavin Rogers via 44net <
44net(a)mailman.ampr.org> wrote:
Hi Eric.
A shame you're not able to directly connect to your ISP's incoming
interface, with their modem being a mysterious blackbox it's going to be
hard. Do you have any controls at all on the ISP modem, perhaps features
like its VPN passthrough is interfering?
I just did a packet capture for a while from my link, and I'm receiving
nothing but good traffic from the USCD gateway. (although in practice it
is incredibly slow here in Australia - less than 1Mbit/sec)
If you need a far-end node to set up some packet captures with or set up
an iperf node or the like, let me know.
73
Gavin
VK6HGR
On 13/01/2025 12:57 pm, Eric Johnson via 44net wrote:
All,
I was trying to bring up an AMPRNet IPIP tunnel in my lab network, but
when I did a packet capture on the WAN side of the gateway I am setting
up, I noticed that on average, about 80% of the IPIP packets I receive
from the UCSD gateway have their inner headers corrupted. As far as I
can tell, the first 4 bytes of the inner header are being overwritten
with a garbage byte sequence (hex 00-04-00-00). I have included a packet
capture showing what's going on. At packet 63, the RIP announcement
starts, and continues through packet 100, so there's some known-good
traffic in there.
Has anyone seen anything like this before?
I have another AMPRNet IPIP tunnel set up on a datacenter server, and it
has no such problem, so this is an isolated issue (i.e., not an issue
with the UCSD gateway). The only other thing I could suspect is that the
ISP-issued modem/gateway combo unit. Of course, I have no visibility
into traffic upstream of this unit, so I don't have a way to know if it
is causing the corruption. Unfortunately, my ISP doesn't let me disable
the gateway function of the unit, so I have to suspect the firmware of
this device.
Any and all help is appreciated. I am going to call my ISP tomorrow and
see if they are aware of any issues with these modem/gateway units.
Thanks,
Eric Johnson - AE0JE
_______________________________________________
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:31 a.m.
I solved all my router issues by moving my IPIP gateway offsite and
using a ZeroTier virtual LAN to bridge the remote router to a LAN
segment here. Works well, only adds a few mS latency, but given that
the IPIP network isn't really a high performance network, this is
inconsequential in practice.
On 13/1/25 4:14 pm, Gavin Rogers via 44net wrote:
Hi Eric.
A shame you're not able to directly connect to your ISP's incoming
interface, with their modem being a mysterious blackbox it's going to
be hard. Do you have any controls at all on the ISP modem, perhaps
features like its VPN passthrough is interfering?
I just did a packet capture for a while from my link, and I'm
receiving nothing but good traffic from the USCD gateway. (although in
practice it is incredibly slow here in Australia - less than 1Mbit/sec)
If you need a far-end node to set up some packet captures with or set
up an iperf node or the like, let me know.
73
Gavin
VK6HGR
On 13/01/2025 12:57 pm, Eric Johnson via 44net wrote:
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
All,
I was trying to bring up an AMPRNet IPIP tunnel in my lab network,
but when I did a packet capture on the WAN side of the gateway I am
setting up, I noticed that on average, about 80% of the IPIP packets
I receive from the UCSD gateway have their inner headers corrupted.
As far as I can tell, the first 4 bytes of the inner header are being
overwritten with a garbage byte sequence (hex 00-04-00-00). I have
included a packet capture showing what's going on. At packet 63, the
RIP announcement starts, and continues through packet 100, so there's
some known-good traffic in there.
Has anyone seen anything like this before?
I have another AMPRNet IPIP tunnel set up on a datacenter server, and
it has no such problem, so this is an isolated issue (i.e., not an
issue with the UCSD gateway). The only other thing I could suspect is
that the ISP-issued modem/gateway combo unit. Of course, I have no
visibility into traffic upstream of this unit, so I don't have a way
to know if it is causing the corruption. Unfortunately, my ISP
doesn't let me disable the gateway function of the unit, so I have to
suspect the firmware of this device.
Any and all help is appreciated. I am going to call my ISP tomorrow
and see if they are aware of any issues with these modem/gateway units.
Thanks,
Eric Johnson - AE0JE
_______________________________________________
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
12:46 p.m.
Their technical support was able to put the box into bridge mode. With the
gateway in bridge mode, the ICMP packets are arriving intact. Crazy - must
be a bug with the NAT code in the gateway's firmware.
73,
Eric - AE0JE
On Mon, Jan 13, 2025 at 12:31 AM Tony Langdon via 44net <
44net(a)mailman.ampr.org> wrote:
I solved all my router issues by moving my IPIP
gateway offsite and
using a ZeroTier virtual LAN to bridge the remote router to a LAN
segment here. Works well, only adds a few mS latency, but given that
the IPIP network isn't really a high performance network, this is
inconsequential in practice.
On 13/1/25 4:14 pm, Gavin Rogers via 44net wrote:
Hi Eric.
A shame you're not able to directly connect to your ISP's incoming
interface, with their modem being a mysterious blackbox it's going to
be hard. Do you have any controls at all on the ISP modem, perhaps
features like its VPN passthrough is interfering?
I just did a packet capture for a while from my link, and I'm
receiving nothing but good traffic from the USCD gateway. (although in
practice it is incredibly slow here in Australia - less than 1Mbit/sec)
If you need a far-end node to set up some packet captures with or set
up an iperf node or the like, let me know.
73
Gavin
VK6HGR
On 13/01/2025 12:57 pm, Eric Johnson via 44net wrote:
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
_______________________________________________
44net mailing list -- 44net(a)mailman.ampr.org
To unsubscribe send an email to 44net-leave(a)mailman.ampr.org
All,
I was trying to bring up an AMPRNet IPIP tunnel in my lab network,
but when I did a packet capture on the WAN side of the gateway I am
setting up, I noticed that on average, about 80% of the IPIP packets
I receive from the UCSD gateway have their inner headers corrupted.
As far as I can tell, the first 4 bytes of the inner header are being
overwritten with a garbage byte sequence (hex 00-04-00-00). I have
included a packet capture showing what's going on. At packet 63, the
RIP announcement starts, and continues through packet 100, so there's
some known-good traffic in there.
Has anyone seen anything like this before?
I have another AMPRNet IPIP tunnel set up on a datacenter server, and
it has no such problem, so this is an isolated issue (i.e., not an
issue with the UCSD gateway). The only other thing I could suspect is
that the ISP-issued modem/gateway combo unit. Of course, I have no
visibility into traffic upstream of this unit, so I don't have a way
to know if it is causing the corruption. Unfortunately, my ISP
doesn't let me disable the gateway function of the unit, so I have to
suspect the firmware of this device.
Any and all help is appreciated. I am going to call my ISP tomorrow
and see if they are aware of any issues with these modem/gateway units.
Thanks,
Eric Johnson - AE0JE
_______________________________________________
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:11 p.m.
Maybe that code should be spelled GNAT ....
On 1/13/25 17:46, Eric Johnson via 44net wrote:
Their technical support was able to put the box into
bridge mode. With
the gateway in bridge mode, the ICMP packets are arriving intact. Crazy
- must be a bug with the NAT code in the gateway's firmware.
73,
Eric - AE0JE
17
days inactive
17
days old
5 comments
4 participants
participants (4)
-
Eric Johnson -
Gavin Rogers -
Mark Herson, N2MH -
Tony Langdon