On Aug 30, 2006, at 10:48 AM, [EMAIL PROTECTED] wrote:
I wish to use hostap (a driver for wireless cards) + libpcap +
tcpdump to
bring some extra details of the packets in the user space.
What sort of extra details?
I wish to know that how libpcap reads the packet from the kernel/
interfa
madhuresh wrote:
Yes you are right. I was mentioning about hostap-driver-0.4.7 which
works as a module with linux kernel.
(The linux-2.6.17.3 kernel has a drivers/net/wireless/hostap directory.
What's the difference between that driver - or any versions from later
Linux kernels - and the ho
[EMAIL PROTECTED] wrote:
For tcpdump, I am trying to find out where is CFG ( call flow graph
structure, which is used for further optimization ) generated? during
parsing stage or after the parsing stage?
*Currently*, the CFG is generated by pcap_parse() (and by a call to
gen_retblk()), whi
Bruce Keats wrote:
After digging into the issue, I have come up with a patch. The crux of the
problem is that the off_ll is added twice when generating the BPF code that
peeks into the LLC header.
Yes. The real problem was that the code was a bit confused about where
to add in off_ll.
I've
Guy Harris wrote:
I've checked into the main and x.9 branch (so if there's an 0.9.5
release, it'll be in that release; I don't know whether there will be
one or not) a change to fix up the addition of off_ll (by centralizing
it, and *not* adding it into other off_ value
abeni wrote:
An USB pseudo header is prepended to the captured URB to give
additional information on URB (type, sender, ecc.).
That pseudo-header is currently in a separate GPL'ed pcap-usb.h header:
1) The rest of libpcap is licensed under the Berkeley license, with
some of it under the fou
On Oct 2, 2006, at 2:31 AM, Paolo Abeni wrote:
I posted this mail a few days ago, but I can't see it in the mailing
list archive... Sorry for any duplicates...
I didn't see it either.
The USB pseudo headers are still in a separate file, must I move them
into pcap.h ?!?
Not necessarily.
On Oct 2, 2006, at 6:21 PM, ronnie sahlberg wrote:
No it is for "raw" usb frames with some additional infomation
added by
the capturing layer.
Some of these frames, those captured when talking to a memorystick,
will
likely contain SCSI CDBs and DATA frames in some layer above the
actu
Michael Richardson wrote:
"Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>> The USB pseudo headers are still in a separate file, must I move
>> them into pcap.h ?!?
Guy> Not necessarily.
Guy> If we have a separate header, however, I&#
dean gaudet wrote:
i think you forgot to cvs add pcap/sll.h ... it's not there in cvs.
Fixed.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
It works. Or at least it seams to work :-). It probably needs more
testing, anyway I tried it with wireshark and grabbed the attached
capture files. The first is obtained plugging a mouse into the use port,
and the second unplugging it.
I don't see any attached capture files
Paolo Abeni wrote:
After a bit more testing I found some issues with current usb sniffing
code:
- the snaplen parameter is just ignored.
- the raw data received from usb port is partially corrupted.
The attached patch should fix both.
Checked in.
-
This is the tcpdump-workers list.
Visit htt
Paolo Abeni wrote:
The attached differential patch fix the compile issue introduced by me.
You can use it instead of revert
'ascii_conversion_and_snaplen_fix.patch' and apply
'ascii_conversion_and_snaplen_fix_v2.patch'.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelma
Paolo Abeni wrote:
A binary interface for sniffing USB packets is coming, so we will soon
get packets with this header formatted following the standard. The
attached patch change the usb setup struct as the standard tell, it is
worthy ?
Yes. Checked in.
-
This is the tcpdump-workers list.
Vis
On Oct 11, 2006, at 11:03 AM, Brocha Strous wrote:
I have 2 different implementations. The problem is only with a very
small number of users so its not server-wide. Possibly related to a
specific firm-ware version of a Zyxel router - are there any known
in-compatibility between pcap and this ro
Paolo Abeni wrote:
The attached patch fix the parsing of setup data fields in current
implementation of usb_read_data.
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Oct 12, 2006, at 6:48 AM, Paolo Abeni wrote:
I'm working to add bluetooth/hci support (like hcidump) to libpcap,
Good!
can you please assign a new DLT value for bluetooth/hci ?
Does "like hcidump" mean the first byte of the data is a code for the
type of packet, i.e.:
1 - H
Paolo Abeni wrote:
Yes. I used my patched version of libpcap with wireshark and it was able
to dissect sniffed hci frames using current wireshark hci dissector[s].
Great!
It's DLT_BLUETOOTH_HCI_H4/LINKTYPE_BLUETOOTH_HCI_H4, with a value of 187.
-
This is the tcpdump-workers list.
Visit https:
Paolo Abeni wrote:
Very sorry, I forgot to add the attach in the previous mail. you can
find the lookupnet fix patch attached to this mail
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
The attached patch enables sniffing from bluetooth devices for the Linux
platform.
Checked in.
I added pcap-bt-linux.h and pcap-usb-linux.h headers and had
pcap-linux.c include them if PCAP_SUPPORT_{BT,USB} is defined and had
pcap-{bt,usb}-linux.c include them uncondition
Paolo Abeni wrote:
the attached patch fix an off by one in current usb sniffing code. It
also substitute the kernel-provided timestamp with gettimeofday. The
kernel provided timestamp use 32 bits to represent a struct timeval (8
bits for tv_sec and 24 for tv_usec), so it's content is quite
misle
On Oct 18, 2006, at 3:41 PM, Alexander Dupuy wrote:
You really want to use select() (or poll() if your operating system
doesn't support select()) instead of a CPU polling loop. You can
use pcap_get_selectable_fd() to get the underlying file descriptor
on a Unix system (won't work on Windo
Sebastien Raveau wrote:
I'm currently trying to pass the file descriptor of a live capture to another
process, so that I can have a very small (as in "auditable") privileged
process able to call pcap_open_live() on the one hand, and a big/fat/ugly/gui
process on the other hand running all the
madhuresh wrote:
I am just anxious to know that why we do filtering of packets at user
space and not at driver level (kernel space).
Because, on those OSes where filtering is done in user space, the OS and
drivers either don't have a filtering mechanism or don't have one that
uses BPF progra
On Oct 23, 2006, at 12:56 PM, madhuresh wrote:
Note, however, "in kernel space" doesn't necessarily mean "at the
driver level"; on Linux, the in-kernel filtering is done by "socket
filters" above the driver, and, even on BSD, although the driver
directly calls the BPF routine to supply a p
madhuresh wrote:
So the final question is "Is there any alternative way (consider
operating system to be linux) apart from BPF code for kernel level
filtering" ?
To my understanding there can be two possibilties:
1. A new interface (say XYZ0) where only filtered packets come from
driver/ker
Guy Harris wrote:
You forgot option 3:
3. Raise the limit on the maximum number of BPF instructions.
You're going to have to add stuff to, or change stuff in, the kernel to
implement this *anyway*, so you might as well just boost the maximum
number of BPF instructions and not ha
Eloy Paris wrote:
Guy,
On Wed, Oct 18, 2006 at 04:12:04PM -0700, Guy Harris wrote:
[...]
Note that in some systems with BPF (older versions of
{Free,Net,Open,Dragonfly}BSD, current versions of Mac OS X), select()
(and poll()) don't work correctly on BPF devices, and so you have to
Eloy Paris wrote:
However, I think the reason that I am not seeing any broken behavior is
because I use BIOCIMMEDIATE.
Right.
There you mentioned "It works around the problem by getting rid of the
timeout, so that as soon as a packet arrives the packet is made
available, rather than the BPF
abakash wrote:
I am new to libpcap and just want to know whether libpcap has got any
http support in it i.e. whether I can extract http header information
from any packet.
You can, if you choose, write code to extract HTTP header information
from any TCP segment captured by libpcap that cont
Hannes Gredler wrote:
you may want to check libpcap/savefile.c
[http://cvs.tcpdump.org/cgi-bin/cvsweb/libpcap/savefile.c?rev=1.147]
to get a better understanding about the .pcap file format.
...and you might want to note that savefile.c is part of libpcap,
meaning that if you just want to
Maria Cruz wrote:
Hi, if a new protocol is introduced to libpcap is it necessary to
update 'gencode.c' for parsing?
You would have to add a case to the switch statement in init_linktype().
At minimum, it'd have to do
/*
* Currently, only raw "link[N:M]" filtering is supporte
On Nov 8, 2006, at 12:30 PM, Cruz Petagay wrote:
I would like to request a link- layer type value for WiMax (802.16).
The purpose is for support in wireshark/ethereal dissector.
I'll look at your mail about the layer at which this capture will be
done, and assign a type value and name to i
srinibas maharana wrote:
I am just trying to find out, whether it is possible
to use libnet/libpcap or, any thing simillar, for
redirecting an client application's data traffic meant
for a server application running on a separate
machine, to another application on the same machine
running the c
Maria Cruz wrote:
DLT_IEEE802_16_MAC_CPS is fine. Thanks. Will you also assign a value?
Yes - that's what this process is all about. I've assigned the value 188.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Guy Harris wrote:
I'll look at your mail about the layer at which this capture will be
done, and assign a type value and name to it.
Done, as per my other mail.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Paolo Abeni wrote:
A new binary interface for USB sniffing is making it's way into the
current kernel tree and I hope that will be available in the near
future. This will solve both problem and the relevant ABI has yet been
fixed, so I can produce the pcap code to use it. The new ABI will
provid
Michael Richardson wrote:
On an slightly off-topic note: is anyone aware of any USB-over-IP
protocols? Consider the case of the thin client that wants to have a
thumb drive inserted in the client show up on the "host".
A quick query to Sergey and Larry's servers found
http://www.digi
On Nov 30, 2006, at 1:08 PM, Aaron Turner wrote:
I guess I can understand why libpcap takes the min of snaplen &
caplen, but it would be nice if libpcap returned the actual captured
data rather then truncating it.
Unfortunately, I don't know where or how these pcap files were
generated, so I d
On Dec 4, 2006, at 2:41 PM, Gianluca Varenni wrote:
- Original Message - From: "Harley Stenzel" <[EMAIL PROTECTED]
>
It certainly does, but it expired more than 2 years ago. Is it
still active?
Although the draft expired 2 yrs ago, and I released some update to
the NTAR code ba
Paolo Abeni wrote:
- I'm not able to take advantage of the memory mapped access: the kernel
prepend to each event an header that is quite different form the libpcap
pcap_usb_header. To keep thinks working I need to modify 'in-place' this
header (but this requires write access to the memory mappe
Jan Allman wrote:
I'm using Ethereal and am confused about the SNMP dump. The field
sizes don't match the specification (RFC 1157).
Where in RFC 1157 does it specify what the field sizes should be?
For example:
E.g.
The 'Version' field should be 4 bytes but its dump is 3 bytes: 02 01 00
David Lopez wrote:
I'm developing a small sniffer for my project. I'm using libpcap
It appears, from your program, that you're using WinPcap (the Windows
port of libpcap).
Are you doing this on Windows (in which case you're using WinPcap) or
on some other OS (in which case you're using libpca
Paolo Abeni wrote:
To access the binary api, some device files have to be accessed. In the
patch the path for this devices is hard-coded, but the effective
location may change depending on the linux distribution.
So the driver that supports the binary API doesn't hard-code the
location of the
On Dec 17, 2006, at 2:18 AM, Paolo Abeni wrote:
this is an updated version of the patch to enable using the new usb
sniffing infrastructure under linux. It retain and clean up a bit the
existing code using the kernel text interface.
The main change from the previous post is an autoconf test fo
[EMAIL PROTECTED] wrote:
(See attached file: mtp2_filtering.tar.gz)
There doesn't seem to be an attachment to your message; the headers on
your message include:
X-Alcanet-MTA-scanned-and-authorized: yes
X-Content-Discarded: application/octet-stream
Does your corporate mail
[EMAIL PROTECTED] wrote:
Well, I do not understand why the attachment was discarded ?
Maybe the policy changed in the same time my email address ?
Anyway, I have renamed the file Tar dot gz file and will send it again as
attachment.
That succeeded. Choosing a different extension probably fool
[EMAIL PROTECTED] wrote:
Well, I do not understand why the attachment was discarded ?
Maybe the policy changed in the same time my email address ?
Anyway, I have renamed the file Tar dot gz file and will send it again as
attachment.
(See attached file: mtp2_filtering.archivegz)
That message,
[EMAIL PROTECTED] wrote:
I think the patch was discarded again in my last mail, so I post again but
in full text mode.
Sorry for the inconvenience..
(See attached file: scanner.l.diff)(See attached file: gencode.c.diff)(See
attached file: gencode.h.diff)(See attached file: grammar.y.diff)
Nop
[EMAIL PROTECTED] wrote:
Here is a short patch to implement filtering for MTP2 frames on SS7.
You can now use "fisu", "lsu", or "msu" to filter the MTP2 messages at
libpcap level.
In most of the case, the filter to use will be "!fisu", to have only the
significants frames.
I checked it in (one
ness wrote:
Below are a few interesting snippets of my code pertaining to libpcap.
All of the code is running on the main thread. Tcpdump and my
implementation both ran on an Airport Extreme card with WEP, but I doubt
that serves any relevance.
It probably isn't of direct relevance, but it a
Jonathan Gruenhut wrote:
This behavior is not unique to my own application; I get the same
behavior simply using tcpdump (version aix3.8 with libpcap version aix0.8).
So is that the tcpdump that comes with AIX and the libpcap that comes
with AIX?
If not, could you try it with the tcpdump th
Abeni Paolo wrote:
Most notably the byte alignment of header contained in each usb
'packet' is enforced to be little endian (currently is in host byte
order and this give some issue). This requires to disable memory mapped
access.
Is there a significant performance improvement from memory-mapp
Kevin Steves wrote:
The following patch fixes a bug in print-bootp.c. It will print an
extra "\n\t " when the last line contains 4 options. It is also
simpler in general and eliminates the need for a first variable.
Also contains some formatting and whitespace cleanup.
Checked into the m
Kevin Steves wrote:
The following patch does the following:
0) use TTEST/TCHECK macros vs. snapend comparisons
1) when -vvv display PAD and END options
(multiple PAD options are summarized)
2) change a trunc string from bootp to rfc1048 because I think that is
what is intended (matches tru
Abeni Paolo wrote:
the attached patch fix a format string error present into the bluetooth support
for linux.
The message involved is an error message, so the issue don't rise too often.
Checked in.
p.s. why don't add "-Wall" to the compiler options? it will help to find such
error.
Not
Kevin Steves wrote:
0) don't print spaces in [ flags ]
1) some whitespace cleanup in that area
Checked in to the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Abeni Paolo wrote:
1) the host reading a capture file can determine the byte order of the
host on which the capture was done,
I did not know this. Can you plase explain me how ?
The file header in a libpcap file starts with a magic number to indicate
that it's a libpcap file; the magic numb
Kevin Steves wrote:
this eliminates extra leading space for DNS dissector.
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Hannes Gredler wrote:
ahh now i get you ... the ttl %3u change was introduced _before_
we decided to print the ID-field ... and this made multiline
outputs more readable ...
checked in your fix into head.
Should it also go into the x.9 branch?
-
This is the tcpdump-workers list.
Visit https://
Abeni Paolo wrote:
the attached patch cleanup the usb_platform_finddevs(), removing the
dependency from debugfs. There are also some other minor cleanup in the
pcap-usb-linux.c file (unused variables removed and indentation fix).
Checked in.
I plan to post the aligment fix for usb header in
[EMAIL PROTECTED] wrote:
I need to capture and decode SSL traffic. Does tcpdump support this?
Tcpdump supports capturing *all* network traffic; if it captures and
saves packets to a file, the packet contents are just a big bucket of
bytes. Note that its default "snapshot length" is 68 byte
Abeni Paolo wrote:
The patch contained in the previous post does conatain an offset
error while accessing the linux usb header struct. The one attached
here should fix the issue. Please give it a review, since this sort
of thing is a bit tricky.
Checked in.
I was tempted by implementing and
Kevin Steves wrote:
I started looking at this because the minimum length check was
off by one.
0) fix off by one (4 vs. 3)
1) print flag bits
2) print rcode fields if either is non-zero
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/
On Jan 30, 2007, at 2:17 AM, [EMAIL PROTECTED] wrote:
I wrote a patch to avoid calling this function if the support for
IPV6 is
not present.
Checked in (but without the change to include ip6.h if the support
*is* present; it's not necessary).
-
This is the tcpdump-workers list.
Visit htt
On Jan 30, 2007, at 4:50 AM, [EMAIL PROTECTED] wrote:
Here is a patch for the libpcap interface with Endace DAG boards.
It should solve the following errors, when you are running Wireshark.
Checked in to the main and x.9 branches, with some additional cleanup
of the code that allocates and
On Jan 30, 2007, at 2:28 AM, [EMAIL PROTECTED] wrote:
I have a systematical crash at tcpdump startup, when I am using
libpcap
(2007-01-30)
I just add a test to check if the USB bus directory is present in
pcap-usb-linux.c, and it
seems to solve the problem.
Checked in.
-
This is the tcpdump
Adelmo Silva wrote:
Jin YunYe wrote:
On 2/2/07, Adelmo Silva <[EMAIL PROTECTED]> wrote:
Hello,
I have a error:
debian:/home/adelmojs/MONOGRAFIA# gcc teste1.c -lpcap -o teste1
teste1.c: In function 'SNIFFER':
teste1.c:294: warning: passing argument 2 of 'strcat' makes pointer from
integer witho
[EMAIL PROTECTED] wrote:
Very minor patch to print basic info about a few more Cisco LAN
protocols. See documentation of the PID values at for instance
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#pre4
Checked into the main and x.9 branches.
[EMAIL PROTECTED] wrote:
Additionally, could you replace the word LSU by LSSU in gencode.c,
gencode.h, grammar.y and scanner.l.
This is the exact term to use for MTP2 messages.
Checked into the main and x.9 branches (with "lsu" supported as an alias
for "lssu", for backwards compatibility).
On Feb 8, 2007, at 1:22 PM, Stephen Donnelly wrote:
As a question to the community in general, is it true that the link
layer checksum is not normally included in libpcap records,
No.
For example, sometimes a frame in a DLT_EN10MB capture might have the
CRC, and other times it might not.
[EMAIL PROTECTED] wrote:
As requested few days before, I would like to use a new DLT to distinguish
between MTP2 without FCS (the current DLT_MTP2) and MTP2 with FCS.
Or perhaps the link type value in the file header should be interpreted
as having bitfields, with the lower 16 bits being the
Jon Steel wrote:
I have found a potential bug in libpcap on OpenBSD and likely FreeBSD as
well. If you simultaneously open several programs that open pcap
connections, you can cause the system to lose track of some of its
BPF's. When you close all the pcap connections some of the BPF's may
repor
Guy Harris wrote:
I can't reproduce this on OS X 10.4 - I get
$ sudo ./bpfMaker.pl en1
BPF's at startup:0
BPF's upon ending:0
...with a version of bpftest.c fixed so that, if pcap_open_live() fails,
it returns before calling pcap_loop() (otherwise
Adelmo Silva wrote:
But, if I wrote:
strcat(string1, &ips1[i]);
Another error happen:
teste1.c:294: error: incompatible types in assignment
So, on line 294 of testel.c, did you write
strcat(string1, &ips1[i]);
or did you write
string1 = strcat(string1, &ips1[i]);
I suspect
Jon Steel wrote:
I did some more digging and I think Ive narrowed the problem down a bit
more. It does appear to be a kernel issue. pcaps off the hook for today.
For those interested, the problem occurs for the following reasons: When
you call open() on OpenBSD it does not lock the file unless y
maneeshs wrote:
There seems to be a race condition in the above code, the check for the
descriptor being free and the call to D_GET to mark the descriptor as
being used is not atomic. So two closely spaced calls to bpfopen could
cause bpf to use the same device twice ?
Yes, if, in OpenBSD, e
(the -request address for a mailing list is for requests to be added
to or removed from a mailing list; it is not for messages sent to the
list itself)
On Mar 6, 2007, at 5:36 PM, ARAMBULO, Norman R. wrote:
Is the ethernet size always equal to 14 bytes?
The lowest-layer Ethernet header is
Albert Chin wrote:
Is CVE-2007-1218 applicable to tcpdump 3.9.4? Doesn't seem so as the
line in the following patch was added after 3.9.4:
The problem in 3.9.5 was that the line was wrong.
The problem in 3.9.4 and before was that the line was *absent*.
The check makes sure that the amount of
Florian Weimer wrote:
Thanks for the clarification. Have you already requested a new CVE
name?
Is one needed? The page at
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1218
says
Off-by-one buffer overflow in the parse_elements function in the 802.11
printer code (print-802_11.c)
Aaron Turner wrote:
notice the addtional 14 byes in the wireshark decode: "G SRC='http://";
When you say "same packet", do you mean that you ran "tcpdump -XX" on a
capture file, and ran Wireshark on the same capture file, and got the
"packet dump example from tcpdump -XX" output from tcpdump
Aaron Turner wrote:
That's an excellent question. The original pcap file is over 3 years
old, and honestly I don't remember. My guess is that the packets were
most likely captured using tcpdump using the default snaplen on a
RedHat Linux box since that was my main development environment at th
Aaron Turner wrote:
Not sure I follow the above. What value are you talking about here...
the file snaplen?
Yes.
Not sure what errors you're talking about here.
People should always compare the packet caplen/len to determine if the
packet was truncated, not the file snaplen.
It's not a qu
On Mar 21, 2007, at 2:26 PM, Greg Hellings wrote:
While stumbling through the tcpdump code it looks to me like tcpdump
uses its own methods (in the print-*.c files) for displaying output to
the screen,
Yes. That is as intended. libpcap is a library for capturing and
sending traffic, and r
On Mar 21, 2007, at 6:07 PM, Greg Hellings wrote:
In my experience libpcap lacks an application-layer parser.
Correct. Parsing the packet at all is left up to the program using
libpcap or the library processing the packets that libpcap generates,
as different applications have different
On Mar 23, 2007, at 3:35 PM, Luis Martin Garcia wrote:
Is there any way, using libpcap or not, to get the IP of a network
interface in a portable and easy way?
With newer versions of libpcap/WinPcap, you could try using
pcap_findalldevs() and look for the interface in question on the list
Jung-uk Kim wrote:
FreeBSD has added PCAP_D_OUT support for pcap_setdirection():
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Aaron Turner wrote:
Honestly, I can't imagine why the snaplen is interesting other then
for properly sizing the packet data buffer,
It might be useful to use as evidence if somebody asks why a capture has
only partial packets in it.
Well the real issue IMHO is the buggy RH hacked libpcap.
[EMAIL PROTECTED] wrote:
Please tcpdump, do not end, but run over damaged packets (move from
current position in cap file byte by byte) from cap file until You find
good header and packet,
Define "good".
The code *could* skip forward until it finds something that appears to
have a caplen <=
Richard Stearn wrote:
+ case DLT_AX25:
+ /*
+* Currently, only raw "link[N:M]" filtering is supported.
+*/
+ off_linktype = -1; /* variable, min 15, max 71 steps of 7
*/
+ off_nl = -1;/* variable, m
Juergen Schimmer wrote:
I would like to request a new DLT value for 802.15.4 Low rate wireless
personal area networks.
I am currently working on an project using 802.15.4 and would like to
use libpcap.
So a packet in a capture file would begin with the 2-octet Frame Control
field, as per Figu
Jon Smirl wrote:
Attached is some clean up for libpcap support of usbmon on Linux.
You might want to send it as "diff -c" or "diff -u" output, in case
changes are made to those files before the patch is applied (as has
already happened - I added RCS IDs to some files that lacked them,
includ
Richard Stearn wrote:
What the implementors of AX.25 on Linux have done is to hand an KISS
packet rather than a pure AX.25 packet to the protocol stack. This
probably was to accomodate the existing base of hardware where packets
were delivered to the system via an async serial port and the leng
Guy Harris wrote:
Is KISS a standard independent of Linux?
Apparently:
http://www.ax25.net/kiss.htm
so DLT_AX25_KISS is, I think, the right way to go here.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Juergen Schimmer wrote:
Yes. In difference t the 802.15.4-2006 spec all Address fields are at
the maximum
size ( This is done in the device driver for better handling in the
upper layers )
In other words, the packets are *NOT* 802.15.4-2006 packets as they
appear on the air, but have had the
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
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
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
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.
Alexander Dupuy wrote:
The fix is easy:
Checked in.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
601 - 700 of 2521 matches
Mail list logo
