A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) is sending an encapped packet that is peculiar: it is either 40 or 44 bytes long, but the length field in the IP header is set to a varying but very large packetsize (for example, 61,683 bytes) and the Don'tFragment bit is set so the amprgw IP kernel sending routine can't break it up into MTU-sized fragments - thus it gets a transmit failure and isn't sent anywhere.
The inner source is always 44.4.39.8, but the destination varies a lot.
I'm completely puzzled by this: I don't know how any common operating system would be generating such a packet.
I can see how a naive IP implementation might have a problem when receiving a packet that is relatively small but claims to be large.
Does anyone know: is this a deliberate attempt to sabotage the destination host? - Brian
Could you grab a pcap of the packet?
Andrew
On Apr 26, 2017, at 9:32 PM, Brian Kantor Brian@ucsd.edu wrote:
(Please trim inclusions from previous messages) _______________________________________________ A few times a minute, a host claiming to be ke6jjj-8 (44.4.39.8) is sending an encapped packet that is peculiar: it is either 40 or 44 bytes long, but the length field in the IP header is set to a varying but very large packetsize (for example, 61,683 bytes) and the Don'tFragment bit is set so the amprgw IP kernel sending routine can't break it up into MTU-sized fragments - thus it gets a transmit failure and isn't sent anywhere.
The inner source is always 44.4.39.8, but the destination varies a lot.
I'm completely puzzled by this: I don't know how any common operating system would be generating such a packet.
I can see how a naive IP implementation might have a problem when receiving a packet that is relatively small but claims to be large.
Does anyone know: is this a deliberate attempt to sabotage the destination host?
- Brian
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
Here's one:
20:51:54.937435 IP (tos 0x0, ttl 18, id 28358, offset 0, flags [none], proto IPIP (4), length 60) 75.101.96.109 > 169.228.66.251: IP truncated-ip - 30268 bytes missing! (tos 0x0, ttl 64, id 28357, offset 0, flags [DF], proto TCP (6), length 30308, bad cksum edf2 (->77b6)!) 44.4.39.8.6178 > 91.230.47.38.55979: Flags [R.], seq 0:30268, ack 814823413, win 0, length 30268 [!RST+ \0x00]
Notice that it has no data payload, it's just packet headers. - Brian
On Wed, Apr 26, 2017 at 09:48:12PM -0600, Andrew Ragone wrote:
Could you grab a pcap of the packet? Andrew
On Wed, Apr 26, 2017 at 09:48:12PM -0600, Andrew Ragone wrote:
Could you grab a pcap of the packet? Andrew
A bit more interesting: the following packet was sent TO 44.4.39.8,
20:52:45.597416 IP (tos 0x0, ttl 64, id 22372, offset 0, flags [none], proto IPIP (4), length 60, bad cksum 0 (->8aa8)!) 169.228.66.251 > 75.101.96.109: IP (tos 0x0, ttl 237, id 6367, offset 0, flags [none], proto TCP (6), length 40) 91.230.47.38.55979 > 44.4.39.8.5682: Flags [S], cksum 0x3024 (correct), seq 2195925477, win 1024, length 0
which is a TCP connection setup request.
and 44.4.39.8 replied with the peculiar size issue packet, rejecting the connection . 20:52:45.647205 IP (tos 0x0, ttl 18, id 28364, offset 0, flags [none], proto IPIP (4), length 60) 75.101.96.109 > 169.228.66.251: IP truncated-ip - 13289 bytes missing! (tos 0x0, ttl 64, id 28363, offset 0, flags [DF], proto TCP (6), length 13329, bad cksum edec (->ba03)!) 44.4.39.8.5682 > 91.230.47.38.55979: Flags [R.], seq 0:13289, ack 2195925478, win 0, length 13289 [!RST+ \0x00]
So it looks like someone was probing the 44.4.39.8 host and a bad reply packet was generated. A bug in the TCP implementation? I wonder what OS it's running. - Brian
-
Andrew Ragone -
Brian Kantor