Date: Sat, 3 Oct 1998 16:39:16 -0700 (PDT) From: "Eric J. Schwertfeger" <ejs@bfd.com> To: questions@FreeBSD.ORG Subject: Trying to learn divert sockets Message-ID: <Pine.BSF.4.05.9810031615170.10070-100000@harlie.bfd.com>
next in thread | raw e-mail | index | archive | help
I'm trying to write a simple program that uses divert sockets, and it isn't going too well. Basically, I can make my program reinject the packets back into the same device as they were diverted from, and that works. However, I'm trying to divert the packets to a different device for various reasons. My luck so far doing this has been zero. I've got a subroutine that sets up sockaddr_in for use, and works well enough that I can bind the local end of a socket to a specific IP address and port, but when I use the same routine in my divert code, using the same port number that I'm diverting, and the IP address of the interface that I want to divert to, I get EADDRNOTAVAIL. I did a hexdump of my sockaddr_in and the sockaddr_in that recvfrom() returned, and I noticed that the recvfrom() version had three additional non-zero bytes after the IP address, and if I zero those out I get the same behavior, even when I'm trying to use the same interface. According to /usr/include/netinet/in.h, those are the first three bytes of sin_zero[8], so I don't know what they are. So, I figured, let's take the recvfrom() version, and stuff the IP address of the desired destination device (lo0 for testing) into that sockaddr_in. Well, the packets don't get rejected, but they don't get processed by ipfw as packets that came in "recv lo0." These are the rules I'm using. /sbin/ipfw add 64100 divert 7123 ip from any to any recv de0 /sbin/ipfw add 64200 deny log ip from any to any recv de0 where my program has opened a divert port on 7123, and does nothing but try to reinject the packets to the loopback device (127.0.0.1). So, by my understanding, which is wrong somewhere, this should work, as the packet hits the divert rule, gets injected into the lo0 device, and so shouldn't trigger the rule 64200. They are triggering that rule, as the logs show. What am I missing? Either those three bytes actually control what interface the packets are reinjected into, or ipfw is seeing the packets as coming from the original interface. At this point, I'm considering using tun devices instead of the loopback device so that it works, but there's something that bothers me about getting the packets through one mechanism, and reinjecting them by another mechanism. Not to mention the fact that will make my trivial program much larger. So, anyone see what I'm missing? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9810031615170.10070-100000>