ipfw1sysctl and lifetime
Hi: Anyone know what are the sysctl option to give more lifetime to net packets? Or another anything to elongate the net packets lifetime without use ipfw2? Thanks. -- http://pollo-es-pollo.blogspot.com Te lo traigo fresco. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gvinum during bootup
Rex Roof [EMAIL PROTECTED] writes: I'm running a FreeBSD6 machine current as of a few days ago and I'm working on a gvinum configuration, I couldn't find any place where it referenced gvinum on startup so after fussing around with the rc system a little, I wrote an /etc/rc.d/gvinum script that looks like so: what about just adding geom_vinum_load=YES to /boot/loader.conf? DES -- Dag-Erling Smørgrav - [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: KLD module with C++ iostreams ?
Aziz KEZZOU [EMAIL PROTECTED] writes: I am wondering if I can use c++ iostreams inside the kernel ? After all the code : cout Hello world! endl; ends accessing the stdout just like : printf(Hello world!\n); right ? There is no stdio in the kernel. So if I could compile my KLD module with static linkage to libstdc++, that should be ok, right ? No. DES -- Dag-Erling Smørgrav - [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: ipfw1sysctl and lifetime
On Thu, 21 Apr 2005, Omar Lopez Limonta wrote: Hi: Anyone know what are the sysctl option to give more lifetime to net packets? Or another anything to elongate the net packets lifetime without use ipfw2? Thanks. sysctl -a |grep ttl will grep for any matching (Time To Live) settings. if thats what your looking for. -- ( 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]
Re: Configuration differences for jails
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Apr 2005, Jeremie Le Hen wrote:
I'm trying to untangle myself on this issue. I have different
filesystems for /, /usr, and /usr/local, mounted in unusual places:
504,p0,1$ ls -l /usr{,/X11R6,/local}
lrwxr-xr-x 1 root wheel 18 7 nov 2003 /usr - fs/base/mount/usr/
lrwxr-xr-x 1 root wheel 25 8 nov 2003 /usr/X11R6 -
../../../apps/mount/X11R6
lrwxr-xr-x 1 root wheel 25 18 abr 20:40 /usr/local -
../../../apps/mount/local
I know I want to share /usr, but not /usr/local, and only parts of /. So
I mount_unionfs /fs/base inside the jail:
above:/fs/base/mount on /fs/jaildata/mount/fs/base/mount (unionfs,
local, read-only, noclusterw)
mount_nullfs(8) will mount one directory and all its content onto another
one, but there is no way to exclude one of the subdirectory. You
will instead have to mount each subdirectory you need, not more. One
other way do achieve this is to make a second null mount over the
directory you don't wan't to share (/usr/local) but I'm not aware of
the consequences of such setup in term of performance and stability.
But this way I don't get the automagically upgrade virtual hosts
behaviour I want, since I'm missing /{,s}bin, /lib and /libexec and I
definitely don't want to share /etc.
You won't have a one to one mapping between jail and null mounts. There
are generally multiple null mounts for a unique jail.
Considering your jail root is /jail/test, and you enabled the
jail_$jail_mount (jail_test_mount here) rc.conf(5) variable, here is
the content of /etc/fstab.test :
%%%
/bin/jail/test/bin nullfs ro 0 0
/sbin /jail/test/sbin nullfs ro 0 0
/lib/jail/test/lib nullfs ro 0 0
/libexec/jail/test/libexec nullfs ro 0 0
/usr/bin/jail/test/usr/bin nullfs ro 0 0
/usr/sbin /jail/test/usr/sbin nullfs ro 0 0
/usr/lib/jail/test/usr/lib nullfs ro 0 0
/usr/libexec/jail/test/usr/libexec nullfs ro 0 0
/usr/libdata/jail/test/usr/libdata nullfs ro 0 0
/usr/share /jail/test/usr/sharenullfs ro 0 0
/usr/compat /jail/test/usr/compat nullfs ro 0 0
%%%
I don't think it's easy to take /etc/ outside the root fs, but I don't
see how to share /bin or /lib without leaking info.
How do you handle this? What are those distribution targets and how can
I use them?
As I said above, null mount each directory.
Regards,
Now I havent caught this whole thread but to my understanding right now
you are talking about mounting nullfs's from the root filesystem /
onto the jail correct ?.
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.
With all due respect This is a bad idea given allmost any situation
that you would have to create a jail for a unsafe proccess or users.
- --
( When in doubt, use brute force. -- Ken Thompson 1998 )
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (FreeBSD)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xF7DF979F
Comment: Fingerprint = D1DC 0AA4 1C4E EAD4 24EB 7E77 B261 50BA F7DF 979F
iD8DBQFCZ5DfsmFQuvffl58RAi6FAJ4n1JeS/MCN2s7zowgWrMAzdnarowCfUQ5n
sVhxoQT+nepoMnj/yYckQbs=
=+Vmn
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configuration differences for jails
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 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sshd dieing? after applying FreeBSD-SA-03:12.openssh
In the future, please do as I did and publish whatever solution you find, my answer was somewhat lame but worked for me and will help the next guy. To the SSH server /etc/hosts I added the client machine, now when it gets to debug1: got SSH2_MSG_SERVICE_ACCEPT it hangs for only 75 seconds. Peace --Devon /~\ \ /Health Care X not warfare / \ Dubya won the digital vote Kerry won the popular vote From: Steven Hartland [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], freebsd-hackers@freebsd.org, [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 20 Apr 2005 14:07:21 +0100 Sorry I don't remember the solution we came up with. It was a long time ago. I think it was to do with DNS invalid / broken DNS or something like that but I couldn't say for sure. Regards Steve - Original Message - From: [EMAIL PROTECTED] This trouble hit me yesterday, 2005 Apr 19 Tue, Google led me to someone else with the exact same trouble. What use to ask the net if nobody publishes an ANSWER? A good netizen does the right thing. By citing the original question, I create a link to a possible answer. This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone (023) 8024 3137 or return the E.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: Configuration differences for jails
From: Jeremie Le Hen [EMAIL PROTECTED] To: ?? ?? [EMAIL PROTECTED] CC: freebsd-hackers@freebsd.org Subject: Re: Configuration differences for jails Date: Wed, 20 Apr 2005 16:37:15 +0200 Now with some distance, I must admit that all this gymnastic is quite boring. I now decided to run two virtual hosts as they are managed in a very natural way. These two hosts are just like two real boxes, one running Bind and the other one running Postfix. When I need to update something in the configuration, I login to the box with ssh(1). This take some more memory and in principle no CPU as all processes are sleeping most of the time. I forgotten to explain that using virtual hosts require some administration too in order to avoid wasting disk space. The jail(8) manual page advices to make world with DESTDIR set. I prefer using null mounts as it doesn't require additional disk space and an upgrade of the host will automagically upgrade virtual hosts. You will nevertheless have to make distribution and distrib-dirs. Here are the directories I advice you to share : /bin /sbin /lib /libexec /usr/bin /usr/sbin /usr/lib /usr/libexec /usr/libdata /usr/share /usr/doc /usr/compat /usr/ports Sharing ports may be more difficult as it may require sharing the port database, but I think it's still possible. Good idea! I will take a try! Regards Jas _ MSN Hotmail http://www.hotmail.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, 20 Apr 2005 16:38:42 +0200, Marc Olzheim [EMAIL PROTECTED] said: Btw.: I'm not sure write(),writev() and pwrite() are allowed to do short writes on regular files... ? I believe it is the intent of the Standard to prohibit this (a paragraph in the rationale says that short writes can only happen if O_NONBLOCK is set, but this is clearly wrong because the normative text says end-of-medium also results in a short write) but there does not appear to be any language which requires atomic behavior for descriptors other than pipes and FIFOs. As a quality-of-implementation matter, for writes to regular files not to be atomic would be considered surprising. -GAWollman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NFS client/buffer cache deadlock
On Wed, 20 Apr 2005 11:52:33 -0400, Brian Fundakowski Feldman [EMAIL PROTECTED] said: I think the first is more useful behavior than the last. Supporting it should be exactly the same as supporting what happens if the actual filesystem fills up. In this case, the filesystem is being requested to write more than there is room for. Returning a short write for operations on regular files would definitely be considered astonishing. The changes that you have made should be considered flow control, not admission control, and should appear to the user no differently than if we were waiting for a slow disk to write something; i.e., the user thread should be blocked until either the entire write completes, or the process is interrupted by a signal. -GAWollman ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ipfw1sysctl and lifetime
On Thu, 21 Apr 2005, Omar Lopez Limonta wrote: I Change: net.inet.ip.fw.dyn_ack_lifetime: 300 - 3600 net.inet.ip.fw.dyn_udp_lifetime: 10 - 10 net.inet.ip.fw.dyn_buckets: 256 - 1024 net.inet.ip.fw.dyn_max: 1000 - 2500 ¿Are good these values? , ¿i need chanege another value? Dont know my friend. I have no way of testing those out right now. I assume those values are from a 5.x machine I only run 4.x's at the moment untill I test 5.4-RELEASE more and evaluate its potential and gain on my systems. -- ( 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]
Re: Configuration differences for jails
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. -- ( 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]
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: Configuration differences for jails
* Jeremie Le Hen [EMAIL PROTECTED] [20050420 18:55]: [snip much appreciated example] I don't think it's easy to take /etc/ outside the root fs, but I don't see how to share /bin or /lib without leaking info. How do you handle this? As I said above, null mount each directory. Thanks, that was exactly what I was looking for. I hadn't read close enough to appreciate the difference betwen unionfs and nullfs until now. What are those distribution targets and how can I use them? I've seen them mentioned again in this thread. There apparently is a make distribution target designed to address /etc, but I can't find it anywhere. qvb -- pica ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Status Report Jan-Mar 2005
January-April 2005 Status Report Introduction The first quarter of 2005 has been extremely active in both FreeBSD-CURRENT and -STABLE. With FreeBSD 5.4 in the final RC stage and an anticipated branch of FreeBSD-6 this summer we have seen a lot of performance improvements in 5 and a couple of exciting new features in 6. The report turnout was extremely good and it seems that the webform provided by Julian Elischer has made it more enjoyable to write reports. Many thanks to Julian for providing this. We also like to get your attention to the open tasks section provided in some reports. On special note, please take a look at the report about the upcoming BSDCan in Ottawa. There will be lots of interesting FreeBSD related talks and activities. If you enjoy reading these reports, you will love the conference. See you there! Thanks to all the reporters, we hope you enjoy reading. _ Projects * Common Address Redundancy Protocol - CARP * FreeBSD Java Project * FreeBSD Release Engineering * GELI - GEOM class for providers encryption * GSHSEC - GEOM class for handling shared secret * Secure Updating Documentation * FreeBSD Dutch Documentation Project Kernel * ATAPI/CAM * Coverity Code Analysis * cpufreq * drm * Filesystem journalling for UFS * Infrastructure Cleanup * Interrupt Latency * Low-overhead performance monitoring for FreeBSD * Many subdirs for UFS * Status Report for FreeBSD ATA driver project * Storage driver SMPng locking Network infrastructure * Dingo * IPv6 Support for IPFW * Move ARP out of routing table * netgraph(4) status report * Removable interface improvements. * Support for telephone hardware (aka Zaptel) * Wireless Networking Support Userland programs * libthread * Pipe namespace added to portalfs Architectures * ARM Support for TS-7200 * PowerPC Port * XenFreeBSD - FreeBSD on Xen Ports * FreshPorts * Ports Collection * Update of the Linux userland infrastructure Vendor / 3rd Party Software * OpenBSD packet filter - pf * twa driver Miscellaneous * BSDCan * FreeBSD Security Officer and Security Team * IMUNES - a FreeBSD based kernel-level network topology emulator _ ARM Support for TS-7200 URL: http://www.embeddedarm.com/epc/ts7200-spec-h.html URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/user/jmg /armHIDEDEL=NO URL: http://people.freebsd.org/~jmg/dmesg.ts7200 Contact: John-Mark Gurney [EMAIL PROTECTED] I have been working on getting FreeBSD/arm running on the TS-7200. So far the board boots, and has somewhat working ethernet (some unexplained packet loss). I can netboot from a FreeBSD/i386 machine, and I can also mount msdosfs's on CF. Open tasks: 1. Figuring out why some small packets transmit with error 2. EP93xx identification information to properly attach various onboard devices _ ATAPI/CAM Contact: Thomas Quinot [EMAIL PROTECTED] ATAPI/CAM integration with the new ATA (mkIII) framework is now completed. ATAPI/CAM is now available as a loadable module (atapicam.ko). It is also independant from the native ATAPI drivers again, as was the case before mkIII. Thanks to Scott Long and Søren Schmidt for their participation in the integration work. _ BSDCan URL: http://www.bsdcan.org/ Contact: Dan Langille [EMAIL PROTECTED] BSDCan made a strong debut in 2004 . The favorable reception gave us a strong incentive for 2005 . We have been rewarded with a very interesting program and a higher rate of registrations. Percentage-wise, we have more Europeans than last year as they have decided that the trip across the Atlantic is worth taking. We know they won't be disappointed. See you at BSDCan 2005! Open tasks: 1. volunteers needed for the conference _ Common Address Redundancy Protocol - CARP URL: http://www.freebsd.org/cgi/man.cgi?query=carpmanpath=FreeBSD+6.0-curr ent URL: http://people.freebsd.org/~mlaier/CARP/ Contact: Max Laier [EMAIL PROTECTED] Contact: Gleb Smirnoff [EMAIL PROTECTED] CARP is an alternative to VRRP. In contrast to VRRP it has full support for IPv6 and uses crypto to protect the advertisements. It was developed by OpenBSD due to concerns that the HSRP patent might cover VRRP and CISCO might defend its patent. CARP has, since then, improved a lot over VRRP. CARP has
Re: KLD module with C++ iostreams ?
David Leimbach wrote: Interesting question. People usually have to implement the C++ runtime to be usable from within the kernel. Things like exceptions and stdout may not be defined in kernel space :) I'm not terribly familiar with how it works on FreeBSD but I know it took a special effort to get C++ support into linux. Dave On 4/20/05, Aziz KEZZOU [EMAIL PROTECTED] wrote: Hi hackers, I am wondering if I can use c++ iostreams inside the kernel ? After all the code : cout Hello world! endl; ends accessing the stdout just like : printf(Hello world!\n); right ? No, that's not true, all the iostreams stuff is totally independent. The iostreams stuff is coming from some of the ugliest code in C++. But, that's not the question, or at very least, it shouldn't BE the question. There is ZERO need to bring in features from C++, all it will do is to directly confuse the code base by greatly adding to the complexity of the code, without giving anything like equivalent features. Some very, very elegant work has been code, OO-ing the kernel code, adding OO features, all without violating the C language code base. Adding in C++ features over stdio stuff is so senseless, it's nearly obscene. If the gain at the end of the road was large enough, I wouldn't be against it so stridently, but I see *so* little gain. BTW, you know where the ugliest code in computer science today is: half is in the actual implementation of the cstdio/template code, the other half is the iostreams stuff. The fact that they energize some very elegant code is causing many folks never to see the fact of the horrible code lumps that exist out in the backyard. So if I could compile my KLD module with static linkage to libstdc++, that should be ok, right ? Any one did or knows how to do this ? Thank you guys for responding to my post. Certainly, it is not a good idea to use _all_ C++ stuff inside the kernel ; in the linux community a similar suggestion resulted in a big discussion of pros cons. I was asking because I have a big portion of C++ code that I am planning to move inside the kernel. But, having compared the effort/time required to port C++ iostreams into the kernel and the effort/time required to get rid of iostreams , I think I will abandon this challenge for now ;-) Just to let you know virtual methods and templates, among others, are supported inside the kernel... Greetings, -aziz ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD Network Implementation Question
[applogies if this is in a FAQ somewhere... I've looked in a number of places, and am not able to find the answer] Hi, I am trying to figure out how large a specific buffer is in FreeBSD. The buffer in question is the buffer between the network layer and the ethernet device, i.e., if packets are being passed down the network stack from tcp faster than the hardware can handle them, at what point do packets start getting dropped locally? I believe the answer is: % sysctl -a [snip] net.inet.ip.intr_queue_maxlen: 50 But try as I might, I can't find the documentation of the variable to confirm it. Can anyone point me in the right direction? Thanks, - Rob . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Network Implementation Question
Rob wrote: [applogies if this is in a FAQ somewhere... I've looked in a number of places, and am not able to find the answer] Hi, I am trying to figure out how large a specific buffer is in FreeBSD. The buffer in question is the buffer between the network layer and the ethernet device, i.e., if packets are being passed down the network stack from tcp faster than the hardware can handle them, at what point do packets start getting dropped locally? I believe the answer is: % sysctl -a [snip] net.inet.ip.intr_queue_maxlen: 50 But try as I might, I can't find the documentation of the variable to confirm it. Can anyone point me in the right direction? You figured it out correctly. However at that moment TCP flow control would kick in and save you from local packet loss so to say. -- Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Network Implementation Question
You figured it out correctly. However at that moment TCP flow control would kick in and save you from local packet loss so to say. Hi, Thanks for the response, but you have actually confused me more. It is my understanding that TCP doesn't have flow control (i.e., local to the node), it has congestion control, which is end-to-end across the network. So it is entirely possible to drop packets locally in this method with a highband width, high latency (so called long-fat) connection. For example, if there were a giga-bit/second link, with a latency of 100 miliseconds rtt, and window scaling set to 14 (the max), tcp could in theory open it's congestion window up to 2^16*2^14 or 2^30 bytes, which could be ACK'd more quickly than the net.inet.ip.intr_queue_max queue would allow for, causing packets to be dropped locally. Basically, the bandwidth-delay product dictates the size the buffer/queue should be, and in the above (extreme) example, it should be 0.1s*1Gb/s=12.5MB which is larger than the 50 packets at 1500 bytes each that you get with net.inet.ip.intr_queue_max=50. In otherwords, this is the reason for the net.inet.ip.intr_queue_drops counter, right? I'm surprised that more of the tuning guides don't suggest increasing net.inet.ip.intr_queue_max to a higher value - am I missing something? The equivalent setting in Linux is 1000, and Windows 2k appears to be 1500 (not that this should be necessarily taken as any sort of endorsement). If my understanding is incorrect, please let me know. In any case, thanks for the help (and thanks to those that have replied off list). - Rob . ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD Network Implementation Question
Rob wrote: You figured it out correctly. However at that moment TCP flow control would kick in and save you from local packet loss so to say. Hi, Thanks for the response, but you have actually confused me more. It is my understanding that TCP doesn't have flow control (i.e., local to the node), it has congestion control, which is end-to-end across the network. tcp_output() knows about queue overflows when it tries to send packets and instantly gives up until ACK's get in. This avoids real packet drops locally and allows to retry the same packet a microseconds later again without having to wait for the other side to signal a real packet loss. So it is entirely possible to drop packets locally in this method with a highband width, high latency (so called long-fat) connection. Packets are not exactly dropped. tcp_output() generates and adds one packet after the other to the interface queue. The moment this doesn't work anymore it breaks out of that loop even it would be allowed by the window to send more. The failing packet is not dropped but retried later and further packets are not produced for the time being. It just defers further delivery. A local loss would be different. There it would fail with one packet, drop it, and try again with the next packet which may go through if the network card was done with an earlier packet that moment. However this is not what happens. Because things happens inside the kernel TCP knows how to deal with this in the right way and to avoid any costly recoveries from these cases. For example, if there were a giga-bit/second link, with a latency of 100 miliseconds rtt, and window scaling set to 14 (the max), tcp could in theory open it's congestion window up to 2^16*2^14 or 2^30 bytes, which could be ACK'd more quickly than the net.inet.ip.intr_queue_max queue would allow for, causing packets to be dropped locally. Basically, the bandwidth-delay product dictates the size the buffer/queue should be, and in the above (extreme) example, it should be 0.1s*1Gb/s=12.5MB which is larger than the 50 packets at 1500 bytes each that you get with net.inet.ip.intr_queue_max=50. You are mixing up the socket buffer size with the interface queue size. Those are not the same. TCP will converges to maximal link speed and then is bound by the output rate of the interface even if the window gets larger. In otherwords, this is the reason for the net.inet.ip.intr_queue_drops counter, right? I'm surprised that more of the tuning guides don't No, not directly. This counter gets to work when the box is doing routing. Drop happen when you go from a high bandwidth link to a low(er) bandwidth link overloading the slow link. On a box not doing routing you should'nt see any drops. suggest increasing net.inet.ip.intr_queue_max to a higher value - am I missing something? The equivalent setting in Linux is 1000, and Windows 2k appears to be 1500 (not that this should be necessarily taken as any sort of endorsement). This doesn't really help. What happens with larger queues is just that you fill the larger queues and it takes longer until TCP's limiting kicks in. The queues have to have some size to provide some smoothing of burstiness but should not be too long to keep some direct feedback in place. If my understanding is incorrect, please let me know. In any case, thanks for the help (and thanks to those that have replied off list). -- Andre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Addendum: FreeBSD Status Report Jan-Mar 2005
Unfortunately, the following report got lost: New Wireless Drivers URL: http://ipw2100.sourceforge.net/firmware.php?fid=4 URL: http://ralink.rapla.net/ Contact: Damien Bergamini [EMAIL PROTECTED] Four new wireless drivers were imported: ipw : driver for Intel PRO/Wireless 2100 adapters (MiniPCI). iwi : driver for Intel PRO/Wireless 2200BG/2225BG/2915ABG adapters (PCI or MiniPCI). ral : driver for Ralink RT2500 wireless adapters (PCI or CardBus). ural : driver for Ralink RT2500USB wireless USB 2.0 adapters. The ipw and iwi drivers require firmwares to operate. These firmwares can't be redistributed with the base system due to license restrictions. See firmware licensing terms here: http://ipw2100.sourceforge.net/firmware.php?fid=4 . Ports which include the firmware images as well as the firmware loader are being worked on. A list of adapters supported by ral and ural can be found here: http://ralink.rapla.net/ . Open tasks: 1. Create ports for ipw and iwi firmwares. 2. Add IBSS support to iwi. 3. Add WPA (802.11i) support to ipw and iwi. 4. Add hardware encryption (WEP, TKIP and CCMP) support in ral and ural. 5. Add automatic rate adaptation support to ural. __ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
