Moin everybody. I'm writing a little program in C. To test my C program
i need a server and a client, so a wrote an as simple as possible
protocolless chat (in perl).
I run the server on localhost:65534 and of course i use my client to
connect to it.
With ethereal i sniff the traffic on lo interface so i can see the
source port where client app works (as example i'll assume it's
localhost:33000) and seq/ack numbers of packet going.
Now my C app comes. It simply lets the user to send a packet from
localhost:33000 to localhost:65534 (using socket raw), and, with the
right seq/ack numbers i should be able to send a packet to the server
with my C application instead of using the client.
My application gets seq number as argv[5] and ack number as argv[6].
Perhaps it's not so clear, the idea is this:

PerlServer listening on 65534  -  SYN
PerClient connects from 33000 to 65534   -  SYN, ACK
PerlServer sends ack back  -  ACK
PerClient sends some data  -  PSH, ACK
PerlServer sends ack back  -  ACK
C-Application sends a fake packet with some data from 33000 to 65534
with correct seq/ack.  - PSH, ACK
PerlServer sends ack back  -  ACK
PerlClient does not expects the ACK and send RST to server (or
everything else, i don't care).

The problem is: i sniff seq/ack with ethereal, i set the adjusted
seq/ack values and I send the fake packet. At this point ethereal shows
my packet just sent but seq number and ack number are completly wrong
and I can't understand why.
If i set Seq = 49, Ack = 1 ethereal says:
sequence number = 1683153356
acknowledgment number = 1687969411

I print the values to check it but they are correct to me, according on
what i wrote as arguments. Here follow a part of the code.
Many many thanks in advance.


#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>
#include <netdb.h>
#include <time.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>
#include <sys/socket.h>
#include <arpa/inet.h>

#define IPHDRSIZE sizeof(struct iphdr)
#define TCPHDRSIZE sizeof(struct tcphdr)

/* Some code... */
int main(int argc,char **argv)
{
   unsigned long seqn, ackn;
   struct tcphdr tcp;
   seqn = strtoul(argv[5], NULL, 10);
   ackn = strtoul(argv[6], NULL, 10);
   tcp.seq      = htonl(seqn);
   tcp.ack_seq  = htonl(ackn);
   printf("Sequence number         : %lu\n", ntohl(tcp.seq));
   printf("Sequence number         : %lu\n", seqn);
   printf("Acknowledgement number  : %lu\n", ntohl(tcp.ack_seq));
   printf("Acknowledgement number  : %lu\n", ackn);
   return 0;
}

Many many thanks again.
TDFS

"The Dark Free Soul" <thedarkfreesoul@gmail.com> wrote in message
news:1141576484.570499.81570@t39g2000cwt.googlegroups.com...
[snip]
> Now my C app comes. It simply lets the user to send a packet from
> localhost:33000 to localhost:65534 (using socket raw), and, with the
> right seq/ack numbers i should be able to send a packet to the server
> with my C application instead of using the client.
[snip]
> The problem is: i sniff seq/ack with ethereal, i set the adjusted
> seq/ack values and I send the fake packet. At this point ethereal shows
> my packet just sent but seq number and ack number are completly wrong
> and I can't understand why.

Is Ethereal showing relative sequence numbers - that is, an offset from the
first sequence number seen in each direction?

Alex

yes and, from the moment seq/ack numbers are not right ethereal marks
the packet as "TCP Out-of-order". Do you have any idea?
The base problem is that the packet has not the seq/ack numbers i want.

"The Dark Free Soul" <thedarkfreesoul@gmail.com> wrote in message
news:1141580150.720711.7670@t39g2000cwt.googlegroups.com...
> yes and, from the moment seq/ack numbers are not right ethereal marks
> the packet as "TCP Out-of-order". Do you have any idea?
> The base problem is that the packet has not the seq/ack numbers i want.

Please quote appropriate context when replying. Using Google Groups, select
"show options" at the top of the article, and then use the "Reply" button at
the bottom of the headers. Trim parts of the article that are not relevant
to your reply.

You can't use the relative sequence numbers; you need to use the actual
sequence numbers. I suspect your code creates packets with the sequence
numbers you supply, but those numbers are wrong. Hint: you should expect
sequence numbers to be at least seven decimal digits more than 99% of the
time.

Alex

> You can't use the relative sequence numbers; you need to use the actual
> sequence numbers. I suspect your code creates packets with the sequence
> numbers you supply, but those numbers are wrong. Hint: you should expect
> sequence numbers to be at least seven decimal digits more than 99% of the
> time.

Ah right! i think the problem must be here but then I don't know how to
get the actual seq/ack numbers. I think you are terribly right, i'm
using relative seq/ack numbers and this is surrely wrong. In ethereal i
think i've always seen the relative numbers. Actually i don't know how
to get the real values but i'll find the way. This evening i'll go
testing :) Many many many thanks Mr Fraser. I'll write here if i'll
solve the problem.
Best regards from Italy.

> You can't use the relative sequence numbers; you need to use the actual
> sequence numbers.

Cool !!  You where right man! Many many thanks, now it works really
well. Thanks thanks thanks :)

In article <1141730445.385988.173630@i40g2000cwc.googlegroups.com>,
 "The Dark Free Soul" <thedarkfreesoul@gmail.com> wrote:

> > You can't use the relative sequence numbers; you need to use the actual
> > sequence numbers. I suspect your code creates packets with the sequence
> > numbers you supply, but those numbers are wrong. Hint: you should expect
> > sequence numbers to be at least seven decimal digits more than 99% of the
> > time.
> 
> Ah right! i think the problem must be here but then I don't know how to
> get the actual seq/ack numbers. I think you are terribly right, i'm
> using relative seq/ack numbers and this is surrely wrong. In ethereal i
> think i've always seen the relative numbers. Actually i don't know how
> to get the real values but i'll find the way. This evening i'll go
> testing :) Many many many thanks Mr Fraser. I'll write here if i'll
> solve the problem.
> Best regards from Italy.

You can change to absolute sequence numbers by going into 
Preferences->TCP, IIRC.

-- 
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***