On 26/07/2016 1:41 AM, Dr. Rolf Jansen wrote:
Am 25.07.2016 um 12:47 schrieb Michael Sierchio <ku...@tenebras.com>:
Writing a divert daemon is a praiseworthy project, but I think you could do
this without sending packets to user land.
You could use tables - …
Am 25.07.2016 um 14:01 schrieb Jan Bramkamp <cr...@rlwinm.de>:
I would use a set of IPFW tables with skipto/call tablearg rules instead …
Michael and Jan, many thanks for your suggestions.
As everybody knows, 'Many roads lead to Rome.', and I am already there. I don't
feel alike going all the way back only for the sake of trying out other routes.
and I personally am responsible for at least parts of several of them ;-)
(parts of ipdivert, netgraph, and various ipfw bits).
Once a week, the IP ranges are compiled from original sources into a binary
sorted table, containing as of today 83162 consolidated range/cc pairs. On
starting-up, the divert daemon reads the binary file in one block and stores
the ranges into a totally balanced binary search tree. Looking-up a country
code for a given IPv4 address in the BST takes on average 20 nanoseconds on an
AWS-EC2 micro instance. I don't know the overhead of diverting, though. I guess
this may be one or two orders of magnitudes higher. Even though, I won't see
any performance issues.
yes the diversion to user space is not a fast operation. When we wrote
it, fast was 10Mbits/sec.
The firewall tables use a radix tree (*) and might be slower than what
you have, but possibly it might be made up for by not having to do the
divert logic. it's not entorely clear from your description why you
look up a country rather than just a pass/block result, but maybe
different sources can access different countries?.
I did similar once using ipfw tables but couldn't find a reliable
source of data.
Independent from the actual usage case (geo-blocking), let's talk about divert filtering
in general. The original question which is still unanswered can be generalized to,
whether "dropping/denying" a package simply means 'forget about it' or whether
the divert filter is required to do something more involved, e.g. communicate the
situation somehow to ipfw.
there is no residual information about the packet in the kernel once
it has been passed to the user process.
so just "forgetting to hand it back" is sufficient to drop it.
Best regards
Rolf
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
_______________________________________________
freebsd-ipfw@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw
To unsubscribe, send any mail to "freebsd-ipfw-unsubscr...@freebsd.org"
