Hannes,
> | I don't feel that tcpdump output should be frozen forever; some changes are
> | appropriate. But the changes I've seen have seemed indiscriminate. Again,
> | why put a comma after the TCP flags? Why reorder the TCP fields relative
> | to one another? Why change the way 'cksum' is sp
Xavier Brouckaert wrote:
How do you do that ? Is there a tool for this ? editcap cannot remove a
single broken packet.
No? Assuming it doesn't choke on the bogus packet, and you know its'
sequence number, something like 'editcap <#
of bogus packet>' should do it...
--
Regards
On Jun 25, 2004, at 4:34 PM, Xavier Brouckaert wrote:
Could it happen because there are several applications using libpcap
at the same time ?
Not if they're writing to different files. There's no data that would
be shared by all libpcap-using processes on a given machine.
If multiple applicatio
Jefferson Ogata wrote:
This usually happens to me when I have a disk full condition while
capturing. Captures stop getting flushed to disk until some space is
cleared, and when they restart a header is no longer in the right place
because a lot of buffered data was lost.
I have 39Gb left so I do
On Jun 25, 2004, at 2:21 PM, Christian Kreibich wrote:
an XML based tcpdump output would
be great in the long term -- it would certainly eliminate a lot of
parsing ambiguity.
Yes - the problem with the traditional UNIX "the output of one program
should be usable as input to another program" idea i
On Fri, Jun 25, 2004 at 02:21:24PM -0700, Christian Kreibich wrote:
| Hi,
|
| On Fri, 2004-06-25 at 02:04, Hannes Gredler wrote:
| >
| > i am a believer that networking dissectors should print data in the order
| > they arrive ... header information comes before ip adresses, right ?
| > the IMHO b
eddie,
On Fri, Jun 25, 2004 at 09:34:47AM -0700, Eddie Kohler wrote:
| These changes should not have been implemented globally, without some flag
| or option to preserve the old behavior. Such a flag should be added.
i had to make a call between polluting the code base further with
new flags
Hi,
On Fri, 2004-06-25 at 02:04, Hannes Gredler wrote:
>
> i am a believer that networking dissectors should print data in the order
> they arrive ... header information comes before ip adresses, right ?
> the IMHO bad bad practise of printing header information (old format)
> at the end of the pa
> Despite all my whining, it is great that tcpdump is being worked on again, and I
> appreciate the effort that you've put into it. I just wish there was an option
> that would preserve the old behavior. (Or, even better, an option that would
> *give* the new behavior.) I think a lot of peopl
Xavier Brouckaert wrote:
I have several corrupted pcap files. The error message looks like this
when I try to reread the trace with tethereal :
This usually happens to me when I have a disk full condition while capturing.
Captures stop getting flushed to disk until some space is cleared, and when
Despite all my whining, it is great that tcpdump is being worked on again, and I
appreciate the effort that you've put into it. I just wish there was an option
that would preserve the old behavior. (Or, even better, an option that would
*give* the new behavior.) I think a lot of people would
Hannes,
These changes should not have been implemented globally, without some flag or
option to preserve the old behavior. Such a flag should be added.
> i am a believer that networking dissectors should print data in the order
> they arrive ... header information comes before ip adresses, right
-BEGIN PGP SIGNED MESSAGE-
Let me just say that I have been bit by the chances to tcpdump in
my own work. Fortunately, it is being compared against previous output
with diff, so updating is much easier.
For those that need to have in a digestable format, we need to have
another solution.
Hi,
I have several corrupted pcap files. The error message looks like this
when I try to reread the trace with tethereal :
$ tethereal -r asax_24_juin_13h47.cap -w asax_24_juin_13h47-2.cap
tethereal: "asax_24_juin_13h47.cap" appears to be damaged or corrupt.
(pcap: File has 536022498-byte packet
On Thu, Jun 24, 2004 at 10:56:09AM -0700, Eddie Kohler wrote:
eddie,
[ ... ]
| Similarly, it seems a mistake to put IP header information (tos, ttl, id,
| offset, flags, proto, length) before the addresses. This changes
| longstanding tcpdump practice and makes the output *less* readable, sin
CVS log entries from 24.06.2004 (Thu) 09:06:44 - 25.06.2004 (Fri) 09:06:46 GMT
=
Summary by authors
=
Author: guy
File: tcpdump/CREDITS; Revisions: 1.97, 1.87.2.8
File: tcpdump/pr
16 matches
Mail list logo
