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 to any in
02020  deny ip from any to in
02030  deny ip from to any in
02040  deny tcp from any to 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, 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
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to