<shoham_peller <at> yahoo.com> writes:
>
> That does not solve the cases I wrote below. The filters I wrote are also
difficult to translate to the syntax
> you suggested:
> * (vlan 1 or vlan 2) and ip
> * (vlan 1 or ether) and ip
>
> I'm hoping to be free to implement the algorithm I suggested in the near
future. Once I'll get around to it,
> you're gonna have a pull request that solves half the problem, as I suggested.
>
Haven't got the time to get to it. I intend to, soon.
Just a question to check that my work won't be for nothing:
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?
Thanks,
Shoham
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
