views:

157

answers:

5

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

+2  A: 

00:24:c4 is a NIC from Cisco and 00:90:7F is a NIC from WatchGuard.

From the IEEE OUI Registry.

How much help that might be ... don't know. Might therefore be an attempted VPN connection.

martin clayton
Thanks Martin..
baash05
+6  A: 

I converted your packet trace snippet into a format understood by text2pcap so I could convert them into the pcap format for viewing in Wireshark (a very handy packet capture and analysis tool):

Looks like some sort of IPv4 multicast traffic at a very rough guess. Here's what I got from the first packet (rest came up as malformed):

No.     Time        Source                Destination           Protocol Info
   1 0.000000    7b:1a:00:90:7f:43     00:00:00_24:c4:b8     0x0fa1   Ethernet II

Frame 1 (31 bytes on wire, 31 bytes captured)
 Arrival Time: Dec  1, 2009 00:33:05.000000000
 [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: 31 bytes
 Capture Length: 31 bytes
 [Frame is marked: False]
 [Protocols in frame: eth:data]
Ethernet II, Src: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43), Dst: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
 Destination: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
  Address: 00:00:00_24:c4:b8 (00:00:00:24:c4:b8)
  .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
  .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
 Source: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43)
  Address: 7b:1a:00:90:7f:43 (7b:1a:00:90:7f:43)
  .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
  .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
 Type: Unknown (0x0fa1)
Data (17 bytes)

0000  08 00 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a   ..E....N..@./..z
0010  9d                                                .
 Data: 080045000110F44E000040062F13CB7A9D
Amal Sirisena
A: 

Thanks guys, I didn't realize that it was just an ethernet frame :)

David Thornley
+2  A: 

These look like ordinary TCP packets but with two extra 00 bytes tagged on at the front. Not sure why that would happen, but they appear to be from 00-90-7f-43-0f-a1 (Watchguard) to 00-24-c4-b8-7b-1a (Cisco).

IP header is 45 00 01 10 f4 4e 00 00 40 06 2f 13 cb 7a 9d e9 7b d0 71 52

TCP header is 7a ed 04 06 8c 61 5d a9 01 f7 0c eb 50 10 ff ff 58 b9 00 00

So you can get the rest of the details from there.

Neil McKee
A: 

As already decoded by others:

RocketSurgeon