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
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
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
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
Alexander Dupuy wrote:
The fix is easy:
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
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.
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
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.
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/
> 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
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
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
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
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
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,
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
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
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
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
19 matches
Mail list logo
