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@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@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