Comment # 14
on bug 9427
from Guy Harris
(In reply to comment #11)
> T3 channel 16 is a single T1.
>
> Didn't see the following hit this bug,
That's because it *didn't* hit the bug...
> From: Mike
> Subject: RE: [Bug 9427] Dissector for T1-data-over-TCP protocol from Guisys
> wanted
...because you can't add comments to a bug by replying to a "the bug changed"
e-mail; you have to go to the Bugzilla page for the bug and edit it.
> The T1 payload (data) is mapped to the Ethernet in the identical format or
> structure in which it is carried in the T1. This means the 1st 8-bits are
> the 1st 8-bits of channel-1, the 2nd 8-bits are Channel-2, etc. the
> 24-octet is Channel 24 and the end of that T1's payload. The next T1's
> payload
"Next" in what sense?
Are we talking about the next *frame* on the *same* T1, or are we talking about
multiple T1s on a T3?
> continues after that so the 'serial' stream of data from the T1 is
> mapped in identical order and structure (as it is on the T1) to the Ethernet
> frames.
I.e., each frame in the capture has 7680 sequential bits from the T1?
And that T1 is carrying Frame Relay traffic? Is that traffic using the full
T1, or is this fractional T1?
If it's full T1, then the dissector would have to scan through the bit stream
looking for a flag sequence (01111110), and process all bits following the flag
sequence un-bit-stuffing them until the next flag sequence is seen, and then
hand the un-bit-stuffed octets to the Frame Relay dissector (assuming that
what's being done is bit-stuffing). This requires reassembly of Frame Relay
frames that cross Ethernet frame boundaries.
(Hopefully, the Frame Relay dissector will recognize the bridged Ethernet
frames and hand them to the Ethernet dissector.)
You are receiving this mail because:
- You are watching all bug changes.