Re: Logging natd translations

2013-05-15 Thread Daniel Eischen
On Wed, 15 May 2013, Daniel Eischen wrote: We need to log all translations from internal IP addresses to external addresses. It's good enough to have IPv4 to Ipv4 translations for TCP streams, just one log for the start of each stream. We're using FreeBSD-9.1-stable and IPFW with userland natd

Logging natd translations

2013-05-15 Thread Daniel Eischen
We need to log all translations from internal IP addresses to external addresses. It's good enough to have IPv4 to Ipv4 translations for TCP streams, just one log for the start of each stream. We're using FreeBSD-9.1-stable and IPFW with userland natd. The -log option of natd just seems to log s

Re: Managing userland data pointers in kqueue/kevent

2013-05-15 Thread LeoNerd
On Wed, 15 May 2013 13:29:59 +0100 Paul "LeoNerd" Evans wrote: > Is that not the exact thing I suggested? > > The "extension to create register a kevent to catch these events" is > that you put the EV_DROPWATCH bit flag in the event at the time you > register it. > > The "returned event [that]

Re: Managing userland data pointers in kqueue/kevent

2013-05-15 Thread LeoNerd
On Wed, 15 May 2013 02:14:55 -0400 Julian Elischer wrote: > I would suggest that one answer would be to create an extension to > register a > kevent to catch these events.. > > (the knote_drop()) > > The returned event could have all the appropriate information for the > event being dropped..

Re: A problem with alq module!

2013-05-15 Thread Lawrence Stewart
On 05/13/13 16:37, Computer Network Man wrote: > Dear Guys; > In a fresh FreeBSD 9 or 9.1 Release if you just run these commands: > # kldload alq > # kldunload alq > # init 0 or shutdown -p now > it will panic! > maybe it's a bug. > We have a module which uses alq API's. > MODULE_DEPEND(mymodul