vlan handling

[Michael Richardson]

{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...}
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 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?

Do you think we should explain the whole algorithm, so the user can
understand the exact behavior, or is it too complicated for the average
user?

If not, How do you think it should be documented?

2) The new logic would require deep understanding of the new algorithm
to know the difference between "(vlan 1 or vlan 2) and ip", "(vlan 1 or
ether) and ip" and "vlan and ip", and why some of them don't work.

Say I have this pull request ready for you today, are you OK with
expecting the users to understand the vlan-filtering algorithm so good?

Will you even take this pull request?

I'm trying to make time to fix this bug and give you a pull request -
I'll be happy to know first that my work won't be for nothing.
Thanks,
Shoham

[Denis Ovsienko]

Post by Michael Richardson
{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...}
   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
   1) How do you think we should document the new vlan-filter handling?
       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 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

[Shoham peller]

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 <***@yandex.ru>
To: tcpdump-workers <tcpdump-***@lists.tcpdump.org>
Sent: Monday, March 31, 2014 9:00 AM
Subject: Re: [tcpdump-workers] vlan handling

Post by Michael Richardson
{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...}
   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
   1) How do you think we should document the new vlan-filter handling?
       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

Post by Michael Richardson
   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

[Shoham peller]

Hi,

I'm having problems implementing it. The problem is the action
precedence bison does.

For example:
"vlan or vlan"

I've written code that makes the "or" keyword to restore the
off_linktype so that the second "vlan" keyword uses off_linktype
that is reseted.

But the action precedence that bison does is:
1. Compute the left side of the or
2. Compute the right side of the or
3. "or" between them

In 1 and 2, the off_linktype is incremented, which makes the right
side "vlan" to use off_linktype that was already incremented.
It's only in 3 that the off_linktype is restored to be the value
before the 2 increments happened in 1 and 2.


Can anyone suggest a solution to this problem?

Thanks,
    Shoham