On 7/4/05, Mike Kershaw [EMAIL PROTECTED] wrote:
Ah, in my case, restarting the remote capture units is highly
undesirable/difficult/annoying to the users.
Ok, but that depends on the application. I think it would be nice to
support easy restarting of remote capture processes, especially if
* Guy Harris:
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
Guy Harris wrote:
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.
A format such as
Hello,
I'm writing a tiny utility named YAT (Yet Another Traceroute). I have
a few
questions.
1) Libnet functions return big endian local (src_ip) and destination
(dst_ip)
IPv4 addresses used in UDP probes.
void
set_ip(const char *host)
{
src_ip =
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
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
Florian Weimer wrote:
But it isn't, the behavior has changed. Otherwise I wouldn't have
this trouble. 8-)
The behavior changed, but that's a bug fix. Not all OS vendors consider
a bug fix to be something that breaks binary compatibility to an extent
that the library's *major* version
Guy Harris [EMAIL PROTECTED] writes:
If the interface doesn't change (so that the new version of the library
is binary backwards-compatible with the old version, even if it's not
forwards-compatible, i.e. new APIs were added or new capabilities were
added to existing APIs), the version
-BEGIN PGP SIGNED MESSAGE-
Thanks to Ken Bantoft, who summarized the Changes between 3.8 and 3.9,
we now have a release.
It is signed, etc.
Whoever it was that has the freshmeat login, please update stuff.
$Header: /tcpdump/master/htdocs/tcpdump-changes.txt,v 1.8 2005/07/05 21:23:44
the -A flag prints hex rather than ascii-only... i think the following
patch is necessary.
-dean
p.s. i submitted a bug/patch but it's been suggested that nobody monitors
the sourceforge bug/patch thingers :)
--- tcpdump-3.9.1/tcpdump.c 2005-07-05 14:09:05.0 -0700
+++
| API addition: typedef direction_t is new
| is now defined at /usr/include/pcap.h:123:
| typedef enum
| {
| D_INOUT = 0,
| D_IN = 1,
| D_OUT = 2,
| } direction_t;
shouldn't that be pcap_direction_t? otherwise i can imagine some
namespace collision occuring...
-dean
-
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 backed out the
[I can't speak english fluently. Sorry :-(]
Guy :
No, they are not. What you get is what's on the network, and if
you have a 14-byte Ethernet header, for an IP datagram, for
example, the IP datagram starts *immediately* after the Ethernet
header - no padding.
Yes. The question was
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
-BEGIN PGP SIGNED MESSAGE-
dean == dean gaudet [EMAIL PROTECTED] writes:
dean the -A flag prints hex rather than ascii-only... i think the
dean following patch is necessary.
dean case 'A': - ++xflag; ++Xflag; ++Aflag; break; -
Guy added that line 19-Dec-2002.
On Tue, 5 Jul 2005, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
dean == dean gaudet [EMAIL PROTECTED] writes:
dean the -A flag prints hex rather than ascii-only... i think the
dean following patch is necessary.
dean case 'A': - ++xflag;
On Jul 5, 2005, at 6:29 PM, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
dean == dean gaudet [EMAIL PROTECTED]
writes:
dean the -A flag prints hex rather than ascii-only... i think the
dean following patch is necessary.
dean case 'A': - ++xflag;
-BEGIN PGP SIGNED MESSAGE-
dean the -A flag prints hex rather than ascii-only... i think the
dean following patch is necessary.
dean case 'A': - ++xflag; ++Xflag; ++Aflag; break; -
oh, a regression test would have shown this.
Can you submit a patch done with 3.8.x
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 the \n\t stuff before the last
bufferful of ASCII data; I
On Tue, 5 Jul 2005, Guy Harris wrote:
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 the \n\t stuff before the
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
21 matches
Mail list logo
