Anyone play with divert sockets lately?
Randall Stewart
rrs at cisco.com
Tue Sep 26 03:42:38 PDT 2006
Ian FREISLICH wrote:
> Randall Stewart wrote:
>
>>Ian FREISLICH wrote:
>>
>>
>>>
>>>I'm using divert sockets extensively for some tunnel/vpn software
>>>I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19
>>>08:33:01 SAST 2006), 4.11-STABLE, and just about everything in
>>>between. I've not had to change the code substantially to make it
>>>work on newer BSDs. All our VoIP goes through this piece of code:
>>>
>>> memset(&from, '\0', sizeof from);
>>> from.sin_addr.s_addr = INADDR_ANY;
>>> from.sin_port = config.tuns[config.tun].fw_rule;
>>> while (tot + ntohs(hdr->length) <= (p - buf + in)) {
>>> out = sendto(config.tuns[config.tun].div_fd, buf +
>
> tot,
>
>>> ntohs(hdr->length), 0, (struct sockaddr *)&from,
>>> sizeof(addr));
>>> ...
>>>
>>>
>>
>>Well, its interesting ... 6.1 appears to work.. but 7.0 does not..
>>
>>Now I don't think the code we have does anything with setting the
>>sin_port like you do (to config.tuns[]...)
>
>
> All that does is tell the divert socket which (ipfw) rule to inject
> the packet after. If you read from the divert socket, do stuff(tm)
> and write back to the divert socket, preserve the struct sockaddr
> *from from the recvfrom() call and use that same data in the sendto()
> call unless you want processing in the stack to start afresh for
> the packet. (I'm sure others will correct that statement, but
> that's my poor-man's understanding)
Well.. looking at the code, I think we leave this untouched from
the recv... that way it re-injects (in theory) at the same place
it came out.. (which is what we want)..
>
> I've found that not zeroing these network structures before use
> confounds things, because you might not initialise all the elements.
> If my memory serves correctly, I think that these structures have
> changed size between 6 and 7, but take my saying so with a pinch
> of salt because I haven't checked recently.
I will go poke around some more when I have time.. I was able
to finish my needed UnitTest without the second tunnel up... so
I am ok for now.. but I do want to circle back and see
if its truely an app bug.. or a problem with the divert code...
Very interesting in any case :-)
R
>
> Ian
>
> --
> Ian Freislich
>
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 815-342-5222 (cell)
More information about the freebsd-current
mailing list