print the correct/absolute numbers instead and see that
this time they are the same.
regards
ronnie sahlberg
On Fri, Aug 20, 2010 at 9:15 AM, Andrej van der Zee
wrote:
> Hi,
>
>
>
>> const struct tcphdr * tcp_hdr = (const struct tcphdr *)(sp + ETHER_HDRLEN
>>> +
The "relative" numbers are not part of the packet/protocol.
The absolute ones are what the actual packets contain.
To get relative numbers you would need some code.
You basically need to keep a list of every single tcp connection you
see, based on ip:port - ip:port.
First time you see a TCP pack
const struct tcphdr * tcp_hdr = (const struct tcphdr *)(sp + ETHER_HDRLEN
+ IP_HL(ip));
This is surely wrong.
The size of the IP header is IP_HL(ip)*4 not IP_HL(ip)
On Fri, Aug 20, 2010 at 7:29 AM, Andrej van der Zee
wrote:
> Hi,
>
>
>
>>> static void handle_packet(unsigned char * ifile, con
treats these as "don't
check, probably checksum offload")
regards
ronnie sahlberg
On Wed, Apr 7, 2010 at 11:56 AM, Roy Smith wrote:
> I've got an application which listens for UDP (SNMP) data. We want to add a
> logging feature where every UDP packet that'
On Sat, Jul 25, 2009 at 5:29 AM, Guy Harris wrote:
>
> On Jul 21, 2009, at 11:12 PM, Guy Harris wrote:
>
>> On Jun 23, 2009, at 7:34 PM, Mike Kershaw wrote:
>>
>>> (This now actually hits my error catcher where 100 fd highs in a row
>>> with no packets triggers a shutdown of the source, since libpc
On Tue, Feb 24, 2009 at 8:17 AM, Oliver Zheng <
mailinglists+tcpd...@oliverzheng.com
> wrote:
> Thanks for the response Aaron.
>
> On Mon, Feb 23, 2009 at 11:34 AM, Aaron Turner
> wrote:
> > In my experience, sending packets on eth0 causes the packet to bypass
> > the TCP/IP stack and be sent out
On Tue, Dec 23, 2008 at 8:18 AM, Matthias Wenzel wrote:
> Guy Harris wrote:
>>
>> On Dec 22, 2008, at 1:51 AM, Matthias Wenzel wrote:
>>
>>> we have a set of opensource tools that read and write pcap files from/to
>>> DECT devices. The SW will go public still this year. We're working with
>>> both
On Tue, Dec 9, 2008 at 7:40 PM, David Gibson
<[EMAIL PROTECTED]> wrote:
> I've implemented a first cut at adding support to libpcap to capture
> from the Linux /dev/input/event* (evdev) devices. Draft patch is
> included below.
>
> However, I've realised there's a problem. Since it's an internal-
On Nov 7, 2007 12:54 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
> Harley Stenzel wrote:
> > On Nov 6, 2007 2:03 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
> >
> >>Any thoughts as to how to deal with false checksum failure reports for
> >>outbound
> >>traffic being sniffed on a system with ChecKsum O
Do we really need 4 bytes to store the endpoint address in the header?
Without changing the size of the header,
what about splitting the four bytes of endpoint address into two 16 bit integers
one of them is endpoint address and the other is which usb interface
the capture was taken on ? the us
Since only 4 such capture files are known to exist as of today, it is
probably better to do the change sooner than later.
Paolo,
you will also need to generate new example captures for the wireshark
wiki as well as a patch to update wireshark asap and if this pcap
patch is accepted.
The wireshar
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 actual usb
layer
but other frames might contain different comman
large segment offload (LSO)
can be easily detected by
TCP checksum==0and being incorrect
and that the segment is much larger than the normal mtu.
On 4/7/06, Guy Harris <[EMAIL PROTECTED]> wrote:
> Hannes Gredler wrote:
> > checked in - thanks for the submission - /hannes
> >
> > On Wed, Ja
The draft describes two different blocks for holding a captured packet:
Packet Block: it contains a single captured packet, or a portion of it.
Simple Packet Block: it contains a single captured packet, or a
portion of it, with only a minimal set of information about it.
I often work with very
Sometimes it would be nice to run a remote capture directly from a
pcap enabled tool such as ethereal.
Security would be a major issue. Also would buy in from pcap folks so that all
applications linking with pcap would gain the capability automagically.
Would wrapping the pcap API inside ONC-RPC
On Tue, 21 Sep 2004 10:38:27 -0400, Jefferson Ogata
[snip]
> > but in my code when I try to read the tcp sequence numbers, I get very
> > odd values of sequence number. Here follows the code snippet I use to
> > read sequence number. The values I get do not correspond to the ones I
> > read using
man tethereal
feed the capture through tethereal and use the flags
-R "not frame" -z conv,tcp
the -R flag is to stop tethereal from printing any packet summaries to stdout,
-z flag is to make tethereal to print a table of all TCP sessions to
stdout after the entire capture file has been parsed.
> > Given all the desirable options people are looking for in this, and the
> > need for future growth, I think we should seriously consider an
> > XML-based format. Besides making it easy, format-wise, to include many
> > optional features and types of metadata, programs could also embed
> > decod
- Original Message -
From: "Jefferson Ogata"
Sent: Wednesday, April 14, 2004 6:29 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> Ronnie Sahlberg wrote:
> > I dont see really the benefit from using XML at all.
>
> Usually I find that people who
- Original Message -
From: "Stephen Donnelly"
Sent: Wednesday, April 14, 2004 12:38 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> > Yes, fully fledged decoded captures would use a lot of extra disk, but a
> > raw no-frills capture could be recorded with maybe only 50% or
- Original Message -
From: "Michael Richardson"
Sent: Tuesday, April 13, 2004 12:58 AM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> -BEGIN PGP SIGNED MESSAGE-
>
>
> > "Darren" == Darren Reed writes:
> Darren> Today, some people might want MD-5, others SHA-1
- Original Message -
From: "Michael Richardson"
Sent: Tuesday, April 13, 2004 12:52 AM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> -BEGIN PGP SIGNED MESSAGE-
>
>
> > "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
> >> Oh, I forgot.
> >>
> >> An
- Original Message -
From: "Loris Degioanni"
Sent: Monday, April 12, 2004 2:56 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> > I'd prefer a general flag field, which would include a direction
> > indication (which might also include, for received packets, an
> > indicatio
- Original Message -
From: "Loris Degioanni"
Sent: Monday, April 12, 2004 2:55 PM
Subject: Re: [tcpdump-workers] Proposed new pcap format
> Essentially, what you propose is that the SHB CONTAINS a section rather
than
> MARKING its beginning. The SHB, in fact, as any other block, includ
Oh, I forgot.
Another useful thing to have is an option for the packet block where one
would store
a reasonably collission-safe 8-byte hash of the packet data.
This would make it much easier to compare two different capture files to see
where packets are missing etc.
-
This is the tcpdump-worker
Hi list,
Im pretty new to this discussion (only joined so i could participate in this
discussion)
I have looked at http://www.tcpdump.org/pcap/pcap.html
and have some comments.
3.1 "this makes the parsing of the file slower but it permits to append
several capture dumps at the same file"
-
26 matches
Mail list logo
