Juergen Schimmer wrote:
2007/4/2, Guy Harris <[EMAIL PROTECTED]>:
In other words, the packets are *NOT* 802.15.4-2006 packets as they
appear on the air, but have had the address fields padded?
Yes
Is this on Linux?
Yes it is on Linux. ( X86 and uClinunx ARM ). At the Moment i try to get
Richard Stearn wrote:
Adding DLT_AX25_KISS is the obvious way to go with the exception that Linux
identifies AX.25 in KISS packets as DLT_AX25 (protocol 3).
"Identifies" in what sense?
I don't see any use of DLT_AX25 in the 2.6.20.4 kernel. It appears to
use ARPHRD_AX25 as the arphrd value
I am running a local pcap application on a Solaris
host, capturing only packets going to and from a
specific interface. Sometimes I see several
packets coming in, in a row, and then several
packets going out, in a row, from that interface.
I think you are seeing the same problem that I have desc
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 a
Hi Roy,
On Tue, Apr 03, 2007 at 09:51:16AM +0100, roy hills wrote:
> >I am running a local pcap application on a Solaris host, capturing
> >only packets going to and from a specific interface. Sometimes I see
> >several packets coming in, in a row, and then several packets going
> >out, in a row,
I've also had problems with Solaris. In my opinion it's not the
best platform for capturing packets in real-time. In Network Expect
(http://www.netexpect.org) I am currently using the following code,
which I borrowed from another open source project (can't remember
which):
[snip]
Great - that w
Hello,
On Tue, Apr 03, 2007 at 02:49:14PM +0100, roy hills wrote:
> >I've also had problems with Solaris. In my opinion it's not the
> >best platform for capturing packets in real-time. In Network Expect
> >(http://www.netexpect.org) I am currently using the following code,
> >which I borrowed fr
On 4/2/07, Abeni Paolo <[EMAIL PROTECTED]> wrote:
on Sun 4/1/2007 11:46 PM Guy Harris wrote:
> Paolo, do you have any comments on the changes?
The only issue I see is the following:
urb_len is the size of the buffer for receiving data. Most of the time
the reply and the receive buffer are the
diff with -u attached
--
Jon Smirl
[EMAIL PROTECTED]
? libpcap.diff
? libpcap.patch
? lpcap.diff
Index: pcap-usb-linux.c
===
RCS file: /tcpdump/master/libpcap/pcap-usb-linux.c,v
retrieving revision 1.14
diff -u -r1.14 pcap-usb-linux
> I'll need to check on how select() is behaving, but it is working, and
> I'm only calling pcap_dispatch() if select() indicates that the pcap
> fd is readable.
Yeah, that's what I do too. However, if I remember correctly, I found
out that select() was not blocking (as it should) when there was
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/
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.
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 nee
There's a minor bug in the tcp_print() function introduced in Hannes'
rewrite in version 1.127 of print-tcp.c. A NUL ('\0') character is
printed after the open bracket '[' and before other options. If you're
just printing to a TTY, you probably won't see the NUL, but it's
definitely there, e.
Alexander Dupuy wrote:
The fix is easy:
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Hi!
> I think you are seeing the same problem that I
> have described in my posting "Not receiving
>packets on Solaris, but no problems on Linux and
> BSD".
>
> I think what we both need is the Solaris/DLPI
> equivalent to the BSD/BPF BIOCIMMEDIATE ioctl.
Do you happen to know what is the So
On Tue, Apr 03, 2007 at 02:13:40PM -0700, Ury Segal wrote:
> > I think you are seeing the same problem that I have described in my
> >posting "Not receiving packets on Solaris, but no problems on Linux
> >and BSD".
> >
> > I think what we both need is the Solaris/DLPI equivalent to the
> > BSD/BPF
On Tue, Apr 03, 2007 at 04:57:27PM +0100, roy hills wrote:
[...]
> What I find is that select() returns when there is any data received
> on the network interface; not just data that will match the pcap
> filter. In other words, just because select() returned indicating that
> the pcap file descr
Guy Harris wrote:
Richard Stearn wrote:
Adding DLT_AX25_KISS is the obvious way to go with the exception that
Linux
identifies AX.25 in KISS packets as DLT_AX25 (protocol 3).
"Identifies" in what sense?
As in returns 3 as an identifier of the protocol type.
I don't see any use of DLT_AX2
19 matches
Mail list logo
