From owner-freebsd-hackers Thu Sep 20 16:23: 8 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from mta3-rme.xtra.co.nz (mta3-rme.xtra.co.nz [203.96.92.13]) by hub.freebsd.org (Postfix) with ESMTP id 0694337B40E for ; Thu, 20 Sep 2001 16:23:03 -0700 (PDT) Received: from development.wgtn.csg.co.nz ([210.86.1.68]) by mta3-rme.xtra.co.nz with SMTP id <20010920232301.BJGZ3395984.mta3-rme.xtra.co.nz@development.wgtn.csg.co.nz>; Fri, 21 Sep 2001 11:23:01 +1200 Content-Type: text/plain; charset="iso-8859-1" From: David Preece Reply-To: davep@afterswish.com To: Alfred Perlstein Subject: Re: sendto not sending what I asked... Date: Fri, 21 Sep 2001 11:23:16 +1200 X-Mailer: KMail [version 1.2] References: <01092110333803.36513@development.wgtn.csg.co.nz> <20010920174759.B61456@elvis.mu.org> In-Reply-To: <20010920174759.B61456@elvis.mu.org> Cc: hackers@freebsd.org MIME-Version: 1.0 Message-Id: <01092111231604.36513@development.wgtn.csg.co.nz> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message