Re: My project wish-list for the next 12 months
Ryan Sommers wrote: Scott Long said: 2. New installer. I know some people still consider this a joke, but the reality is that sysinstall is no longer state of the art. It's fairly good at the simple task that it does, but it's becoming harder and harder to fix bugs and extend functionality in it. It's also fairly unfriendly to those of us who haven't been using it since 1995. The DFly folks have some very interesting work in this area (www.bsdinstaller.com) and it would be very good to see if we can collaborate with them on it. I've spent a good deal of time taking notes and diagrams of what I wanted from a new installer. However, time constraints have kept me from actually putting any of it to code yet. I've looked at the DFly installed quite a bit and I like what it offers, however, I have a few complaints with it. Quite honestly I wasn't impressed with the code. Another issue I had with the dfly installer was one point I believe needs to be central to any next-gen installer. Internationalisation. My idea of an installer front-end would use a dynamically loadable language library. All resources of the front-end (ie strings, images, etc) would be packaged into a seperate language-pack. These language-packs can then be grouped together into a language library. A few basic packs would be distributed with the default library but other libraries could easily be substituted to make localized distribution sets with little trouble. The benefit of this is that instead of translating the code you would only need to translate the language-(pack|library). I think this would greatly simplify translation and make a seperation between language and the front-end code. This is where my complaint with Dfly comes in, upon reading the source, there are string constants everywhere. Perhaps I am missing something, but this means that in order to supply localization support much work would need to be done to find some scheme that doesn't mean translating the source. I have quite a bit of notes on seperation and even down to specific methods and sub-libraries necessary for the back-end. Perhaps if I have some time soon I'll put it into a PDF somewhere. Has anyone else put much thought into this? Yes, we have. I18n is something that we're actively working on implementing, and is something that we take quite seriously. I know that not very many FreeBSD developers use IRC, but we are all available in #dfinstaller on EFNet. We're using gettext for this at the moment. Kind regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: My project wish-list for the next 12 months
Jose M Rodriguez wrote: El Jueves, 2 de Diciembre de 2004 02:23, Peter Kieser escribió: Scott Long wrote: 2. New installer. I know some people still consider this a joke, but the reality is that sysinstall is no longer state of the art. It's fairly good at the simple task that it does, but it's becoming harder and harder to fix bugs and extend functionality in it. It's also fairly unfriendly to those of us who haven't been using it since 1995. The DFly folks have some very interesting work in this area (www.bsdinstaller.com) and it would be very good to see if we can collaborate with them on it. Please, don't change /stand/sysinstall *too* much, there is really nothing wrong with the interface of it, and it's what makes FreeBSD so "quick" to install. At the very least, make sure you do NOT go for an XFree86 installation, and keep to the "KISS" approach. Visually wise, theres nothing wrong with the current installer.. and its one of the things I "promote" about FreeBSD -- the ease to install. It's small, its fast.. and it works, however in error situations it does mess up badly. I second that. It's the biggest thing we can put in a floppy. But, if works on a new installer are needed, this must be neccesary: sysinstall is only the most user related thing of and overall process. I think this must begin with taking /usr/src/release out of /usr/src and work on a new release build system. Also, I can remenber, al last, other previous try. Please, use a safe path. As a reference, Mandrake Drakx is accesible via cvs (but gpl). http://www.mandrakelinux.com/en/drakx.php3 As anaconda (which use python instead of perl) is an installer working from a system interpreter in a big mdfs. works over perlgtk2 and a vesa X server. This may be used in FreeBSD for cdrom/pxe installs Anaconda is also GPLed and also requires a good few changes for most of it to run under FreeBSD. I haven't made any of these changes, but we looked into using Anaconda in DragonFly before we started on our own installer, and it would have just been too much work for the deadline we had (our 1.0 installer was written in less than 3 months!). Yes, it is in Python, but all the VESA stuff is via framebuffer, not an X server, so it's not something that we could use easily. At least, this was the case when I researched it in May. Anything GPL probably won't qualify in the first place, due to obvious license incompatibilities. While I don't want to sound shameless, I do urge you who are used to sysinstall to take a look at our installer -- http://www.bsdinstaller.org. It's very simple to extend, and it's not very large. I haven't looked at Drakx at all, so I can't say anything useful about that. HTH, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple IPs in jail
Justin Hopper wrote: On Wed, 2004-12-08 at 00:26 -0800, Aaron Glenn wrote: On Wed, 08 Dec 2004 00:23:24 -0800, Justin Hopper <[EMAIL PROTECTED]> wrote: Two questions: 1) Is there any formal plans to incorporate the functionality of jails binding multiple IPs into the FreeBSD base any time soon? Someone hasn't read up on 5.x... I'm confused. I've been running and developing on 5.x for a few months now, and I'm pretty sure that multiple IPs are not supported (it's always possible that I've missed something...). I was curious if Poul or anyone else had plans to put the functionality into the base system in the near future? Correct. 5.x does not have this feature; Aaron, please read for yourself before you are rude towards others. 2) Has anyone used Pawel's multiple IP patch in a semi-production environment? Can anyone report any problems or issues that they've had with it? I toyed with it at home without a single issue. Still, in a hosting environment I'd use 5.x Are you sure you toyed with it? And in a production environment, I'd still recommend 4.10. The patch from Pawel that I was looking at was "against-CURRENT", so I was assuming that was for 5, and not some 4.x-CURRENT branch? Correct. Pawel's patches haven't been incorporated for various reasons, but I'm not a committer, so I won't give them. There have been several threads on the list questioning this over the last year and a half. I have run the MIP patch and found no problems. I believe there is a race condition that it introduces, but that could be irrelevant / incorrect information. I'll leave it up to PJD and others to provide any more information if it is necessary and to you to search the lists for the other relevant threads. Kind regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple IPs in jail
Chris Howells wrote: On Wednesday 08 December 2004 08:23, Justin Hopper wrote: 1) Is there any formal plans to incorporate the functionality of jails binding multiple IPs into the FreeBSD base any time soon? 'ifconfig alias' Please, people, read his question. Into JAILS. When you attempt to add an alias into a jail: j02# ifconfig fxp0 alias 192.168.2.1 ifconfig: ioctl (SIOCAIFADDR): permission denied Thanks. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multiple IPs in jail
Justin Hopper wrote: [snip] Thanks for understanding my question, Devon. I guess at this point I'll patch a system here and begin testing with it, and hopefully PJD or PHK or somebody else @freebsd will respond with any plans to roll this functionality into the base system. It's really not a problem if there is no plans to do it, I just don't want to spend a lot of time fiddling with a patch and then find it in the base system in 5.4 or something. No problem. Let me know if you need help getting it to work. I know there have been some changes since the patches were written and that it probably won't apply cleanly. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Ziatech 5503 watchdog driver
Hey, I'm busy writing a Ziatech 5503 watchdog driver for FreeBSD (and porting all the watchdog stuff to DragonFly BSD) and Plan 9. For my driver, I have no way to identify that the system has the driver, so I wanted to make it conditional on options ZT5503 existing in the kernel configuration file. I have a couple of related questions: 1) Where in the tree should my zt5503wd.c file be placed? 2) Regarding watchdog.h; this device supports other times than those provided from between 250MS to 256S. Hope nobody minds this changing :). 3) To make sure I understand how this works: o The device is compiled in / loaded o watchdogd is used to tell the system to start the timer o I get a bunch of flags in my eventhandler function's 2nd argument that I can then use to write to my device's registers with the proper information The first and third questions are the most important, I think. --Devon pgpKSN1sdBwYt.pgp Description: PGP signature
Re: Ziatech 5503 watchdog driver
On Fri, Mar 18, 2005 at 03:55:53PM -0700, Warner Losh wrote: > > I'm busy writing a Ziatech 5503 watchdog driver for FreeBSD (and > > porting all the watchdog stuff to DragonFly BSD) and Plan 9. For my > > driver, I have no way to identify that the system has the driver, so > > I wanted to make it conditional on Rather, I have no way to identify that the system has the device :). > > options ZT5503 > > That's not a good enough reason to make it an option, it should really > be a device. Users that want it can add it to their kernel config. > In fact, they'd have to add it either way, so why make it weird for > them. > > Put this device on the ISA bus, give it an identify routine that > always adds it (this isn't GENERIC safe, but since there's no way to > know the device is there, you are stuck with that). OK. I don't know a hell of a lot about how the ISA bus works, though I suppose that I remember that things using the old SB 16 cards (Wolfenstein, anyone?) would simply probe various I/O ports. Unfortunately, in my case, there are really no board specific I/O registers that will give me information I can detect (or so it seems from the manufacturer's manuals), though I am going to write a couple of tests today to read some of these registers and see if there is any useful information contained within them which I might use to probe. Assuming no useful information exists, is it enough to let the device attach regardless if the user has device zt5503 in the configuration file? Maxime suggested that I use device hints to gather the port and such. Where should I put these hints? NOTES? If I understand correctly, to hook this up into the build, I will still have a line in files which will look something like: dev/ziatech/zt5503.coptional zt5503 Hm, Ziatech is now Performance Technologies. Should that perhaps be dev/pt then instead? > > existing in the kernel configuration file. I have a couple of > > related questions: > > > > 1) Where in the tree should my zt5503wd.c file be placed? > > usually these thigns go in dev/foo/foo.c. However FreeBSD and > DragonFly have differeing layouts. FreeBSD has a modules subtree to > build modules, while DF has it in the dev tree. The dev tree is also > partitioned so it would be in dev/misc/foo/foo.c. Yeah, I figured I'd ask Matt or Joerg where it'd best go there :). I Think the preferred location was dev/misc/foo as you suggest. > > 2) Regarding watchdog.h; this device supports other times than those > > provided from between 250MS to 256S. Hope nobody minds this changing > > :). > > Nope. :-) Ok then :) > > 3) To make sure I understand how this works: > > o The device is compiled in / loaded > > You'll need to make it a real device if you want loading to work. The > alternative is to make it a pseudo-device, but that's more hassle than > it is worth since you need to access resources. An option definitely > won't work. Another good reason to not write it as such. > > o watchdogd is used to tell the system to start the timer > > o I get a bunch of flags in my eventhandler function's 2nd > > argument that I can then use to write to my device's > > registers with the proper information > > These don't look like questions... They're not stated as such; I've only taken a brief look around the watchdog functionality and I just wanted to confirm that this is how the stuff works so I don't end up goofing it up :). > > Warner Thanks for the help! --Devon pgpEDn9ivlh3s.pgp Description: PGP signature
Re: Ziatech 5503 watchdog driver
On Sat, Mar 19, 2005 at 09:02:15AM +0100, Devon H. O'Dell wrote: > On Fri, Mar 18, 2005 at 03:55:53PM -0700, Warner Losh wrote: > > > I'm busy writing a Ziatech 5503 watchdog driver for FreeBSD (and > > > porting all the watchdog stuff to DragonFly BSD) and Plan 9. For my > > > driver, I have no way to identify that the system has the driver, so > > > I wanted to make it conditional on > > Rather, I have no way to identify that the system has the device :). AHA! But I have finally found something that will make my life a little easier, I think. I just noticed a read only register with a default value of 0x80 and tested it. It returns 0x80. Is this enough to test on / probe for? --Devon pgpXutcVaHxAF.pgp Description: PGP signature
Re: Ziatech 5503 watchdog driver
On Sat, Mar 19, 2005 at 09:43:41AM +0100, Devon H. O'Dell wrote: > On Sat, Mar 19, 2005 at 09:02:15AM +0100, Devon H. O'Dell wrote: > > On Fri, Mar 18, 2005 at 03:55:53PM -0700, Warner Losh wrote: > > > > I'm busy writing a Ziatech 5503 watchdog driver for FreeBSD (and > > > > porting all the watchdog stuff to DragonFly BSD) and Plan 9. For my > > > > driver, I have no way to identify that the system has the driver, so > > > > I wanted to make it conditional on > > > > Rather, I have no way to identify that the system has the device :). > > AHA! But I have finally found something that will make my life a > little easier, I think. I just noticed a read only register with a > default value of 0x80 and tested it. It returns 0x80. Is this enough > to test on / probe for? > > --Devon Sorry, hate replying to myself. Turns out the value here is variable. Assuming I cannot find anything to identify the system, can I simply attach the driver if it is enabled in the configuration file? --Devon pgpiI4n0WkP7o.pgp Description: PGP signature
Re: Ziatech 5503 watchdog driver
On Wed, Mar 23, 2005 at 02:24:54PM -0500, John Baldwin wrote: > On Saturday 19 March 2005 04:04 am, Devon H. O'Dell wrote: > > On Sat, Mar 19, 2005 at 09:43:41AM +0100, Devon H. O'Dell wrote: > > > > Sorry, hate replying to myself. Turns out the value here is variable. > > > > Assuming I cannot find anything to identify the system, can I simply > > attach the driver if it is enabled in the configuration file? > > Yes. See the identify routines for things like apm and pmtimer for examples. Thanks, looks like I will have to do it this way. :) I'm going to have time for it this weekend, so it should be ready by Monday. --Devon > -- > John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > pgpKk4l3fEtf6.pgp Description: PGP signature
Re: organization
On Mon, Mar 28, 2005 at 01:42:16PM -0500, c0ldbyte wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 28 Mar 2005, mohamed aslan wrote: > > >hi guys > >it's my first post here, BTW i was a Linux hacker and Linux kernel > >mailing list member for 3 years. > > > >and I've a comment here , i think the freebsd kernel source files > >aren't well organized as Linux ones. > > Well thats nice, Didnt your mommy say once to you before "If you dont have > nothing good to say then dont say nothing" ?. Thats not a really detailed > look into where you think the files are not well organized. Personly I > think you have had your head stuck in the Linux culture to long to comment > on anything going on with the Freebsd code or how the system is layed out. Perhaps you should take a bit of your own advice `c0ldbyte'. I'm personally sick of your condescending attitude towards everybody on the public lists. Cut it out. --Devon pgpNJ6xL4OHDT.pgp Description: PGP signature
Re: Fwd: 5-STABLE kernel build with icc broken
On Tue, Mar 29, 2005 at 02:12:53PM +0100, David Malone wrote: > On Tue, Mar 29, 2005 at 09:11:07PM +1000, Peter Jeremy wrote: > > That's almost a year ago and specifically for the amd64. Does anyone > > know what the results were? > > I had a quick dig around on cvsweb this morning: > > > http://grappa.unix-ag.uni-kl.de/cgi-bin/cvsweb/src/sys/i386/i386/bcopy.s?cvsroot=dragonfly > > > I dunno if Matt has benchmarks for before and after. > > David. I believe it was asserted on the list that the modification doubled the performance. I have not tested this. --Devon pgpvyrjtIvlIN.pgp Description: PGP signature
Re: C programming question
On Mon, Apr 04, 2005 at 11:43:21AM -0700, Matt wrote: > I need some help understanding some C code. > > int (*if_ioctl) >(struct ifnet *, int, caddr_t); > > int (*if_watchdog) >(int); > > Can someone break down these declarations (if that's what they are)? Is > this a form of typecasting? Thanks for your help. These are pointers to functions accepting arguments of type: struct ifnet *, int, caddr_t and int both returning type integer. In the structure in which they are defined, they can be called with structure.if_ioctl(ifnet, int, caddr_t) Kind regards, Devon H. O'Dell pgpdBYRntqE5Q.pgp Description: PGP signature
Re: Configuration differences for jails
On Thu, Apr 21, 2005 at 08:23:46AM -0400, c0ldbyte wrote: > On Thu, 21 Apr 2005, Joerg Sonnenberger wrote: > > >On Thu, Apr 21, 2005 at 07:39:08AM -0400, c0ldbyte wrote: > >>Now if that last question is correct and thats the proccess you are using > >>to create a jail then depending on the situation wouldnt that inturn > >>defeat some of the main purposes of the jail, like the following. If you > >>mounted your "/bin" on "/mnt/jail/bin" then if a person that was looking > >>to break in and effect the system that is currently locked in the "jail" > >>all he would have to do is just write something to the "jail/bin" which is > >>actualy your root "/bin" and then the next time a binary is used from your > >>root directories it could still infect the rest of the system ultimately > >>defeating the purpose of what you just set up. To my understanding and use > >>a jail is somewhat totaly independent of the OS that it resides in and > >>wont be if you are using nullfs to mount root binary directories on it. > > > >ro mount as written by grant parent protects against this. > > > >Joerg > > Right, I saw the (ro) option as you specified, but still there have > been flaws in the sytem and forseen more flaws to come as allmost > any programmer these days come accross and to just rely on it being > (ro) just seems kind of not something that you should look to totaly > to protect the system that the jail resides on. Even though in the > unpredicted future a jail could be broken out of to such a instance > I consider it to be a safer practice to just make installworld > $DESTDIR && make distribution DESTDIR=$DESTJAIL -DNO_MAKEDEV_RUN > and just delete stuff out of $DESTJAIL that you dont need for things > to run properly and then there is never a instance or less of a > chance that things will go wrong for you. As I said before depending > on the use of the jail as well would also be a determination on > how the jail is setup to but should never interact with the main > system that holds the jail. > > Thats only my opinion though and just releaves thought about other > security issues that deal with the main part of the system. Well he's per his statement using it in a virtual server environment where he would simply like to ease administrative work by reducing the number of jails that need to be upgraded every time. The likelyhood of there being an issue with read only mounts is quite low. I'd consider the ability to break out of a jail as more of a threat than that. Additionally, I'm pretty sure it wouldn't be very difficult to prove that there are no issues with this. Read only mounts are so useful, and frequent, that I'm quite sure we'd know if there were security issues with them. As with any jail, you are in part trusting the security of the main machine, since it has access to all the jailed environments. I'd be worried about this being compromised before I point out possible (non-existant) issues with read-only mounts. --Devon > -- > ( When in doubt, use brute force. -- Ken Thompson 1998 ) > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > > !DSPAM:42679acd458596534657138! > pgp7y860eARhU.pgp Description: PGP signature
Re: ABV.BG ??????????? ???????
On Thu, Apr 21, 2005 at 03:46:43PM +0300, freebsd-hackers@freebsd.org wrote: > blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! Turn this off. pgpfqXCgnd4rU.pgp Description: PGP signature
Re: ABV.BG ??????????? ???????
On Thu, Apr 21, 2005 at 02:47:32PM +0200, Devon H. O'Dell wrote: > On Thu, Apr 21, 2005 at 03:46:43PM +0300, freebsd-hackers@freebsd.org wrote: ^- whoops, I didn't notice that. > > blagodarq za izpratenoto ot Vas pismo nai skoro shte vi otgovorq!! > > Turn this off. Argh, it seems that this person sends the message from the list address. It's been going on for months, really, can't the subscribed address be unsubscribed? pgpuFWrKDkGnM.pgp Description: PGP signature
Re: prioritizing small ip packets?
Baldur Gislason wrote: IPFW does have a queue feature which is a part of dummynet. You can match packets based on size and send them to different queues. Baldur On Mon, Jun 13, 2005 at 09:36:57PM +0300, Erik Udo wrote: I came across this idea for prioritizing small IP packets, so that for example HTTP requests, game packets and other small, but importat packets would get uploaded before the big packets. Big files are usually uploaded in bigger packets, right? So, i haven't found a way to make this happen, i googled for it but didn't find anything. Does PF or IPFW have this feature? I'm not sure the rationale is appropriate, though. You should be more worried about prioritizing ACKs if this is an asynchronous low-speed connection. --Devon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tuning to run large (1000+) numbers of null_mounts
2006/1/18, Ensel Sharon <[EMAIL PROTECTED]>: > > I am running over 2000 null mounts on a FreeBSD 6.0-RELEASE system. I am > well aware of the status of the null_mount code, as advertised in the > mount_nullfs man page: > > THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T > WORK) > AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR > OWN > RISK. BEWARE OF DOG. SLIPPERY WHEN WET. This has been removed from the manpage because it's no longer accurate. I believe I recall seeing another thread with someone asking whether it still applied and the answer was, ``No.'' --Devon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Sun DTrace on FreeBSD
2006/3/15, Peter Jeremy <[EMAIL PROTECTED]>: > About six months ago, there was a lot of press publicity given to a > port of Sun's DTrace code to FreeBSD. Does anyone know what (if > anything) is happening to this? Google doesn't turn up anything more > recent and I don't recall reading anything on the mailing lists. It's part of my Copious Free Time stuff. I'd love to be able to work on it more often, but with what I'm doing these days, there is not a whole lot of time. I do have a little more progress on the DTrace provider (which includes the pseudo-device) that hasn't been committed to my Perforce tree yet. I certainly haven't given up on the project; I simply haven't had the time to make as much progress as fast as I did in the beginning. --Devon > -- > Peter Jeremy ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Minidumps in FreeBSD 4
And my apologies to those of you who found out that this file didn't exist on the server yesterday -- it should be there now. --Devon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
vr(4) performance
Hey all, So, vr(4) kind of sucks, and it seems like this is mostly due to the fact that we call m_defrag() on every mbuf that we send through it. This seems to really screw performance on outgoing packets (something like 33% the output efficiency of fxp(4), if I'm understanding this all correctly). I'm sort of wondering if anybody has attempted to address this before and if there's a way to possibly mitigate this behavior. I know Bill Paul's comments say ``Unfortunately, FreeBSD FreeBSD doesn't guarantee that mbufs will be filled in starting at longword boundaries, so we have to do a buffer copy before transmission.'' -- since it's been a long day, and I'm about to go home to grab a pizza and stop thinking about code, would anybody mind offering suggestions as to either: a) Pros and cons of guaranteeing that they're filled in aligned (and possibly hints on doing it), or b) Possible workarounds / hacks to do this faster for vr(4) Any input is appreciated! (Except ``vr(4) is lol'') Kind regards, Devon H. O'Dell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Single UDP sockets : duplex capable?
2006/11/28, Garrett Cooper <[EMAIL PROTECTED]>:
Hello,
Just wondering, abstractly..
Both sides can read from and write to the socket file descriptor.
You'll need to develop a protocol to determine when either given side
is expecting to receive or to send data (if both sides sit around in
read(2), you're not going to get much done) :)
--dho
-
| A -[socket (UDP)]-> B |
-
A creates a UDP socket (call it 's1') to talk to B.
Can B use the same socket ('s2') to talk to A using read(2) or
recv(2), or does A have to accept(2) traffic from B using a different
socket?
The programming language I'm using is C (not C++).
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: unique hardware identification
2006/12/19, Koen Martens <[EMAIL PROTECTED]>: Hi All, I was wondering, if something like a unique hardware identification would be possible on FreeBSD. I'd like a machine to authenticate to a server, for which it will need a unique identification. Problem is, it should be generated automatically and not easy to fake / detect without already having root access to the box. I'm thinking of something like combining serial numbers from CPU/disks for example, but there does not seem to be a clear way to obtain these (not all cpu's even have a serial number in there). I am just inquiring if someone on this list has an idea that might help with this problem. Gr, Koen Hey Koen, I know a lot of people / companies use the MAC address of a given interface for this purpose, but it's not generally very useful since most interfaces will allow you to set your own MAC address. Something you could use instead is a one-wire device, attached to the motherboard (if it has a header for it). If the motherboard does not, you can get LCDs from e.g. CrystalFontz that provide an interface to such devices. The Dallas one-wire thermometers have a unique 64-bit identifier on them, however this is only really useful if you have the ability to control the hardware platform. If you are attempting to identify a specific hardware platform (e.g. a standard set of motherboards and devices), you can enumerate devices and device IDs on the PCI bus, creating some sort of hash of those. In the end, with the client controlling the hardware, client-side security and validation is rather difficult. Even hacking the kernel to only run signed binaries is going to be difficult to keep secure, even keeping the key in some hardware secured storage, shipping the system without a debugger or symbols, and controlling the hardware. Thank you, media, for blowing the Pentium III CPUID feature up into something horrible. Uniquely identifiable hardware is very useful when licensing :\. Regarding your questions, the serial number of the hard drive is usually not too difficult to figure out. Take a look at atacontrol(8), for instance: dho# atacontrol cap ad4 Protocol Serial ATA II device model WDC WD1600JS-75NCB2 serial number WD-WCANM3753524 The serial number should be unique. camcontrol(8) can probably give you similar information for SCSI disks. Hope this is of some use. I'd be interested in seeing what others are doing. Kind regards, Devon H. O'Dell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: harddrive no memory ---FreeBSD scenario
2007/3/8, Rudy Rockstar <[EMAIL PROTECTED]>: If I had say a 15k rpm drive, would it be possible to configure the FreeBSD kernel to not use system memory and ONLY the hard drive for caching instructions and executing operations? No, probably not. Also, a 15K RPM drive still isn't very fast (compared to RAM) Can FreeBSD be built to run on a system memory free system (can we also circumvent the system cache for that matter), if not is it very difficult to make it run on such a systemme. Apart from wondering how you're getting the motherboard to get past POST without RAM, I'm wondering how you'd get the bootloader and kernel to load in a RAM-less system. You could probably do it for a system with a minimal amount of RAM and let (most) everything run in swap, but that's just going to be ridiculously slow. regardz, ~Rudy Any particular reason you're looking into doing this? Kind regards, Devon H. O'Dell _ [EMAIL PROTECTED]&% ---_ http://www.[1]rudyrockstar.com -_-__--- -- - ---CELLY--678.984.3831: RiP 1997 -2004 -AIM:rudyrockstar- --- ---- -ICQ:6636643-- --- -- -- --- -YahoO:rudyrockstar- --- - -MSN:[EMAIL PROTECTED] ~~~!~!~!~~~!~~~~~~ _ [2]Find what you need at prices youll love. Compare products and save at MSN(r) Shopping. References 1. http://www.rudyrockstar.com/ 2. http://g.msn.com/8HMAENUS/2728??PS=47575 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SimpleTech USB HDD driver
Scott Mitchell wrote: On Mon, Sep 22, 2003 at 09:12:50AM -0400, [EMAIL PROTECTED] wrote: No worries - it's what the lists are for. AFAIK all USB mass storage devices should be supported by the umass driver, but some devices will have issues. I use various flash cards and 'pen drives' all the time - a real hard disk should look the same to the driver. Bear in mind that 4.x only supports USB 1.1, so even if you have USB 2.0 ports on your machine, and a USB 2.0 drive, the most you'll get out of it is somewhere in the region of 1 MB/s. Look forward to hearing of your success - good luck! Scott Well, what do you know, a quick mount_msdos /dev/da0s1 worked just fine ;). Something to add to the hardware compatibility list I guess. Here's the dmesg entry: umass0: In-System Design USB Storage Adapter, rev 2.00/11.01, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 650KB/s transfers da0: 117800MB (241254720 512 byte sectors: 64H 32S/T 52264C) I did get the below message, but it does not seem to goof up anything. (da0:umass-sim0:0:0:0): READ(6)/WRITE(6) not supported, increasing minimum_cmd_size to 10. My laptop only has USB 1.1 anyway (it's an old Latitude L400 -- don't think it has 2.0 anyway). 650KB/s is fine. I'm just using it to back up my *cough*VERY LEGAL*cough* mp3s ;) Thanks for setting my head straight about this. I think this should be listed on the web page. The reason I asked in the first place is because there are no mailing list articles about this (that Google could find with about 31899821498 different queries, anyway ;) and the webpage gives me the idea that it doesn't support larger devices. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SimpleTech USB HDD driver
Scott Mitchell wrote: This is fine - just an informational message rather than anything actually wrong. Out of curiosity, what does that indicate (or where can I find comments in the source)? Indeed... the docs should probably just list the classes of device that should work, rather than specific instances. I did once start updating the umass(4) manpage to say this, but got discouraged by a flurry of list messages complaining that XYZ device didn't work - didn't feel up to documenting the intricacies of the quirking mechanism. Now that this is less of a problem, I should probably pick that up again. Anyway, glad you got it working. Yes, I also got an email from the product manager of the SimpleDrive asking me what sort of documentation I was looking for. This seems like an open-source friendly company; just so that we can keep this in mind in case there are portable storage device/hard drive issues in the future. It looks like Firewire is also taken care of, but you never know what else there might be in the future. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: two soundcards and realplayer
Martin Ván(a wrote: Hi, I use two soundcards on my Freebsd5.1 box - Sb Live and SB AWE64, FreeBSD somehow figured out that Live is better than Awe and made it "primary" soundcard. The reason I have AWE still in computer, is it's amplyfing skills /2x4W/ so I don't need aditional amplyfier. With Xmms it's fine, I just changed confile and enjoy music. But I can't figure out how to swap soundcards in RealPlayer and Mplayer. Is there a way how to change it system wide? Thank you Martin Well, I suppose you could do something like mv /dev/dsp0 /dev/dsp.tmp && mv /dev/dsp1 /dev/dsp0 && mv /dev/dsp.tmp /dev/dsp1 Not sure how terribly well that'd work (and it's a horrendous hack), though you can select the output device in mplayer with the ao: option. I don't know anything about RealPlayer, so I wouldn't be able to help you there. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
IPFW and the IP stack
I've been looking through the IP stack for shits and giggles and was wondering why a few things are the way they are with IPFW's implementation. I went back through the CVSWeb stuff to check out the changes and it appears that most of my questions are purely cosmetic issues; but I still don't understand them. Specifically, pretty much everything in the iphack: section relied on IPFW being defined in the kernel configuration. Several checks went away when COMPAT_IPFW was defaulted into the kernel, then several were removed to make a buildable kernel without having options IPFIREWALL defined in the kernel configuration. Throughout these changes, several variables related to IPFW were removed from #ifdef IPFIREWALL checks. At this point, most IPFW variables are initialized by default (including some stuff for natd) and every call to ip_input() does a check at if (fw_enable && IPFW_LOADED) (I believe this is true for ip_output() as well). Why are these variables and sections compiled in by default instead of left out if no firewall is existent in the kernel? Hope that doesn't sound too ambiguous :) Kind regards, Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW and the IP stack
Op 4-dec-03 om 15:28 heeft Marko Zec het volgende geschreven: On Thursday 04 December 2003 15:13, Devon H.O'Dell wrote: I've been looking through the IP stack for shits and giggles and was wondering why a few things are the way they are with IPFW's implementation. I went back through the CVSWeb stuff to check out the changes and it appears that most of my questions are purely cosmetic issues; but I still don't understand them. Specifically, pretty much everything in the iphack: section relied on IPFW being defined in the kernel configuration. Several checks went away when COMPAT_IPFW was defaulted into the kernel, then several were removed to make a buildable kernel without having options IPFIREWALL defined in the kernel configuration. Throughout these changes, several variables related to IPFW were removed from #ifdef IPFIREWALL checks. At this point, most IPFW variables are initialized by default (including some stuff for natd) and every call to ip_input() does a check at if (fw_enable && IPFW_LOADED) (I believe this is true for ip_output() as well). Why are these variables and sections compiled in by default instead of left out if no firewall is existent in the kernel? Perhaps to allow for IPFW to be loaded as a module? Marko *slaps self* This is obviously the most logical explanation. There's a good bit of questioning for PFIL_HOOKS to be enabled in generic to allow ipf to be loaded as a module as well. If this is the case, we'll have two firewalls that have their hooks compiled in by default allowing for them both to be loaded as modules. (Is this still scheduled for 5.2?) But at this point, there's no way to allow one to turn the IPFW hooks *off*. Is there a reason for this? Would it be beneficial (or possible) to hook ipfw into pfil(9)? This way, we could allow the modules to be loaded by default for both and also allow for the total absence of both in the kernel. Sorry if I've missed discussions on this and am being redundant. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPFW and the IP stack
On Thursday, December 4, 2003, at 05:28 PM, Robert Watson wrote: On Thu, 4 Dec 2003, Devon H.O'Dell wrote: This is obviously the most logical explanation. There's a good bit of questioning for PFIL_HOOKS to be enabled in generic to allow ipf to be loaded as a module as well. If this is the case, we'll have two firewalls that have their hooks compiled in by default allowing for them both to be loaded as modules. (Is this still scheduled for 5.2?) But at this point, there's no way to allow one to turn the IPFW hooks *off*. Is there a reason for this? Would it be beneficial (or possible) to hook ipfw into pfil(9)? This way, we could allow the modules to be loaded by default for both and also allow for the total absence of both in the kernel. Sorry if I've missed discussions on this and am being redundant. Sam Leffler has done a substantial amount of work to push all of the various "hacks"" (features?) behind PFIL_HOOKS, and I anticipate we'll ship PFIL_HOOKS enabled in GENERIC in 5.3 and use it to plug in most of these services. This also means packages like IPFilter and PF will work "out of the box" without a kernel recompile, not to mention offering substantial architectural cleanup. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Senior Research Scientist, McAfee Research This is great news and definitely something I am interesting in contributing to. Sam: how can I help with this? Kind regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SVBUG what happened tonight (12-04-2003)
At 08:11 AM 12/5/03 +, Mark Murray wrote: Hi Could you please discuss spam issues on a spam list. Your mail has nothing to do with FreeBSD. I'm sorry about your car accident, but that is also not hackers@ material. It is, however OK for [EMAIL PROTECTED] My friend... let me make this clear to you. My car accident no matter. You are an idiot. Get your head out of your ass. Thank you Jessem. Jesse, Please keep this crap off the FreeBSD mailing lists and in private emails. Thanks, Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Using the struct cmsgcred in practice
Hey everyone, I'm working on an application that needs to make use of the cmsgcred structure, but am unable to find decent documenation on it -- the only code I have found using it (via Google) is in PostgreSQL, but it's abstracted through multiple layers (the server code, in any case -- the client code is quite straightforward). Would anybody be able to give me tips on what to send to the client to request the data? I've been able to find the code to read the code from the client and to get the client to send the response to the server. But any simple client/server someone could hack up demonstrating this principle solely (or software package that's more straightforward and less abstracted that PostgreSQL) would be greatly appreciated. Kind regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "secure" file flag?
If you want an interesting problem to work on, come up with a solution to the keying problem for disk encryption. It somehow needs to allow automated, unattended reboots during "normal" operations but prevent attackers from compromising the system. Maybe you could have the system send an SMS message when it needs a key, you reply with a one-time key from your mobile phone? Actually, this is quite similar to what people at Vasco do (http://www.vasco.com). They make devices that (from what I can tell) hash a PIN and a timestamp (along with some other arbitrary values generated by a server, which are optional) and give you a return hash. From what I've seen, the hash is rather elementary and I feel somewhat silly using it to log into my bank. I sent an email to them a while ago; it seems that the security may lie somewhat on the knowledge of the hashing function. But there are definitely devices that do these sorts of things (although the ones from Vasco don't work with GSM, so sending the SMS back would have to go through the phone). Although, I must say, that sending the SMS via the phone is quite insecure as well. If you've the ability to send SMSes, you can most likely fake the address your SMS is coming from, just like you can fake an email. Although, AFAIK, it's a bit more difficult to track the origin of an SMS message. However, most new phones have J2ME capability. I hate Java, but since it's the HLL that we're allowed to use, we could make use of it. After Helix has had some time to be cryptanalyzed, it might be a good candidate for just this kind of application -- a lightweight, fast, easily implementable encryption and authentication algorithm (though it looks promising to me). Until then, some other kind of encryption/authentication could take place. In any case, many phones allow sockets to be created and sent (and if they don't, they most certainly support HTTPS channels). I think an app utilizing this would be a bit more secure in this scenario than one via SMS (or via the Vasco method, I don't have a ton of faith in their closed-source solution). This would be a good, mobile way to provide a one-time key, though. You might even be able to implement it to request keys from multiple administrators assuming the first administrator failed. Who knows. Haven't been following this discussing very closely, so feel free to poke me with a stick if I'm babbling about some obscure tangent. While you're in there, paint that bikeshed blue. Only if there's not someone painting it already :) -- Where am I, and what am I doing in this handbasket? Wes Peters [EMAIL PROTECTED] --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [patch] Raw sockets in jails
Christian S.J. Peron <[EMAIL PROTECTED]> scribbled: > Poul/group > > The following patch makes raw sockets comply with prison IP addresses. > Some tools such as traceroute(8) may require that the prison IP address > be specified on the command line. I.E. > > traceroute -s > > Otherwise it might fail. > > (because of this we may want to get rid of the > create_raw_sockets MIB all together). > > Anyway, take a gander at it (testers feedback welcome): > > Regards > Christian S.J. Peron Nice work! It doesn't seem that it would be very difficult to get this to comply with Pawels multiple IPs in jail patch, but it would have to be optimized a bit as the IPs are currently stored in a linked list in his patch and traversing that list to determine whether the IP complies with the jails allotted IP range is sub-optimal (as it would have to be done on a per-packet basis). If we could store those IPs in a hash table with a fast algorithm for O(1) lookup times, the prison subsystem would experience significant feature improvements. -- Kind regards, Devon H. O'Dell | [EMAIL PROTECTED] ICQ: 2903604| IRC: [EMAIL PROTECTED]/[EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: "Next Generation" kernel configuration?
Avleen Vig wrote: On Tue, Jul 20, 2004 at 07:39:31PM -0500, Conrad J. Sabatier wrote: Just musing on an idea here: I've been thinking for a while now about trying to write a tool to make kernel configuration easier, sort of a "make config" (as in ports) for the kernel, similar to what's available on some of the Linux distros. I've read over the other posts in this thread, but I cannot say I think this is a good idea. In fact, I think it's a very bad idea, but with very good intentions. Here's why.. I'm a strong proponent of user education. The FreeBSD handbook is one of the best education tools for someone who wants to use FreeBSD, right from beginner to more advanced levels. A "config tool", while useful for beginners, would quickly result is those beginners not learning about building a kernel themselves, copying GENERIC to `hostname -s | tr "[:lower:]" "[:upper:]"`, editing it, learning what is in LINT, remembering to look through there, etc. This process teaches users a lot about how a BSD kernel is configured, what options are availible, and where to look for more options. The end result would be more people building kernels themselves, but not knowing what is actually happening, or what more is possible. It would mean less educated users, and I don't think that is somewhere any organization needs to go (look at what happened to the average Microsoft user's IQ level, after people stopped using DOS and started having machines do the work for them). Like I said, I think your intentions are good, but I have concerns about the suggested solution. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" I wholly disagree. I think using an excuse ``people will let everything else do the work for them and nobody will ever learn'' to discourage the development of automation tools is very poor. Try applying that argument to any utility that you use. You'd have to write your own bloody operating system because ``learning's in your best interest''. I'm sure this will become another bikeshed, so I suggest whoever came up with the idea to put up or shut up. People are interested in solutions, not suggestions. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD Kernel buffer overflow
- Original Message From: Matt Emmerton <[EMAIL PROTECTED]> To: Mike Meyer <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: FreeBSD Kernel buffer overflow Date: 18/09/04 05:41 > > > - Original Message - > From: "Mike Meyer" <[EMAIL PROTECTED]> > To: "Matt Emmerton" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]>; "Avleen Vig" > <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; > <[EMAIL PROTECTED]> > Sent: Saturday, September 18, 2004 1:22 AM > Subject: Re: FreeBSD Kernel buffer overflow > > > > In <[EMAIL PROTECTED]>, Matt Emmerton > <[EMAIL PROTECTED]> typed: > > > I disagree. It really comes down to how secure you want FreeBSD to be, > and > > > the attitude of "we don't need to protect against this case because > anyone > > > who does this is asking for trouble anyway" is one of the main reason > why > > > security holes exist in products today. (Someone else had brought this > up > > > much earlier on in the thread.) > > > > You haven't been paying close enough attention to the discussion. To > > exploit this "security problem" you have to be root. If it's an > > external attacker, you're already owned. > > I'm well aware of that fact. That's still not a reason to protect against > the problem. > > If your leaky bucket has 10 holes in it, would you at least try and plug > some of them? > > -- > Matt Emmerton So should we stop the command ``shutdown -h now'' from working for root? After all, he can DoS the system with it? How about this: let's disallow root from loading kernel modules! That way this can't ever happen. Even better: Why don't we just not boot into a usable environment! Then we have NO security holes. You guys are failing to see: ROOT HAS OMNIPOTENT POWER. SOMEBODY MUST HAVE OMNIPOTENT POWER. THIS IS NOT A BUG. THERE IS NOTHING TO SEE HERE, MOVE ON. Not to be sarcastic, but you guys are missing the problem. The problem was that someone was unaware of a kernel API. When you start programming for the kernel, you need to make sure that the code is secure. If you think this is a problem, take a look at init(8) and learn about securelevels. What happened: someone was unfamiliar with the syscall API. They crashed their system. They screamed wildly, believing they'd found a buffer overflow, when they'd merely overloaded the function stack and screwed up the call. This caused the system to reboot. Solution: make it more clear that syscalls take only 8 arguments. Make it clear that you can pass arguments in a struct to a syscall. Make it clear that many/most syscalls do this anyway. If there's beef on this, take it to [EMAIL PROTECTED] --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 2 inet connections
Claudiu Dragalina-Paraipan wrote: Hi, I have this situation: 2 inet connection at 2 different ISP, one with 2Mbps and one with 128kbps; and a big NATed network behind it, and a small group of real addresses. I want to do this: use the first connection as "primary" connection, and if this fails, go to the second connection, as a backup. The problem is that none of the ISP will help me in any way, so I have to find a solution by my own. I am trying to avoid the making of a software that watches the connections and "declare" a line dead when no TCP connection can be made, thus switching to the secondary/backup line. I realize that there is no way of using the group of real addresses on the backup line, since they are not routed, but this is not of such importance. I need only to provide Internet connection for the NATed network. So... can someone provide me with some good practical advice for this situation ? NOTE: I want to use FreeBSD for this, so FreeBSD specific advices are welcome. In fact I don't even think of other solution. I realize that this is not a very common situation, and I hope I have explained it sufficiently clear. Thank you very much. Best regards, You might want to look at various patches for FreeBSD multipath routing that are available via the mailing lists. They're pretty easy to find with a search for FreeBSD Multimath routing via google. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new intrusion detection system
Tomas Pluskal wrote: Hello to all, I have implemented a new type of intrusion detection system for my Master thesis. I would like to announce this information, in case anyone would be interested in this research. The IDS system is designed as a kernel module for FreeBSD 5.2. It is inspired by the SpamAssassin program, which detects spam by applying a set of tests to every email message and counting a sum of point score generated by each test. My IDS system applies a set of tests to every running process in the OS and counts its score generated by the tests. Therefore, the purpose of the IDS is not to monitor the network traffic, but rather to monitor the process activity. The current system status is a "working prototype" - it is not ready for production usage, but it may serve as a good base for an interesting research. If you are interested in this topic, please read the details here: http://plusik.pohoda.cz/thesis/ Thanks, Tomas Hello Tomas, At a first glance of this email, I thought ``An IDS based upon SpamAssassin ideology? Intrusions differ too much from spam for this to be accurate!'' After reading your thesis, my ideas were changed. This work is certainly very interesting, and I encourage you to continue its development. Certainly one thing that would be desirable that I did not see listed in the improvements section (and many other IDS systems, such as Bro) would be the ability to carry out some action (instead of pure reporting) based upon behavior; this would allow for IDS as well as IPS behavior. I'm quite interested and impressed by the work you've done here. Do you have any plans of setting this up as a collaborative project? Can I help you by providing a place for you to do this? At the moment, I'm not able to provide much help for implementing any of the features listed in your thesis (although I am interested in working on and with this software at some point in the not-too-far future :)), but please let me know if I can help by providing resources, as this is something that I can do with little effort and in little time. Congratulations, and good luck with your study! Kind Regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new intrusion detection system
Brian Barto wrote: Very interesting stuff. Certainly worth more investigation. Something occurred to me while I read your thesis. Though maybe it was worth a mention. The TTL (time to live) could potentially cause the IDS module to be easily beaten. An attack could begin and immediately go into a sleep state with the intent to expire the TTL. Later resuming with it's actions going unnoticed. I hope to see more on this. I think it is a very creative and useful idea. Thanks, Brian This is certainly something that will need to be researched and tuned in practical environments. In many cases, it's not practical to wait for over a certain period of time to perform the combination of commands needed to exploit software due to network or file issues. But it is a very valid point. --Devon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
