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)Received on Tue Sep 26 2006 - 08:42:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:00 UTC