26 Apr
2017
26 Apr
'17
11:30 p.m.
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
26 Apr
26 Apr
11:48 p.m.
Could you grab a pcap of the packet?
Andrew
On Apr 26, 2017, at 9:32 PM, Brian Kantor
<Brian(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
11:54 p.m.
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
27 Apr
27 Apr
12:10 a.m.
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
2766
days inactive
2766
days old
3 comments
2 participants
participants (2)
-
Andrew Ragone -
Brian Kantor