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 edited 13 Nov '13, 17:34  Guy Harris ♦♦ |
One Answer:
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. answered 12 Nov '13, 23:54 Guy Harris ♦♦ 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
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 |
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.
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