Re: Cool little 100BaseTX switch - they're coming down in price
Matthew Dillon wrote:
>
> I picked up a nifty little D-Link DSS-5+ 5-port 10/100 switch today
> CompUSA had a 5-port network kit labeled 'DFE-910' which had the
> DSS-5+ and two DFE-530TX+ NIC Cards ('rl' driver), plus cables, for $130.
Warehouse.com sells the Netgear FS105 for $99.99. If you open them up,
don't be surprised to see exactly the same chipset, and perhaps even the
same board. You'd be astonished how many of these commodity items are
OEM'd from the same vendor.
I have a nice, shiny new 8-port 10/100 switch at work, with ATM-155 uplink,
ATM T1/E1 Circuit emulation on the front, and AAL-1 inputs for bridging
your PBX over the same DS3 or OC3 uplink circuit. It costs a bit more than
$130, or at least it will when I get the IP routing software working. ;^)
> It appears to operate quite nicely. I can run all 5 ports at
> 100BaseTX speeds in full-duplex mode and it seems to take whatever
> I throw at it, though I didn't life test it so I don't know what
> it can actually handle. It seems to have sufficient buffering to
> deal with fragmented NFS packets without losing anything so I'm happy.
If you can spare it for a few days, I'll be glad to plug it into a SmartBits
and tell you what it'll REALLY do.
> Prices have fallen a lot in the last year. I'm happy to be able to
> get rid of my HUBs, I was constantly having to deal with packet loss
> when running saturation tests and never able to figure out what
> was causing it.
Switches are a better solution, no doubt about it. They are well worth
the cost, even if you're just trying to pep up an old 10Base-T network.
Investing in 10Base-T switches at this time is a false economy; for only
a few dollars more per port you can get 10/100 switches like yours and
upgrade machines to Fast Ethernet as budget allows.
> Note that buy.com lists a 'DFE-910' kit for around $100, but their
> description of it is that it contains a hub rather then a switch. I
> know what I got at CompUSA was a switch, not a hub, but I don't know
> what you'd get if you bought the DFE-910 part number from buy.com.
Warehouse.com lists the D-Link DSS-5+ as a 5 port auto 10/100 desktop switch
ext pwr (external power, I presume) for $109.99. I suspect that might be
the same as what you got, despite the clash in product nomenclature.
--
"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: Cool little 100BaseTX switch - they're coming down in price
> > hub. It works fine except that it hangs occasionally (can be > > reset by power-cycling). > > Most of these can be attributed to the crappy wall wart they call a > power supply. If it's plugged into an UPS or replace it with your own DC > power supply they generally hold up a lot better. > > I have a Netgear FS108 at home (8 port 10/100 switch) and I've found > Netgear stuff to be as cheap as I would go and still be reasonably > reliable. In the "don't do this at home" category, I have to relate a story regarding one of the Netgear FS108 switches. Recently, at my "day job" at UUNET, we moved into some new office space. I packed up all my stuff (including one of these FS108 switches) and put it all back together again in my new office space. I noticed a couple of things, first that my SGI LCD display panel wasn't working any more; I though the @$&*$ moves must have dropped it or something. The other thing was that when I powered up the FS108 ethernet swtich under my desk, that I immediately smelled that distinctive "hot electronic smell", followed by smoke (!) coming out of the FS108 box. Hmm.. So, I open up the case of the switch, and noticed that there's a *really* big chip with a *really* big heatsink attached -this is the "bridge on chip". And I noticed another, smaller IC which had a hole blown out of the epoxy case (which subsequently allowed the smoke to escape. It was than than I make the connection - Hmm.. SGI LCD monitor don't work. Ethernet switch makes smoke. Ethernet switch wants 5VDC power brick. SGI LCD monitor wants 12VDC power brick. Ooops! So, after switching power bricks, the SGI LCD monitor starts working again. It really wants 12V and not 5V. In a "what the hell" move, I powered up the ethernet Netgear Ethernet switch with it's preferred 5V power brick -- AND IT WORKS JUST FINE! Well mostly; I think the chip with the hole was involved in driving the Transmit/Collision LEDs which don't do anything anymore. But pushing packets through the box seems to work great; it's still doing the bridge thing of forwarding traffic to the right port, etc. So, please don't do this. I'm sure I'm just luckly. Hell, the thing might burst into flames one day. But I was sure impressed that I keept on working, even after the smoke got loose. Oh, and double check your power bricks before you plug them in. It would sure be nice if there were standard connections for each voltage, but that's certainly not the case.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
> hub. It works fine except that it hangs occasionally (can be > reset by power-cycling). Most of these can be attributed to the crappy wall wart they call a power supply. If it's plugged into an UPS or replace it with your own DC power supply they generally hold up a lot better. I have a Netgear FS108 at home (8 port 10/100 switch) and I've found Netgear stuff to be as cheap as I would go and still be reasonably reliable. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
:At work I've got experience with 32-port D-Link 10/100 switched :hub. It works fine except that it hangs occasionally (can be :reset by power-cycling). So we don't buy them any more. Also :at my pre-previous employer we had small 8-port 10Mpbs hubs from :D-Link and they had the same problem, so it seems to be a family :problem. With about 20 hubs there was a hang approximately every :other day. : :-SB Oh joy. Well, we'll see what happens with this one. I had a Sohoware superflex 10/100 hub and it hung nearly every day. I'm also testing out a linksys switch (I bought a D-Link switch and a LinkSys switch). Unfortunately the NIC cards that came with the LinkSys switch, as far as I can tell, are no longer supported in -current. -Matt Matthew Dillon <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Cool little 100BaseTX switch - they're coming down in price
Matthew Dillon wrote:
>
> I picked up a nifty little D-Link DSS-5+ 5-port 10/100 switch today
> CompUSA had a 5-port network kit labeled 'DFE-910' which had the
> DSS-5+ and two DFE-530TX+ NIC Cards ('rl' driver), plus cables, for $130.
>
> It appears to operate quite nicely. I can run all 5 ports at
At work I've got experience with 32-port D-Link 10/100 switched
hub. It works fine except that it hangs occasionally (can be
reset by power-cycling). So we don't buy them any more. Also
at my pre-previous employer we had small 8-port 10Mpbs hubs from
D-Link and they had the same problem, so it seems to be a family
problem. With about 20 hubs there was a hang approximately every
other day.
-SB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Cool little 100BaseTX switch - they're coming down in price
I picked up a nifty little D-Link DSS-5+ 5-port 10/100 switch today
CompUSA had a 5-port network kit labeled 'DFE-910' which had the
DSS-5+ and two DFE-530TX+ NIC Cards ('rl' driver), plus cables, for $130.
It appears to operate quite nicely. I can run all 5 ports at
100BaseTX speeds in full-duplex mode and it seems to take whatever
I throw at it, though I didn't life test it so I don't know what
it can actually handle. It seems to have sufficient buffering to
deal with fragmented NFS packets without losing anything so I'm happy.
Prices have fallen a lot in the last year. I'm happy to be able to
get rid of my HUBs, I was constantly having to deal with packet loss
when running saturation tests and never able to figure out what
was causing it.
Note that buy.com lists a 'DFE-910' kit for around $100, but their
description of it is that it contains a hub rather then a switch. I
know what I got at CompUSA was a switch, not a hub, but I don't know
what you'd get if you bought the DFE-910 part number from buy.com.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
NLM v4 (file locking and NFS v3)
We have come across a problem wrt to a network file lock manager. Consider the case of a lock on a local file, and a request from a remote machine to lock that same file. fcntl(fd, F_SETLK, &fl) will return immediately with EAGAIN (this is for an exclusive case, of course), F_SETLKW will block (even if O_NONBLOCK has been set, this is annoying even if documented behavior). The question then becomes how is a user process to tell when the lock has become available again? Neither select(), nor poll() seem to have the desired affect. A couple possibilities that have floated by are to have a select() with a 30 second timeout, at which point scan the entire lock pending list. Are there any other possibilities? Also, could we get the fhopen, fhstat, and fhstatfs calls MFC-ed? They appear to be straightforward calls that do not depend on any VFS changes in -CURRENT. Furthermore they are very special purpose, they only have the potential to destabilize the system (if there are any bugs in them) if a program calls them. As it stands I know of zero production programs that would call these [nonexistent] syscalls :) -- David Cross | email: [EMAIL PROTECTED] Acting Lab Director | NYSLP: FREEBSD Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, David Scheidt <[EMAIL PROTECTED]> wrote: >On Sat, 18 Dec 1999, Ronald F. Guilmette wrote: > >> >> In a nutshell, teergrubing is the name that has been given to a simple >> technique that exploits a small but significant known weakness of most >> SMTP client implementations. This weakness is exploited to either slow >> down or halt the flow of e-mail from some SMTP client to some SMTP server. > >Think about it before you fire it up. You are essentially launching a DOS >attack on somebody's mail server. In some jurisdictions, that's a felony. That is just plain false. In fact it is more than false. It is silly. Why would you want to spread such a ridiculous rumor? Do you work for the DMA or something? The tgd daemon is an entirely defensive weapon... kinda like the old Regan-era Star Wars idea. It just sits there and does nothing until someone else attacks. If and when you _do_ start spamming my server, if I happen to be running the thing, all that happens is that you get stuck like a bug on flypaper. Next you'll be telling us that flypaper is against the laws that prohibit cruelty to animals. :-) Yea. Right. In which parallel Universe? P.S. What's so silly about this is that you got it entirely bass-ackwards. If *you* are sending *me* a ton of spam, it is *you* you might be prosecuted for having launced a Denial-Of-Service attack, not me. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In the last episode (Dec 18), Kevin Day said: > I've started a side project that I'm trying to figure out how to > scale. The end result will be a test-based realtime chat (IRC, java, > or otherwise) that will bring very large crowds. You wouldn't believe > how many geeks will show up on IRC for a TV/Movie star even > lessor known ones. > > I've found that a poorly advertised event with a not-so-famous > actress can draw 3-5 thousand people, easily. If I'm able to make > this grow, I'm sure that number will go much higher. > > What's the practical number of TCP connections per server? Is there > an easy guideline for how ram the kernel will be taking per > connection/route/socket/fd/etc? As a datapoint, the busiest IRC server in 1998 was irc.blackened.com, which peaked at around 8700 simultaneous connections (with a lot more traffic than you're likely to see). I forget whether it was running 2.2.7 or 3.0, but it was definitely FreeBSD, running a standard ircd. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Sat, 18 Dec 1999, David Scheidt wrote: > On Sat, 18 Dec 1999, Ronald F. Guilmette wrote: > > > > > In a nutshell, teergrubing is the name that has been given to a simple > > technique that exploits a small but significant known weakness of most > > SMTP client implementations. This weakness is exploited to either slow > > down or halt the flow of e-mail from some SMTP client to some SMTP server. > > Think about it before you fire it up. You are essentially launching a DOS > attack on somebody's mail server. In some jurisdictions, that's a felony. My mistake. I confused this with some of the other anti-spam measures. Being slow isn't criminal. (fortunatly for me!)_ David To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Sat, 18 Dec 1999, Ronald F. Guilmette wrote: > > In a nutshell, teergrubing is the name that has been given to a simple > technique that exploits a small but significant known weakness of most > SMTP client implementations. This weakness is exploited to either slow > down or halt the flow of e-mail from some SMTP client to some SMTP server. Think about it before you fire it up. You are essentially launching a DOS attack on somebody's mail server. In some jurisdictions, that's a felony. David Scheidt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody know if there is any way to make ports use differentwork dir?
On Sat, 18 Dec 1999, Matthew Dillon wrote: # It would be nice if there were a way to tell the ports system to put the # work directory somewhere other then where it is currently placed. For # example, to put it in /usr/obj or something like that. Has anyone done # this? Try setting the value of WRKDIRPREFIX which is akin to MAKEOBJDIRPREFIX in bsd.obj.mk. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Anybody know if there is any way to make ports use different workdir?
On Sat, Dec 18, 1999, Matthew Dillon wrote: > It would be nice if there were a way to tell the ports system to put the > work directory somewhere other then where it is currently placed. For > example, to put it in /usr/obj or something like that. Has anyone done > this? The authors of bsd.port.mk have. Try this: $ cd /usr/ports/misc/rtfm $ WRKDIRPREFIX=/tmp DISTDIR=/tmp make >> rtfm-0.2.tar.gz doesn't seem to exist on this system. >> Attempting to fetch from http://www.freebsd.org/~chris/distfiles/. Receiving rtfm-0.2.tar.gz (4881 bytes): 100% 4881 bytes transferred in 0.1 seconds (48.25 Kbytes/s) ===> Extracting for rtfm-0.2 >> Checksum OK for rtfm-0.2.tar.gz. ===> Patching for rtfm-0.2 ===> Applying FreeBSD patches for rtfm-0.2 ===> Configuring for rtfm-0.2 ===> Building for rtfm-0.2 cc -o rtfm rtfm.c -O -pipe -Wall Simply set WRKDIRPREFIX and DISTDIR and nothing gets written to the ports directory. Obviously you could put this in /etc/make.conf and make it much easier on yourself. Note that you end up in this case with /tmp/usr/ports/misc/rtfm/work/rtfm-0.2/ that you get to rip out later. Additionally, a /tmp/rtfm-0.2.tar.gz is left behind. -- |Chris Costello <[EMAIL PROTECTED]> |State-of-the-practice: What we can do with the money you have. `-- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Anybody know if there is any way to make ports use different work dir?
I would like to get my /usr/ports over a read-only NFS mount. At the moment the only way I can compile up any given port is to mkdir work and create and mount an MFS filesystem over it. A union mount might also work but union mounts are still somewhat problematic. It would be nice if there were a way to tell the ports system to put the work directory somewhere other then where it is currently placed. For example, to put it in /usr/obj or something like that. Has anyone done this? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, Ken Bolingbroke <[EMAIL PROTECTED]> wrote: >> If you would like to see an example of a very simple multi-connection server >> that runs as a single process (written in C) as described above, let me know >. > >I'd be very interested in seeing this, if you could post a URL perhaps? OK. Try this URL: ftp://ftp.e-scrub.com/pub/teergrube/sendmail-8.9.3-teergrube-patches.gz Fetch that file and then un-gzip it. Once you have done that, get a virgin set of Sendmail 8.9.3 sources, unpack them, cd to the root of the resulting directory, and then use un-gzipped file as a patchkit to patch the Sendmail sources. Then read the README.teergrube file which describes everything in great detail. (The part you are really looking for... the simple milti-connection daemon... is in the file tgd.c.) Basically, this patchkit adds a new (but very simple) daemon program to the Sendmail distribution. After applying the patches, and building Sendmail as you normally would, you will end up with both an executable for Sendmail and also an executable called `tgd'... the teergrubing daemon. (These will both get installed, e.g. into /usr/sbin) when/if you then install Sendmail as you normally would.) The code for the tgd daemon, in addition to being a simple demonstration of a single-process/multi-connection server daemon (as well as a nice simple demonstration of how to pass open file descriptors via UNIX domain sockets) also has a great deal of utilitarian value, especially if you happen to be one of the folks who, like myself, abhor all of the e-mail spam that seems to ceasely flow through the net's many remaining open and unsecured mail relays. Suffice it to say that if we could get a couple of hundred sites running this daemon, the current unsecured mail server hijacking problem on the net could be (and most likely would be) almost instantly reduced to per- haps 1/100th of its current size... not necessarily because all those remaining open relays would get properly closed/secured by their owners, but just because they would all suddenly become a lot less effective as spam conduits. Please see: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html for a brief introduction to basic tactical teergrubing. (The tgd daemon takes this quite a bit further, into what I would call ``advanced hard-core strategic teergrubing''). In a nutshell, teergrubing is the name that has been given to a simple technique that exploits a small but significant known weakness of most SMTP client implementations. This weakness is exploited to either slow down or halt the flow of e-mail from some SMTP client to some SMTP server. Teergrubing has been employed for some time in the fight against e-mail spam on the net, but I believe that it would be fair to say that the Sendmail patchkit whose URL is given above, and the `tgd' daemon contained therein, takes the general strategy of teergrubing to a new level. Teergrubing has been approved for use throughout the Internet by the Coalition for Non-Violent Resistance (CNVR). Ideally, tgd, and the associated Sendmail patches, should be used in conjunction with some external list of the IP addresses of ``bad'' e-mail sources that are to be disiplined. In this context, ``bad'' E-mail sources are either mail servers belonging to known spammers or else unsecured open mail relays (that may be remotely hijacked by spammers) or both. Three such lists exist at the present time. They go by the names of ORBS, RSS, and MAPS RBL. (Most people have probably heard of the MAPS RBL by now.) The ORBS list is most agressive of the three. It lists essentially any and all open/unsecured mail relays that have been brought to its attention. For more info regarding the ORBS list see http://www.orbs.org/. The RSS list only lists open mail relays that have already been found and explioted by spammers to relay spam. For more information on the RSS list see http://www.orbs.org/. The MAPS RBL list primarily lists IP addresses associated with mail servers of known spammers, but also lists some open mail relays that have already been exploited. See http://www.mail-abuse.org/rbl/ for more information on the MAPS RBL. The patchkit mentioned above allows any one of these lists to be used to select which mail senders will be teergrubed. In addition, a locally- maintained list of ``bad'' e-mail sources may also be specified, in addition to one of the external lists just mentioned. One last word about the goals of teergrubing... It will in fact most likely NEVER be possible to get every last one of the morons who are still running open/unsecured mail servers to properly secure/ close those servers. Some, perhaps many, will merely upgrade to more recent version of their current mail server software... versions which include anti-teergrubing logic... and then just continue on running their servers as open/unsecured mail relays. That's OK. Those few can then be blocked
Re: Practical limit for number of TCP connections?
> >Using a thread per connection has always been a bogus way of programming, > >it's easy, but it doesn't work very well. > > > OK, even if nobody else does, I'll bite. > > Why not? It scales poorly. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, Alfred Perlstein <[EMAIL PROTECTED]> wrote: >On Sat, 18 Dec 1999, Kevin Day wrote: > >> > The _clean_ way of doing it would be to write your multi-user server using >> > threads, and to assign one thread to each connection. If you can do that, >> > then the logic in the program becomes quite simple. Each thread just sits >> > there, blocked on a call to read(), until something comes in, and then it >> > just parses the command, does whatever it is supposed to do in response to >> > that command, and then goes back to the read() again. >> > >> > But as I understand it, there is not yet sufficient threads support in the >> > FreeBSD kernel to make this work well/properly. (I may perhaps be misinfo >rmed >> > about that, but that's what I have been told anyway.) >> >> I believe this is how ConferenceRoom works, so it seems ok, but I remember >> the comments that FreeBSD was their least preferred platform because of >> thread problems. > >Using a thread per connection has always been a bogus way of programming, >it's easy, but it doesn't work very well. OK, even if nobody else does, I'll bite. Why not? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, you wrote: > > >On Sat, 18 Dec 1999, Ronald F. Guilmette wrote: > >> # Increase the max # of open sockets, systemwide (use only on older kernels) >> #/sbin/sysctl -w kern.somaxconn=16384 > >Regarding the comment, "use only on older kernels", why only on older >kernels? Ummm because newer kernels don't seem to have any such parameter. :-) >What classifies as an older kernel--pre-3.0? pre-3.3? Try executing the command: /sbin/sysctl -w kern.somaxconn=16384 as root. If it works, then you have an ``older'' kernel. If it doesn't, then you have a ``newer'' one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sun4c as Xterminal - Problems
In message <[EMAIL PROTECTED]>, Dan Busa row writes: >Earlier than that. 2.2.5? It prevents the machine from being used >as part of a smurf amplifier. If you want to change the behaviour >see > >icmp_bmcastecho="NO"# respond to broadcast ping packets This is different; the change I was referring to stops FreeBSD from recognising old-style IP broadcasts as broadcasts. If you have a network 172.16.0.0/16, then 172.16.255.255 is accepted as a broadcast address, but 172.16.0.0 is not. Diskless Sun machines attempt to use the latter, so the broadcasts get ignored. The change is older than I thought though. The code was #ifdef'd out back in Dec 1995 in v1.33 of sys/netinet/ip_input.c, and was removed completely in v1.48 (Oct 1996). Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Sat, 18 Dec 1999, Kevin Day wrote: > > The _clean_ way of doing it would be to write your multi-user server using > > threads, and to assign one thread to each connection. If you can do that, > > then the logic in the program becomes quite simple. Each thread just sits > > there, blocked on a call to read(), until something comes in, and then it > > just parses the command, does whatever it is supposed to do in response to > > that command, and then goes back to the read() again. > > > > But as I understand it, there is not yet sufficient threads support in the > > FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed > > about that, but that's what I have been told anyway.) > > I believe this is how ConferenceRoom works, so it seems ok, but I remember > the comments that FreeBSD was their least preferred platform because of > thread problems. Using a thread per connection has always been a bogus way of programming, it's easy, but it doesn't work very well. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
On Sat, 18 Dec 1999, Ronald F. Guilmette wrote: > # Increase the max # of open sockets, systemwide (use only on older kernels) > #/sbin/sysctl -w kern.somaxconn=16384 Regarding the comment, "use only on older kernels", why only on older kernels? What classifies as an older kernel--pre-3.0? pre-3.3? If you don't use this on new kernels, is there an alternative or is it now dynamically allocated as I've seen rumored will happen? > If you would like to see an example of a very simple multi-connection server > that runs as a single process (written in C) as described above, let me know. I'd be very interested in seeing this, if you could post a URL perhaps? Thanks, Ken Bolingbroke [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
Kevin Day wrote: > > In message <[EMAIL PROTECTED]>, you wrote: > > > > >What's the practical number of TCP connections per server? > > > > I've gotten over 8,000 at one time on one FreeBSD box. I'm aware of boxes having been tested to ~100,000 connections if my memory serves correctly. I know there were problems going over 64k connections at one point due to a 16 bit reference counter in the routes. > > The way to solve that is to include calls to setsockopt() in your server > > that will have the effect of reducing the per-connection I/O buffer sizes > > just after you accept() each new connection. > > Speaking of accepting... What's the upper limit on listen queues? Something > around 64, correct? Tuneable: peter@overcee[6:00am]~src/sys/kern-244> sysctl kern.ipc.somaxconn kern.ipc.somaxconn: 128 Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Natd with Pmtu Discovery
Natd does not handle pmtu discovery well when the mtu for the interface it is using is changed, either manually or under program control, after natd is started. The following provides details of why, and a work-around. Problem --- Gateway router with natd has erratic or poor TCP performance when the outbound (nat) interface is modified after startup or during startup subsequent to launcing natd from rc.network such as from scripts in /usr/local/etc/rc.d or /etc/rc.local. Analysis 1. Natd learns the mtu value of its interface on startup from rc.network following ifconfig or DHCP initialization. 2. Skip startup from a startup script in /usr/local/etc/rc.d/skip.sh modifies the mtu value in the kernel interface structure. 3. On receiving a packet to transmit outbound, natd generates an icmp type 3 need-to-fragment packet back to the sending host using the value learned in paragraph 1. 4. The sending host retransmits using this size. The packet is still too large for the outbound interface to transmit. 5. If the sending host happens to be a WinNT with pmtu discovery enabled, paragraphs 3 and 4 are repeated until black hole discovery takes over, if enabled, or forever, if not enabled. The -dynamic flag does not cause natd to learn the new value when the interface mtu is modified. While this problem was discovered in gateways that use both skip and natd on the same interface, it has been confirmed that the problem exists any time the natd interface mtu is modified, either manually or during startup after the natd daemon has been started. Workaround -- This behavior can be avoided for the current autostart requirement by delaying the startup of natd until after the interface mtu is set by skip from skip.sh (such as placing the equivalent shell script line in /etc/rc.local). The program name, option flags and interface name will have to be given explicitly as these values from rc.conf are not available in rc.local. Correction -- The natd program should learn the modified value of the interface mtu before transmitting need-to-fragment messages. As this method of avoiding fragmentation is becoming more common (and is mandatory in IPV6) this would be a worthwhile modification. Wierd Note -- The problem does not appear to occur in 3 gateways that are bit-identical except that they are running unstripped binaries (identical, if stripped) of natd. Jim Flowers <[EMAIL PROTECTED]> #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, you wrote: >Speaking of accepting... What's the upper limit on listen queues? Something >around 64, correct? I don't know, but why do you ask? Do you have some reason to believe that the length of listen queues is going to be an issue? >> Quite a lot of memory (either virtual or real) will also get sucked up >> *if* you have a separate and independent process handling each separate >> connection. A simple experiment I did awhile back indicated that on >> recent-vintage versions of FreeBSD, the absolute minimum per-process >> overhead was 12KB. That is a *minimum*, e.g. for a process that contains >> essentially no code and no data. But you will probably never see that in >> practice, which is to say your minimum per-process overhead is going to >> be bigger than that. > >Yeah, I don't plan on doing things the apache way. :) One process per client >seems silly here, since nearly every client will be getting the exact same >data. I think that you mean that you don't plan on doing things the Sendmail way. (1/2 :-) Seriously, Sendmail forks a child for every connection... two actually, assuming that the client actually DOES SOMTHING (e.g. sending mail) and then that child/children hang around until the _client_ finishes what it is doing... which can sometimes take a long long time if the client itself is slow. But unless I'm mistaken... which I very well might be... apache just gets a request, services it, and that that it... That par- ticular instance of Apache then goes immediately back to the free servers pool. That's what I was told anyway. >> The _clean_ way of doing it would be to write your multi-user server using >> threads, and to assign one thread to each connection. If you can do that, >> then the logic in the program becomes quite simple. Each thread just sits >> there, blocked on a call to read(), until something comes in, and then it >> just parses the command, does whatever it is supposed to do in response to >> that command, and then goes back to the read() again. >> >> But as I understand it, there is not yet sufficient threads support in the >> FreeBSD kernel to make this work well/properly. (I may perhaps be misinform >ed >> about that, but that's what I have been told anyway.) > >I believe this is how ConferenceRoom works, so it seems ok, but I remember >the comments that FreeBSD was their least preferred platform because of >thread problems. Yes. As I say, my understanding is that FreeBSD still doesn't have real and/or complete thread support in the kernel. So if you have a multi-threaded application and one thread blocks (e.g. on I/O) then the whole thing is blocked. >> The other way is just have your server be a single thread/process, and to >> have it keep one big list of all of the connections (i.e. socket fds) that >> it has open at present. Then it just executes mail loop, over and over >> again. At the top of the main look is one big honkin' call to select() >> in which you find out which of your connections is ready to be read or >> written. Then you go off and read/write those as appropriate, and then >> just come back and do the big select() again. (You could do this using >> calls to poll() instead of calls to select(), and that might be a bit >> more efficient.) > >This is how traditional ircd's handle it, and how I was planning to. It >seems the most efficient, especially since 99.999% of the clients will be >receiving the same data, it'll make transmission pretty easy. Not really. To be safe, you really shouldn't just assume that you can just blast out the same output data to all of the connections at the same time. You really should check (using select() or poll()) to see which ones are actually and currently in a state where you _can_ write to them. Some may not be, in which case writing to them is a Bad Idea... either that data you write will be thrown away (if you set the socket to non-blocking mode) or else worse, your whole server will block on that one socket and the one call to write() or send(). >> If you want a lot of connections, start by increasing the values of >> "maxusers" and NMBCLUSTERS in your kernel config file. Then build and >> install a new kernel. How much is enough for these parameters? Beats >> me. If you find that you are running out of resources, increase them >> some more and then try again. > >I really wish more of those options were dynamically tunable, instead of a >magic formula that maxusers controls. :) I can only agree. The system I was running that had more than 8,000 connections open at a time in fact had only a small handful of ``users'', i.e. me and a few daemon processes, and the big server process I described. It therefore seemed kinda weird to have to set maxusers to something in excess of 200, and doing so probably caused a bunch of kernel tables to be a lot bigger than they really had to be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freeb
Re: Practical limit for number of TCP connections?
Wow, thanks for such a detailed reply. :) > > > In message <[EMAIL PROTECTED]>, you wrote: > > >What's the practical number of TCP connections per server? > > I've gotten over 8,000 at one time on one FreeBSD box. Yeah, best case, I've had several thousand myself, but not really doing anything. :) I'm going to try to come up with a test suite for this sorta thing, unless someone pipes in that it already exists. > The biggest memory issue for a box that's handling a lot of TCP con- > nections at a time is the socket I/O buffer sizes. Unless you take > steps, programatically, to reduce these, you will get (I think) one > 4KB buffer for input and another 4KB buffer for output. This is for > EACH active TCP connection. I hadn't considered this much buffering, but it makes sense. > > This can add up to a substantial amount of memory if you have a lot of > connections. > > The way to solve that is to include calls to setsockopt() in your server > that will have the effect of reducing the per-connection I/O buffer sizes > just after you accept() each new connection. Speaking of accepting... What's the upper limit on listen queues? Something around 64, correct? > > Quite a lot of memory (either virtual or real) will also get sucked up > *if* you have a separate and independent process handling each separate > connection. A simple experiment I did awhile back indicated that on > recent-vintage versions of FreeBSD, the absolute minimum per-process > overhead was 12KB. That is a *minimum*, e.g. for a process that contains > essentially no code and no data. But you will probably never see that in > practice, which is to say your minimum per-process overhead is going to > be bigger than that. Yeah, I don't plan on doing things the apache way. :) One process per client seems silly here, since nearly every client will be getting the exact same data. > The _clean_ way of doing it would be to write your multi-user server using > threads, and to assign one thread to each connection. If you can do that, > then the logic in the program becomes quite simple. Each thread just sits > there, blocked on a call to read(), until something comes in, and then it > just parses the command, does whatever it is supposed to do in response to > that command, and then goes back to the read() again. > > But as I understand it, there is not yet sufficient threads support in the > FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed > about that, but that's what I have been told anyway.) I believe this is how ConferenceRoom works, so it seems ok, but I remember the comments that FreeBSD was their least preferred platform because of thread problems. > The other way is just have your server be a single thread/process, and to > have it keep one big list of all of the connections (i.e. socket fds) that > it has open at present. Then it just executes mail loop, over and over > again. At the top of the main look is one big honkin' call to select() > in which you find out which of your connections is ready to be read or > written. Then you go off and read/write those as appropriate, and then > just come back and do the big select() again. (You could do this using > calls to poll() instead of calls to select(), and that might be a bit > more efficient.) This is how traditional ircd's handle it, and how I was planning to. It seems the most efficient, especially since 99.999% of the clients will be receiving the same data, it'll make transmission pretty easy. > If you want a lot of connections, start by increasing the values of > "maxusers" and NMBCLUSTERS in your kernel config file. Then build and > install a new kernel. How much is enough for these parameters? Beats > me. If you find that you are running out of resources, increase them > some more and then try again. I really wish more of those options were dynamically tunable, instead of a magic formula that maxusers controls. :) Thanks again, Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Practical limit for number of TCP connections?
In message <[EMAIL PROTECTED]>, you wrote:
>What's the practical number of TCP connections per server?
I've gotten over 8,000 at one time on one FreeBSD box.
>Is there an easy guideline for how {much} ram the kernel will be taking per
>connection/route/socket/fd/etc?
Not that I am aware of.
The biggest memory issue for a box that's handling a lot of TCP con-
nections at a time is the socket I/O buffer sizes. Unless you take
steps, programatically, to reduce these, you will get (I think) one
4KB buffer for input and another 4KB buffer for output. This is for
EACH active TCP connection.
This can add up to a substantial amount of memory if you have a lot of
connections.
The way to solve that is to include calls to setsockopt() in your server
that will have the effect of reducing the per-connection I/O buffer sizes
just after you accept() each new connection.
Quite a lot of memory (either virtual or real) will also get sucked up
*if* you have a separate and independent process handling each separate
connection. A simple experiment I did awhile back indicated that on
recent-vintage versions of FreeBSD, the absolute minimum per-process
overhead was 12KB. That is a *minimum*, e.g. for a process that contains
essentially no code and no data. But you will probably never see that in
practice, which is to say your minimum per-process overhead is going to
be bigger than that.
If this part of the equation (i.e. per-process overhead) causes you grief
(as it did in my case) then you might consider writing your server as a
sort of multi-user monitor sort-of thing, i.e. a single process that will
service multiple connections. (That's what I did.)
There are _potentially_ a couple of ways of doing this, but at the present
time, and with current FreeBSD kernels, you probably don't have a lot of
choice, and I think there's only one way of doing it.
The _clean_ way of doing it would be to write your multi-user server using
threads, and to assign one thread to each connection. If you can do that,
then the logic in the program becomes quite simple. Each thread just sits
there, blocked on a call to read(), until something comes in, and then it
just parses the command, does whatever it is supposed to do in response to
that command, and then goes back to the read() again.
But as I understand it, there is not yet sufficient threads support in the
FreeBSD kernel to make this work well/properly. (I may perhaps be misinformed
about that, but that's what I have been told anyway.)
The other way is just have your server be a single thread/process, and to
have it keep one big list of all of the connections (i.e. socket fds) that
it has open at present. Then it just executes mail loop, over and over
again. At the top of the main look is one big honkin' call to select()
in which you find out which of your connections is ready to be read or
written. Then you go off and read/write those as appropriate, and then
just come back and do the big select() again. (You could do this using
calls to poll() instead of calls to select(), and that might be a bit
more efficient.)
The only real problem with doing things this way is that you have to diddle
some things to make sure the bit arrays that you pass to select() are big
enough to handle the maximum number of connections you ever anticipate
having to service/maintain at one time. Ideally, all you really have to
do in order to get this to happen is to redefine the pre-processor symbol
FD_SETSIZE to your max connections number before you include ,
but then your are stuck selecting some other compile-time fixed number
(in place of the default 1024), and personally, I prefer to use a somewhat
different approach that allows me to use a dynamic number, i.e. one I get
from querying the kernel for the current hard limit on simultaneously open
fds.
>My next interview will be Sunday, but to a much smaller audience than
>normal, so I'll be able to do some experimenting. Can anyone recommend
>specific things to watch for, wrt limits and memory use? I'll be watching
>vmstat carefully, at least.
If you want a lot of connections, start by increasing the values of
"maxusers" and NMBCLUSTERS in your kernel config file. Then build and
install a new kernel. How much is enough for these parameters? Beats
me. If you find that you are running out of resources, increase them
some more and then try again.
After installing your new kernel, you'll probably want to add commands
like the following to your /etc/rc.local file:
# Increase the max # of open files, systemwide
/sbin/sysctl -w kern.maxfiles=16384
# Increase the max # of open sockets, systemwide (use only on older kernels)
#/sbin/sysctl -w kern.somaxconn=16384
# Increase max # of open files per process
/sbin/sysctl -w kern.maxfilesperproc=16384
Last but not least, make sure that whatever account your server will run
under is associated with some login class (see /etc/login.conf) that has
an appropriately high setting for openfiles
Re: aout gdb in 3.x
On Saturday, 18 December 1999 at 14:51:59 +, Doug Rabson wrote: > On Fri, 17 Dec 1999, Julian Elischer wrote: > >> >> How does one compile a version of GDB that can read a.out files? >> I know there is a way of doing it but I have totoally failed to work >> out how to do so. > > I think you can do this by changing src/gnu/usr.bin/binutils/gdb/Makefile. > Change: > > CFLAGS += -DFREEBSD_ELF > > to set FREEBSD_AOUT instead. I thought it used to be possible for gdb to recognize multiple formats. Is this no longer the case? 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
Re: ATA w/ today's -CURRENT
On Mon, 13 Dec 1999, Steve Ames wrote: > Hrm... no question that the ATA driver is better today, but its still > not reporting DMA on my Quantum bigfoot drive (which should support DMA: > http://www.quantum.com/products/archive/bigfoot_cy/bigfoot_cy_features.htm) > > The Maxtor is pretty old (But its been current since 3.0 :) but may > still have some DMA support? (ftp://ftp.maxtor.com/pub/ide/71626ap.txt) I have this drive lying in the general few-foot radius of my computer. It's... well, problematic, to say the least, if trying to use it as a slave on ata1 where ata-pci0 (ALi) ata0 --- ad0: ATA-4 (16 s/i, 1 dq, UDMA33) \ `-- acd0: (PIO) `-- ata1 --- ad1: ATA-4 (ditto ad0) `-- ad2: ATA-0 (16, 1, PIO) I get these messages and very goofy access to ad1: Dec 15 19:08:06 green /kernel: Mounting root from ufs:/dev/ad0s1a Dec 15 19:08:06 green /kernel: ad1: ad_timeout: lost disk contact - resetting Dec 15 19:08:06 green /kernel: ata1: resetting devices .. done Dec 15 19:08:06 green /kernel: ad1: ad_timeout: lost disk contact - resetting Dec 15 19:08:06 green /kernel: ata1: resetting devices .. done Dec 15 19:08:06 green /kernel: ad1: ad_timeout: lost disk contact - resetting Dec 15 19:08:06 green /kernel: ata1: resetting devices .. done Dec 15 19:08:06 green /kernel: ad1: ad_timeout: lost disk contact - resetting Dec 15 19:08:06 green /kernel: ad1: ad_timeout: trying fallback to PIO mode Dec 15 19:08:06 green /kernel: ata1: resetting devices .. done (rc continues here) So ad1 runs in PIO, and mount may or may not have successfully gotten ad1 mount entries up. > > What am I missing? > Something possibly close to what I am :/ That 71626 seems strange. > -Steve -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sun4c as Xterminal - Problems
On Sat, 18 Dec 1999, Ian Dowse wrote: > In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: > >I'm trying to use a Sun ELC (sun4c) as an Xterminal on my FreeBSD > >system using Xkernel 2.0. I've used the old howto's from 1996 > >(Philippe Regnauld) as well as NetBSD diskless howto's to set this up. > > >So, does anyone have a fix for this? Back in '96-97, Luigi Rizzo and > >Mike Smith (among others) seemed to be doing this, so I'm hoping someone > >still does. > > I think sometime around 3.0, the networking code in FreeBSD stopped > responding to IP broadcasts where the 'zero' subnet broadcast address, > which in your case is 209.9.69.0. Earlier than that. 2.2.5? It prevents the machine from being used as part of a smurf amplifier. If you want to change the behaviour see icmp_bmcastecho="NO"# respond to broadcast ping packets in rc.conf If you do turn it on make sujre your firewall or router are blocking pings to your broadcast address. Dan -- Dan Busarow 949 443 4172 Dana Point Communications, Inc.[EMAIL PROTECTED] Dana Point, California 83 09 EF 59 E0 11 89 B4 8D 09 DB FD E1 DD 0C 82 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Practical limit for number of TCP connections?
I've started a side project that I'm trying to figure out how to scale. The end result will be a test-based realtime chat (IRC, java, or otherwise) that will bring very large crowds. You wouldn't believe how many geeks will show up on IRC for a TV/Movie star even lessor known ones. I've found that a poorly advertised event with a not-so-famous actress can draw 3-5 thousand people, easily. If I'm able to make this grow, I'm sure that number will go much higher. What's the practical number of TCP connections per server? Is there an easy guideline for how ram the kernel will be taking per connection/route/socket/fd/etc? My next interview will be Sunday, but to a much smaller audience than normal, so I'll be able to do some experimenting. Can anyone recommend specific things to watch for, wrt limits and memory use? I'll be watching vmstat carefully, at least. Thanks, Kevin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Register a KLD module
Andrzej Bialecki wrote: > On Sat, 18 Dec 1999, Zhihui Zhang wrote: > > > > > I have looked at the KLD examples and found out that they boils down to a > > DECLARE_MODULE() macro with the subsystem given as SI_SUB_DRIVERS. Is > > there any reason for using this particular SI_SUB_DRIVERS? I see another > > example at http://www.freebsd.org/~abial/ that uses SI_SUB_EXEC. > > > > Is this subsystem id really useful for KLDs? KLDs are loaded when we run > > the kldload command and the subsystem ids are sorted at boot time. > > This is not quite true. The KLDs can be loaded by the bootloader. > > Andrzej Bialecki And DECLARE_MODULE() is a primary method of initializing things in the static kernel binaries too. For device driver modules it doesn't matter much, but should be done at the same time as the others so that a complete device driver set is available before probing begins. Drivers that are added after probing cause a reprobe to happen/ Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Register a KLD module
On Sat, 18 Dec 1999, Zhihui Zhang wrote: > > I have looked at the KLD examples and found out that they boils down to a > DECLARE_MODULE() macro with the subsystem given as SI_SUB_DRIVERS. Is > there any reason for using this particular SI_SUB_DRIVERS? I see another > example at http://www.freebsd.org/~abial/ that uses SI_SUB_EXEC. > > Is this subsystem id really useful for KLDs? KLDs are loaded when we run > the kldload command and the subsystem ids are sorted at boot time. This is not quite true. The KLDs can be loaded by the bootloader. Andrzej Bialecki // <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com) // --- // -- FreeBSD: The Power to Serve. http://www.freebsd.org // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Register a KLD module
I have looked at the KLD examples and found out that they boils down to a DECLARE_MODULE() macro with the subsystem given as SI_SUB_DRIVERS. Is there any reason for using this particular SI_SUB_DRIVERS? I see another example at http://www.freebsd.org/~abial/ that uses SI_SUB_EXEC. Is this subsystem id really useful for KLDs? KLDs are loaded when we run the kldload command and the subsystem ids are sorted at boot time. Any help is appreciated. -Zhihui To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Resolv.conf question
Andy Farkas wrote: > > On Fri, 17 Dec 1999, Jim Durham wrote: > > > The 3.3 Box is a local server on a disconnected LAN talking > > to a "remote" server that spools mail, which is grabbed by > > fetchmail. We are running PPP on-demand to the external > > server via a dial-up to an ISP. However, PPP only holds the > > line up from 8am-8pm and this is happening at 1:59am, coinciding > > with the "periodic daily" scripts from crontab. > > > > Seemed wierd to me.. > > "enable dns" in /etc/ppp/ppp.conf will cause ppp to fiddle with > resolv.conf everytime you connect (8am-8pm). Hello Andy, You were correct. One of the scripts in "periodic/daily" was tickling the tun0: interface, causing ppp to automatically connect to the ISP at 1:59am. Apparently, it was busy enough to stay up and not reconnect on the days when I checked the modification time of the /etc/resolv.conf file, so it fooled me by being 1:59m instead of 8am, when cron fires up the connection. I pulled the "enable dns" line out and all should be well now. It had me puzzled for sure. Thanks to you and all who replied. -- Jim Durham To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic sysctls (Re: Per CPU timekeeping for SMP)
On Fri, 17 Dec 1999, Zhihui Zhang wrote: > > On Fri, 17 Dec 1999, Andrzej Bialecki wrote: > > > On Fri, 17 Dec 1999, Arun Sharma wrote: > > > > > I have also figured out how to dynamically register sysctl nodes. > > > The trick is to basically malloc a sysctl_oid and fill in the right > > > fields and calling sysctl_register_oid. The code is in a kernel > > > module available from: > > > > > > http://sharmas.dhs.org/~adsharma/projects/freebsd/sysctl.tar.gz > > > > > > It really needs to go into the base kernel. Also, I think > > > sysctl_register_long and its yet to be written friends (register_int) > > > etc, need to go into kern_sysctl - so that others can reuse the code > > > to dynamically create sysctl nodes. > > > > Can this patch be applied to FreeBSD 3.3-Release? If so, is it difficult > to do so? You would need to port the dynamic sysctl work first. In principle it isn't difficult but it affects quite a few files other than the core sysctl code itself. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: aout gdb in 3.x
On Fri, 17 Dec 1999, Julian Elischer wrote: > > How does one compile a version of GDB that can read a.out files? > I know there is a way of doing it but I have totoally failed to work > out how to do so. I think you can do this by changing src/gnu/usr.bin/binutils/gdb/Makefile. Change: CFLAGS += -DFREEBSD_ELF to set FREEBSD_AOUT instead. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Sun4c as Xterminal - Problems
In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >I'm trying to use a Sun ELC (sun4c) as an Xterminal on my FreeBSD >system using Xkernel 2.0. I've used the old howto's from 1996 >(Philippe Regnauld) as well as NetBSD diskless howto's to set this up. >So, does anyone have a fix for this? Back in '96-97, Luigi Rizzo and >Mike Smith (among others) seemed to be doing this, so I'm hoping someone >still does. I think sometime around 3.0, the networking code in FreeBSD stopped responding to IP broadcasts where the 'zero' subnet broadcast address, which in your case is 209.9.69.0. We currently work around this on some 3.x machines by adding an alias address (which can be anything, even not in the same subnet) that has a broadcast address of our subnet zero address. Try something like: ifconfig fxp0 inet 10.0.0.1 netmask 0x broadcast 209.9.69.0 alias Maybe the old behaviour of responding to the subnet zero address should be available via a sysctl? Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
