Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

IP Frag - Sig 1204

I'm seeing a lot of sig 1204 from my network to external domain controllers. A packet capture shows the following:

Source IP:

Source Port: 16191/UDP

Destination IP:

Dest Port: 16191/UDP

Packet Length is 1541 Bytes

DF is not Set, More Fragments not set

TTL 128

Header Checksum 0x466f (incorrect, should be 0x4160)

Data: 1499 Bytes

The data is all:

3f 3f 3f 3f 3f 3f 3f 3f which is decoded as ??????

This is triggered many, many times a day from inside addresses aimed at domain controllers... any ideas?



Re: IP Frag - Sig 1204

Could you possibly capture some traffic and sent it to This will help to diagnose the problem.

New Member

Re: IP Frag - Sig 1204

I am seeing this as well. I have packet captures I can upload as necessary. I have been seeing this for a long time. Basically this seems to always happen between Windows machines; in my environment, one of the pair of machines in an alert will always be an active directory box or part of a SQL cluster.

The packets always appear to start with a "normal" header, but around byte 38 (where the source port is stored) the pattern of 0x3f bytes begins. In many packets the pattern repeats up to 1517, completely padding out the packet; in other cases its not as many. On those where there is the full amount of padding, the packet ends up "oversized."

Since the source and destination port fields are both overwritten with 0x3f3f (they are double-byte fields) the IDS and any sniffer software seems to identify this as source and destination port 16191. The length field is also reported as 16191 and the checksum shows as 0x3f3f.

There was one fellow who reported this on the Incidents mailing list at SecurityFocus, but he never figured out what was causing it in his environment - he thought is might be some kind of unknown trojan activity. He also uses Cisco IDS, although I don't know the specific model/version. In my own environment, all the Windows servers are Compaq of various models, so there might be something there as well.

This was reported on the SANS daily digest about a week ago - they said they were receiving some reports of this activity but had no data. The attached capture is one I took on an IDSMv2 blade here; I edited it to only include the single packet that fired the alerts (it's always the first packet, and there are never any others in the remaining packets in these captures).


CreatePlease login to create content