>
>so it appears to keep state in "p->bp" and "p->cc" that keeps track of
>how much data is left in the buffer it most recently read into and where
>the beginning of that data is.
>
>I think at least some of the other BPF implementations on platforms that
>return more than one packet per read (for example, DLPI, which does that
>if there's a "bufmod" STREAMS module) behave similarly.
ouch! you're right! pcap-dlpi does preservce enough state to
re-read the old buffer... my problem 8^) starring too hard
at the dlpi layer stuff ...
gotta stop drinking that hard lemonade...
thanks =)
mts.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
