tcpdump mailing list archives

Re: vlan handling


From: Shoham peller <shoham_peller () yahoo com>
Date: Mon, 31 Mar 2014 00:19:31 -0700 (PDT)

There is a few problems with your solution:
* It isn't backward-compatible
* I doesn't solve the issue. (vlanid-2 and arp or vlanid-3 and ip) is not neccessarily solving the offset problems.

If you think the vlan syntax should change it's doable, only you have to be backward-compatible and it's another matter 
from solving the offset issue.

I'm reminding you my 2 questions:
1) How will this be documented?
2) Do you even want me to implement it, since "(vlan or ip) and proto 2" would continue not work with the suggested 
solution

Thank you,
        Shoham



________________________________
 From: Denis Ovsienko <infrastation () yandex ru>
To: tcpdump-workers <tcpdump-workers () lists tcpdump org> 
Sent: Monday, March 31, 2014 9:00 AM
Subject: Re: [tcpdump-workers] vlan handling
 

31.03.2014, 02:18, "Michael Richardson" <mcr () sandelman ca>:

{For reasons I do not understand, yahoo.com doesn't even attempt to deliver
email from Shoham to tcpdump.org. There is simply no connections in the
logs of the spam filter system...}

From Shoham:

   Haven't got the time to get to it. I intend to, soon.

   2 questions (that are very related to each-other) to check that my work
   won't be for nothing:

   1) How do you think we should document the new vlan-filter handling?
   The documentation today states:
       Note that the first vlan keyword encountered in expression changes
   the decoding offsets for the remainder of expression on
       the assumption that the packet is a VLAN packet. The vlan [vlan_id]
   expression may be used more than once, to filter on
       VLAN hierarchies. Each use
/*
Best Regards,
                Shohamp
*/

of that expression increments the filter
   offsets by 4.

   After the pull, It'll be harder to explain why "vlan or ip and udp"
   works but "(vlan or ip) and udp" doesn't.

   How do you think it should be documented?

If the present behaviour was to change anyway that could be used for syntax clarification. For example, instead of 
single "vlan" keyword that means different things in different context the new syntax could be based on keywords like 
below:

8021q: EtherType = 0x8100
vlanid N: EtherType = 0x8100 and VID = N in the outermost 32-bit tag
vlanid-2 M: EtherType = 0x8100 and there are at least two (Q-in-Q) 32-bit tags and the 2nd (inner) VID = N
vlanid-3 K: EtherType = 0x8100 and there are at least three (Q-in-Q-in-Q) 32-bit tags and the 3rd (most inner) VID = K

If I got the problem wrong and/or there's a cleaner wolution, please illustrate with examples.

Thank you.

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers


Current thread: