From: "Dan Joumaa" <[EMAIL PROTECTED]>
103 9.443254 192.168.1.6 -> 205.166.76.40 TCP pacmand > https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
104 9.443364 192.168.1.2 -> 205.166.76.40 TCP pacmand > https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
105 9.443617 192.168.1.6 -> 205.166.76.40 TCP pacmand > https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
106 9.443654 192.168.1.2 -> 205.166.76.40 TCP pacmand > https [SYN]
Seq=0 Ack=0 Win=2920 Len=0 MSS=536
107 9.496102 205.166.76.40 -> 192.168.1.2 TCP https > pacmand [SYN,
ACK] Seq=0 Ack=1 Win=1608 Len=0 MSS=1460
108 9.496185 192.168.1.2 -> 205.166.76.40 TCP pacmand > https [RST]
Seq=1 Ack=341266652 Win=0 Len=0
(192.168.1.1 = next hop, 192.168.1.2 = this computer, 192.168.1.6 =
the client)
Here's the rules:
00001 divert 4747 tcp from 192.168.1.6 to any in
00001 divert 4747 udp from 192.168.1.6 to any in
The following rules are added dynamically when my client sends a packet
to a server so we can get it back on the divert socket. In this case,
it would be:
That seems like a maybe dicey strategy to me. Seems like it wouldn't
scale well and could be subject to some race conditions. Why not just
divert all packets (or all TCP and UDP) and sift them in your program for
what's interesting? Or use a rule based on a destination of 192.168.1.6?
00001 divert 4747 tcp from 205.166.76.216 to any in
00001 divert 4747 udp from 205.166.76.216 to any in
Ok, so why shouldn't the machine send a RST when the SYN,ACK is received?
It sounds like you are sending a synthesized SYN packet (one the OS
didn't generate) with the source address of your machine (192.168.1.2),
which the other end responds correctly to with a SYN,ACK which is getting
delivered to the OS since you have no divert rule for 192.168.1.2. Since
the OS didn't send the SYN and knows nothing of the connection, it sends
a RST. Perfectly normal.
... modify the packet for sending ...
... and send it through a raw socket.
I find it more convenient when working with divert sockets to send
packets through the divert socket itself. It lets you control where it
reenters the rule chain, which direction it is travelling, which
interface, etc. Just an idea.
If it's from someone outside the LAN, modify it for forwarding to the
client...
I don't have any idea what you are trying to accomplish but am having a
hard time imagining any situation where it would be useful to send the
same packet out twice to two different destinations.
I don't know that it will help much, but if you are interested in an
example of another program working through divert sockets, you can take a
look at this one I wrote: http://www.madole.net/shaper/
David
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
