Re: [tcpdump-workers] pcap_inject change?
Steve Bourland wrote: > Yes, things broke moving from 4.15.0-32 to 4.15.0-34, so it looks like > the change came with the move from -32 to -33 (the original machines > showing the problem have the -33 kernel installed). > These kernels are what come with Ubuntu 18.04 from Canonical. Should I > file a bug with them or do you have "better pull" and enough > information to follow up on this? I am more than happy to continue to > follow this, but I am going to be an unknown to folks vs. you. We have no more pull than you, and you have the test cases, and versions, and could test. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject change?
On Tue, 11 Sep 2018, Michael Richardson wrote: Steve Bourland wrote: > I'm a little confused, why would the capture mechanism matter for the > pcap_inject call? I am capturing both senders packets on the same > machine (a single tcpdump call). I was thinking my next move would be > to grab the 18.04 kernel and install it on the 16.04 machine to see if > that triggers the behavior on the 16.04 machine. I'm sorry, I mis-understood. I read pcap_inject, then immediately forgot that point... then understood that you were saying that there was garbage at the end of the captured packets! So I have no idea. What kernel versions are involved? What does strace on each show for the system call that sends the packet? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ No problem, I have found the 16.04 (using 4.4.0-) was "good" but once I installed kernel 4.15.0-34 it started misbehaving. Now realized I have a third machine (does have different Intel NIC, but using the same driver, so a bit of a difference there) that is "well behaved" running 18.04...with kernel 4.15.0-32, so updating it to 4.15.0-34 to see if that "ruins" its behavior Yes, things broke moving from 4.15.0-32 to 4.15.0-34, so it looks like the change came with the move from -32 to -33 (the original machines showing the problem have the -33 kernel installed). These kernels are what come with Ubuntu 18.04 from Canonical. Should I file a bug with them or do you have "better pull" and enough information to follow up on this? I am more than happy to continue to follow this, but I am going to be an unknown to folks vs. you. Thanks so much for your help, Steve ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject change?
On Tue, 11 Sep 2018, Michael Richardson wrote: Steve Bourland wrote: > are captured, if called with size argument 60, 74 are captured). On > matching hardware under Ubuntu 16.04 (libpcap 1.7.4), pcap_inject with > size 50 results in 60 bytes on the wire (expected minimum packet size) > and the padding is all zeros. Both machines are using the same Intel > e1000e driver versions (3.2.6-k). Has anyone else seen this or have a > workaround? It sounds like different kernel packet capture mechanisms are being used. The pcap_lib_version string will tell you what's compiled in, but not which one is used. (TPACKET3 vs 2, etc.) There was no way in earlier versions of libpcap to even know which was used. I thought we had a way in 1.9, but I can't find it... so I think that I'm wrong, I'm just remembering that we discussed that we should? The pcap_lib_version string will tell you what's compiled in, but not which one is used. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ OK, as I expected (feared), when I brought the 16.04 machine from kernel 4.4.0-109 to 4.15.0-34 it started injecting the "extra" 14 bytes, so it looks like it is a change in the kernel handling of the injection. Does anyone have any pointers on how to handle this? Thanks, Steve ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject change?
On Tue, 11 Sep 2018, Michael Richardson wrote: Steve Bourland wrote: > are captured, if called with size argument 60, 74 are captured). On > matching hardware under Ubuntu 16.04 (libpcap 1.7.4), pcap_inject with > size 50 results in 60 bytes on the wire (expected minimum packet size) > and the padding is all zeros. Both machines are using the same Intel > e1000e driver versions (3.2.6-k). Has anyone else seen this or have a > workaround? It sounds like different kernel packet capture mechanisms are being used. The pcap_lib_version string will tell you what's compiled in, but not which one is used. (TPACKET3 vs 2, etc.) There was no way in earlier versions of libpcap to even know which was used. I thought we had a way in 1.9, but I can't find it... so I think that I'm wrong, I'm just remembering that we discussed that we should? The pcap_lib_version string will tell you what's compiled in, but not which one is used. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ I'm a little confused, why would the capture mechanism matter for the pcap_inject call? I am capturing both senders packets on the same machine (a single tcpdump call). I was thinking my next move would be to grab the 18.04 kernel and install it on the 16.04 machine to see if that triggers the behavior on the 16.04 machine. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject() on loopback (FreeBSD)
On Jun 16, 2014, at 2:50 AM, Guy Harris wrote:
> On Jun 15, 2014, at 1:56 PM, Fernando Gont wrote:
>
>> I will certainly file a bug report, and CC you. My understanding is that
>> this should be filled in most (if not all) of the BSD variants? (because
>> besides the error message one obtains, it seems that in several flavors
>> of them, pcap_inject() fails for the same reason).
>
> NetBSD, OpenBSD, and Dragonfly BSD appear not to even have the ...
...and OpenBSD may need to do
/* BPF writes need to be handled specially. */
if (dst->sa_family == pseudo_AF_HDRCMPLT) {
bcopy(dst->sa_data, &af, sizeof(af));
af = ntohl(af);
} else
af = dst->sa_family;
as its loopback device has a DLT_ of DLT_LOOP rather than DLT_NULL and, with
DLT_LOOP, the 4-byte AF_ header of the packet is in *network* byte order rather
than *host* byte order.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject() on loopback (FreeBSD)
On Jun 15, 2014, at 1:56 PM, Fernando Gont wrote:
> I will certainly file a bug report, and CC you. My understanding is that
> this should be filled in most (if not all) of the BSD variants? (because
> besides the error message one obtains, it seems that in several flavors
> of them, pcap_inject() fails for the same reason).
NetBSD, OpenBSD, and Dragonfly BSD appear not to even have the
/* BPF writes need to be handled specially. */
if (dst->sa_family == AF_UNSPEC)
bcopy(dst->sa_data, &af, sizeof(af));
else
af = dst->sa_family;
code, so
/* BPF writes need to be handled specially. */
if (dst->sa_family == pseudo_AF_HDRCMPLT)
bcopy(dst->sa_data, &af, sizeof(af));
else
af = dst->sa_family;
code needs to be added, and the subsequent switch needs to be changed from
switch (dst->sa_family) {
to
switch (af) {
with a
u_int32_t af;
added to looutput().
Darwin's code path is very different, and I haven't followed the twisty little
maze of code paths into xnu:bsd/net/dlil.c and through if_loop.c to see whether
this bug exists or not (and haven't written code to test it).
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject() on loopback (FreeBSD)
Hi, Guy, First of all, thanks so much for your help and detailed explanation! -- I really appreciate it... On 06/15/2014 08:07 PM, Guy Harris wrote: > >> which would seem to indicate that pcap_inject() is overwriting the >> value I set with something else (pseudo_AF_HDRCMPLT?). > > It indicates that *some* piece of code is overwriting that value. Yep. Apologies for being sloppy [] > /* BPF writes need to be handled specially. */ if (dst->sa_family == > pseudo_AF_HDRCMPLT || dst->sa_family == AF_UNSPEC) > bcopy(dst->sa_data, &af, sizeof(af)); else af = dst->sa_family; > > As the person who came across this bug, you should file a bug on > this; if you can, CC me on it, or, if not, let me know what bug ID it > gets assigned so that I can try to CC myself on it. I will certainly file a bug report, and CC you. My understanding is that this should be filled in most (if not all) of the BSD variants? (because besides the error message one obtains, it seems that in several flavors of them, pcap_inject() fails for the same reason). Thanks! Best regards, -- Fernando Gont e-mail: ferna...@gont.com.ar || fg...@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject() on loopback (FreeBSD)
On Jun 15, 2014, at 5:23 AM, Fernando Gont wrote:
> I'm trying to send an IPv6 packet with pcap_inject() on the loopback
> interface of a FreeBSD 9.2 system.
>
> What I write with pcap_inect() is the IPv6 packet, preceded with the
> 4-byte AF header (which I set to PF_INET6 (which is 28) in host byte order).
>
> However, pcap_inject() fails with
> "send: Address family not supported by protocol family"
>
> and I also get this message on the console::
> "looutput: af=31 unexpected"
>
> which would seem to indicate that pcap_inject() is overwriting the value
> I set with something else (pseudo_AF_HDRCMPLT?).
It indicates that *some* piece of code is overwriting that value.
However, pcap_inject(), on systems with BPF, is:
static int
pcap_inject_bpf(pcap_t *p, const void *buf, size_t size)
{
int ret;
ret = write(p->fd, buf, size);
#ifdef __APPLE__
a bunch of code only used on OS X/iOS
#endif /* __APPLE__ */
if (ret == -1) {
snprintf(p->errbuf, PCAP_ERRBUF_SIZE, "send: %s",
pcap_strerror(errno));
return (PCAP_ERROR);
}
return (ret);
}
so it's not what's setting pseudo_AF_HDRCMPLT.
The offending code is in bpfwrite():
if (d->bd_hdrcmplt)
dst.sa_family = pseudo_AF_HDRCMPLT;
"dst" is handed to looutput() in sys/net/if_loop.c, which does
/* BPF writes need to be handled specially. */
if (dst->sa_family == AF_UNSPEC)
bcopy(dst->sa_data, &af, sizeof(af));
else
af = dst->sa_family;
The common code for Ethernet sends (ether_output()) explicitly handles both
AF_UNSPEC *and* pseudo_AF_HDRCMPLT; the loopback driver needs to handle it as
well, e.g. either
/* BPF writes need to be handled specially. */
if (dst->sa_family == pseudo_AF_HDRCMPLT)
bcopy(dst->sa_data, &af, sizeof(af));
else
af = dst->sa_family;
or
/* BPF writes need to be handled specially. */
if (dst->sa_family == pseudo_AF_HDRCMPLT || dst->sa_family == AF_UNSPEC)
bcopy(dst->sa_data, &af, sizeof(af));
else
af = dst->sa_family;
As the person who came across this bug, you should file a bug on this; if you
can, CC me on it, or, if not, let me know what bug ID it gets assigned so that
I can try to CC myself on it.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_inject and 802.1q subinterfaces on Solaris?
On 23/05/11 10:16 AM, Tim Sammut wrote: On 05/20/2011 04:08 PM, Darren Reed wrote: Hi, Darren, thanks for the note. Are you using a virtual interface such as vnic0? Or does it have another name? The virtual interfaces appear as ce101002 and ce102002; the physical interface is ce2. We're using the instructions at [1] to setup the Solaris machine. Which Solaris 10 update? Looks to be "Solaris 10 9/10". Any thoughts or pointers would be much appreciated. Thanks! This is a known problem with the cassini driver. As yet nobody has made a patch for Solaris 10 that contains the fix for this problem. To get a patch for it, you would need to work through your support contract. Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject and 802.1q subinterfaces on Solaris?
On 05/20/2011 04:08 PM, Darren Reed wrote: > Hi, Darren, thanks for the note. > Are you using a virtual interface such as vnic0? > Or does it have another name? The virtual interfaces appear as ce101002 and ce102002; the physical interface is ce2. We're using the instructions at [1] to setup the Solaris machine. > Which Solaris 10 update? > Looks to be "Solaris 10 9/10". Any thoughts or pointers would be much appreciated. Thanks! hope all is well tim [1] http://download.oracle.com/docs/cd/E19253-01/816-4554/fpdga/index.html - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject and 802.1q subinterfaces on Solaris?
On 19/05/11 03:33 PM, Tim Sammut wrote: Hi, everyone. I have a small tool that uses pcap_inject to send ethernet frames on specific host interfaces. When injecting on a 802.1q virtual interface on Solaris the frame is ultimately transmitted without the 802.1q header that should have been add by the host OS. This is Solaris 10 on SPARC with libpcap 1.1.1, and the same scenario works perfectly on Linux. Is this something that should work on Solaris too? Can you provide more information? Are you using a virtual interface such as vnic0? Or does it have another name? Which Solaris 10 update? Darren - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject and 802.1q subinterfaces on Solaris?
On May 19, 2011, at 7:43 PM, Guy Harris wrote: > Ultimately, libpcap depends on the OS to provide raw packet capture and > injection capabilities. If the Solaris networking stack allows a DLPI device > bound to a VLAN interface to have packets handed to it with a full Ethernet > header and to use the Ethernet header but add in the appropriate VLAN header, > by doing, for example, a special ioctl - and either that ioctl is harmless on > other interfaces or libpcap can somehow determine whether it needs to make > that ioctl - then libpcap could (and should) be changed to do that. If the > Solaris networking stack doesn't allow that, you're out of luck - you might > have to open the hardware interface, construct the packets complete with VLAN > header, and send the packets out on that. Or, if it can get enough information to synthesize the 802.1q header, libpcap could work around it by copying the packet to a private buffer, adding the 802.1q header, and handing that to the DLPI device. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject and 802.1q subinterfaces on Solaris?
On May 19, 2011, at 3:33 PM, Tim Sammut wrote: > I have a small tool that uses pcap_inject to send ethernet frames on > specific host interfaces. When injecting on a 802.1q virtual interface > on Solaris the frame is ultimately transmitted without the 802.1q header > that should have been add by the host OS. This is Solaris 10 on SPARC > with libpcap 1.1.1, and the same scenario works perfectly on Linux. > > Is this something that should work on Solaris too? Ultimately, libpcap depends on the OS to provide raw packet capture and injection capabilities. If the Solaris networking stack allows a DLPI device bound to a VLAN interface to have packets handed to it with a full Ethernet header and to use the Ethernet header but add in the appropriate VLAN header, by doing, for example, a special ioctl - and either that ioctl is harmless on other interfaces or libpcap can somehow determine whether it needs to make that ioctl - then libpcap could (and should) be changed to do that. If the Solaris networking stack doesn't allow that, you're out of luck - you might have to open the hardware interface, construct the packets complete with VLAN header, and send the packets out on that. I don't know which of those is the case; a quick look at the Sun^WOracle documentation didn't find anything obvious. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
On Feb 9, 2010, at 10:20 PM, Frank W. Miller wrote: > I'm getting the feeling that pcap_inject() isn't well supported? I guess it's a question of which code we're talking about in the code path to the hardware. pcap_inject() - like the rest of libpcap - is implemented atop an underlying mechanism in the OS (or, in Windows/WinPcap, atop a kernel-level driver that runs atop an underlying mechanism in the OS; in UN*Xes, the kernel mechanism is built in). To a large degree, pcap_inject() (and the rest of libpcap) depends on the kernel-mode code it uses; the libpcap developers don't own that code and can, at best, compensate for problems in that code, and sometimes can't even do that. It could be that libpcap is doing something wrong, although what it does is relatively simple - it does a send() system call on the socket descriptor it opened. It *might* be that, if the socket is in memory-mapped mode, that doesn't work, but I'd have to look at the Linux kernel socket code to see. It might also be that a send() on the socket is what it should be doing, but, somehow, that's not working, either due to a Linux kernel bug or a driver bug. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
I'm getting the feeling that pcap_inject() isn't well supported? I'm using two laptops: 1) Dell Latitude 630 and 2) Dell Mini 9. The Dell Mini-9 has a Intel 1000 WiFi Link PCIe card in it. I don't know what 802.11 hardware is in the 630. Thanks, FM > -Original Message- > From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers- > ow...@lists.tcpdump.org] On Behalf Of Guy Harris > Sent: Tuesday, February 09, 2010 10:26 PM > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] pcap_inject() > > > On Feb 8, 2010, at 2:34 PM, Frank W. Miller wrote: > > > FWIW, packetspammer does not work either. > > The current top-of-tree version of packetspammer from > > git://git.warmcat.com/packetspammer > > uses pcap_inject(), so it's not *too* surprising that it doesn't work. It > is a nice small (and open-source) program to use to try to reproduce it, > though.- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
On Feb 8, 2010, at 2:33 PM, Frank W. Miller wrote: > Stock FC12. Linux kernel 2.6.31.5-127.fc12.1686.PAE #1 SMP What type of 802.11 adapter are you using? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
On Feb 8, 2010, at 2:34 PM, Frank W. Miller wrote: > FWIW, packetspammer does not work either. The current top-of-tree version of packetspammer from git://git.warmcat.com/packetspammer uses pcap_inject(), so it's not *too* surprising that it doesn't work. It is a nice small (and open-source) program to use to try to reproduce it, though.- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
FWIW, packetspammer does not work either. FM > -Original Message- > From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers- > ow...@lists.tcpdump.org] On Behalf Of Guy Harris > Sent: Monday, February 08, 2010 3:30 PM > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] pcap_inject() > > > On Feb 8, 2010, at 1:33 PM, Frank W. Miller wrote: > > > I'm trying to use pcap_inject over my 802.11 connection. I can receive > > packets using pcap_next() fine and when I call pcap_inject() it returns > with > > the length of the frame to be transmitted except that no frame is seen > over > > the air. I have a sniffer on another machine that is watching and I > never > > see the frame. > > On what version of what operating system are you running the program > that's using pcap_inject()? (For Linux distributions, give both the > kernel version and the distribution name and its version.)- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
Stock FC12. Linux kernel 2.6.31.5-127.fc12.1686.PAE #1 SMP Thanks, FM > -Original Message- > From: tcpdump-workers-ow...@lists.tcpdump.org [mailto:tcpdump-workers- > ow...@lists.tcpdump.org] On Behalf Of Guy Harris > Sent: Monday, February 08, 2010 3:30 PM > To: tcpdump-workers@lists.tcpdump.org > Subject: Re: [tcpdump-workers] pcap_inject() > > > On Feb 8, 2010, at 1:33 PM, Frank W. Miller wrote: > > > I'm trying to use pcap_inject over my 802.11 connection. I can receive > > packets using pcap_next() fine and when I call pcap_inject() it returns > with > > the length of the frame to be transmitted except that no frame is seen > over > > the air. I have a sniffer on another machine that is watching and I > never > > see the frame. > > On what version of what operating system are you running the program > that's using pcap_inject()? (For Linux distributions, give both the > kernel version and the distribution name and its version.)- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject()
On Feb 8, 2010, at 1:33 PM, Frank W. Miller wrote: > I'm trying to use pcap_inject over my 802.11 connection. I can receive > packets using pcap_next() fine and when I call pcap_inject() it returns with > the length of the frame to be transmitted except that no frame is seen over > the air. I have a sniffer on another machine that is watching and I never > see the frame. On what version of what operating system are you running the program that's using pcap_inject()? (For Linux distributions, give both the kernel version and the distribution name and its version.)- This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS
On Thu, Jan 14, 2010 at 5:50 PM, Guy Harris wrote: > > On Jan 14, 2010, at 5:45 PM, David Crowcroft wrote: > >> It looks like you either forgot to attach the files, or majordomo >> stripped them off your e-mail. > > The latter. > >> (plese resend them off-list to me, if necessary). > > Will do. > For instance, do I need to calculate the FCS in the Ethernet frames I send? >>> >>> *Probably* not, at least in most cases. >> >> Is there a portable way of deciding whether I *need* to do it? > > No. I don't even know whether there are any platforms where you do. While I can't say for certain such platforms don't exist, I can say I haven't seen the need to do so any platform in the last 10 years- including embedded systems used on the ISS (as in International Space Station). So unless you're coding for something really really obscure/obsolete I wouldn't worry about manually providing the FCS. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero" - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS
On Jan 14, 2010, at 5:45 PM, David Crowcroft wrote: > It looks like you either forgot to attach the files, or majordomo > stripped them off your e-mail. The latter. > (plese resend them off-list to me, if necessary). Will do. >>> For instance, do I need to calculate the FCS in the Ethernet frames I >>> send? >> >> *Probably* not, at least in most cases. > > Is there a portable way of deciding whether I *need* to do it? No. I don't even know whether there are any platforms where you do. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS
Hello, Guy, >> Does anyone have an example program in C-language that uses the >> pcap_inject() funtion of the libpcap library? > > I've attached some programs I've written as quick tests. It looks like you either forgot to attach the files, or majordomo stripped them off your e-mail. (plese resend them off-list to me, if necessary). >> For instance, do I need to calculate the FCS in the Ethernet frames I >> send? > > *Probably* not, at least in most cases. Is there a portable way of deciding whether I *need* to do it? (I assume that by default, "you don't need to calculate it", right? Thanks a lot, David - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() an Ethernet's FCS
On Jan 14, 2010, at 5:15 PM, David Crowcroft wrote: > Does anyone have an example program in C-language that uses the > pcap_inject() funtion of the libpcap library? I've attached some programs I've written as quick tests. They might or might not compile on your UN*X, or on Windows; you might have to tweak some of the #includes and/or define some of the ETHER_xxx_LEN values yourself. > For instance, do I need to calculate the FCS in the Ethernet frames I > send? *Probably* not, at least in most cases. It's not inconceivable that, if a given Ethernet device is capable of being told "transmit this frame, which includes the FCS field, and do not calculate the FCS yourself", the driver could, when handed a frame through whatever mechanism pcap_inject() uses on that platform, transmit the frame in that fashion. I suspect that, in practice, that won't happen, as it complicates the job of applications that are trying to implement a protocol atop raw Ethernet by using that mechanism. In particular, on at least some versions of Mac OS X: at least some of the Ethernet drivers will configure the hardware (if necessary) to provide the full frame content, including the FCS field, on received packets, and will hand those packets to BPF with the FCS, so you get the FCS field when you capture packets; when you send a packet by writing it to BPF, however, you don't have to supply the FCS; (as indicated by my testing it with the attached programs). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject troubleshooting
On Jan 12, 2009, at 9:05 PM, David Murray wrote:
Good point. However, the packets that I am capturing are going
end-to-end and they are being replayed to the same receiver.
Subsequently, the payload size of the frame should be less than 1500.
What *is* the payload size of a frame that's not being successfully
sent?
Do you think it is possible that when I capture and replay these
packets pcap is appending new headers to the frame without removing
the
old hence pushing the packet size above 1514 bytes for Ethernet?
Libpcap wouldn't do that - the code in libpcap to transmit packets is
Pretty Damn Simple; for example, in Linux, it's a bunch of error
checking to make sure you're not sending on the "any" device, followed
by
ret = send(handle->fd, buf, size, 0);
if (ret == -1) {
snprintf(handle->errbuf, PCAP_ERRBUF_SIZE, "send: %s",
pcap_strerror(errno));
return (-1);
}
return (ret);
so it just takes your data and hands it to the send() system call on
the PF_PACKET socket it opened for capturing and sending.
Whether the Linux *kernel* adds additional headers is another matter,
but I don't expect it to.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject troubleshooting
Quoting Guy Harris : I'm assuming your wired NICs are Ethernet NICs; the maximum payload size for Ethernet is 1500 bytes. The maximum payload size for IEEE 802.11 is 2304 bytes, at least according to IEEE 802.11-1999: 6.2.1.1.2 Semantics of the service primitive ... The data parameter specifies the MSDU to be transmitted by the MAC sublayer entity. For IEEE 802.11, the length of the MSDU must be less than or equal to 2304 octets. 1500 < 1552 < 2304. Good point. However, the packets that I am capturing are going end-to-end and they are being replayed to the same receiver. Subsequently, the payload size of the frame should be less than 1500. Do you think it is possible that when I capture and replay these packets pcap is appending new headers to the frame without removing the old hence pushing the packet size above 1514 bytes for Ethernet? - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject troubleshooting
On Jan 12, 2009, at 8:44 PM, David Murray wrote: I am writing an application using the libpcap library that is capable of caching and replaying frames. I originally wrote and tested this program using a embedded ALIX system that runs a 500Mhz Geode processor. I felt that the slow performance of this CPU was causing a few problems so I decided to try it out on a proper desktop PC. However, I am having problems with the pcap_inject function. While the other functions appear to work fine, pcap_inject is returning the error ?send: message too long?. The function also returns -1. By printing out the packet size I know that this frame is 1552 bytes which is higher than the end-to-end MTU of 1500 bytes. However, this is also confusing, because when I run the same code on my embedded machine, which works, the packet size also appears to be 1552 bytes. The embedded machine is running a Debian variant called Voyage Linux whereas the Desktops I have tried this code on are running Ubuntu Intrepid. I have tried two IBM and Dell desktops and a range of wired NICs. Maybe a key difference between the two systems is that on the embedded system, packet injection occurs over a Atheros WiFi interface whereas on the desktops packet injection occurs over the Wired NIC. I'm assuming your wired NICs are Ethernet NICs; the maximum payload size for Ethernet is 1500 bytes. The maximum payload size for IEEE 802.11 is 2304 bytes, at least according to IEEE 802.11-1999: 6.2.1.1.2 Semantics of the service primitive ... The data parameter specifies the MSDU to be transmitted by the MAC sublayer entity. For IEEE 802.11, the length of the MSDU must be less than or equal to 2304 octets. 1500 < 1552 < 2304. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject displaying in pcap_loop
On Tue, May 29, 2007 at 07:53:20PM -0600, David Vos wrote: > I am using libpcap-0.9.5 on Mac OS 10.4.9. > > I have a pcap_loop() handler which displays the packets I receive. > > If I call pcap_inject(), then shortly after call pcap_loop(), the > injected packet is displayed by pcap_loop. > > I tried to get around this by using pcap_setdirection(PCAP_D_IN), and > while outgoing packets from the OS did not display in the pcap_loop(), > the injected packet still did. > > Is there a way I can inject a packet with pcap_inject() and not see it > display from pcap_loop()? Don't use promiscuous mode or use a PCAP filter that discards the packets you're injecting. Cheers, Eloy.- - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject vs. pcap_sendpacket and max frame
Bug ID# 5108045 I'm going to see if I can get one of my contacts at apple to nudge it along in the system. Unfortunately, neither of them work with the OS X kernel, so not sure what they can do. -Aaron On 4/3/07, Guy Harris <[EMAIL PROTECTED]> wrote: Aaron Turner wrote: > Looks like I'll need to see if my contacts @ Apple can get this bug > fixed. Do you have an ADC account? If so, file a bug (and send me the bug number). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject vs. pcap_sendpacket and max frame
Aaron Turner wrote: Looks like I'll need to see if my contacts @ Apple can get this bug fixed. Do you have an ADC account? If so, file a bug (and send me the bug number). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject vs. pcap_sendpacket and max frame
My code is indeed based on the libnet code and does not use BIOCSHDRCMPLT on OS X. Looks like I'll need to see if my contacts @ Apple can get this bug fixed. Thanks for the info Guy. -- Aaron Turner http://synfin.net/ http://tcpreplay.synfin.net/ - Pcap editing & replay tools for Unix On 4/3/07, Guy Harris <[EMAIL PROTECTED]> wrote: Aaron Turner wrote: > 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). I.e., if you directly call write() on a BPF device with a byte count > 1500, it succeeds in OS X 10.4.9? Does your code do a BIOCSHDRCMPLT ioctl on the BPF device? (Libnet 1.1.2.1 doesn't appear to do so on OS X.) There appears to be a bug wherein the BPF write code in OS X, when the "header complete" mode is set on the BPF device, compares the *total* packet length, not the packet length minus the link-layer header length, against the MTU on the adapter, so a full-length packet is too big. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject vs. pcap_sendpacket and max frame
Aaron Turner wrote: 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). I.e., if you directly call write() on a BPF device with a byte count > 1500, it succeeds in OS X 10.4.9? Does your code do a BIOCSHDRCMPLT ioctl on the BPF device? (Libnet 1.1.2.1 doesn't appear to do so on OS X.) There appears to be a bug wherein the BPF write code in OS X, when the "header complete" mode is set on the BPF device, compares the *total* packet length, not the packet length minus the link-layer header length, against the MTU on the adapter, so a full-length packet is too big. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject vs. pcap_sendpacket and max frame size
*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 <[EMAIL PROTECTED]> 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.
Re: [tcpdump-workers] pcap_inject() fails with rc 0 on HP-UX
[ I really can't seem to set the proper account for these responses Here's to fooling the duplicate message detector ] On 4/4/06, Guy Harris <[EMAIL PROTECTED]> wrote: > Harley Stenzel wrote: > > 2) It's not clear under what circumstances a rc 0 could ever be > > returned. Only on retrun from write() or dlrawdatareq() could rc be > > 0. > > dlrawdatareq() returns the return value of putmsg(), and putmsg() > returns 0 on success. > > I've checked into the main and x.9 branches a change to, on HP-UX, have > the inject routine return, on success, the number of bytes it was asked > to write. That should at least fix that problem. (Workaround: use > pcap_sendpacket(), which is defined to return 0 on success.) OK, that seems to be working well. > > 3) I ported libnet's transmission code into pcap_inject_dlpi(). It > > still does not work, but the failure mode is different -- it reports > > the number of octets written correctly, but the frame is still not on > > the wire. > > I infer from "still not on the wire" that the frame didn't appear on the > wire with standard libpcap, either. Is that the case? If so, my change > won't fix that - it just changes what's returned to match the > pcap_inject() API. I've dug into this deeper, and it it's working now. I'm still haven't determined exactly what the problem was; I've changed too many variables. It's now working on a different HP-UX 11.23 ia64 box that is not multihomed using CVS libpcap. There's also some (ethernet) port security measures in my environment that was being triggered because of a bug in my code. Therefore, I no longer believe that this is a general packet transmit bug (aside from the already-fixed retrun code). I will report if I discover anything of general interest as I continue my port. Thank you. --Harley - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() fails with rc 0 on HP-UX
On Apr 4, 2006, at 8:51 AM, Harley Stenzel wrote: On 4/3/06, Rick Jones <[EMAIL PROTECTED]> wrote: I believe this is a long-standing limitation of promiscuous mode support in HP-UX - only one process may have a promiscuous stream open on an interface at one time. I believe that is the case for DL_PROMISC_PHYS (give me everything that reaches the NIC). I cannot recall if that would be the same for the lesser "give me everything that the NIC gives the host" DL_PROMISC_SAP. Using tcpdump as an example: bash-3.00# tcpdump -p -i lan2 > /dev/null & [1] 14650 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan2, link-type EN10MB (Ethernet), capture size 96 bytes bash-3.00# tcpdump -p -i lan2 > /dev/null tcpdump: recv_ack: promisc_sap: UNIX error - Device busy That's requesting DL_PROMISC_SAP mode. Perhaps in HP-UX, only one process can request that mode at a time, as Rick hypothesized might be the case - if so, it's yet another reason for a "userland protocol" library that would use the underlying packet capture mechanism's features in the right way for a userland protocol implementation atop some link layer (e.g., not doing SAP promiscuity on those platforms with such a notion). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() fails with rc 0 on HP-UX
On 4/3/06, Rick Jones <[EMAIL PROTECTED]> wrote: > > 4) What is the expected interaction of multiple libpcap instances on > > HP-UX? I can't use my program and tcpdump at the same time; something > > I can do on other OSes. > > I believe this is a long-standing limitation of promiscuous mode support > in HP-UX - only one process may have a promiscuous stream open on an > interface at one time. I believe that is the case for DL_PROMISC_PHYS > (give me everything that reaches the NIC). I cannot recall if that would > be the same for the lesser "give me everything that the NIC gives the > host" DL_PROMISC_SAP. Using tcpdump as an example: bash-3.00# tcpdump -p -i lan2 > /dev/null & [1] 14650 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lan2, link-type EN10MB (Ethernet), capture size 96 bytes bash-3.00# tcpdump -p -i lan2 > /dev/null tcpdump: recv_ack: promisc_sap: UNIX error - Device busy So, even without promiscous mode, it is not possible on HP-UX to have multiple libpcap instances on the same nic. > If you need/want that limitation lifted, definitely get in touch with > the HP Response Centre and excercise your support contract(s) to have an > enhancement request opened against DLPI. Thanks, we may do that. It is inconvenient to not be able to use tcpdump and a lipbcap app simultaneously. > Does your program actually require promiscuous mode to function? No, it does not require promiscous mode. It does need to register multiple ethernet multicast addresses, however. > rick jones --Harley - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() fails with rc 0 on HP-UX
Harley Stenzel wrote: However, on HP-UX, that same call returns rc 0. I was not able to find a pre-existing bug for this problem, however I was able to find this message: http://www.tcpdump.org/lists/workers/2004/03/msg00103.html indicating that at least in 2004, HP-UX send would not work. The #ifdeffed-out code was replaced since then. 2) It's not clear under what circumstances a rc 0 could ever be returned. Only on retrun from write() or dlrawdatareq() could rc be 0. dlrawdatareq() returns the return value of putmsg(), and putmsg() returns 0 on success. I've checked into the main and x.9 branches a change to, on HP-UX, have the inject routine return, on success, the number of bytes it was asked to write. That should at least fix that problem. (Workaround: use pcap_sendpacket(), which is defined to return 0 on success.) 3) I ported libnet's transmission code into pcap_inject_dlpi(). It still does not work, but the failure mode is different -- it reports the number of octets written correctly, but the frame is still not on the wire. I infer from "still not on the wire" that the frame didn't appear on the wire with standard libpcap, either. Is that the case? If so, my change won't fix that - it just changes what's returned to match the pcap_inject() API. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_inject() fails with rc 0 on HP-UX
WRT the return of zero as the number of bytes - perhaps some of the code in pcap_dpli is ass-u-me-ing the return value from a call will give that? I've not looked at that source in a very long time though... 4) What is the expected interaction of multiple libpcap instances on HP-UX? I can't use my program and tcpdump at the same time; something I can do on other OSes. I believe this is a long-standing limitation of promiscuous mode support in HP-UX - only one process may have a promiscuous stream open on an interface at one time. I believe that is the case for DL_PROMISC_PHYS (give me everything that reaches the NIC). I cannot recall if that would be the same for the lesser "give me everything that the NIC gives the host" DL_PROMISC_SAP. If you need/want that limitation lifted, definitely get in touch with the HP Response Centre and excercise your support contract(s) to have an enhancement request opened against DLPI. Does your program actually require promiscuous mode to function? rick jones - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
