Guy Harris wrote:
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
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
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
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
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, and therefore the CVS snapshot compiles, but 3.9.1
fails in print-dhcp6.c.
If you're planning to do a subrelease to fix the -A flag
Guy Harris <[EMAIL PROTECTED]> writes:
> 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
> aforementioned change.
It's not too late to release 0.9.2 with these API changes and encourage
people not to use 0.9.1.
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*
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" stuf
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
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
-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
-BEGIN PGP SIGNED MESSAGE-
> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
>> -BEGIN PGP SIGNED MESSAGE-
>>
>>
>>
>>> "dean" == dean gaudet <[EMAIL PROTECTED]>
>>> writes:
>>>
dean> the -A flag prints hex rather than ascii-only
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': - ++xfl
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':
-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 1
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
[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: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 af
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.
> | 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...
-
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
+++ tcpdump-3.9.1
-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
m
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 versio
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 shoul
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
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
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 = libnet_get_ipaddr4
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
* 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 thou
> > 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
> there are many of them.
IMHO thats cap
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
Hi all,
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 socket
32 matches
Mail list logo
