Re: pcap_inject vs. pcap_sendpacket and max frame size

["Aaron Turner" <synfinatic () gmail com>]

*sigh*

Long story short, I just figured out that both pcap_inject() and
pcap_sendpacket() have the same problem (a bug in my code was hiding
the error returned by pcap_sendpacket()).

However the bug doesn't seem to affect directly sending using BPF
directly or using Libnet (which also goes through BPF on OS X).

Anyways, since both libpcap methods seem to have this issue, I'm just
going to give priority to using BPF directly for injection in my code.
I'm not sure if other lower level methods have this problem in
libpcap (like PF_PACKET under Linux), but it's probably something
someone should look into further.


--
Aaron Turner
http://synfin.net/
http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix


On 3/31/07, Aaron Turner <synfinatic () gmail com> wrote:
> Odd problem under OS X:
>
> I've tried using both pcap_inject() and pcap_sendpacket() to send raw
> ethernet frames and I've found that pcap_sendpacket() has no problem
> sending a 1514byte frame (14 byte ethernet header w/ 1500 bytes of
> data) while pcap_inject() complains that the frame is too large (errno
> = 40, "send: Message too long")
>
> Key details:
> MacBook Pro running OS X 10.4.9
> libpcap 0.9.5
> MTU 1500
> Packet #10 from
> http://tcpreplay.synfin.net/trac/browser/trunk/test/test.rewrite_pad
>
> Utilizing the raw BPF device to send the same packet seems to work for
> me as well.
>
> On a whim, I tried disabling BIOCSHDRCMPLT in libpcap/pcap-bpf.c, but
> that didn't seem to have any impact.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.