This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Guisys has developed for me an output from a T1 mapped as ethernet payload to a target laptop. The only relation to the data on the T1 is the packet payload. Is there a Wireshark decode for this, or a way to script out the IP addresses and other details in the payload, please?

Data is sent by a Cisco 10k PE router over DS3, inside which channel 16 is the circuit of interest, delivered to another Cisco router as a T1, using Frame-Relay at layer 2, LMI ANSI Annex D.

My goal is to check for reported packet loss by seeing the original packet and or the retransmitted frame, telling me if the sending or receiving router or telco requires investigtion.

I do see good data sent from a core router to the PE router.

Thanks - Brett

asked 11 Nov '13, 23:29

FSSBrett's gravatar image

FSSBrett
11113
accept rate: 0%

edited 13 Nov '13, 17:34

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196

What does "an output from a T1 mapped as ethernet payload to a target laptop" mean? Does it mean that they take packets from a T1 and send them out on an Ethernet to your laptop (which is presumably running Wireshark)? If so, in what fashion do they encapsulate that payload? Without knowing that, we're unable to determine whether Wireshark can be made to dissect that without change or if some changes would have to be made to Wireshark.

(12 Nov '13, 16:46) Guy Harris ♦♦

Guy, Yes, you uderstood me correctly. All the time slots of the T1 are mapped into one Ethernet packet's payload.

As for encapsulation, pardon, not the best with telco, but the router is sending Frame Relay -

Serial2/0/2/16:0 is up, line protocol is up Hardware is PMC FREEDM, PMC TEMUX, TDK LIU Description: XXXXXXXXXXXXX Encapsulation FRAME-RELAY IETF, crc 16, loopback not set

T3 2/0/2 is up. Hardware is C10K Half Height CT3 line card Applique type is Channelized T3 Controller is in channelized mode Description: XXXXXXXXXXXXXXXXX No alarms detected. Framing is M23 (Configured) Line Code is B3ZS, Clock Source is Line

T1 16 is up timeslots: 1-24 No alarms detected. Framing is ESF, Clock Source is Internal

Thanks - Brett

(12 Nov '13, 21:09) FSSBrett

All the time slots of the T1 are mapped into one Ethernet packet's payload.

That's not something that Wireshark currently understands. If you can get documentation of the packet format, including the Ethernet type used (hopefully they got an official Ethernet type from the IEEE rather than picking one at random...), and can supply a sample capture file for development testing purposes, we might be able to write a dissector for that protocol.

If you can do that, please file an enhancement request at the Wireshark Bugzilla and attach the documentation to it (or post a link to it) and attach the capture file.

permanent link

answered 12 Nov '13, 23:54

Guy%20Harris's gravatar image

Guy Harris ♦♦
17.4k335196
accept rate: 19%

Guy,

In an effort to assist in a solution to query...

My understanding is that the entire T1-payload is Frame-relay and as such the Ethernet Frame (layer-2) payload is this also fully Frame-relay (the same payload transported from the T1 to the Ethernet frame). No change is made to this Frame-Relay data.

The continuous/sequential Frame-Relay data resides at 0010 through 0C18 of each and every Ethernet Frame.

I believe the core question may be, how to configure (or script) Wireshark to decode Frame-Relay at these locations within each Layer-2 Ethernet Frame?

Mike

(13 Nov '13, 08:35) mbp

Guy, just created bug # 9427

Attached a copy of the data.

Tell me what you think please?

Thanks - Brett

(13 Nov '13, 10:20) FSSBrett

I think it's being transported over TCP, as per my analysis in the bug.

That makes it unlikely, although not impossible, for the data to be at a particular offset in each frame.

The transport in the capture is many-layered, with TCP over IP over PPP over L2TP over UDP over IP over MPLS over VLAN-encapsulated Ethernet, so the payload starts well after an offset of 0x0010.

So either the capture attached to the bug isn't a capture of the traffic in question, or it's not as described by mbp.

(13 Nov '13, 12:20) Guy Harris ♦♦

Guy, just responded in the bug. Yes, TCP, multilayered (MPLS, etc. too)over L2TP.

What Mike stated about where the data is mapped is likely where the dissection needs to start. But no being a programmer, I could only guess on the difficulty or success of extracting the Guisys payload and getting to look like the original Ethernet, prior to T1.

Thanks - Brett

(13 Nov '13, 12:44) FSSBrett

So either the capture attached to the bug isn't a capture of the traffic in question

That's the case; the new capture attached to the bug is either running directly atop Ethernet/802.3 (with a length field, but no LLC header) or 802.2. I suspect it's directly atop Ethernet, as, when Wireshark dissects those frames according to the IEEE 802.3 Ethernet specification, the 802.2 headers look somewhat random.

(13 Nov '13, 15:37) Guy Harris ♦♦

The first file I sent was what the data inside the Guisys output should resemble, once extracted, as indicated in the bug for how the Guisys payload starts.

So, Guisys ouputs "fake" frames, who's payload is... "1. Only T1 payload or content is transferred to the Ethernet Frame (no T1 Framing or Overhead) 2. The Packets always start with DS0 Channel-1 (unless the T1 slips due to incorrect clocking) 3. and continues through to DS0 channel-24 4. The Packet contains a total of 40-T1's (960-bytes). Starting at 0010 and ending at 03CF. 6. A GUISYS calculated CRC, used ensure payload integrity (4-bytes) - in this example; 8d ae 0c 18 (note that this is not the Ethernet Frame FCS)"

If I had a serial sniffer, we could see the data expected and perhaps know the dileating characters for the standard network frame/packet structure. But it must be that the Guisys fake frame payload contains with whatever portions of the sending router's data was being delivered to the telco T1, across as many T1 channels per fake frame, for as many fake frames that are needed to transmit a real source router packet.

Hope this helps - Brett

(13 Nov '13, 16:03) FSSBrett
showing 5 of 6 show 1 more comments
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×3

question asked: 11 Nov '13, 23:29

question was seen: 1,717 times

last updated: 13 Nov '13, 17:34

p​o​w​e​r​e​d by O​S​Q​A