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]
