Re: [tcpdump-workers] [libpcap] OR'ing vlans impossible in tcpdump filter (#158)
Please take this discussion to the tcpdump-workers list. shohamp writes: > This commit by @yuguy explains this issue very well. yacc parsers the > bpf from left to right without saving the state, and doesn't provide a > tree of some kind, which would allow an easy solution. @yuguy says that > OR'ing vlans in the current parsing methodology is impossible. > But there might be a solution, if GCC used yacc in previous version to > parse C code, a state can be saved. We simply want yacc to parse > parenthesis, and using them to increment the offset, and with each 'OR' > it encounters, resetting the offset to it's last state. Let me explain: > tcpdump -d 'vlan and (vlan or arp) or ip' means: 1. filter vlan with > the current offset (0) and increment offset ( = 4) 2. open > parenthesis. push the offset in a stack 3. filter vlan with the current > offset (0) and increment offset ( = 8) 4. or. reset the offset to it's > state in the last parenthesis from the offset stack ( = 4) 5. filter > arp with the current offset (4) 6. close parenthesis. pop the offset's > state 7. or. reset the offset to it's state in the last parenthesis > from the offset stack ( = 0) 8. filter ip with the current offset (0) > As it seems to me, this will solve the issue, and would allow OR'ing > vlans. > What do you say? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Can libpcap affect speed of packets sending/recieving?
Hi, I wonder if libpcap can somehow affect speed of processing packets by TCP/IP stack? I noticed that such behavior can happen in particular Linux environments with high traffic load - without capturing all is Ok, with capturing (especially on "any" interface) it seems that packets stuck in TCP/IP stack (sometimes application that generates traffic receives a huge amount of EAGAIN error). Thanks, Sergey Gomanyuk This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] IEEE float decoded incorrectly (#333)
01.10.2013, 06:11, "Michael Richardson" : > from > https://github.com/the-tcpdump-group/tcpdump/issues/333 > > details an issue where differences in arch and compiler result in different > extractions of floating point objects in LMP packets. Guy discovers it has > something to do with assumptions about x86 SSE. > > and I think we might find more expertise on the list. List, Dmitrij Tejblum solved this with the -ffloat-store GCC flag. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
