Comment # 8
on bug 9427
from Guy Harris
(In reply to comment #7)
> Ethernet Frame Structure [Brett: not the payload of Test3 trace frames]
Presumably you mean that the frames in the test3.pcapng file *are* in a format
that has:
> • The structure is as follows; 6+6+2+2+960+4+4 = 984
> 1. Destination MAC address (6-bytes) - in this example; ff ff ff ff ff ff
> 2. Source MAC address (6-bytes) - in this example; 00 00 25 af 00 00 Ramtec
> mfg
> 3. Packet Length (2-bytes) - for T1-payload this will always be; 03 c6
> 4. A Packet Sequence Number (2-bytes) - in this case; 00 00 (but will
> increment each Frame)
followed by "the T1 content".
If so, that means that it's running atop raw Ethernet/802.3, with no 802.2
header, and thus is not a valid Ethernet frame according to IEEE Std 802.3,
meaning that Wireshark will need a special hack in order to tell it to dissect
the frames as T1-over-Ethernet frames rather than as normal Ethernet frames.
(I.e., it's not a matter of "configuring" Wireshark; there will need to be code
changes or, at least, a plugin dissector.)
So that part isn't hard to dissect once we somehow hook a dissector in to catch
those non-standard Ethernet frames.
Moving on:
> The T1 content
> 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
So does that mean that every 3 bytes of the T1 content have 24 bits, the first
of which is the bit in channel 1, the second of which is the bit in channel 2,
and so on, with the last bit being the bit in channel 24?
You are receiving this mail because:
- You are watching all bug changes.