Re: [tcpdump-workers] libpcap buffering...
On Mar 30, 2014, at 7:01 AM, barcaroller wrote: > I have two questions related to buffers in libpcap. > > - I would like to to use the pcap_set_buffer_size() to run various > performance tests. However, I do not know the default buffer size (on a > 64-bit Linux system with 16 GB of RAM) and I do not know how to get it (there > is no pcap_get_buffer_size()). How can I tell what the existing buffer size > is before I start changing that value? You'd have to modify libpcap to provide that information. > - I would like to improve the performance of pcap_dump() when writing packets > to disk. I know that pcap_dump() already uses some kind of buffering. The only buffering it uses is the buffer provided by the "standard I/O library" routines (fopen(), fwrite(), fclose()) that it uses to open the dump file, write to it, and close it. > What is the best way to approach this? Can the aforementioned function > (pcap_set_buffer_size()) be used for this purpose, No. The standard I/O buffer is completely separate for the packet capture buffering. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] vlan handling
{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 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
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan handling
31.03.2014, 02:18, "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...}
>
> 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 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
