Re: [tcpdump-workers] Request for link-layer header type (XRA)

2017-12-11 Thread Bruno Verstuyft
Updated the specification with clarifications below.

2017-12-05 13:47 GMT+01:00 Bruno Verstuyft :

>
>
> 2017-12-04 22:21 GMT+01:00 Guy Harris :
>
>> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
>> wrote:
>>
>> > we put the specification of the XRA header online.
>>
>> The MAC document speaks of "logical" upstream and downstream channels;
>> are those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs
>> refer to?
>>
> Yes, from the MULPI spec:
> Logical (Upstream) Channel: A MAC entity identified by a unique channel ID
> and for which bandwidth is allocated by an
> associated MAP message. A physical upstream channel may support multiple
> logical upstream
> channels. The associated UCD and MAP messages completely describe the
> logical channel.
>
> 5.2.1.1.3.1  Downstream Data Forwarding in a MAC Domain:
> A MAC Domain provides downstream DOCSIS data forwarding service using the
> set of downstream channels
> associated with the MAC Domain. Each downstream channel in a MAC Domain is
> assigned an 8-bit Downstream
> Channel ID (DCID).
>
>
>
>>
>> To what do the start and stop minislots in the "Minislot ID" TLV refer?
>>
>
> These are the minislots, relative in an OFDMA frame. The minislot with the
> lowest subcarriers has id 0.
>
>
>>
>> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
>>
>
> Symbol ID is a number assigned to each symbol by our hardware. This is
> mainly used for timing calculations. It can also be used to visualize the
> correlation between NCP (Next Codeword Pointers) and the corresponding
> downstream data packets.
>
> Burst ID is used to map mac frames to the corresponding databurst. A
> databurst can e.g. contain a segment:(see MULPI 7.2.4
>  Continuous Concatenation and Fragmentation). This means a segment can
> contain multiple Mac frames, or a Mac frame can be spread over multiple
> segments. In our sniffer, we extract these Mac frames from the segments. To
> save the information of which Mac frame belongs to which segment (or
> multiple segments), we use the Burst ID: each data burst gets a unique
> Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used to
> reference these Burst IDs.
>
> Subslot ID: A minislot can be divided into multiple subslots to provide
> multiple transmission opportunities for Bandwidth requests
> (see PHY 8.2.4.1  Subslot Structure). This is the ID of this subslot. The
> leftmost subslot has id 0.
>
>
>
>
>>
>> Does the SID TLV contain the Service Identifier for the service flow in
>> which the packet was sent?
>>
>
> Yes
>
>>
>> Does the IUC TLV contain the Interval Usage Code for the burst if the
>> packet is a burst?
>
>
> Yes
>
>
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


[tcpdump-workers] Packet sanitization and IP masking (PR #615)

2017-12-11 Thread Chang, Alice
Hello all,



In my attempt to get this pull request toward completion, I intend to rebase 
the branch's commit history to one concise commit. Before I do so, however, I 
am planning on making changes from my short options to long options, and would 
like to elicit some suggestions (if any) regarding my proposed option names.



There are currently two main features to this PR: a masking of external IP 
addresses to some mask IP, and TCP/UDP payload sanitization in IPv4. Calling 
the former currently looks like [ --external-mask|-* mask_ip ] but I am 
currently planning to remove the -* short opt and rename the long one to 
--mask-external-address. As for the latter feature, the packet sanitization 
works by using -0 to zero out the payload, and -00 to remove it completely. I'm 
planning to change this to --zero-tcpudp-payload and --no-tcpudp-payload, 
respectively. (The result will be that none of these features will be using a 
short opt.) Are there any objections or suggestions to these names?



Additionally, I know that there's a lot of work being done to fix CVE issues. I 
was wondering if/how I could be of help in that effort.



Thanks! And thanks to the maintainers for their guidance thus far.



Best,

Alice




"This e-mail, and any attachments hereto, may contain information that is 
privileged, proprietary, confidential and/or exempt from disclosure under law 
and are intended only for the designated addressee(s). If you are not the 
intended recipient of this message, or a person authorized to receive it on 
behalf of the intended recipient, you are hereby notified that you must not 
use, disseminate, copy in any form, or take any action based upon the email or 
information contained therein. If you have received this email in error, please 
permanently and immediately delete it and any copies of it, including any 
attachments, and promptly notify the sender at In-Q-Tel by reply e-mail, fax: 
703-248-3001, or phone: 703-248-3000. Thank you for your cooperation."
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Re: [tcpdump-workers] Request for link-layer header type (XRA)

2017-12-11 Thread Guy Harris
On Dec 5, 2017, at 4:47 AM, Bruno Verstuyft  wrote:

> 2017-12-04 22:21 GMT+01:00 Guy Harris :
> 
>> On Nov 16, 2017, at 1:21 AM, Bruno Verstuyft 
>> wrote:
>> 
>>> we put the specification of the XRA header online.
>> 
>> The MAC document speaks of "logical" upstream and downstream channels; are
>> those what the "Downstream Channel ID" and "Upstream Channel ID" TLVs refer
>> to?
>> 
> Yes, from the MULPI spec:
> Logical (Upstream) Channel: A MAC entity identified by a unique channel ID
> and for which bandwidth is allocated by an
> associated MAP message. A physical upstream channel may support multiple
> logical upstream
> channels. The associated UCD and MAP messages completely describe the
> logical channel.

You might want to say "ID of downstream *logical* channel" in the remarks for 
"Downstream Channel ID"; the remarks for "Upstream Channel ID" already say 
"logical upstream channel" (is it best to say "logical XXX channel" or "XXX 
logical channel"?).

>> To what do the start and stop minislots in the "Minislot ID" TLV refer?
> 
> These are the minislots, relative in an OFDMA frame. The minislot with the
> lowest subcarriers has id 0.

So those are the minislots from section 7.4.1 "Signal Processing Requirements" 
of the PHY specification?

>> What do the "Symbol ID", "Burst ID", and "Subplot ID" TLVs contain?
> 
> Symbol ID is a number assigned to each symbol by our hardware. This is
> mainly used for timing calculations. It can also be used to visualize the
> correlation between NCP (Next Codeword Pointers) and the corresponding
> downstream data packets.

So to which symbol in the packet does that refer?

> Burst ID is used to map mac frames to the corresponding databurst. A
> databurst can e.g. contain a segment:(see MULPI 7.2.4
> Continuous Concatenation and Fragmentation). This means a segment can
> contain multiple Mac frames, or a Mac frame can be spread over multiple
> segments. In our sniffer, we extract these Mac frames from the segments. To
> save the information of which Mac frame belongs to which segment (or
> multiple segments), we use the Burst ID: each data burst gets a unique
> Burst ID. In the Mac Frame the "Burst Info"/"Burst ID reference" is used to
> reference these Burst IDs.

So your sniffer assigns the Burst IDs?

There's a variable-length "Burst ID" field and a "Burst ID Reference" field.  
Does the "Burst ID" field contain a single burst ID?  If so, to which burst was 
that ID assigned?  And what does the "Burst ID Reference" field contain?

>> Does the SID TLV contain the Service Identifier for the service flow in
>> which the packet was sent?
> 
> Yes

You might want to spell out "Service Identifier" in the remarks.

>> Does the IUC TLV contain the Interval Usage Code for the burst if the
>> packet is a burst?
> 
> Yes

You might want to spell out "Interval Usage Code" in the remarks.

___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers