automated checking of Security Advisories
I have a partly-baked idea regarding the security advisories that I see on freebsd-announce. While I applaud the intent of these notices, I wonder if some sort of automation might not make them a bit more useful. Let's say we encoded the advisories in XML and put them up for HTTP access, encoding the version characterization information (e.g., Affects) in some mechanically-usable fashion. Then, a Perl script on the local machine could look up the advisories, run the tests, and report the results, all without compromising the privacy of the local system. I am quite willing to write a first cut at the client code, but I think I need to get some buy-in from the folks who are generating the advisories. Specifically, I need version characterization data in a form which can be reliably used by an automated script. Is this generally a feasible thing to provide? If so, the rest seems pretty simple. I can read the advisories as they come in over email, parse them and munge them into XML (with a bit of hand-work, if need be) and put them up for general access. -r -- http://www.cfcl.com/rdm - home page, resume, etc. http://www.cfcl.com/Meta/md_fb.html - The FreeBSD Browser email: [EMAIL PROTECTED]; phone: +1 650-873-7841 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Orinoco MiniPCI
In message <[EMAIL PROTECTED]> Brandon Fosdick writes: : A search of the archives revealed that PCI adapters for orinoco cards : don't work yet. So I guess there's no hope of getting the MiniPCI card : working either? Nope. : Does it work in -current? Nope. I'm working on it. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Orinoco MiniPCI
On 24-Apr-01 Brandon Fosdick wrote: > A search of the archives revealed that PCI adapters for orinoco cards > don't work yet. So I guess there's no hope of getting the MiniPCI card > working either? > > Does it work in -current? There may be hope, if you're interested, I just spent a bit of time this weekend getting the Netgear MA-301 working. ( The MA-301 is a PLX based PCI bridge that an MA-401 PC card is inserted into ). All that I needed to do was change the following defines in src/sys/dev/wi/if_wireg.h: #define WI_PCI_VENDOR_EUMITCOM 0x1638 #define WI_PCI_DEVICE_PRISM2STA 0x1100 To: #define WI_PCI_VENDOR_EUMITCOM 0x1385 #define WI_PCI_DEVICE_PRISM2STA 0x4100 Admittedly, I have no clue what I'm doing, as I have never even looked at a data sheet for these critters, but, so far, it appears to work fine. ;-) If the MiniPCI card is based on the PLX, similar modifications may be all you need. If it is PLX based, boot with the verbose option and find the vendor and device codes for it. Season the above defines to taste, and voila! Once we have a clue as to the cards now coming onto the market, iterating through the various vendor and device codes in the wi driver should be pretty trivial. BTW, the MA-401 is a Prism2 based card, and works out of box on -current in a PC card slot. Sure beats running 300' of CAT5 into the backyard! My most humble thanks to Bill Paul for writing the wi driver and to all those who have maintained to it. -- E-Mail: Kenneth P. Stox <[EMAIL PROTECTED]> Date: 23-Apr-01 Time: 21:23:59 -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: thttpd hack for sendfile and accept filters.
On Sat, Apr 21, 2001 at 08:55:55PM -0700, Kris Kennaway wrote: >>> http://people.freebsd.org/~kris/thttpd-2.19+kq.patch >> Commit them to the port! :-) > Yeah, I should. I should also submit them back to the author :-) And the poor port maintainer for review first please. :-) But anyway, thttpd 2.21 has kqueue and accept filtering support. I've tested it a little in 4.3-STABLE, and it seems fine. Except in -current, which I'm looking into. Cheers, -- Anders. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Orinoco MiniPCI
Brooks Davis wrote: > > On Mon, Apr 23, 2001 at 08:07:43PM -0400, Brandon Fosdick wrote: > > A search of the archives revealed that PCI adapters for orinoco cards > > don't work yet. So I guess there's no hope of getting the MiniPCI card > > working either? > > Actually, that should be a different problem. The Orinoco PCI adaptors > don't work because they are PCI-CardBus bridges and have interrupt > routing issues. (Warner said today that someone waved money at him to > fix that so it should happen.) On the other hand, there are other PCI > adaptors for other cards that work with wi that use an adaptor that > presents a PCI bus interface to a PCCard. I would expect the MiniPCI > cards will do something like that since it would be pretty stupid to do > it the other way given the rather minimal available realestate on a > MiniPCI card. It's probably just a matter of adding the right entry to > the wi_pci_probe function in if_wi.c. PCI support for this was one of > the first things merged after the 4.3 code freeze was lifted. Ah, I installed 4.3-R. I'll try updating my sources. -Brandon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Orinoco MiniPCI
On Mon, Apr 23, 2001 at 08:07:43PM -0400, Brandon Fosdick wrote: > A search of the archives revealed that PCI adapters for orinoco cards > don't work yet. So I guess there's no hope of getting the MiniPCI card > working either? Actually, that should be a different problem. The Orinoco PCI adaptors don't work because they are PCI-CardBus bridges and have interrupt routing issues. (Warner said today that someone waved money at him to fix that so it should happen.) On the other hand, there are other PCI adaptors for other cards that work with wi that use an adaptor that presents a PCI bus interface to a PCCard. I would expect the MiniPCI cards will do something like that since it would be pretty stupid to do it the other way given the rather minimal available realestate on a MiniPCI card. It's probably just a matter of adding the right entry to the wi_pci_probe function in if_wi.c. PCI support for this was one of the first things merged after the 4.3 code freeze was lifted. > Does it work in -current? The bridges still don't work in current either. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 PGP signature
Orinoco MiniPCI
A search of the archives revealed that PCI adapters for orinoco cards don't work yet. So I guess there's no hope of getting the MiniPCI card working either? Does it work in -current? -Brandon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: cv_wait() or sv_wait() in FreeBSD
On 23-Apr-01 Zhihui Zhang wrote: > > Do we have conditional/synchronization variable support in FreeBSD? If > not, is there any alternative mechanism to use in the kernel? Thanks. There are cv's in -current. man 9 condvar > -Zhihui -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI -> PCMCIA Bridge Adapter
In message <[EMAIL PROTECTED]> Peter Pentchev writes: : I think there was talk on -mobile about this recently, with someone : (I can't remember who, but Warner Losch comes to mind) saying that : this cannot be done in 4.x-stable at the moment, and it shall not : be done in 4.x-stable ever. It's supposed to work in -current, due : to the complete rewrite of the PCMCIA/CardBus code there. That's almost right. Someone has wave $$$ under my nose to make pci bridges work in -stable with OLDCARD. It doesn't yet work in -current for reasons unknown. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI -> PCMCIA Bridge Adapter
In message <[EMAIL PROTECTED]> Lists Account writes: : I just was wondering if anyone out there knew of any drivers that support : the pccard PCI -> PCMCIA bridge adapter, also made by pccard (see : www.pccard.co.uk), similar to the ISA -> PCMICIA bridge adapter that is : currently supported under FreeBSD The simple PLX based bridges are supported for an and wi. More complete support for them may be forthcomign. The cardbus bridge chip on a pci card isn't (yet) supported by FreeBSD. I do have a contract to make them work, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cv_wait() or sv_wait() in FreeBSD
* Zhihui Zhang <[EMAIL PROTECTED]> [010423 12:33] wrote: > > Do we have conditional/synchronization variable support in FreeBSD? If > not, is there any alternative mechanism to use in the kernel? Thanks. FreeBSD Current has these, see the cv_wait manpage. FreeBSD stable doesn't and you can use the traditional tsleep/wakeup/wakeup_one mechanisms. -- -Alfred Perlstein - [[EMAIL PROTECTED]] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ptrace(PTRACE_SYSCALL,...
Sounds like this might also be useful to make a procfs-free truss Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 23 Apr 2001, diman wrote: > > Hello, guys > > I'm porting ltrace to FreeBSD and have one little question. > ltrace uses non-standard PTRACE_SYSCALL request, which tells > the kernel to stop traced process on every syscall entry > and notify the parent. > > It makes us possible to trace child's syscalls and *catch > execve/xfork events* and many more. BTW, that request > is non-standard and FreeBSD doesn't support it. > > So, guys, what is a right way for a parent to catch > child making syscall under FreeBSD? I have dosen > k-mode solutions but how to do that from user-space? > > Thanks you very much! > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cv_wait() or sv_wait() in FreeBSD
Do we have conditional/synchronization variable support in FreeBSD? If not, is there any alternative mechanism to use in the kernel? Thanks. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI -> PCMCIA Bridge Adapter
On Mon, Apr 23, 2001 at 08:25:56PM +0200, Lists Account wrote: > Hi All, > > I just was wondering if anyone out there knew of any drivers that support > the pccard PCI -> PCMCIA bridge adapter, also made by pccard (see > www.pccard.co.uk), similar to the ISA -> PCMICIA bridge adapter that is > currently supported under FreeBSD > > If anyone knows of such a driver please let me know, any help on this one > would be much appreciated I think there was talk on -mobile about this recently, with someone (I can't remember who, but Warner Losch comes to mind) saying that this cannot be done in 4.x-stable at the moment, and it shall not be done in 4.x-stable ever. It's supposed to work in -current, due to the complete rewrite of the PCMCIA/CardBus code there. Sorry, but :( I myself was up against this problem, and I ended up getting a PCMCIA -> ISA bridge - it works flawlessly in -stable. G'luck, Peter -- No language can express every thought unambiguously, least of all this one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI -> PCMCIA Bridge Adapter
Hi All, I just was wondering if anyone out there knew of any drivers that support the pccard PCI -> PCMCIA bridge adapter, also made by pccard (see www.pccard.co.uk), similar to the ISA -> PCMICIA bridge adapter that is currently supported under FreeBSD If anyone knows of such a driver please let me know, any help on this one would be much appreciated Many Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Netboot FreeBSD on Apple Airport (port format)
I put together a port version of the code to boot FreeBSD on an Airport base station. I haven't polished it but it produces a functional image. Some code should be converted from nasm to gas but I just haven't had time to mess with that hopefully some else might. There is code to netboot over a Wavelan card but I haven't integrated that or included it in the port. Instead it is in raw.tgz. Till Straumann ([EMAIL PROTECTED]) did most of the work and I made is support FreeBSD. The code is at: http://www.ambrisko.com/doug/airport/ Please grab it and polish it. Thanks, Doug A. Hello, this is TillLoad, Copyright <[EMAIL PROTECTED]>, 2001 (GPL) (Basemem: 0x027F00) run therboot or irport? >E ROM segment 0x8000 length 0x40EA reloc 0x9800 Boot from (N)etwork or from (L)ocal? N Etherboot/32 version 4.6.12 (GPL) for [NE2100] Probing...[NE2100] PCnet/ISA+ 79C961A base 0x0300, DMA 5, addr 00:30:65:3A:59:5F Searching for server (DHCP)... Me: 192.168.2.194, Server: 192.168.2.254, Gateway 192.168.2.254 Loading /tftpboot/kernel.bsd (ELF/FreeBSD)0680- Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 4.3-BETA #9: Wed Mar 21 15:41:11 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/AIRPORT Timecounter "i8254" frequency 1193182 Hz CPU: AMD Unknown (486-class CPU) Origin = "AuthenticAMD" Id = 0x4a4 Stepping = 4 Features=0x0 real memory = 4194304 (4096K bytes) avail memory = 1998848 (1952K bytes) Preloaded elf kernel "kernel" at 0xc025bb00. npx0: on motherboard npx0: 387 emulator isa0: on motherboard pcic0: at port 0x3e0 iomem 0xd on isa0 pcic0: Polling mode pccard0: on pcic0 pccard1: on pcic0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x30 on isa0 sio0: type 16550A, console lnc0 at port 0x300-0x317 iomem 0xd-0xd irq 10 on isa0 lnc0: PCnet-ISA II address 00:30:65:3a:59:5f lnc0: driver is using old-style compatability shims RTC BIOS diagnostic error e4 pccard: card inserted, slot 0 Sending DHCP Discover packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Offer packet on lnc0 from 192.168.2.254 (accepted) (no root path) Sending DHCP Request packet from interface lnc0 (00:30:65:3a:59:5f) Received DHCP Ack packet on lnc0 from 192.168.2.254 (accepted) (got root path) lnc0 at 192.168.2.194 server 192.168.2.254 boot file /tftpboot/kernel.bsd router 192.168.2.254 rootfs 192.168.2.254:/usr/home/ambrisko/netboot swapfs 192.168.2.254:/usr/work/netboot Adjusted interface lnc0 md_lookup_swap: Swap size is 262144 KB Mounting root from nfs: NFS ROOT: 192.168.2.254:/usr/home/ambrisko/netboot NFS SWAP: 192.168.2.254:/usr/work/ij3/netboot wi0: at port 0x240-0x27f irq 5 slot 0 on pccard0 wi0: Ethernet address: 00:02:2d:09:4b:f2 pccardd[40]: Assigning I/O window 0, start 0x240, size 0x40 flags 0x5 pccardd[40]: Assign wi0, io 0x240-0x27f, mem 0x0, 0 bytes, irq 5, flags 0 pccardd[40]: wi0: Lucent Technologies (WaveLAN/IEEE) inserted. dhclient: New IP Address(wi0): 207.76.207.134 dhclient: New Subnet Mask (wi0): 255.255.255.0 dhclient: New Broadcast Address(wi0): 207.76.207.255 dhclient: New Routers: 207.76.207.254 pccardd[40]: pccardd started login: ROOT LOGIN (root) ON ttyp0 FROM crab login: ROOT LOGIN (root) ON ttyp1 FROM 207.76.207.135 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UFS block size vs. write speed
On Mon, 23 Apr 2001, Niek Bergboer wrote: > I've implemented a quick hack on the BSD ftp-client: in the original > recv-file function data is read from a socket into a buffer, which is > then written to a file. I've mmap-ed the file, and rather than reading > from the socket into the buffer, I read directly from the socket into > the mmaped region. I use the MAP_SHARED and MAP_NOSYNC flags, and > especially the latter makes a huge difference. I seem to remember Matt Dillon saying that if you extend a file through mmap'd writes, it will become very fragmented. Check the archives for this mailing list during decemeber or so, I believe the thread had something to so with usenet servers. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP intercept?
In light of this, I would say that it would be cool to put into the ipfw
or ipf code seeing as how there are already hooks into the network stack
in the code. I am not sure how people will take the ipfw implementation
soley because I know there was alot of "hacking" being done to it in the
recent months (??). Im also not sure how well Darren would take the code
written if it was done for ipf.
Otherwise, you'll have to add some more hooks into the stack code
(tcp_{input,output}.c and perhaps others) and then handle it that way.
Im not really familiar with how (un)successful TCP intercept has been with
Cisco, but I would find that as a cool option :-)
Take it easy,
Andrew
On Mon, 23 Apr 2001, Alex Pilosov wrote:
> In cisco terminology, 'tcp intercept' is what the 'ip and tcp reassembly'
> part of ipnat does (without port/address rewriting). For example, a router
> in the middle which is doing the intercept will have to buffer/reassemble
> tcp stream and only forward packets after they are confirmed good.
>
> Example: packets with a wrong sequence number will be bounced at the
> router. On ciscos, tcp-intercept can also rate-limit syn packets...
>
> I'm not sure if it can be enabled in ipnat separately, but hell, if
> someone wants to do it...
>
> On Sun, 22 Apr 2001, Andrew R. Reiter wrote:
>
> >
> > What's TCP intercept?
> >
> > On Mon, 23 Apr 2001, E.B. Dreger wrote:
> >
> > > Greetings all,
> > >
> > > I'm no kernel hacker, and trying to think of useful little projects to
> > > change that. ;-)
> > >
> > > AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already working
> > > on this? Would it be of interest to anyone? My initial thoughts are that
> > > it should be implemented in the same neighborhood as stateful firewall
> > > code, as the two are rather closely related.
> > >
> > >
> > > Eddy
> > >
> > > ---
> > >
> > > Brotsman & Dreger, Inc.
> > > EverQuick Internet / EternalCommerce Division
> > >
> > > Phone: (316) 794-8922
> > >
> > > ---
> > >
> > >
> > > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > > with "unsubscribe freebsd-hackers" in the body of the message
> > >
> >
> > *-.
> > | Andrew R. Reiter
> > | [EMAIL PROTECTED]
> > | "It requires a very unusual mind
> > | to undertake the analysis of the obvious" -- A.N. Whitehead
> >
> >
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-net" in the body of the message
> >
> >
>
>
*-.
| Andrew R. Reiter
| [EMAIL PROTECTED]
| "It requires a very unusual mind
| to undertake the analysis of the obvious" -- A.N. Whitehead
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP intercept?
In the last episode (Apr 23), Wes Peters said: > > I'm no kernel hacker, and trying to think of useful little projects > > to change that. ;-) > > > > AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already > > working on this? Would it be of interest to anyone? My initial > > thoughts are that it should be implemented in the same neighborhood > > as stateful firewall code, as the two are rather closely related. > > If you mean IP forwarding, you can do that with ipnat (part of > ipfilter) or with natd. If you mean network interface monitoring, > see the man page for bpf. Otherwise, you'll have to explain what you > mean by "TCP intercept", it is not a terminology in common use. It's a Cisco term. From what I can tell, it essentially proxies all TCP sessions, but solely to shorten the 3-way handshake timeout and trap SYN floods before the host sees them. It's useless for protecting modern systems, but if you have a lot of legacy OSes in your network, TCP Intercept will protect them all without forcing you to upgrade them. http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/secur_c/scprt3/scdenial.htm I don't trust a border router to proxy every TCP session going through it, though. Since the router doesn't know the capabilities of the 2nd host at the time it proxies the connection from the 1st, you can't negotiate any enhanced TCP features like SACK or rfc1323 (window scaling or timestamping). -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ptrace(PTRACE_SYSCALL,...
Hello, guys I'm porting ltrace to FreeBSD and have one little question. ltrace uses non-standard PTRACE_SYSCALL request, which tells the kernel to stop traced process on every syscall entry and notify the parent. It makes us possible to trace child's syscalls and *catch execve/xfork events* and many more. BTW, that request is non-standard and FreeBSD doesn't support it. So, guys, what is a right way for a parent to catch child making syscall under FreeBSD? I have dosen k-mode solutions but how to do that from user-space? Thanks you very much! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: UFS block size vs. write speed
On Fri, Apr 20, 2001 at 05:54:26AM -0700, Alfred Perlstein wrote: > > PS: The tests were already done with the fs mounted async. The > > drive in question communicates at UDMA/33 on a PIIX4 controller in > > an AMD K6/2 233 system. > It's funny, but you have the ideal system for an interesting > optimization I've always wanted to try. Since you seem to be > reading over the network, have you tried doing this, creating > the file and then using ftruncate on it to extend it, then use > mmap() and read directly from the socket into the mmap'd area. I've implemented a quick hack on the BSD ftp-client: in the original recv-file function data is read from a socket into a buffer, which is then written to a file. I've mmap-ed the file, and rather than reading from the socket into the buffer, I read directly from the socket into the mmaped region. I use the MAP_SHARED and MAP_NOSYNC flags, and especially the latter makes a huge difference. The files are read using FTP with a buffer size of 64 kb. They are read from a Linux 2.4 machine with cartloads of memory and I make sure the Linux box has the files cached in memory. The Linux machine is connected to the same 100 MBit/FDX switch and network congestion is virtually non-existant. Because the FreeBSD machine (the K6/2 233) only has 64 MB of RAM, I've made the files small (10 files of 4 MB each, and later 5 files of 8 MB each). The normal BSD ftp-client reads all the files a approx. 6.5 to 7 Mbyte/s and this speed is more or less constant for all the files. The mmap-ed version of the ftp-client reads the first few files at 8 to 8.5 MByte/s after which the throughput collapses due to the limited amount of memory available for caching. I've noticed that using madvise() with MADV_WILLNEED or MADV_SEQUENTIAL does not make that much of a difference. Conclusion: using the mmap trick, the box displays the ugly "all your system is one big write cache" Linux-behaviour ;) Until memory is full that is, after which throutput becomes lousy (4.5 Mbyte/s). > You may have to experiment with several different madvise() flags > to get optimal performance. Or you may discover that doing this > "trick" actually makes performance worse because of the way > the trick screws with what the vm system expects. > I think a combination of MADV_SEQUENTIAL and/or MADV_WILLNEED > could do the trick. See above. Niek -- Conscience doth make cowards of us all. -- Shakespeare To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
help To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP intercept?
"E.B. Dreger" wrote: > > Greetings all, > > I'm no kernel hacker, and trying to think of useful little projects to > change that. ;-) > > AFAIK, FreeBSD lacks support for TCP intercept. Is anyone already working > on this? Would it be of interest to anyone? My initial thoughts are that > it should be implemented in the same neighborhood as stateful firewall > code, as the two are rather closely related. If you mean IP forwarding, you can do that with ipnat (part of ipfilter) or with natd. If you mean network interface monitoring, see the man page for bpf. Otherwise, you'll have to explain what you mean by "TCP intercept", it is not a terminology in common use. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
