Hi Ronnie,
Note:
> The relative numbers are not part of the TCP protocol.
> The relative numbers does not actually exist. Only the absolute
> numbers exist in the packets.
>
> Relative numbers are an invention inside tcpdump to make the printed
> numbers easier to read for humans.
>
>
>
Thank you
Note:
The relative numbers are not part of the TCP protocol.
The relative numbers does not actually exist. Only the absolute
numbers exist in the packets.
Relative numbers are an invention inside tcpdump to make the printed
numbers easier to read for humans.
Example:
Try deleting the first 10 pa
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
Hi,
> 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)
>>
>>
> Thank you very much! Now I do get the same seq and ack number for my app
> and tcpdump -vv.
>
>
Though
Hi,
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)
>
>
Thank you very much! Now I do get the same seq and ack number for my app
and tcpdump -vv.
Thanks,
Andrej
-
This i
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
On 08/19/2010 06:44 PM, Andrej van der Zee wrote:
Hi,
Hi Andrej,
Several others have already mentioned it -- tcpdump is using
relative sequence numbers to make it easier to read the output.
Large sequence numbers are perfectly valid (after all, they are
32-bit unsigned numb
Hi,
Hi Andrej,
>
> Several others have already mentioned it -- tcpdump is using relative
> sequence numbers to make it easier to read the output. Large sequence
> numbers are perfectly valid (after all, they are 32-bit unsigned numbers).
>
> Use the -S argument to tcpdump and you'll see tcpdump re
Hi Andrej,
Several others have already mentioned it -- tcpdump is using relative
sequence numbers to make it easier to read the output. Large sequence
numbers are perfectly valid (after all, they are 32-bit unsigned numbers).
Use the -S argument to tcpdump and you'll see tcpdump report large
Can you provide some examples of those "weird seq and ack numbers"?
Thanks for your reply.
With weird I meant different than obtained with "tcpdump -vv". There numbers
are much too high:
seq 101688001 ack 580300460
seq 103252140 ack 276497601
seq 101689793 ack 580300460
seq 101592513 ack 580
Hi,
Source port and dest number seem to be ok, so I guess this is not the
>> problem. Nevertheless, I tried the code below but it does not make a
>> difference. Why do I get those weird seq and ack numbers? I am really
>> stuck...
>>
>
> Can you provide some examples of those "weird seq and ack n
2:43 PM
To:
Subject: Re: [tcpdump-workers] tcp sequence and ack number with libpcap
On 08/19/2010 05:29 PM, Andrej van der Zee wrote:
Source port and dest number seem to be ok, so I guess this is not the
problem. Nevertheless, I tried the code below but it does not make a
difference. Why do I get those
On 08/19/2010 05:29 PM, Andrej van der Zee wrote:
Source port and dest number seem to be ok, so I guess this is not the
problem. Nevertheless, I tried the code below but it does not make a
difference. Why do I get those weird seq and ack numbers? I am really
stuck...
Can you provide some examp
Hi,
If I get "bad cksum 0 (->4327)!" for packets with "tcpdump -vv" like below,
do I have to take special measures to read fields like seq and ack from the
TCP header?
17:55:47.657974 IP (tos 0x0, ttl 128, id 13151, offset 0, flags [DF], proto
TCP (6), length 1420, bad cksum 0 (->4327)!)
172.
Hi,
>> static void handle_packet(unsigned char * ifile, const struct pcap_pkthdr
>> *
>> h, const u_char * sp)
>> {
>> const struct ip * ip = (struct ip *) (sp + ETHER_HDRLEN);
>> const struct tcphdr * tcp_hdr = (const struct tcphdr *)(sp + ETHER_HDRLEN
>> + sizeof(struct iphdr));
>>
>
> You a
Hi,
> I think you are performing your byte ordering conversion wrong. Seq and
> > Ack values are transmitted in network byte order so you need to perform
> > a "network to host long" conversion, and for that, you need to user
> > ntohl(), not htonl().
>
> On standard platforms with byte order 123
Hi,
On Thu, Aug 19, 2010 at 08:47:26PM +0200, Luis MartinGarcia. wrote:
>
> I think you are performing your byte ordering conversion wrong. Seq and
> Ack values are transmitted in network byte order so you need to perform
> a "network to host long" conversion, and for that, you need to user
> nto
On 08/19/2010 04:23 PM, Andrej van der Zee wrote:
> Hi,
>
> I am trying to get the TCP sequence and ack number of TCP packets. Somehow I
> get different values than "tcpdump -vv" does. The numbers are way too big
> all the time. Source and destination ports are just fine. Below the relevant
> code.
--
From: "Andrej van der Zee"
Sent: Thursday, August 19, 2010 7:23 AM
To:
Subject: [tcpdump-workers] tcp sequence and ack number with libpcap
Hi,
I am trying to get the TCP sequence and ack number of TCP packets. Somehow
I
get
From: Andrej van der Zee
Subject: [tcpdump-workers] tcp sequence and ack number with libpcap
To: tcpdump-workers@lists.tcpdump.org
Date: Thursday, August 19, 2010, 9:23 AM
Hi,
I am trying to get the TCP sequence and ack number of TCP
packets. Somehow I
get different values than "tcpdump -vv&q
Hi,
On Thu, Aug 19, 2010 at 11:23:39PM +0900, Andrej van der Zee wrote:
> I am trying to get the TCP sequence and ack number of TCP packets. Somehow I
> get different values than "tcpdump -vv" does. The numbers are way too big
> all the time. Source and destination ports are just fine. Below the r
instead of big-endian (network byte order), but I
see you use htonl in your code which is correct.
Try -S option with tcpdump to get "absolute" numbers.
Cheers,
mark...
--- On Thu, 8/19/10, Andrej van der Zee wrote:
> From: Andrej van der Zee
> Subject: [tcpdump-workers] tcp sequenc
Hi,
I am trying to get the TCP sequence and ack number of TCP packets. Somehow I
get different values than "tcpdump -vv" does. The numbers are way too big
all the time. Source and destination ports are just fine. Below the relevant
code. I studied the tcpdump source code but can't find why. Please
23 matches
Mail list logo
