Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 1:20 PM, Guy Harris wrote: Use "isprint()" rather than "isascii()" in "print_payload()". ...and, while you're at it, print the payload in hex, as well as ASCII, to emphasize that there's *no* guarantee that TCP data is text.

Re: [tcpdump-workers] Ether-Type incomplete

On Jun 29, 2005, at 2:50 PM, Borja López wrote: After a search in this list database i've found a case where someone had nearly the same problem (http://www.mail-archive.com/tcpdump-workers@lists.tcpdump.org/ msg00339.html). The cause of the problem is that ether_type is read by processor in

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 3:07 PM, Robert Lowe wrote: Seems like that kind of functionality might be a good candidate for inclusion in libpcap itself, no?? There are already functions to dump to a savefile; why not printable output as well?? How much printable output do you want? Should libpcap i

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

On Jun 29, 2005, at 5:50 PM, 广星 wrote: What I most concern about is how to print the payload in the correct format? For example, there is a HTTP packet, how can I print the HTTP payload according to its real content, such as"HTTP/1.1 206 Partial". Well, the first thing you have to determi

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

广星 wrote: How can I determine the right format? For example a packet has been identified as an HTTP packet, How can I know what its format is and are there many formats of the content of http? Note that a TCP segment, in a link-layer frame, doesn't necessarily correspond to a single HTTP req

Re: [tcpdump-workers] detecting libpcap 0.9

Florian Weimer wrote: What's the best way to detect libpcap 0.9 and later versions? In my application, I've got a workaround for this Debian bug: That bug is not unique to Debian. Apparently, this bug has been fixed in versions aft

Re: [tcpdump-workers] detecting libpcap 0.9

Florian Weimer wrote: * Guy Harris: note that the *same* executable image can run with *different* libpcap library versions, if it's built with a shared version of libpcap, so a compile-time test can't always give the right answer. Is this really the case? I thought that most dis

Re: [tcpdump-workers] libpcap: cooked socket warning & only beacon

Aki Tran wrote: I'm using libpcap- and jpcap to capture the wireless packets in monitor mode from a linux system (Fedora Core 3). I could only capture beacon frames, not control or data frames. I got this run-time warning: Warning: arptype 801 not supported by libpcap - falling back to cooked

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment questions

Cyril wrote: 2) Are pcap_next() network layer data aligned in memory ? IE -- Alignment Link layer data -- Gap -- Alignment Network layer data No, they are not. What you get is what's on the network, and if you have a 14

Re: [tcpdump-workers] detecting libpcap 0.9

only OS that comes with libpcap, so having the library version number available only at compile time would be a mistake (at least one OS that ships libpcap as a shared library doesn't even ship it with a version number: Guy-Harris-Computer.local$ ls -l /usr/lib/libpcap*.dylib

Re: [tcpdump-workers] detecting libpcap 0.9

On Jul 5, 2005, at 2:39 PM, dean gaudet wrote: shouldn't that be pcap_direction_t? otherwise i can imagine some namespace collision occuring... Yeah, probably. I've checked in a change to do that - and to rename the D_ values in it to PCAP_D_ as well. - This is the tcpdump-workers list.

Re: [tcpdump-workers] detecting libpcap 0.9

On Jul 5, 2005, at 3:03 PM, Guy Harris wrote: Yeah, probably. I've checked in a change to do that - and to rename the D_ values in it to PCAP_D_ as well. Unfortunately, that happened after the 0.9/3.9 release, so, for better or worse, we're stuck with the old names; I've

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

On Jul 5, 2005, at 3:34 PM, Cyril wrote: Yes. The question was stupid. My program computes a data offset (14 for an Ethernet header) and assumes that network layer data follow link layer data However, I set up a BPF filter and BPF man page says : The bh_hdrlen field exists to account

Re: [tcpdump-workers] 3.9.1 -A flag broken

dean> case 'A': - ++xflag; ++Xflag; ++Aflag; break; - Guy added that line 19-Dec-2002. The "++xflag;" line? Which change added it? Revision 1.192 only changed the white space in the "case 'A':" code, at least according to "cvs diff -w -r1.1

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 5, 2005, at 7:30 PM, Michael Richardson wrote: oh, a regression test would have shown this. ...and a cleaner implementation of "-A" - i.e., one with a new routine to print out the packet data as ASCII, rather than one that jams that functionality into a routine that does a hex-an

Re: [tcpdump-workers] 3.9.1 -A flag broken

Guy Harris wrote: Here's a patch that has separate routines for "-A", "-x", and "-X", and that separately tests Aflag, xflag, and Xflag, and gives them all appropriate names. Ok, *here's* the patch. It also changes "-A" not to print th

Re: [tcpdump-workers] 3.9.1 -A flag broken

dean gaudet wrote: heheh cool, you seem to have come to the same conclusions as me... and i've got a regression test at http://arctic.org/~dean/patches/tcpdump-3.9.1-test-print-flags.patch i tried posting this earlier but i exceeded the 40k posting limit. I guess that explains why *neither*

Re: [tcpdump-workers] detecting libpcap 0.9

Romain Francoise wrote: It's not too late to release 0.9.2 with these API changes and encourage people not to use 0.9.1... ...assuming that we do it before some {Linux distribution, flavor of BSD, etc.} puts 0.9.1 into a release that lasts for N months before the next release, with 0.9.2, co

Re: [tcpdump-workers] tcpdump 3.9.1 under Windows

Loris Degioanni wrote: There is an issue compiling 3.9.1 in Windows. The problem is that my last patch to win32\prj\windump.dsp (2005/6/4) was not propagated to the tcpdump_3_9 branch, Most of us checking in changes were checking them into both branches, so we might have missed a change check

Re: [tcpdump-workers] libpcap and signals

Luis Monge wrote: I have a program that makes a live capture using pcap_loop. I also send a signal to that program (at midnight) and I catch that signal. My question is if the code I have inside the signal-catching function can be interrupted by the treatment of more packets (in pcap_loop). "In

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

to worry about byte order.) If by "big-endian values" you mean that, for example, 127.0.0.1 would have the value 0x7f01, no, you don't convert that with "ntohl()": Guy-Harris-Computer.local$ tcpdump -d 'ip dst host 127.0.0.1 and icmp[20:4] == 0x7f01&#x

Re: [tcpdump-workers] 3.9.1

Romain Francoise wrote: The CHANGES file in libpcap-0.9.1.tar.gz is... strange: ... Looks like the entry got mangled. The main branch doesn't have the mangled entry for May 27th, and is otherwise identical (other than the RCS header). - This is the tcpdump-workers list. Visit http

Re: [tcpdump-workers] pcap_dump error checking

Mark Ellzey Thomas wrote: Recently I have been wanting for pcap_dump to make me aware of any issues with writing to a file (a full disk). Are there any issues with changing pcap_dump from void to size_t? It changes the ABI of the function, requiring a major version number change to libpcap.

Re: [tcpdump-workers] detecting libpcap 0.9

Michael Richardson wrote: If it happens this week, I'm fine with that. OK, I'll check those changes in again this week. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] tcpdump 3.9.1 under Windows

Speaking of x.9 changes, if we're going to be doing x.9.2 soon to fix various problems, should I also make pcap_fopen_offline(), pcap_file(), pcap_fileno(), pcap_dump_fopen(), and pcap_dump_file() UN*X-only, as per the discussions about the issues with different flavors of MSVC++'s C libraries

Re: [tcpdump-workers] [Libpcap] Endianess and memory alignment

On Jul 7, 2005, at 4:37 PM, Cyril wrote: [iBook] Running what OS? Mac OS X (Mach kernel + Darwin). (...+all the frameworks, apps, Finder, etc. - but those aren't relevant to this particular issue.) Oks. So, BPF/LSF filter assumes that multi-byte values are in network byte order (ie b

Re: [tcpdump-workers] 3.9.1 -A flag broken

Michael Richardson wrote: Now, we need to commit the fix :-) I took that as an indication that I should check in the patch whose URL I sent to the list; I've checked it into the main and x.9 branches. There's also the other issue I mentioned: However, I also noticed that, while "-x" suppres

Re: [tcpdump-workers] about libpcap

On Jul 7, 2005, at 7:45 PM, hong liu wrote: Hello, I am using libpcap library to capture ip data from data link. I am wondering if there is a way to time out reading a packet from data link. For example, if there is no data coming in 1 second, timer times out and process will do other thi

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 5, 2005, at 9:46 PM, dean gaudet wrote: i also think the 3.9 behaviour needs some slight modifications, so i'vemade two changes on top of your patch Guy. Well, on top of one of the versions of my patch; it's not the version that got checked in. (I did the original versi

Re: [tcpdump-workers] about libpcap

Cyril wrote: And if the system can't use select() *and* the packet capture mechanism doesn't support a timeout ? The only UN*X systems I know of where select() can't be used are FreeBSD 4.3 and 4.4 (due to BPF deficiencies fixed in 4.5); OS X 10.4[.x] (due to select() not working o

Re: [tcpdump-workers] about libpcap

Matthew Luckie wrote: Can you define the behaviour of 'not work' with BPF on tiger? "Not work" as in "if you select on a BPF device and nothing else, you will only wake up when the select timeout expires; the store buffer getting transferred to the hold buffer won't trigger a wakeup". I us

Re: [tcpdump-workers] about libpcap

Guy Harris wrote: "Not work" as in "if you select on a BPF device and nothing else, you will only wake up when the select timeout expires; the store buffer getting transferred to the hold buffer won't trigger a wakeup". Actually, it might work for select(), alth

Re: [tcpdump-workers] 3.9.1 -A flag broken

On Jul 6, 2005, at 1:56 PM, Guy Harris wrote: So presumably "-X" should suppress the "print_default()" calls in link-layer printers (i.e., the if (!xflag && !qflag) print_default(...); calls). I'll look at doing that, unless somebody objects. I&

Re: [tcpdump-workers] mbuf leaks with tcpdump on netbsd

Pavan Mirla wrote: After I use tcpdump to set my interface to promiscuous mode I se that my mbufs are getting exhausted.I later get the errot "mlcpool reached it's limit, increase NMBCLUSTERS size. " netstat -m shows me multiple calls to protocol drain routines.I am using netBSD version 1.6. Ca

Re: [tcpdump-workers] complete struct for tcp_header

Thinh Ho wrote: Is there a struct for the options field of tcp_header? No. That field is variable in both length and contents, so there can't be a C-language data structure for it (and I don't know whether any language has a concept of "data structure", in the sense in which it's used in la

Re: [tcpdump-workers] FreeBSD 5.4 & BIOCSRTIMEOUT & pcap_open_live()

Richard Huddleston wrote: Freshly installed FreeBSD 5.4. New user of FreeBSD. pcap_open_live() fails with a BIOCSRTIMEOUT: Invalid argument pcap_open_live( device, BUFSIZ, 1, -1, errbuf ) itimerfix() in the 5.4 kernel does int itimerfix(struct timeval *tv) { if (tv->tv_sec < 0

Re: [tcpdump-workers] 0.9.2/3.9.2

Michael Richardson wrote: Any objection to 0.9.2 going out in the next 20 hours? At this point, I don't see anything in the CVS tree that I think needs any changes. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] FreeBSD 5.4 & BIOCSRTIMEOUT & pcap_open_live()

On Jul 11, 2005, at 1:03 PM, Richard Huddleston wrote: Just referencing Tim Carsten's pcap doc: "...to_ms is the read time out...0 sniffs until an error occurs; -1 sniffs indefinitely)." I *really* need to sit down and edit that document - and incorporate Nathan Jennings' sniffex.c into

Re: [tcpdump-workers] complete struct for tcp_header

On Jul 12, 2005, at 3:42 AM, Thinh Ho wrote: Thanks for your reply! Extracting the data is where I am stuck... The struck of option is below: typedef struct option { byte byte1; byte byte2; byte byte3; } option; An option might have fewer than, or more than, three bytes. For that reason, ne

Re: [tcpdump-workers] FreeBSD 5.4 & PCAP: blocked read() on pcap_lookupnet()

Richard Huddleston wrote: (gdb) where #0 0x280ee6fb in read () from /lib/libc.so.5 #1 0x28090c57 in pcap_lookupnet () from /usr/lib/libpcap.so.3 #2 0x28091adb in pcap_loop () from /usr/lib/libpcap.so.3 GDB is buggy, it appears, and printed a bogus stack trace; pcap_loop() doesn't call pcap

Re: [tcpdump-workers] FreeBSD 5.4 & PCAP: blocked read() on pcap_lookupnet()

Sam Pierson wrote: This is unavoidable, as the problem lies within FreeBSD, correct? To what does "this" refer? It's an intended feature that a zero timeout will wait until "enough" packets arrive, so if you're not in non-blocking mode, it is, indeed, "unavoidable" that a read will block un

Re: [tcpdump-workers] FreeBSD 5.4 & PCAP: blocked read() on pcap_lookupnet()

Sam Pierson wrote: What I meant was that in a situation where you send a single packet, you can't pick it up as soon as it comes, you have to wait for some other timeout value that you supply... the problem is that it only has a time resolution of 1ms, so for applications that depend on a finer

Re: [tcpdump-workers] print-slow.c

Loris Degioanni wrote: Some genius had the idea of adding a new file (print-slow.c) to the repository few hours before the x.9.2 release, without at least trying to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile under Windows (even if it used to compile the night before t

Re: [tcpdump-workers] Link-layer hex value

Costas Djouvas wrote: I am trying to get a packet in hex. Though, I cannot get the link layer part of the packet in hex. I have read some previous discutions in the list but nothing helped. Can anyone send me the command that I have to use in order to do that. Costas P.S Failed attemps tcpdu

Re: [tcpdump-workers] print-slow.c

On Jul 13, 2005, at 9:50 AM, Loris Degioanni wrote: Yes, in a genera way, we should a a pre-release building (and possibly testing?) procedure, carried on by one person (or a limited group of people) after the CVS has been locked. Note that this procedure needs to include at least one pers

Re: [tcpdump-workers] 64-bit pcap timestamp problems

Phil Wood wrote: I scanned through an ethereal-dev list of Auguest 1999 about 64-bit pcap timestamp problems. It appears that the consensus was such that pcap files written on 64 bit machines will not be readable on 32 bit machines and arsy-varsy. That was the consensus at the time in etherea

Re: [tcpdump-workers] lpcap not capturing non-accepted connections?

[EMAIL PROTECTED] wrote: I found out the problem, for some reason it wasn't sniffing localhost traffic, If by "localhost traffic" you mean traffic being sent from the machine to itself, the reason is that, on most if not all OSes, that traffic gets "wrapped around" internally to the machine b

Re: [tcpdump-workers] Variable length LLC headers

Mike Kershaw wrote: I've been working on bringing the radiotap headers to Linux so that we'll finally have a kernel-level multi-platform consistent way to get signal data on wireless cards. Well, it'd also need to be brought to the Aironet driver on the BSDs as well, to complete that process.

Re: [tcpdump-workers] new bug in tcpdump

Martin Stransky wrote: Hello, there is a new bug, buffer overflow, it's in 3.9.3 too. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164227 OK, I've checked in (a variant of) Ulrich's fix - but, as I noted in that bug, I'm not sure how a string could've been long enough to overflow t

Re: [tcpdump-workers] misprinting of GRE tunneled packets on NetBSD

Gert Doering wrote: The effect is quite weird - with "-i", it will not dump, but exit immediately, printing an empty message: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -i gre0 tcpdump: WARNING: gre0: no IPv4 address assigned tcpdump: [EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU

Re: [tcpdump-workers] Variable length LLC headers

Mike Kershaw wrote: Well, yes. :) I still have to get my patches accepted to the ieee80211 branch, merged into the kernel, and then all the driver patches done and accepted. It's a step in the right direction tho. If you're working on the FreeBSD Aironet driver, you might want to look at th

Re: [tcpdump-workers] Variable length LLC headers

Mike Kershaw wrote: Sorry, I'm only messing with the linux stuff at the moment, While you're doing that, could you beat up on the driver teams to get them to adopt the same APIs for turning on monitor mode and setting the channel? There's a whole bunch of different commands (and presumably

Re: [tcpdump-workers] Variable length LLC headers

Mike Kershaw wrote: I've been developing a database of cards based on the iwpriv fingerprints. So far, the method seems to be sound. I hope to use that to map sources automatically inside Kismet to the kismet 'specialty' sources. As drivers evolve, I should only need one standard source under

Re: [tcpdump-workers] proxy connection tag?

noc ops wrote: I'm looking for any help in detecting (if possible) *outgoing* client request (see below flow) header information for transparent proxies via some sort of pattern match. Maybe proxy connection tag? Is it doable? So far my search has turned up negative. As noted in the Ethereal t

Re: [tcpdump-workers] version number pb libpcap093 and tcpdump393

rmkml wrote: x.9.2 or x.9.3 ? It's 0.9.3/3.9.3 - the VERSION files weren't updated. They were updated since then, so if subsequent 0.9.x/3.9.x releases are made, they'll identify themselves as 0.9.4/3.9.4. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscri

Re: [tcpdump-workers] [PATCH] DCCP support

27; print-dccp.c:57:2: #error "Adjust your defines" Unfortunately, the suggestion made by the errors doesn't help: Guy-Harris-Computer.local$ ls -l /usr/include/asm/byteorder.h ls: /usr/include/asm/byteorder.h: No such file or directory Guy-Harris-Comp

Re: [tcpdump-workers] Filter on offline pcap

cycl0ne dude wrote: what i know is, filter only works in filtering traffic on interface only, but how about on offline pcap file? pcap_setfilter() works on a pcap_t that you've opened with pcap_open_offline() the same way it works on a pcap_t you've opened with pcap_open_live(). - This is t

Re: [tcpdump-workers] Strange PCAP filter compilation with certain

Jan C. Nordholz wrote: init_linktype() sets off_linktype to -1 (not present), and off_nl (and _nosnap) to 0 (packet starts immediately), which is fine. But gen_proto() insists that for Q_IP, regardless of the current DLT, the link level should be inspected: ...which is also fine; "gen_linktype

Re: [tcpdump-workers] Strange PCAP filter compilation with certain

Guy Harris wrote: There should probably be another way of indicating "we're now parsing MPLS-encapsulated stuff", e.g. a Boolean flag. I'll look at implementing that (and put it into the x.9 branch). I've checked into the main and x.9 branches a change to do t

Re: [tcpdump-workers] Strange PCAP filter compilation with certain

Guy Harris wrote: I've checked into the main and x.9 branches a change to do that (with a Boolean flag). ...followed by a change that checks the label stack level, instead (the Boolean wasn't necessary). - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] Strange PCAP filter compilation with certain

Jan C. Nordholz wrote: Which one do you mean - the one I took the gdb trace and the output from? Sure, no problem, but as I said, it's basically a 10-liner, if you don't count the #include statements in... ;-) I was even too lazy to include a reverse translator numeric->symbolic instruction code

Re: [tcpdump-workers] not net problem

On Aug 8, 2005, at 10:40 AM, Black, Michael wrote: What I want is for 10.4.4 to see ALL non-10.4.4 traffic (like a honeypot). Seems like a reasonable request to say "not net 10.4.4" If by "10.4.4 traffic" you mean "traffic from an address on the 10.4.4 network to an address on the 10.4.4 ne

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

On Aug 8, 2005, at 3:43 PM, Albert Chin wrote: I've built libpcap-0.9.3 and tcpdump-3.9.3 on HP-UX 11i: # tcpdump tcpdump: no suitable device found libpcap-0.8.3/tcpdump-3.8.3 works fine. How can I help debug this? What happens if you change "add_or_find_if()" in "inet.c" in libpcap so

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

Albert Chin wrote: With the patch below, ...which is exactly the change I intended. I get: # tcpdump tcpdump: Just "tcpdump:", and nothing else? Not even a message saying it's starting a capture? That's weird. Is it dumping core, exiting immediately, or continuing to run but not

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

On Aug 8, 2005, at 8:57 PM, Albert Chin wrote: Nothing. Even if I specify the interface: # tcpdump -i lan0 tcpdump: # echo $? 1 OK, so it appears it's not a problem in the code to enumerate interfaces. What does "tcpdump -D" print? # tcpdump 1.lan0 2.lo0 OK, so it's at least

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

Albert Chin wrote: Nothing. Even if I specify the interface: # tcpdump -i lan0 tcpdump: # echo $? 1 Try applying the attached patch to "pcap-dlpi.c", rebuild, rebuild tcpdump, and try again. Index: pcap-dlpi.c === RCS f

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

Guy Harris wrote: Albert Chin wrote: Nothing. Even if I specify the interface: # tcpdump -i lan0 tcpdump: # echo $? 1 Try applying the attached patch to "pcap-dlpi.c", rebuild, rebuild tcpdump, and try again. Don Ebright sent me mail noting another possible problem. He

Re: [tcpdump-workers] Pings fail unless tcpdump is watching both

Cian Masterson wrote: Can anyone tell me what changes/hooks tcpdump puts into the stack that might lead to this behaviour? Tcpdump (or other programs such as snort, Ethereal, etc.) just call libpcap to do the capturing. Libpcap doesn't make modifications to the networking code path (except

Re: [tcpdump-workers] Minor linux radiotap patch

Mike Kershaw wrote: Since I'm working more on pushing the radiotap patches into the kernel, heres a super-tiny patch to libpcap to properly detect the link type. This isn't yet an official arphrd, but madwifi also uses it for radiotap output on linux and I expect we'll have it official soon. If

[tcpdump-workers] Radio headers and snapshot lengths

Speaking of radiotap, the current tcpdump snapshot length defaults of 68 (for tcpdump without IPv6 support) and 96 (for tcpdump with IPv6 support) don't correspond to the same amount of payload above the "link layer" on all network types. For most network types, the difference is small - if we

Re: [tcpdump-workers] Minor linux radiotap patch

Mike Kershaw wrote: No, it's the next in line, and madwifi uses it as well for radiotap on linux. OK, I've checked the patch into the main and x.9 branches. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

Albert Chin wrote: Missing a closing '}'? Yes. This patch works. Thanks! I've checked it in. Does it also fix the problems with Ethereal? If not, what happens if you try to run more than one tcpdump at the same time? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

On Aug 16, 2005, at 4:29 PM, Ebright, Don wrote: I have some information regarding your question to Albert Chin. If I try to run more than one tcpdump at the same time on HP-UX, it doesn't work for me. ... It appears that the second pcap_open_live() fails with one of two errors

Re: [tcpdump-workers] Pings fail unless tcpdump is watching both

Cian Masterson wrote: In case anyone else is experiencing similar behaviour with their driver (or in case I'm trawling this list in a few years time wondering how I fixed it) the problem was with skb->tail not being updated properly in my code on the receive side. Six lashes with a wet cabbag

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

On Aug 17, 2005, at 2:24 PM, Albert Chin wrote: To be more specific, "future release of the DLPI provider". So, I think a LAN patch could correct the problem. In PHNE_25388, we find: ( SR:8606225662 CR:JAGad94736 ) HP-UX only allow one unbound promiscuous stream per interface, when trying

Re: [tcpdump-workers] 3.9.3 on HP-UX 11i

On Aug 17, 2005, at 2:16 PM, Albert Chin wrote: Capture->Interfaces->Capture (on lan0 interface) results in: The capture session could not be initiated (recv_ack: promisc_phys: UNIX error - Device busy). Please check to make sure you have sufficient permissions, and that you

[tcpdump-workers] 0.9.4/3.9.4 release?

I've checked in some libpcap fixes for HP-UX and Mike Kershaw's support for radiotap in Linux, and Hannes has checked in some changes in both libpcap and tcpdump for additional Juniper link-layer types. Unless there are some other fixes in the pipeline, or some tcpdump vulnerabilities not y

Re: [tcpdump-workers] Error on launching tcpdump

On Aug 19, 2005, at 3:03 PM, Ronald SURAY wrote: How can I resolve this problem? Try building and installing the "Current tar files" versions of libpcap and tcpdump; there are some HP-UX problems fixed in them. (They will, at some point, be released as 0.9.4 and 3.9.4; earlier 0.9.x re

Re: [tcpdump-workers] Error on launching tcpdump

On Aug 22, 2005, at 2:30 PM, Ronald SURAY wrote: Where can I find the releases of libpcap 0.9.4 and tcpdump 3.9.4 ? When they are released, you will be able to find them on www.tcpdump.org. They have not been released yet, however, so you currently cannot find them anywhere. - This is

Re: [tcpdump-workers] sniffex.c - libpcap example code proposal

Nathan Jennings wrote: Thanks for the help and suggestions. They are implemented in the updated attached "sniffex.c" source file, v0.1.1. I've checked that in to the Web site, with some changes, and updated the tutorial to refer to it (I changed both the tutorial code and sniffex.c code to r

Re: [tcpdump-workers] Missing libpcap.so

David Rosal wrote: I'm trying to use an application that needs to be linked dinamically against libpcap, so it needs libpacp.so to be installed. I've downloaded libpcap-0.9.3 and installed it, but it only provides the static library libpcap.a. I've tried also adding --enable-shared to config

Re: [tcpdump-workers] Magic number for libpcap file format with nsec resolution?

On Aug 29, 2005, at 3:18 AM, Ulf Lamping wrote: Could you provide me with a magic number for the libpcap file format I've outlined some time ago? It will simply be the same format as the common libpcap format, except that the lower 32bits of the timestamp field are nsec resolution instea

Re: [tcpdump-workers] Spelling fixes

On Sep 2, 2005, at 1:42 PM, Michael Richardson wrote: "Romain" == Romain Francoise <[EMAIL PROTECTED]> writes: Romain> Can we merge these spelling fixes (courtesy of Michael Romain> Shields <[EMAIL PROTECTED]>) for 3.9.4? Go ahead, pull up to branch. They're not checked into the

Re: [tcpdump-workers] Spelling fixes

Romain Francoise wrote: Can we merge these spelling fixes (courtesy of Michael Shields <[EMAIL PROTECTED]>) for 3.9.4? Checked into the main and x.9 branches. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] [PATCH] DCCP support

Ian McDonald wrote: Please find attached a reworked patch which I believe addresses all of Guy's original concerns and also adds options processing and other enhancements. "dh_end" still isn't being used, as per my original comment: In addition, there are no TCHECK(), TCHECK2(), TTEST(), or

Re: [tcpdump-workers] libpcap: raw write to ethernet header not working under Solaris?

(Blah blah blah wrong From: address bounce blah blah blah fool the duplicate message detector into not bouncing this retransmission from the right address blah blah blah.) On Sep 6, 2005, at 1:45 AM, fanci wrote: So, libpcap is passing "0" for the "sap" parameter to invoke a DLPI_BIND_REQ.

Re: [tcpdump-workers] libpcap: raw write to ethernet header not working

fanci wrote: As for my workaround, I didn't really hardcoded 88-8e in libpcap; instead I modified a bit in pcap_open_live() to let it parse the "char *ebuf" parameter in "$SAP=%d" format. If the parse succeeds, then libpcap would take the user-supplied number for SAP. Otherwise, it uses 0 for th

Re: [tcpdump-workers] libpcap: raw write to ethernet header not working

On Sep 7, 2005, at 5:27 AM, fanci wrote: That's really complicated @_@ Yes, that's what happens if you have more than one e-mail address. One thing to remind... actually you don't have to quote "Broadcom"'s name in the manpage if you're to indicate the SAP- overwriting problem... I

Re: [tcpdump-workers] Amateur radio protocols

Richard Stearn wrote: Has there been any development effort in the past on any of the above protocols? The only thing I was able to find from a quick Google was a patch at http://www.tux.org/pub/net/ip-routing/lbl-tools/tcpdump-tcpdump.org-ss991030.dif.gz which appears to inc

Re: [tcpdump-workers] Amateur radio protocols

Richard Stearn wrote: A cursory look at the print-ax25 from that patch indicates that some of the support is missing, e.g. ARP printing for ax25 is not in the current tcpdump.org tcpdump. So somewhere between tcpdump 3.4 & 3.9 the ax.25 support was taken out. That presumes that there *was* sup

Re: [tcpdump-workers] CAN-2003-1029 CAN-2003-0989 etc.

Florian Weimer wrote: Have these vulnerabilities been fixed in the main tcpdump code? I can't answer about "etc." without knowing what's included in "etc." (is it all CVE items for tcpdump?), but the two you mention are, as far as I know, fixed in the top of the main and 0.9.x branches (I che

Re: [tcpdump-workers] [PATCH] small cross-compile fix

David Smith wrote: A problem with cross-compiling tcpdump is that it isn't possible to override the finding the location of the SSLeay libraries/headers. The small attached patch fixes this. So how do you override that? I don't see where Xprefix is getting set, other than in that code. - Th

Re: [tcpdump-workers] [PATCH] DCCP support - revised

Ian McDonald wrote: Please find attached a slightly revised patch to tidyup a bug with seqno/ackno processing. Checked into the main and x.9 branches. I got rid of the dh_end variable, and added RCS IDs. I gave you and Arnaldo credit in the CREDITS file; should I put Yoshifumi Nishida in

Re: [tcpdump-workers] [PATCH] DCCP support - revised

(Noise inserted here to trick the duplicate-message dissector into letting this message pass; the original was sent from the wrong address.) Ian McDonald wrote: Thanks for putting this in - please credit Nishida-san as well. Done. - This is the tcpdump-workers list. Visit https://lists.sand

Re: [tcpdump-workers] [PATCH] small cross-compile fix

David Smith wrote: At first I tried to do this the "right" way of using a cached configure variable, but the ac_cv_ssleay_path code is a bit too complicated for that, since it actually sets two variables - ac_cv_ssleay_path and incdir. So, this Xprefix change is a bit of a hack, but not *too* g

Re: [tcpdump-workers] [PATCH] small cross-compile fix

On Sep 21, 2005, at 2:13 PM, David Smith wrote: OK, here's a cleaner solution. It does this the "right" way using a cached config variable. So should that be applied to the configure.in *before* your previous patch? If so, does it mean that there's no need to have the user say where th

Re: [tcpdump-workers] libpcap based timestamp in linux

On Sep 23, 2005, at 8:01 PM, Manish Jain wrote: My question is regarding when does libpcap timestamp the packet - when the packet arrives in the kernel from NIC or when the packet is read by application in user space? Libpcap reads the time stamp when it reads the packet. However, the ti

Re: [tcpdump-workers] post-capture BPF filtering (feature proposal)

Sebastien Raveau wrote: I could always make a separate capture just to be able to forward all traffic while my first capture is filtered, but I am not comfortable with that solution. This is why I am writing this feature proposal to this list: * possibility of registering a separate callback fu

Re: [tcpdump-workers] Minor patch to print-radius.c

[EMAIL PROTECTED] wrote: As far as I can see, print_vendor_attr() in print-radius.c doesn't account for the fact that the length field includes itself (1 byte) and type (1 byte), thus attempting to print 2 bytes too much when printing the ASCII text form of the Value field. Yes. However, while

Re: [tcpdump-workers] send packets

Vossie wrote: My opinion is that libpcap are not able to send packets, it can only capture it!!! I think you will agree if you have a look at "man pcap" Not if the output of "man pcap" mentions pcap_sendpacket() and pcap_inject(); those were added in libpcap 0.9.x. - This is the tcpdump-wor

<    1   2   3   4   5   6   7   8   9   10   >