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 " rule for port 80 out
> user program: recvfrom() on a raw socket bound to
>
> My question is: whether I should expect to be able to get
> the full packet including data payload for a packet diverted
> to port ? 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]"
