Date: Wed, 12 May 2004 17:59:28 -0400 (EDT) From: "Tom R. no spam" <tr5374@csc.albany.edu> To: freebsd-questions@freebsd.org Subject: ipfw divert but no packet payload? Message-ID: <Pine.GSO.4.58.0405121704400.20286@unix2.its.albany.edu>
next in thread | raw e-mail | index | archive | help
I've followed the divert and ipfw manpages, Stevens _Unix Network Programming_ & etc, Baldine's Feb 2000 "Divert Sockets mini-HOWTO" at www.tldp.org/HOWTO, and everything else I could find (not very much exactly about this, tho). My situation is: firewall: have "ipfw divert <portnum>" rule for port 80 out user program: recvfrom() on a raw socket bound to <portnum> My question is: whether I should expect to be able to get the full packet including data payload for a packet diverted to port <portnum> ? I want to be able to inspect the packet content before it is sent out. Right now my user code just prints the packet, then does sendto() back to the raw socket to send the packet on its way, but there is no data payload. Everything I've seen about divert seems clearly to expect the full data payload to be available to whatever is receiving from the raw socket. Web browsing works, & tcpdump shows full packets, but I can't see any data payload in the user program. User prog can read the ip header length, tcp header length, and full ip packet length from the packet (20, 40, and 60 respectively, after converting to bytes). Per the "60", packet seems to be saying there *isn't* any data payload, only the 20+40 header bytes. The recvfrom() memory buffer argument is 2048 bytes long, and I can printout all its many "0" bytes after the headers. I understand tcpdump uses the bsd packet filter to get merely a copy of the packet, but the full packets are getting to where they're addressed somehow because browsing is working, and tcpdump is showing packet sizes like 467, etc. "ipfw -a list" shows the same divert packet count as how many my user program sees, and byte count == (60 * pkt count). (Tho a couple of early runs, before I did full printouts and had settled on simple ipfw rules, had occasional 44 byte recvfrom() returns and ipfw packet sizes mixed in with the 60 byte returns/sizes.) Any suggestions would be very appreciated. (I'm using FreeBSD as Mac OSX 10.2.8, which has shown no strangeness other than a couple of odd console.log alerts relating to unrecognized ipfw rules while I was fiddling with my own ipfw preparing for trying the divert stuff.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0405121704400.20286>