Here's the "ipfw -a list" content at the start. I run a shell script manually to set these, it starts with a flush then adds rules. The "keep-state" are leftover from studying dynamic rule creation. (FWIW, Mac OSX 10.2.8 seemed on brief review not to use a "3000 check-state" I originally was trying.)
2000 - 2040 are stock OSX, 4010 - 4030 are mine, 4040 - end are stock OSX. -------------------------------------------------- 02000 allow ip from any to any via lo* 02010 deny ip from 127.0.0.0/8 to any in 02020 deny ip from any to 127.0.0.0/8 in 02030 deny ip from 224.0.0.0/3 to any in 02040 deny tcp from any to 224.0.0.0/3 in 04010 allow udp from me to any 53 keep-state out 04020 divert 55374 tcp from me to any 80 out 04030 allow tcp from me to any keep-state out setup 04040 allow tcp from any to any established 12190 deny tcp from any to any 65535 allow ip from any to any -------------------------------------------------- On Wed, 12 May 2004, JJB wrote: > Post you ipfw rules so people can see what you are talking about. > > -----Original Message----- > 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.) _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
