Re: kqueue microbenchmark results
On Fri, Dec 08, 2000 at 11:06:07PM -0700, Wes Peters wrote: > Dan Kegel wrote: > > > > His role right now is to keep the kernel as simple as possible. > > So the major advancements of pushing file servers and web servers into > the kernel fit into this role how? totally orthoganal to the `linus thinks bsd has cooties' "discussion", but I'll take a stab at shedding some light. as we're veering wildy off-topic for -hackers, I'll be brief. the few people who may actually care can email me off list for more info. as dan mentioned, khttpd added no complexity at all to the 'core kernel'. That is, it added no controversial APIs that have to be maintained over time, etc. Thats simply because it was a lame hack of moving a wimpy static http responder into kernel threads :) tux, being a much more interesting design, messes with all sorts of stuff. Most notably it added working "zero copy" tcp and lots of SMP scalability fixes. getting damn-near-linear performance inprovements as cpu and interfaces are added is definitely interesting, if not even remotely useful for 99% of the userbase. Ingo did it as an intial exploratory implementation. It served its role, current more careful "zero copy" development is branched from early tux code. so anyway, the trend isn't to push servers into the kernel. khttpd was put in because it was of no risk to Linus and ended up acting as motivation to do it right, if its going to be done at all. Doing it then showed the possible gains which are now being folded into proper APIs that userland servers will be able to use. (dunno if kiofd and such interfaces have been discussed in public yet, I know they've been babbled about at conferences. think splice meets iolite, using fds rather than new syscalls and without the VM tricks..) -- zach To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
Wes Peters wrote: > Dan Kegel wrote: > > "Daniel C. Sobral" wrote: > > > Why is it that I get the feeling more and more nowadays that Linus is > > > suffering from a worsening case of NIH when it comes to things > > > originated on BSD? > > > > Don't jump to conclusions. He's honestly trying to > > understand what the optimal interface would be. > > Let him catch up. Help him understand the requirements > > which motivated the kqueue design and why his proposed > > system call does not meet them. > > > > His role right now is to keep the kernel as simple as possible. > > So the major advancements of pushing file servers and web servers into > the kernel fit into this role how? Regardless of whether those complicate the kernel - and I suspect khttpd and tux don't complicate the kernel much - what Linus is doing here is different: he's doing a reductionist analysis of what it takes to do poll() right. I've done the same thing before, and yes, the people whose favorite interface I seemed to be ignoring were pissed off. But it was the only way for me to understand the true requirements. In the end, I usually add back part of the stuff I initially stripped out, once I understood what it was for. That said, I like kqueue, and I don't like the interface Linus proposed. But I'm still not quite sure how to demonstrate that his interface won't do the job. (Wish I had time.) - Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Partial start on pci + serial/parallel cards
OK. I have a partial start on the serial/parallel cards. It isn't attaching anything yet, but should give people an idea on the direction I'd like to head. As part of this work, I'll likely remove pci attachment of sio, and change it to puc. puc is the name NetBSD uses (I snagged the tables and some code from NetBSD's puc driver, btw) so I kept using it. I'll also need to add puc attachments to sio and ppc drivers. I'll also need to add the bus resource allocations stuff so that the client drivers can just use bus resource 0, ala isa. I think that Matt Dodd's recent work makes this relatively easy, but haven't had a chance to look at that closely. Again, this is preliminary and posted for commentary only. I wanted to get this out. http://people.freebsd.org/~imp/puc.tar.gz Comments and patches welcome. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
Dan Kegel wrote: > > "Daniel C. Sobral" wrote: > > > > Why is it that I get the feeling more and more nowadays that Linus is > > suffering from a worsening case of NIH when it comes to things > > originated on BSD? > > Don't jump to conclusions. He's honestly trying to > understand what the optimal interface would be. > Let him catch up. Help him understand the requirements > which motivated the kqueue design and why his proposed > system call does not meet them. > > His role right now is to keep the kernel as simple as possible. So the major advancements of pushing file servers and web servers into the kernel fit into this role how? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: GDB Displaying all vars in a stack frame.
On 09-Dec-00 Stephen Hocking wrote: > Is there some simple one-liner command that allows me to display the values > of > all the variables within the current stack frame? 'info locals' I think, or 'show locals' if that doesn't work.. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GDB Displaying all vars in a stack frame.
On Friday, 8 December 2000 at 18:29:26 -0600, Stephen Hocking wrote: > Is there some simple one-liner command that allows me to display the values of > all the variables within the current stack frame? info local Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
GDB Displaying all vars in a stack frame.
Is there some simple one-liner command that allows me to display the values of all the variables within the current stack frame? Stephen -- The views expressed above are not those of PGS Tensor. "We've heard that a million monkeys at a million keyboards could produce the Complete Works of Shakespeare; now, thanks to the Internet, we know this is not true."Robert Wilensky, University of California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPP connection
Forget this; I didn't read your message closely. I see now that the authentication passed. Gary Aitken wrote: > > I've only used kernel ppp for a dedicated line, > and there wasn't any user authentication required in that case, > so I'm probably not much help... > What does your /etc/ppp/options file look like, > and the associated /etc/ppp/pap-secrets and /etc/ppp/chap-secrets? > What kind of authentication is the machine you are connecting to set up to use? > (If it's simply prompting for a username & password, that's pap). > > You might add the "debug" option to your options file and check the logs > in /var/log. > > Thierry wrote: > > > I'm trying to use kppp with freeBSD, but when I want to connect, > > > > My modem dials, ID and the password are accepted, > > > > and I receive a message : > > > > pppd 2.3.5 started by root, uid 0 > > Connect: ppp0 <--> /dev/modem > > Modem hangup, connected for 1 minutes > > Connection terminated, connected for 1 minutes > > > > and the modem port is closed. > > > > and kppp print in a dialog "Logging on to Network..." > > > > Can you help me ? > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On 2000-12-08 10:02 -0600, Mike Silbersack <[EMAIL PROTECTED]> wrote: > Seriously, though. There must be some way to abuse such direct access to > the pci configuration registers. Just because nobody has figured it out > how yet doesn't mean that enabling the feature is a good idea. Well, what makes you think, that nobody has figured out why read access to the pci config space registers might not be a good idea ? ;-) The reason is simple: There are a number of PCI devices that fail in a number of ways, if certain config space registers are accessed while the device is active. This is counterintuitive at first, but just try to read a config register beyond 0x80 from an NCR SCSI chip while it is executing SCRIPTS code ... The PCI spec made higher numbered config space registers implementation dependent. Some vendors mapped their devices' operational registers into config space, even though the spec never encouraged that (though I'm not sure that such an (ab)use of config registers was declared forbidden in later revisions of the spec.). Since there are a number of devices that could be severely impacted by read accesses to configuration space registers, we can't safely permit any user such read access. Root hopefully knows what he is doing and only accesses such registers that are meant to be accessed while the device is operating ... Regards, STefan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPP connection
I've only used kernel ppp for a dedicated line, and there wasn't any user authentication required in that case, so I'm probably not much help... What does your /etc/ppp/options file look like, and the associated /etc/ppp/pap-secrets and /etc/ppp/chap-secrets? What kind of authentication is the machine you are connecting to set up to use? (If it's simply prompting for a username & password, that's pap). You might add the "debug" option to your options file and check the logs in /var/log. Thierry wrote: > I'm trying to use kppp with freeBSD, but when I want to connect, > > My modem dials, ID and the password are accepted, > > and I receive a message : > > pppd 2.3.5 started by root, uid 0 > Connect: ppp0 <--> /dev/modem > Modem hangup, connected for 1 minutes > Connection terminated, connected for 1 minutes > > and the modem port is closed. > > and kppp print in a dialog "Logging on to Network..." > > Can you help me ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PPP connection
Hi, I'm trying to use kppp with freeBSD, but when I want to connect, My modem dials, ID and the password are accepted, and I receive a message : pppd 2.3.5 started by root, uid 0 Connect: ppp0 <--> /dev/modem Modem hangup, connected for 1 minutes Connection terminated, connected for 1 minutes and the modem port is closed. and kppp print in a dialog "Logging on to Network..." Can you help me ? Thank in advance. Thierry Jonas. __ Vous avez un site perso ? 2 millions de francs à gagner sur i(france) ! Webmasters : ZE CONCOURS ! http://www.ifrance.com/_reloc/concours.emailif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, Dec 08, 2000 at 12:07:49AM -0700, Chad R. Larson wrote: > I thought the space staked out by the *BSD gang was approximately > this: > NetBSD - the least amount of platform-specific code possible; run > on most anything > OpenBSD - pro-active security, bullet-proof from attacks > FreeBSD - best performing on the Intel PC platform s/the Intel PC/server/ The Alpha has very good I/O bandwidth and 64-bit address space. Thus it fits our niche. You also mentioned Sparc, but really should have said sparc64(pci based). hopefully embeded soon too. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
Look at ipproto switch table... That might help you find some function pointers that would be logical to hijack in order to do this sort of thing. it's in /usr/src/sys/netinet/*.c somewhere. andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: >We are about to begin a little project that has the following requiremnet. > >Perform IP packet filtering in the following way : > > > i) look at an ip packet header. If some conditions are met let the packet pass >otherwise reject the packet. > > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. > > > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: > > i) if anyone has done something similar do you have any advice. > ii) Anyone know where I should start hacking. Would it be best to try to > hack the firewall code or the ipforwarding code > > Any such advise would be helpful. > > > Alwyn Goodloe > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > *-. | Andrew R. Reiter | [EMAIL PROTECTED] | "It requires a very unusual mind | to undertake the analysis of the obvious" -- A.N. Whitehead To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
:On Fri, Dec 08, 2000 at 05:53:18AM +, [EMAIL PROTECTED] wrote: :> :> How frequently do people fsck? : :Once per reboot usually. : :Joe :-- :Josef Karthauser [[EMAIL PROTECTED], [EMAIL PROTECTED]] No, that's an fsck -p ... if the filesystem is clean, it doesn't do anything. fsck scans the filesystem only when booting after a crash. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
"Daniel C. Sobral" wrote: > > David Malone wrote: > > > > On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: > > > I'd love to do that, but am not quite sure how I'd go about it. > > > If you read the l-k mailing list, you'll see Linus calling kqueue > > > "overengineered", and what he is proposing is something that is > > > definitely not well thought out. > > > > Maybe Alexander Viro could help? He often follows what's happening > > in the BSD world and seems to do lots of good VFS type work in the > > Linux world. Matt Dillon recently worked with him on the file > > discriptor locking patches he committed. > > Why is it that I get the feeling more and more nowadays that Linus is > suffering from a worsening case of NIH when it comes to things > originated on BSD? Don't jump to conclusions. He's honestly trying to understand what the optimal interface would be. Let him catch up. Help him understand the requirements which motivated the kqueue design and why his proposed system call does not meet them. His role right now is to keep the kernel as simple as possible. You need to prove that his proposed interface is simpler than possible :-) - Dan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCIOCGETCONF/PCIOCREAD requires write permission?
On Fri, 8 Dec 2000, Chad R. Larson wrote: > I'm not trying to foster a war here. There seems to be enough of > that anyway. But unless this PCI register reading thingie is an > issue for i386 boxen (and I don't think it is) we shouldn't cripple > functionality on the i386 for the Alpha. Allowing programs direct access to hardware is Windows 95's thing, though. We don't want to tread on its turf. Seriously, though. There must be some way to abuse such direct access to the pci configuration registers. Just because nobody has figured it out how yet doesn't mean that enabling the feature is a good idea. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umodem and manual
KE: I try testing 3com USB modem, but don't know, how connect to him ? KE: Maybe i can get some help about it ? I found problem (MAKEDEV create umodem0 with rw--- permissions, change it to 660) When Zyxel Omni USB modems be supported in FreeBSD kernel ? -- Best Regards ZHECKA-RIPN To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kqueue microbenchmark results
David Malone wrote: > > On Wed, Oct 25, 2000 at 05:01:17PM -0500, Jonathan Lemon wrote: > > I'd love to do that, but am not quite sure how I'd go about it. > > If you read the l-k mailing list, you'll see Linus calling kqueue > > "overengineered", and what he is proposing is something that is > > definitely not well thought out. > > Maybe Alexander Viro could help? He often follows what's happening > in the BSD world and seems to do lots of good VFS type work in the > Linux world. Matt Dillon recently worked with him on the file > discriptor locking patches he committed. Why is it that I get the feeling more and more nowadays that Linus is suffering from a worsening case of NIH when it comes to things originated on BSD? -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
[EMAIL PROTECTED] wrote: > > How frequently do people fsck? Well, that depends on whether I'm attached atm or not. Oh, you mean filesystems? :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] "The bronze landed last, which canceled that method of impartial choice." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
umodem and manual
Hi ppls. I try testing 3com USB modem, but don't know, how connect to him ? Maybe i can get some help about it ? ZHECKA-RIPN -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Shared Memory
FreeBSD 4+ I had something like 8192 processes in mind and same goes for max open files I'd like 256M shared memory... William Carlsson Second Line Support Teligent Nordic AB P.O. Box 213 S-149 21 Nynäshamn SWEDEN Telephone: +46 - 8 - 59 99 11 92 eMail: [EMAIL PROTECTED] http://www.teligent.se "And then it comes to be that the soothing light at the end of your tunnel was just a freight train, comin' your way." -Original Message- From: Peter Pentchev [mailto:[EMAIL PROTECTED]] Sent: den 8 december 2000 14:00 To: [EMAIL PROTECTED] Cc: Mikko Tyolajarvi; [EMAIL PROTECTED] Subject: Re: Shared Memory On Fri, Dec 08, 2000 at 01:01:16PM +0100, William Carlsson - Teligent Nordic, AB - Sweden wrote: > Isn't all kern.* read only? > Seems like it can't be changed more than it's in theory changeable > > Something like the maximum nuber of files and processes, that is suposed to > be > soft configurable in login.conf (doesn't work either) > > ,D Does anything work in FreeBSD? ,D Uhm.. what version of FreeBSD do you have in mind? On a 4.2 I have.. [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 256 [roam@ringworld:v2 ~]$ On another console: [root@ringworld:v0 /etc]# perl -pi -e 's/maxproc=256/maxproc=512/' login.conf [root@ringworld:v0 /etc]# Logout and re-login on the first one: [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 512 [roam@ringworld:v2 ~]$ Feels quite changeable to me :) And btw - no, almost none of the kern.* sysctls are read-only. [root@ringworld:v0 /etc]# sysctl kern.coredump kern.corefile kern.syncdelay ker n.consmute kern.coredump: 1 kern.corefile: %N.core kern.syncdelay: 30 kern.consmute: 0 [root@ringworld:v0 /etc]# sysctl -w kern.coredump=0 kern.corefile='%N.CORE' ker n.syncdelay=100 kern.consmute=1 kern.coredump: 1 -> 0 kern.corefile: %N.core -> %N.CORE kern.syncdelay: 30 -> 100 kern.consmute: 0 -> 1 [root@ringworld:v0 /etc]# ..to name an (almost) random sample :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
Lists Account wrote: > > Look at IPF/IPFW they both have state table stuff in them, and analyzing > the ip header is done by both as well. I would suggest you hack ipf to do > what you want if it doesnt do it already. > > Cheers > > Andrew > > On Fri, 8 Dec 2000, Alwyn Goodloe wrote: > > >We are about to begin a little project that has the following requiremnet. > > > >Perform IP packet filtering in the following way : > > > > > > i) look at an ip packet header. If some conditions are met let the packet pass > >otherwise reject the packet. you could hack your chacks into if_fw.c if they are not already supported.. what kinds of checks do you want to do? Alternatively you could use teh divert sockets to make all packets that might need filtering, up to a userland process that can do arbitrarily complicated filtering. If you want a framework with which to start, you could start with natd and strip out the address translation calls and replace them with your filtering calls. OR you could catch packets at the ethernet using netgraph and either write a loadable netgraph module that does your filtering, or passes it up to a daemon that can do arbitrary filtering. it would be easier for us to answer if you said what kind of filtering you want to do. > > > > > > ii) Look at ip packet headers of established connections and when certain > > conditions are met tear down the connection. > > > > > > Obviously this isn't the kind of thing we will be using the usual > > firewall software, at least not as I understand the software. What I > > want to know from you FreeBSD hackers is: > > > > i) if anyone has done something similar do you have any advice. > > ii) Anyone know where I should start hacking. Would it be best to try to > > hack the firewall code or the ipforwarding code > > > > Any such advise would be helpful. > > > > > > Alwyn Goodloe > > [EMAIL PROTECTED] > > > -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Budapest v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shared Memory
On Fri, Dec 08, 2000 at 01:01:16PM +0100, William Carlsson - Teligent Nordic, AB - Sweden wrote: > Isn't all kern.* read only? > Seems like it can't be changed more than it's in theory changeable > > Something like the maximum nuber of files and processes, that is suposed to > be > soft configurable in login.conf (doesn't work either) > > ,D Does anything work in FreeBSD? ,D Uhm.. what version of FreeBSD do you have in mind? On a 4.2 I have.. [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 256 [roam@ringworld:v2 ~]$ On another console: [root@ringworld:v0 /etc]# perl -pi -e 's/maxproc=256/maxproc=512/' login.conf [root@ringworld:v0 /etc]# Logout and re-login on the first one: [roam@ringworld:v2 ~]$ limits | fgrep maxproc maxprocesses 512 [roam@ringworld:v2 ~]$ Feels quite changeable to me :) And btw - no, almost none of the kern.* sysctls are read-only. [root@ringworld:v0 /etc]# sysctl kern.coredump kern.corefile kern.syncdelay ker n.consmute kern.coredump: 1 kern.corefile: %N.core kern.syncdelay: 30 kern.consmute: 0 [root@ringworld:v0 /etc]# sysctl -w kern.coredump=0 kern.corefile='%N.CORE' ker n.syncdelay=100 kern.consmute=1 kern.coredump: 1 -> 0 kern.corefile: %N.core -> %N.CORE kern.syncdelay: 30 -> 100 kern.consmute: 0 -> 1 [root@ringworld:v0 /etc]# ..to name an (almost) random sample :) G'luck, Peter -- This would easier understand fewer had omitted. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel question (detecting a user log-on)
Torbjorn Kristoffersen <[EMAIL PROTECTED]> writes: > I'm wondering about two things, how does the kernel detect that a > user logs on a tty, and what should I know if I was to write a kernel > module that detects it (And does something about it)? Must I > read the TCP in-packets for port 23 and detect if a user logged on? > I'm pretty unsure about this.. Why don't you tell us what you want to do, instead of how you think it must be done? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
Look at IPF/IPFW they both have state table stuff in them, and analyzing the ip header is done by both as well. I would suggest you hack ipf to do what you want if it doesnt do it already. Cheers Andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: >We are about to begin a little project that has the following requiremnet. > >Perform IP packet filtering in the following way : > > > i) look at an ip packet header. If some conditions are met let the packet pass >otherwise reject the packet. > > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. > > > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: > > i) if anyone has done something similar do you have any advice. > ii) Anyone know where I should start hacking. Would it be best to try to > hack the firewall code or the ipforwarding code > > Any such advise would be helpful. > > > Alwyn Goodloe > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Shared Memory
Isn't all kern.* read only? Seems like it can't be changed more than it's in theory changeable Something like the maximum nuber of files and processes, that is suposed to be soft configurable in login.conf (doesn't work either) ,D Does anything work in FreeBSD? ,D -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mikko Tyolajarvi Sent: den 7 december 2000 18:54 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Shared Memory In local.freebsd.hackers you write: >Could anyone enlighten me on how to set the amount of shared memory? If you mean the wretched System V IPCs, the parameters are in LINT. Search for "SHM". >I'd like that info for FreeBSD 2.2.2, 3.x, 4.x The parameters only have descriptive comments in 4.2, but I think they are the same in all releases (they're in LINT in RELENG_2 from '98 at least). $.02, /Mikko P.S. Hmm... there seems to be writable sysctl values (e.g. kern.ipc.shmmax). Maybe a kernel recompile isn't needed anymore. -- Mikko Työläjä[EMAIL PROTECTED] RSA Security To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
On Fri, Dec 08, 2000 at 12:03:12AM -0500, Alwyn Goodloe wrote: > i) look at an ip packet header. If some conditions are met let the packet pass >otherwise reject the packet. > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. I presume you mean TCP in the second case, IP doesn't have a notion of an established connection by itself. > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: This sounds exactly like what regular packet filtering software like ipfw or ipf do (both have man pages). Another possibility would be to use netgraph and the ng_bpf device, which can do any filtering that the Berekley Packet Filter can do. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Kernel question (detecting a user log-on)
On Thu, Dec 07, 2000 at 09:30:54PM +0100, Torbjorn Kristoffersen wrote: > Hi Hackers, > > I'm wondering about two things, how does the kernel detect that a > user logs on a tty, and what should I know if I was to write a kernel > module that detects it (And does something about it)? Must I > read the TCP in-packets for port 23 and detect if a user logged on? > I'm pretty unsure about this.. > > I know it could easier be implemented in userland by reading the > _PATH_UTMP file, but I'm more interested in doing it in kernel space. Generally the kernel does not know anything about user logins. Those are handled either by login(1) in the case of console, serial or telnet logins, or by sshd(8) and similar remote login daemons. Monitoring TCP activity on port 23 would only catch plain telnet logins, and probably not always. You'd be far better off hacking support for what you need into login(1), sshd(8) and all other such daemons; or a much simpler, though FreeBSD-specific solution (not that hacking login(1) isn't FreeBSD-specific) - modify the login(3) libutil function. It is used by login(1) and by the OpenSSH daemon in the FreeBSD base system; I *think* the original SSH daemon also uses it if present. You'd want to either add a syscall, or some tty ioctl to alert your kernel module about a user login, and then have login(3) perform that alert. Hope that helps, and when you come up with something working, please post more information either on the list, or to me privately - what you've hinted at doing sounds interesting :) G'luck, Peter -- This inert sentence is my body, but my soul is alive, dancing in the sparks of your brain. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
On Fri, Dec 08, 2000 at 05:53:18AM +, [EMAIL PROTECTED] wrote: > > How frequently do people fsck? Once per reboot usually. Joe -- Josef Karthauser[[EMAIL PROTECTED], [EMAIL PROTECTED]] . FreeBSD: The power to change the world To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimal UFS parameters
[EMAIL PROTECTED] schrieb: > > How frequently do people fsck? Only at boot time, or when problems surface. Just my $.02 -Christoph Sold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [tcpdump-workers] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 09:51:42PM -0800, Alfred Perlstein wrote: > I'm very curious how they managed to run "windump" on FreeBSD. Presumably they're referring to tcpdump there, as per the first paragraph in "2. Tests": This Section aims at giving some indications about the performance of the capture process on various operating systems. Results obtained under the various Windows platforms have been compared with the ones provided by BPF/libpcap/TCPdump in FreeBSD 3.3 in order to determine the goodness of our implementation. > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. Perhaps. However, from my stracing of windump on NT 4 SP4 and trussing of tcpdump on FreeBSD 3.4, the only difference appears to be that tcpdump does 8K writes and windump does 4K writes Currently, I suspect that it lies with the BPF kernel buffer only being 32K; that's the most you can get on FreeBSD 3.x, but you can crank it up to 512KB on 4.x - libpcap on 4.x only sets it to 32K, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
On Thu, Dec 07, 2000 at 11:39:58PM -0800, Guy Harris wrote: > Or, as per my other mail, perhaps using, on Windows, a version of the > standard I/O library that does bigger writes, hence fewer system calls. Nope. According to "strace for NT": http://www.securiteam.com/tools/Strace_for_NT_-_low_level_system_calls_tracer.html and the Windows(R) NT(R)/2000 Native API Reference: http://www.newriders.com/books/title.cfm?isbn=1578701996 it's doing 4K writes in the underlying NT system call "NtWriteFile()". I suspect that running the test on FreeBSD 4.x and tweaking libpcap to use a 512KB buffer might make a big difference here. At this point, we might want to limit followups to one or more of: [EMAIL PROTECTED] - for discussing changes to libpcap to allow the buffer size to be set from an application and/or changing the size it initially tries on BSD (the current version in CVS starts at 32768 and keeps dividing that in half until it finds something that works); [EMAIL PROTECTED], [EMAIL PROTECTED] - for discussing changes to allow the buffer size to be changes with BIOCSBLEN even if the BPF device is attached to an interface. (Both FreeBSD and OpenBSD have the maximum buffer size for BPF as 512KB in the top of the CVS tree; NetBSD still has it as 32K.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: nslookup deprecation [was 4.2 complaint]
Brandon Fosdick wrote: > > Dag-Erling Smorgrav wrote: > > > > Yusuf Goolamabbas <[EMAIL PROTECTED]> writes: > > > Recently there was a message indicating that ISC is deprecating > > > nslookup. > > > > "Recently"? nslookup has been officially deprecated for about a year > > and a half, I believe. > > Will a replacement be added to the base distro? When? This comes up VERY often, please make a habit of checking the mail archives before posting questions of this sort. If all you need to do is look up a name -> address or address -> name mapping, 'host' provides everything you need, and then some. If you are doing serious DNS debugging, you have to learn dig, period. HTH, Doug -- So what I want to know is, where does the RED brick road go? Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
> > > > (Hurm Wintendo outperforming unix???!?? Something's > > improper about this, and it ought to be fixed... :-) > > Comments? Other OS numbers: more recent > > FreeBSD versions? Solaris? Tru64? Optimization > > patches? Can those OO MSDN lobotomies actually > > be good things? Hurm... The Italian gauntlet has > > been thrown down --dr :-) > > > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm > > I'm looking at this, FreeBSD seems to better on all accounts except > writing the packets to disk. > > Can any of the winpcap people explain exactly how they measured > the disk performance? > ... > Honestly, it really looks like the fault lies with the way tcpdump > writes to disk and not with FreeBSD. What I couldn't figure out from the url was if they were using dma for the disk. Maybe they were using it on Windows and not on FreeBSD? (On FreeBSD 3 you have to enable it with flags in the kernel config file.) Also they don't say if they have changed the debug.bpf_bufsize sysctl from its default smallish 4096 bytes. Those 2 things can make a huge difference. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [Ethereal-dev] Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
:> or with a redirect from tcpdump on a shell line,
:
:Assuming, as I suspect is the case, that they're using the same command
:on the OSes in question (or using "tcpdump" on FreeBSD and "windump" on
:Windows), that's also unlikely - it's just "{tcp,win}dump -w test.acp".
It amounts to the same thing, since -w does nothing more then an
fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't
even double buffered.
But I think the last poster had it right... if the bpf buffer size
was not changed from the default 4096, just about anything can interrupt
the packet flow.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
: : :(Hurm Wintendo outperforming unix???!?? Something's : improper about this, and it ought to be fixed... :-) : Comments? Other OS numbers: more recent : FreeBSD versions? Solaris? Tru64? Optimization : patches? Can those OO MSDN lobotomies actually : be good things? Hurm... The Italian gauntlet has : been thrown down --dr :-) : :url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm Oh yah, I remember this... this is a pretty old benchmark, by the way. Sigh. All this demonstrates is that the person tring to write the packets to disk doesn't know what he's doing. There's nothing wrong with FreeBSD, per say. Looking at the data I would guess that they are appending to a file using write()'s on a packet-by-packet basis or with a redirect from tcpdump on a shell line, rather then spend the 60 seconds it would take to program-in some fairly trivial user-level buffering. The program is obviously stalling on the write and causing the BPF filter to overflow its output buffer. Just because FreeBSD refuses to use all available memory to buffer a single file's writes doesn't mean it's broken, just that the benchmark is. I'm guessing simply double-buffering the disk writeing with two dd's would be sufficient to capture all packets to disk and if someone seriously intended to use a FreeBSD box as a packet-capture system they would write a capture program to talk to the BPF socket directly and implement proper buffering in that rather then tring to use tcpdump. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: kyxtech: freebsd outsniffed by wintendo !!?!?
(Please don't spam this many lists with such a large message.) The test is pretty questionable. FreeBSD 3.3 is over a year old, and I would suspect that the one actual outstanding criticism here (filesystem latency) is probably due to the default synchronous-mode filesystem. A more valid test would use one of the 4.x family FreeBSD releases and soft updates. There are still plenty of things that could be done to further accelerate the system, but that's the one clear item here. > (Hurm Wintendo outperforming unix???!?? Something's > improper about this, and it ought to be fixed... :-) > Comments? Other OS numbers: more recent > FreeBSD versions? Solaris? Tru64? Optimization > patches? Can those OO MSDN lobotomies actually > be good things? Hurm... The Italian gauntlet has > been thrown down --dr :-) > > url: http://netgroup-serv.polito.it/winpcap/docs/performance.htm -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
