Re: divert as module?
> Stop right here. If you didn't compile IPDIVERT in the kernel, > the hooks aren't in the tcp/ip stack and you're screwed. > > Figuring out a way to fix this is on my TODO list, though I don't > have any ideas that don't cost a performance hit for non-DIVERT > users. The LEASE stuff has a similar problem, but it eats the overhead anyway, but screws up a number of details in a couple of places, making it pretty useless to load NFS as a module, at least for serving. There are really several ways to do this: o Jump table with fixup on first call - This is the least overhead, since each caller is fixed up once; the bad news is: no unload. o Another way is to do what the NFS LEASE code does; this adds a pointer dereference and compare to zero with jump - This is more overhead, as you say; the real pain here is the jump, which wouldn't be necessary, if it were possible to tell the compiler "I expect this compare to succeed most of the time" or "I expect this compare to fail most of the time" using a "#pragma"; if you could do that, the compiler could change branch order generation by tacking a hint onto the quad tree, and reordering (or not reordering) it. You can get the same effect by placing the default path inside the if test, but then you get a branch instruction, which is not much better. o A sneaky way to do this is to put the diversion into the failure path. This makes divert very expensive, comparatively (in terms of code path), and adds some constraints to how it must be used, but makes it so that you only ever divert packets you would otherwise throw away - That said, there are server things in the IPFW code that could be diked out as "more useless than divert", forceful rejection being one of them, since everyone who is a bad guy ignores it anyway, so the argument would be "what's important?", since everyone's choice for success and failure code path would be different. - On the other hand, if it's considered so heavy that it already has #ifdef's for it, the divert code is a good candidate for failure code path. My personal vote would be fore LEASE, if the reason is that the code is large, not because it is slow, and failure path, if it's because the code is slow, not because it is large. Terry Lambert [EMAIL PROTECTED] --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: divert as module?
On Sun, Oct 22, 2000 at 09:52:03PM +0200, Leif Neland wrote: > I want to install ipfw and natd to a machine working as isdn-router, which I > lost the kernel config for > I connect to the world via userland-ppp and isdnd. > > I don't have any ipfw or divert compiled in the kernel, but I can load > ipfw.ko, so the firewall rules can work (I now see my isp sends IGMP's to > me...) Stop right here. If you didn't compile IPDIVERT in the kernel, the hooks aren't in the tcp/ip stack and you're screwed. Figuring out a way to fix this is on my TODO list, though I don't have any ideas that don't cost a performance hit for non-DIVERT users. -- Bill Fumerola - Network Architect, BOFH / Chimes, Inc. [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: divert as module?
> On Sun, 22 Oct 2000, Nimrod Mesika wrote: > > >> Or can I use ppp's nat together with ipfw? > > > >I see no reason why you can't. In fact, it will probably be more > >efficient as you will not need two user processes (ppp and natd). > I tried, I can. (I should just have tried instead of asking...) > Furthermore, I don't see why ipfw gains you anything over ppp filters. > Just run w/ ppp -nat and setup some ppp filters as explained in ppp(8). > You'll be good to go. I wanted to get logged what gets denied, I haven't noticed an option in ppp to do that. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: divert as module?
On Sun, 22 Oct 2000, Nimrod Mesika wrote: >> Or can I use ppp's nat together with ipfw? > >I see no reason why you can't. In fact, it will probably be more >efficient as you will not need two user processes (ppp and natd). Furthermore, I don't see why ipfw gains you anything over ppp filters. Just run w/ ppp -nat and setup some ppp filters as explained in ppp(8). You'll be good to go. -- Brandon D. Valentine <[EMAIL PROTECTED]> "Few things are harder to put up with than the annoyance of a good example." -- Mark Twain, Pudd'nhead Wilson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: divert as module?
On Sun, Oct 22, 2000 at 09:52:03PM +0200, Leif Neland wrote: > But the command > "ipfw add divert natd all from any to any via tun0 " > fails: > 0 divert 8668 ip from any to any via tun0 > ipfw: setsockopt(IP_FW_ADD): Invalid argument I don't know about a kernel module, but when ipfw is compiled as part of the kernel you also need: options IPDIVERT to enable divert sockets. Maybe you can just recompile the module. I'm not sure. > Or can I use ppp's nat together with ipfw? I see no reason why you can't. In fact, it will probably be more efficient as you will not need two user processes (ppp and natd). -- Nimrod. http://www.geocities.com/rodd_27 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
