If you want a timeout, so you don't wait forever for a packet to
arrived, I'd suggest using select() or poll() on UN*X systems (other
than *BSD and Mac OS X, where select() and poll() might not work
correctly on BPF devices - and, in the case of Mac OS X, where poll()
doesn't work *at all* on "
Guy Harris wrote:
On Dec 17, 2008, at 11:10 AM, Dustin Spicuzza wrote:
Is there currently a way to save protocol headers (and by this, I mean
ARP/IP/TCP/UDP/ICMP headers) to a file *without* the remaining payload?
There's no way to do *exactly* that.
You can, however, specify a snapshot len
With BPF and Digital UNIX's packetfilter, changing the filter flushes
the buffer. With Linux, changing the filter doesn't flush the buffer
- so current versions of libpcap purge the buffer themselves, so
that, after you change a filter, you don't get any packets that
wouldn't have passed t
Latha G wrote:
Hi all,
I have a question on interpreting the output of -d option..
I used tcpdump -d option
o/p: (000) ret #96
I interpreted it as returning 96 bytes of the data.
yes
and i used tcpdump -dd option
o/p: { 0x6, 0, 0, 0x0060 },
I interpreted, 0x6 refers to the opcode of ret
> I'm failing at connection establishment. I can squirt the packet out using
> libnet and get a reply using pcap, but the connection-initiating TCP seems
> to be generating a RST on my behalf before I can transmit the third packet
> of the handshake.
[ ... ]
> The libnet code to transmit packets
Can you define the behaviour of 'not work' with BPF on tiger?
"Not work" as in "if you select on a BPF device and nothing else, you
will only wake up when the select timeout expires; the store buffer
getting transferred to the hold buffer won't trigger a wakeup".
ah, that may explain it, as
The only UN*X systems I know of where select() can't be used are
FreeBSD 4.3 and 4.4 (due to BPF deficiencies fixed in 4.5);
OS X 10.4[.x] (due to select() not working on *any* character
special files);
Can you define the behaviour of 'not work' with BPF on tiger? I use
select on a
Hi
I've sent a small patch to freebsd-net that enables bpf writes for all
DLT_NULL devices in the tree in a consistent way. I'm about to look
into doing the same for netbsd / openbsd / etc. Before I do this, I
want to establish consensus that this is ok, or have a solid reason
why not to do this
This is probably a pointless optimization, as you probably relatively
rarely have multiple BPF devices bound to the same interface receiving
the bulk of the packets (as opposed to some daemon with a filter that
passes only the packets it's interested in), but would there be any
advantage to hav
Hi
There is code in pcap-bpf.c to set the selectable fd to -1 if it is
detected the OS is FreeBSD 4.3 or 4.4
I don't think the check actually successfully detects 4.3 or 4.4, as the
osinfo.release parameter will have something like 4.3-RELEASE or
4.4-STABLE in it.
Below is a patch to libpcap-2
10 matches
Mail list logo
