Any packet containing sufficiently long sequence of 'J' characters disappears

skynerd

@stephenw10 Disappears on the LAN side, packet not occurring in the client's Wireshark trace, clients wait until timeout. Reproduced on Linux using wget and Mac using curl (though I've only done the trace on Linux).

I haven't tried an outbound packet, will do. (Edit: nope, no lost packet, at least not requesting a URL with a nonexistant path containing a sufficiently large number of J's.)

What I see it on is the original large .deb file, and small text files of various sizes containing nothing but the letter 'J', after I narrowed down where the original .deb file was failing.

stephenw10

Hmm, so you only see it on the 2100 when downloading a file with the offending string from WAN to a client on LAN?

You see the packet leave the LAN in a pcap but it never arrives at the client?

Other traffic continues to pass at that time though? It's not like the NIC stops responding or the switch stops passing traffic?

How do you have the switch configured in the 2100? Potentially it could be failing to pass that, though it's hard to imagine that.

tinfoilmatt

@skynerd said in Any packet containing sufficiently long sequence of 'J' characters disappears:

Running the packet capture on the router I see the offending packets from the server, on both the WAN and LAN interface, but they never make it to the machine making the request.

Assuming you connect one of your hosts directly to the ~~pfSense box~~ 2100's LAN interface—are you able to run a simultaneous pcap on said host?

Point would be to determine what, if anything, makes it 'onto the wire' downstream of pfSense.

SteveITS

@skynerd FWIW can't reproduce, testing with 130 J's in a file. Do have Comcast but have my own modem so no SecurityEdge. Which does do weird stuff sometimes. But I'd think if it was their issue you could repro it connected direct to the Comcast router...or another router behind it as you describe.

Brainstorming, web server compression?

stephenw10

Also testing on a 2100? Through the built in switch?

SteveITS

@stephenw10 Yes. Also through an AP connected to one of the LAN ports, to be clearer, though that seems irrelevant to the "on a 2100" part.

tinfoilmatt

@stephenw10 If I understand OP correctly, it's only happening on the 2100 running Plus (i.e., not on 'unofficial' hardware running CE).

I'd maintain that a direct connection to the LAN interface with the Linux and/or Mac hosts is the easiest way to rule out the 2100 running Plus specifically.

tinfoilmatt

@SteveITS Direct connect to that 2100!

skynerd

@tinfoilmatt said in Any packet containing sufficiently long sequence of 'J' characters disappears:

I'd maintain that a direct connection to the LAN interface with the Linux and/or Mac hosts is the easiest way to rule out the 2100 running Plus specifically.

I tried that earlier and reproduced, though today I assigned the "LAN" interface directly to the port I'm plugged into ("Port 3" in this case rather than "Port 5" the "LAN Uplink"), and it still reproduced.

skynerd

@SteveITS

I'm using my own cable modem in bridge mode. The packet capture from the Netgate 2100 ruined all my theories blaming Comcast or the modem, the packets are being received and the headers and data don't seem to be modified. Doesn't care about it using port 80 or not either.

Testing across my local network, going through the 2100 but not routed through the WAN, doesn't reproduce.

tinfoilmatt

Obligatory mention that pcap on network host (what you presumably refer to as "the client's Wireshark trace" in this post) needs to be in promiscuous mode. Software firewall could also interfere.

stephenw10

@skynerd said in Any packet containing sufficiently long sequence of 'J' characters disappears:

Testing across my local network, going through the 2100 but not routed through the WAN, doesn't reproduce.

Was that just through the switch? Like between devices in the same subnet? Or routing between VLANs on the LAN side?