On Fri, 21 Sep 2001 10:47, you wrote:
> > the
> > buffer I pass is appended as data on the end of an IP packet with unknown
> > protocol, rather than replacing the IP and TCP headers (i.e. appending
> > the ethernet header) as I had hoped.
> It would help if you'd provided what you think you're sending and
> what the other end is actually seeing.
Sure, The contents of the buffer are:
struct packet
{
ip ipbit;
tcphdr tcpbit;
};
//fill in some basics of the packet we are about to send
packet pkt;
pkt.ipbit.ip_v=4;
pkt.ipbit.ip_hl=5;
pkt.ipbit.ip_tos=0;
pkt.ipbit.ip_len=htons(40);
pkt.ipbit.ip_off=0;
pkt.ipbit.ip_ttl=64;
pkt.ipbit.ip_p=6;
pkt.ipbit.ip_src.s_addr=/*inet_addr(argv[4])*/inet_addr("10.0.0.102");
pkt.ipbit.ip_dst.s_addr=/*inet_addr(argv[2])*/inet_addr("10.0.0.103");
pkt.tcpbit.th_dport=/*htons(atoi(argv[3]))*/htons(80);
pkt.tcpbit.th_ack=0;
pkt.tcpbit.th_x2=0;
pkt.tcpbit.th_off=5; //20 bytes, no options
pkt.tcpbit.th_flags=TH_SYN;
pkt.tcpbit.th_win=htons(65535); //advertise a big window
pkt.tcpbit.th_urp=0;
[snip, fast forward to later in the code]
//fill in random bits of packet
pkt.ipbit.ip_id=/*rand()%65536*/htons(0x1234);
pkt.tcpbit.th_sport=/*htons(1024+rand()%64511)*/htons(0x4321);
pkt.tcpbit.th_seq=/*rand()*/htonl(0x12345678);
//find checksums
pkt.ipbit.ip_sum=0;
pkt.tcpbit.th_sum=0;
pkt.ipbit.ip_sum=in_cksum((unsigned short*)(void*)&pkt,20);
pkt.tcpbit.th_sum=tcpsum(&pkt.ipbit);
where both in_cksum and tcpsump have been used before and appear to work :)
the sin structure is filled out:
sockaddr_in sin;
bzero(&sin,sizeof(struct sockaddr_in));
sin.sin_family=AF_INET;
sin.sin_addr.s_addr=pkt.ipbit.ip_dst.s_addr;
sin.sin_port=pkt.tcpbit.th_dport;
finally I send with this (where pBuffer is just put in to give the debugger
something to look at).
void* pBuffer=&pkt;
sendto(sck,pBuffer,40,0,(struct sockaddr *)&sin,sizeof(sin));
OK, so at this point the contents of the buffer are:
0xbfbff9dc: 0x45 0x00 0x00 0x28 0x12 0x34 0x00 0x00
0xbfbff9e4: 0x40 0x06 0x53 0xd0 0x0a 0x00 0x00 0x66
0xbfbff9ec: 0x0a 0x00 0x00 0x67 0x43 0x21 0x00 0x50
0xbfbff9f4: 0x12 0x34 0x56 0x78 0x00 0x00 0x00 0x00
0xbfbff9fc: 0x50 0x02 0xff 0xff 0xee 0xf8 0x00 0x00
And the packet that actually gets sent:
0000 00 d0 b7 1b b2 6c 00 80 ad 72 b6 cc 08 00 45 00
0010 00 3c 1f dd 00 00 ff ff 86 19 0a 00 00 66 0a 00
0020 00 67 45 00 00 28 12 34 00 00 40 06 53 d0 0a 00
0030 00 66 0a 00 00 67 43 21 00 50 12 34 56 78 00 00
0040 00 00 50 02 ff ff ee f8 00 00
So here we have the two hardware addresses (ending 0xb6 0xcc, top line),
marking as IP protocol (0x08 0x00), then the IP packet written by the OS
(0x45 0x00 top line, to 0x00 0x67 on the third line) followed by the buffer I
provided for a total length of 60 bytes. Interestingly the IP packet written
by the OS has a protocol of 0xff=unknown (the 0x17th byte).
>Without that I can't help
> much except to suggest that you make sure you're using htons/htonl
> in the right spot and on the right size types.
Yeah, been bitten by this before, but in my experience providing a packet
with broken checksums results in it either not being sent, or being ignored
by the recipient. This behaviour is entirely new and suggests there's
something I don't understand about the interface onto the OS since if I was
wanting to send a packet of data over IP without declaring which protocol it
was for, this would be a pretty good way of doing it :)
Oh, experience yes, I have worked with divert sockets before, but not raw -
hence the confusion.
Cheers,
Dave
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
