Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We see these packets being injected in an FTP-DTP channel during a downlink file transfer on Telstra's NEXTG mobile network. We are not sure if these are network level packets, a problem with our 3G modem (HC25 based) or something like our firewall injecting in the stream.

Using a tool we noticed that the PPP framing fails with protocol length errors, so they are mostly likely mobile network packets.

I am hoping someone here can identify the signature of the packets so that I can chase this up with the appropriate vendor.

There is definitely a format to these packets: -

Packet1: 00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00

Packet2: 00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ff ff a3 79 00 00

Packet3: 00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ff ff e2 5d 00 00

Packet4: 00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ff ff 20 91 00 00

Packet5: 00 00 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ff ff e9 88 00 00

share|improve this question
    
We have since done further analysis and the PPP framing is not a problem, we are however experiencing TCP FCS failures during transfer. –  user27695 Dec 1 '09 at 23:10
    
CrossPosted: stackoverflow.com/questions/1823271/… –  user27695 Dec 2 '09 at 2:18

3 Answers 3

up vote 3 down vote accepted

It looks like a series of TCP ACKs to ports 1030 and 1032. After reformatting the dump into a format that text2pcap can handle, e.g.

0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ................
0030 ff ff 58 b9 00 00                               ................

0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 00 ff 6b 50 00 00 40 06 b8 22 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 7b 82 01 f7 0c eb 50 10 ................
0030 ff ff a3 79 00 00                               ................

0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 02 20 5b 50 00 00 40 06 c7 01 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 61 7c 59 01 f7 0c eb 50 10 ................
0030 ff ff e2 5d 00 00                               ................

0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 01 38 d8 52 00 00 40 06 4a e7 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ed 04 06 8c 62 42 f9 01 f7 0c eb 50 10 ................
0030 ff ff 20 91 00 00                               ................

0000 00 24 c4 b8 7b 1a 00 90 7f 43 0f a1 08 00 45 00 ................
0010 00 d0 4d 58 00 00 40 06 d6 49 cb 7a 9d e9 7b d0 ................
0020 71 52 7a ee 04 08 4b fb 0b 8f 03 5d 51 1a 50 10 ................
0030 ff ff e9 88 00 00                               ................

you can convert the hex dump into a pcap file. The first frame looks like this in Tshark:

Frame 1: 54 bytes on wire (432 bits), 54 bytes captured (432 bits)
    Arrival Time: Dec  1, 2009 08:24:53.000000000
    Epoch Time: 1259684693.000000000 seconds
    [Time delta from previous captured frame: 0.000000000 seconds]
    [Time delta from previous displayed frame: 0.000000000 seconds]
    [Time since reference or first frame: 0.000000000 seconds]
    Frame Number: 1
    Frame Length: 54 bytes (432 bits)
    Capture Length: 54 bytes (432 bits)
    [Frame is marked: False]
    [Protocols in frame: eth:ip:tcp]
Ethernet II, Src: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1), Dst: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
    Destination: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
        Address: Cisco_b8:7b:1a (00:24:c4:b8:7b:1a)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1)
        Address: Watchgua_43:0f:a1 (00:90:7f:43:0f:a1)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol, Src: 203.122.157.233 (203.122.157.233), Dst: 123.208.113.82 (123.208.113.82)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 272
    Identification: 0xf44e (62542)
    Flags: 0x00
        0.. = Reserved bit: Not set
        .0. = Don't fragment: Not set
        ..0 = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (0x06)
    Header checksum: 0x2f13 [validation disabled]
        [Good: False]
        [Bad: False]
    Source: 203.122.157.233 (203.122.157.233)
    Destination: 123.208.113.82 (123.208.113.82)
    [Source GeoIP: Australia, Kingston, 04, -27.666700, 153.116699]
        [Source GeoIP Country: Australia]
        [Source GeoIP City: Kingston, 04]
        [Source GeoIP Latitude: -27.666700]
        [Source GeoIP Longitude: 153.116699]
    [Destination GeoIP: Australia, Terrigal, 02, -33.450001, 151.449997]
        [Destination GeoIP Country: Australia]
        [Destination GeoIP City: Terrigal, 02]
        [Destination GeoIP Latitude: -33.450001]
        [Destination GeoIP Longitude: 151.449997]
Transmission Control Protocol, Src Port: 31469 (31469), Dst Port: iad1 (1030), Seq: 1, Ack: 1, Len: 0
    Source port: 31469 (31469)
    Destination port: iad1 (1030)
    [Stream index: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgement number: 1    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
        0... .... = Congestion Window Reduced (CWR): Not set
        .0.. .... = ECN-Echo: Not set
        ..0. .... = Urgent: Not set
        ...1 .... = Acknowledgement: Set
        .... 0... = Push: Not set
        .... .0.. = Reset: Not set
        .... ..0. = Syn: Not set
        .... ...0 = Fin: Not set
    Window size: 65535
    Checksum: 0x58b9 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]

None of the frames carried a payload so it's hard to say with any certainty what's going on. Since you mention FTP these could simply be data connection ACKs.

share|improve this answer

My guess is they are some sort of encapsulated IP packet.

0x0800 == the Ethernet type for IP
0x45 == IPv4 with 5*4=20 byte header
0x00 == Type of Service
0x00d0 == length
0x4d58 == ID
0x0000 == offset
0x40 == TTL (64)
0x06 == protocol (TCP)

Interesting links:

btw, I don't suppose 00:24:c4:b8:7b:1a or 00:90:7f:43:0f:a1 happen to be your local device's address, and the other the remote side?

share|improve this answer

Have you attempted viewing these packets in Wireshark? It contains a lot of decoders for various protocols - are you certain that this traffic is not included?

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.