On Feb 3, 2011, at 2:05 AM, Schemmel, Hans-Christoph wrote:
> I´ve mixed up some field sizes in my previous mail. Msg_ID and Freq_ID have a
> size of 2 octects, not 1 octect like the other fields, sorry. So the optional
> part has a size of 7 octects. But your conclusion is correct: The Header_Size
> is
> multiple of *7*, if there is a frame with N PPP packets, Header_Size is
> multiple
> of 7. If it is not multiple of 7, the frame is not valid. Direction field and
> Header_Size fields are always present.
OK, so it's:
Header_Size: 1 octet
A sequence of zero or more instances of:
Msg_ID: 2 octets
Freq_ID: 2 octets
Start_Pos: 1 octet
End_Pos: 1 octet
Flag: 1 octet
Direction: 1 octet
MUX_Frame: the rest of the packet
> It is possible that a valid Mux_frame (with PPP_frames as payload) has parts
> that don´t correspond to a PPP packet. Two examples: (1) At the beginning of a
> PPP connection, a Mux_frame with "CONNECT" (AT mode) and the first PPP packet.
> (2) A Mux_frame with a LCP Terminate packet (PPP) and a "NO CARRIER" packet
> (AT
> mode).
OK, so presumably the parts that don't correspond to a PPP packet would be the
"holes" in the MUX_Frame field, i.e. the parts that don't correspond to any of
the PPP packets described by Start_Pos and End_Pos. How should those parts be
interpreted (if at all)?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
