Re: poor ethernet performance?
> : Good point but I think it's like how much of 100Mhz a 100BaseTX > :can push. If it pushes 100%, then it might be wise to have a little more > :room for overhead. Kinda like a car, better to have reserve power when > :you need it then pushing it to the max. In regards to 1000BaseT, I > :thought there was no standards for that yet, atleast all the Gigabit stuff > :is all fiber and not copper. Quality of cable does matter, atleast in > :high-end audio/video it does and I'm sure data would be more picky than > :human ears. > : > : > :Cheers, > :Vince - vi...@mcestate.com - vi...@gaianet.net __ > :Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > > The copper gigabit standard isn't out yet, but I was under the impression > that they were pretty close. > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. One of the big deals with the different grades of cable is the degree of crosstalk between the transmit and receive pairs in the cable sheath. When you're talking about Category-3 or Category-5 cable systems, this INCLUDES the connectors, patch panels, cross-connect blocks and cross-connect cables. For instance, you have to work pretty hard to do better than 10Base-T with a Category-3 wiring system if you have type 66 punch blocks because of the impedence bump and crosstalk issues. Same sort of things apply at 100base-T and Category-5 cable systems. Using gold-plated "Monster Cable" is just pissing away money of the other components are also up to the same level of "quality" (har, har). And, as Matt said, if you're not getting CRC errors then it's good enough, and there's no point spending money to get better wire. louie (who uses #12 ROMEX cable for speaker wire.) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---Steve Tarkalson said: > > this is solved by one of two methods: > >1-) require the caller of gethostbyaddr() to supply a pointer to > >a hostent struct which will be filled. > > or 2-) the library uses thread specific storage which is re-used in > >each call. > > > You could malloc() a struct hostent for each call to > gethostby*(), each time registering the hostent in some list along with the > thread's PID. If the same thread calls gethostby*, use the same buffer, or > allocate a new one if another thread calls it. Have a static function be > called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
> > Well, I am the person who has this problem. > > The RFCs does not explicitly say that we should not use underscore > > character > > as far as I understood. But it suggests which characters we should use. > > > RFC 952 > >1. A "name" (Net, Host, Gateway, or Domain name) is a text string up >to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus >sign (-), and period (.). Note that periods are only allowed when >they serve to delimit components of "domain style names". > > RFC 1101 > >The current syntax for network names, as defined by [RFC 952] is an >alphanumeric string of up to 24 characters, which begins with an >alpha, and may include "." and "-" except as first and last >characters. This is the format which was also used for host names >before the DNS. Upward compatibility with existing names might be a >goal of any new scheme. > > The above two documents limit the characters that may be used a a _ is not > one of them. FreeBSD behaves correctly in this manner. But the DNS is used to hold all sorts of information. For example, how do you reconcile domain names like: 42.10.202.144.IN-ADDR.ARPA in the DNS? It violates the "starts with alpha" "requirement" in 952 and 1101 that you quotes, yet we use these things all the time. In fact, you can send email to that domain name because it has an A record associated with it, as well as a PTR record. I've always thought that the code that barfs on these names in gethostbyname() really violates the "be conservative in what you send, and liberal in what you receive" thought that made the Internet work. Yeah, yeah, BIND does it, but that's no excuse, either. What do I know; I was just the first chair of the domain name working group in the IETF so many years ago before it got fashionable. grumble, louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
> > That IS a violation of the standard, since A records > are not valid for hosts in in-addr.arpa. > And next I suppose you'll tell me that PTR records are not valid outsize of the IN-ADDR.ARPA portion of the DNS namespace? What people really miss is that the DNS is a distributed database with delegation, used for all sorts of purposes. Some of them are widely known and almost universal (e.g., "look up and address for this host"). Some parts of the namespace are used as indicies for special purposes (e.g., translate a 4 octet IP address into a DNS name). The DNS can store names where the values used for each octet of a label in a DNS name can have any value at all between 0 and 255, including " ", ".", and other rude things. The general purpose mechansim can be (ab)sed for all sorts of purposes not originally envisioned (like Hesiod - you want to exclude "_" from user names?) While gethostbyname() and it's ilk are used for one limited, scoped purpose is no reason to break previously working configurations. That the ISC got a hair up their ass to break all those previously working names is just a shame. Depending on my application, I might just want to have some part of the DNS namespace return object that look like IP addresses for domain names which are not "hosts." The current implemention of bind makes that impossible unless I want to resort to using the raw resolver routines, which is just busy-work. This is just an example of "smart-ass" software that believes it knows better than the user does. louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
[I'm catching up on a bunch of FreeBSD mail since being out on vacation, so perhaps I've missed the essence of this thread..] I've also had the desire to capture the output produced when /etc/rc is run for all the reasons mentioned. I always thought that perhaps init would simply capture stdout on the other end of a pipe, and logically do the "tee" thing with it. In fact, couldn't init logically exec a sh /etc/rc | tee /tmp/rc-output when invoking /etc/rc? (Where to put the output would seem to be one of the more difficult choices since you don't start with a writable file system mounted anywhere..) Or perhaps init could capture the output on the end of a pipe and subsequently syslog it while it's echoing it to /dev/console. louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: c9x (new ANSI C)
> On Wed, 19 May 1999, Chuck Robey wrote: > > > Becoming well versed in C++ has meant that I can now bore you endlessly > > with well expressed reasons why I dislike C++. Now you have all the > > language propeller-heads wanting to change C into a C++ lookalike. > > > I've always preferred Objective-C, simply because it's unintrusive (not > that I speak it that well :). Truly and example of the "less is more" concept in action. I've done some non-trivial development in Objective-C, and I can assure you that I haven't missed C++'s operator overloading. louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial ports programming
> > Hi! > > > > Some days ago I've faced with the following problem: > > I need some kind of action (while coding user space > > program actively handling the serial port) to get > > sure all the bytes I've wrote to it are _transmitted_. > > I know about "ioctl(fd, TIOCDRAIN)", but this ioctl > > is accomplished with tty buffers draining to (probably) > > FIFO buffer of the serial port. Is there any (portable > > preferably) way to get an acknolege or to block until > > FIFO buffer is cleared? The situation is that I can't > > simply write additional 64 bytes (I did not see any > > serial ports with FIFO larger than 64 bytes) and > > drain the tty buffers - I have to catch the exact > > moment ... > > You could close the device, but that may have an adverse effect on your > application, as it will drop DTR. > > There is no other way, no. Generally speaking, when you have this type of concern regarding communications between two devices, you have to rely on the remote device to acknowledge the data. Even if you knew all the bits left the UART in your serial port, the data could have been damaged along the way, or might simply be queued up inside of an error-corrected modem that's trying to deliver the data to the remote end. louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Advice on deriving accurate time values from the kernel?
I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're willing to spend some money, you can get hardware to plug into a PCI slot that can return timestamps in 100ns units, as well as generating interrupt at some time in the future, etc. See http://www.bancomm.com/cbc637PCI.htm for one example of such hardware. I have a device driver for FreeBSD for this board which even allows user processes to get precise timing by mmap()'ing the device registers into user space for easy access. The driver will be contributed to the FreeBSD project "soon." I was pretty close to doing so just prior to the newbus conversion and now need to update the driver for a more recent -current. louie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: EBCDIC -> ASCII
> > Warner Losh writes: > > > Even the name (dd) comes from IBM's control language (JSYS?). > > Huh! I never realized that. > //GO.SYSIN DD * > ... > // > Where are my punch cards? :-) man 6 bcd To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: echo request deny
> On Tue, 6 Feb 2001, milunovic wrote: > > > Is there anyway to deny echo request on FreeBSD (except ipfw add deny > > icmp from any to any) ? > > On Linux It was simple,just echo 1>/proc/.../icmp_echo_request > > If you just want to block echo_requests and don't want to > block any other ICMP why not use ipfw? > > ipfw add 1000 deny icmp from any to any in via xl0 icmptypes 8 > > This will still allow other icmp to work...so why not use it? Yes, indeed. Just blocking all of ICMP will cause things like Path MTU discovery to fail. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: call for testers: port aggregation netgraph module
The crock in these trunking schemes is all the trouble and effort expended to avoid re-ordering frames across the trunk bundle. This is why you see things like the hashing techniques so that an individual flow of traffic doesn't get reordered because it always is serialized over the a single path. I'll observe that there's nothing in the IP architecture which (should) rely on packets not being reordered. I'll also observe that in a network with multiple ethernet switching running a spanning-tree protocol, you probably should't rely on packet reordering never happening when a link fails and the spanning tree computation is re-run. So, a clever implementation might choose to drain a single queue rather than having multiple queues, one per network interface. Of course, some network stacks don't deal well with TCP segments arriving out-of-order, but they are just broken. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: howto access an oddly shaped partition on a floppy ?
> > > this would only work after the kernel has control, and the kernel > > > needs far more than 10 cylinders... > > > > What about /boot/loader? Does that use the bios also? Can't we build > > one with a modified fd0 in it? > > yes it uses the bios, and it is large enough (100+ KB compressed if > you include forth, ~70KB without) to kill most of the savings coming > from this trick. So how about a options flag on the floppy driver which translates block addresses beyond 1440K into the "extra" sectors? I don't know that there's a "clean" way insert that into the driver, just glancing at the code.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: howto access an oddly shaped partition on a floppy ?
> > So how about a options flag on the floppy driver which translates > > block addresses beyond 1440K into the "extra" sectors? I don't > > know that there's a "clean" way insert that into the driver, just > > glancing at the code.. > > that is another possibility, yes. But it still remains the challenge > of controlling how the filesystem code allocates blocks to > make sure that the first things you write really end up into > the "initial" part of the disk so the bios can boot from it. Depending on the shape of the files you need to have on the disk, you could split this between two FreeBSD partitions (/dev/fd0a and /dev/fd0d or something), with the second partition being the bizzaro extra sectors. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
> As I remember, way back in the mists of 1990 when I first encountered a NeXT > box, one of the principal reasons for selecting the Mach 2.x micro kernel was > "mach messaging". This was a unified mechanism for almost all IPC both within > one host or distributed over a network, where eg. sockets (netork or unix > domain), pipes etc. were seen as abstractions of the core messaging function. > This fitted very well with the general OO design philosophy of the company. > If anyone has access to a copy of the socket(2) man page from any NeXTSTEP > version, I dimly remember there being an informative paragraph about this > point. This is mostly true, but the Mach kernel they shipped definately wasn't what I'd call a "micro kernel". It was based on the earlier CMU monolithic 4.3BSD Mach kernel. At the time, we had a source license for their kernel (at least most of; not device drivers, feh!), and this was very clear. > Whilst Mach messaging was not commonly used directly in the Unix userland > which was pretty much stock BSD 4.3, it was very important in the AppKit --- > NeXT's real stock in trade. In fact, the IPC between the appkik/user processes and the Display PostScript server really made use of this, could result in very high performance when moving large bitmapped images, etc. I would love to have a UI available these days; it was worlds better than X at the time, and frankly, still better than what we have today. The afterstep and WindowMaker guys have made some progress emulating the visual interface. But can you imagine trying to run GNOME or KDE on a 25Mhz 68030 today? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to disable software TCP checksumming?
The TCP checksum protects more than just the contents of the packet on the wire; it's also a (somewhat) weak check on the contents of your packet sitting in memory, and as it's going over the bus in your computer between memory and peripherals and for other end-to-end sorts of issues. Of course, with rude things like NAT boxes and other network elements taking liberties with your data, this becomes less and less useful as time goes on, sigh. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to disable software TCP checksumming?
> Giorgos Keramidas wrote: > > > > There are good reasons why checksumming in upper layers should not be disabled > > even if some lower layer does checksumming of its own. I recall reading some > > good points on this one at "TCP/IP Illustrated, Volume I" from (now late) > > Richard W. Stevens. > > It seems to me to be kind of moot to check the same value twice, unless > you suspect hardware problems. Aren't you talking about two different > checks over the same data instead of checksum off-loading? Suspect hardware problem? Of course you should! That's why memory systems have parity or ECC, and I/O buses are similarlly protected. At least on real computers. The link-level CRC only protects the data as it goes over the link between the link-level hardware which generates the CRC and the box on the other end that receives it. It does not protect the data end-to-end, so if it's gets corrupted whilst sitting in memory in an intermediate node, you won't detect that. Why would it get corrupted? 1. Software. Random unrelated other software does a random store in the buffer containing your packet sitting in memory. Fancy device drivers that do scatter-gather I/O gets it wrong every now and then and points off into space. mbuf cluster which should be treated as read-only isn't, and some other code hoses it. (See PR kern/27782 at http://www.FreeBSD.org/cgi/query-pr.cgi?pr=27782 for an example of this.) 2. Hardware. I found broken UNIBUS hardware 15 or 20 years ago this way. I had some broken hardware which took frame relay frames on a HSSI interface and turned them into AAL5 ATM cells that would get the cell reassembly wrong if you pushed too hard. Or just plain broken memory that results in packet corruption. I've personally experienced all these problems. Maybe I'm just unluckly. One common thread of my experiences is being close to the bleeding edge of technology where stuff isn't as mature as many people are used to. This end-to-end issue is not a theoretical consideration. While the 1's complement internet checksum isn't that strong, it does detect a bunch of bug-like behavior like this. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to disable software TCP checksumming?
> "Louis A. Mamakos" wrote: > > > > > > > > It seems to me to be kind of moot to check the same value twice, unless > > > you suspect hardware problems. Aren't you talking about two different > > > checks over the same data instead of checksum off-loading? > > > > Suspect hardware problem? Of course you should! That's why memory > > systems have parity or ECC, and I/O buses are similarlly protected. At > > least on real computers. > > > > The link-level CRC only protects the data as it goes over the link > ^^ > > After reading the rest of his messages, I'm not so sure, but I would > think he was talking about _transport_ level check sum, and verifying > that with hardward (NIC) instead of software (IP stack). If I'm not mistaken the message that started this thread inquired about adding an option to prevent TCP from doing a checksum, since the fancy gigabit hardware performed reliable link-level error detection itself. I argue that since TCP is an end-to-end transport protocol that individual error detection on a per-hop basis is not sufficient either theoretically or practically. My last message illustrated a number of cases where the transport of the packet over a link was reliably done, but the contents of the packet were corrupted by malfunctioning software or hardware which the end-to-end TCP checksum detected. I have less of an issue with the endpoints of the TCP connection offloading checksum computation to the NIC card, though you're still exposed to a certain class of error, like the PR I referenced. The problem is what happend to your data in intermediate network elements (routers, etc.) between the endpoints of the TCP connection. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making support for ADSL interface ??
> How good is FreeBSD current structures for running ADSL, I'm thinking about the > ATM support already present, and probably using netgraph ? I would need support > for the most common protocols used worldwide, t.ex PPPoATM, IPoATM You'd also need to support PPPoE, which on most ADSL systems appears as PPP on Ethernet as RFC-1490 bridged encapsulation of the ethernet frames in AAL5 ATM cells. It's unclear that this is worth doing at the ATM level since the CPE devices with an Ethernet are fairly inexpensive; the existing Ethernet interface might be the most cost effective. There's also limited standardization on management interfaces for ADSL CPE equipment. It's been a couple of years since I've been involved with the ADSL forum, but there were proposes to have some management channel to the CPE device (perhaps using ILMI? I don't recall). Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Making support for ADSL interface ??
> Louis, > > Thanks for your reply. > > "Louis A. Mamakos" wrote: > > > > You'd also need to support PPPoE, which on most ADSL systems appears > > as PPP on Ethernet as RFC-1490 bridged encapsulation of the ethernet > > frames in AAL5 ATM cells. It's unclear that this is worth doing at > > the ATM level since the CPE devices with an Ethernet are fairly > > inexpensive; the existing Ethernet interface might be the most cost > > effective. > > I will need to support PPPoE, but netgraph can probably take care of > that But directly, as the point is to have one single low cost box > with everything, that why I'm working on doing an ADSL board with PCI > interface And I might even put the ADSL interface on the mainboard. What I'm not sure is if the netgraph code currently has hooks into the ATM network interfaces, and if it "knows" about ethernet frame bridge encapsulation. I'm guessing that the netgraph platform would make the most sense to support this kind of application. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: problem with systm.h trying to call resettodr()
I didn't think resettodr(9) was a system call exposed to user program, but instead a function available to be called from kernel code. Thus, the section 9 manual page. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to disable software TCP checksumming?
Setting aside the degree to which you choose to be paranoid about where data can be corrupted, and the likelyhood thereof-- there is an architectural issue here, which is that the CRC provided by your friendly neighborhood Ethernet NIC card only protects the data over one Ethernet subnetwork. The TCP checksum, and TCP in general, provides end-to-end semantics, independent of the concatenation of physical links the TCP segments might transit from the source to the destination. If you have an end-to-end protocol, with end-to-end semantics, then you need and end-to-end mechanism. Remember years ago when Sun by default shipped their OS with UDP checksums disabled for UDP-based NFS traffic. The position was that you had this strong 32 bit CRC protecting your NFS traffic between the client and server (on the same LAN, of course) and the UDP checksum was wasteful and degrading performance. And people had mysterious things happen to their files when running UDP/NFS over WAN links and other interesting media and circumstances. Everything old is new again. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Status of encryption hardware support in FreeBSD
> In a message dated 06/27/2001 11:06:12 PM Eastern Daylight Time, > [EMAIL PROTECTED] writes: > > > That's not really the point here, I was talking about lowest end > > hardware compared to high end CPU. If we compare with high end hardware, > > then we're talking about factor >50 faster than software There are > > chips out that can do >1Gbit 3-DES, given a 64bit/66Mhz PCI bus. > > > > I'm just starting with a low end chip to complement my 133 Mhz 486 based > > net4501 board, with the goal of low cost and low power, not absolute > > performance. > > Its cheaper and more flexible to buy a faster motherboard, which is the point > to the rest of us who are deciding if we care about a hardware solution. Really? Have you even looked at the net4501 board which was mentioned? It's a single-board computer constructed for some specific communication applications, with no VGA or keyboard support, or spinning fans, and is pretty inexpensive and in a very small form factor. Why do I want to replace this with "a new motherboard?" Please consider that you probably can't imagine all the applications that these platforms might be used in, an the availability of fire-breathing Really Fast CPUs might not actually be applicable to some applications with very specific requirements. "A new motherboard" isn't going to be more flexible since it's likely to require a power supply larger than the whole low-power computer you propose to replace. I'd rather spend the $100 or $150 to add crypto performance for some applications and maintain the small form factor, low power consumption, and no moving parts. The "rest of us" covers quite a few people, with a variety of interesting applications. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD Mall now BSDCentral
> I was thinking about this the other day. I don't think there's very > much money likely to be made in "value-add" CD distributions in the > near future -- that requires hard work to add value, and that requires > someone being paid to do it. The value-add may have nothing to do with the contents of the CD's. Consider that having a well-run subscription service might be valuable, or perhaps better physical packaging in other than the standard jewel boxes. Or adding some addition disks as part of the set of other useful software or documentation. Perhaps providing sets of pre-built picobsd distributions with floppy images? Maybe with hardcopy versions of the handbook or other documentation. Or perhaps someone with phone-in tech support to help people install, run and support FreeBSD. There's a number of different price points and and value propositions you could shoot for. The tricky bit is finguring out which of the alternatives people want. :-) louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bridging
They can't be in the same collision domain -- the only way to do that is to have an Ethernet repeater which repeats bit by bit fron one segment to another, and propagating a collision on one segment as a jam on another. On a FreeBSD box, where you interfaces to ethernet segments are NIC cards, you can't get your hands on the ethernet frame until the NIC has received it completely. Thus, you don't have to opportunity to act as a repeater (not that you'd want to anyway) to have a single collision domain. louie > On Fri, 7 Jul 2000, Narvi wrote: > > > > On Thu, 6 Jul 2000, Sean Lutner wrote: > > > > > > > > > > > Bridges create a broadcast zone. broadcast packets will cross the bridge > > > > unobstructed. > > > > > > OK. So do bridged interfaces fall within the same collision > > > domain?... or are they just members of the same broadcast domain? > > > > > > > They can't be in the same collison domain - you'll realise it if you > > think about it for a second. > > It is possible to span 2 collison domains across 1 VLAN...so > yes they could be, if it were possible with FreeBSD (?IS it?) to > put two ethernet cards in this setup: > > FreeBSD > int1 int2 > /\ > / \ > /\ > switch1 switch2 > > If int1 and int2 were part of the same collision domain, then > switch1 and switch2 would also be part of the same collosion > domain and visa versa. This would be pretty cool to see happen, > essentially making a VLAN switch (with Layer 3 capabilities). > > > Nick Rogness > - Speak softly and carry a Gigabit switch. > > > > > > > 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: 64bit Ethernet Controllers
> Have any 64bit PCI ethernet controllers been tested in 4.x yet? Preferably > quad port..I've seen a few around (adaptec has one) but no mention on the > list of specific experience. This may not be exactly what you meant, but the Alteon Gigabit ethernet controllers (the ti device) are 64 bit PCI cards. The ones I'm using have optical connections, but they do have a twisted pair version with support for a 10/100-Base-T phy in addition to the gigabit phy. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: freebsd and non-preemtive threads
> * Robert Watson <[EMAIL PROTECTED]> [000821 18:01] wrote: > > > > For reference, my recollection is that peemption-aware userland thread > > libraries tend to make alot of timer syscalls, losing some of the > > advantage of being a userland thread library (low context switch cost, few > > transistions between user/kerneland). The AFS LWP code included a > > fasttime() mechanism that took advantage of the ability to mmap kernel > > memory under SunOS, allowing direct access to the timer variable in > > kernel, without a context switch. I do not believe that native ports to > > Linux/FreeBSD/et al have retained this capability, especially given its > > requirements for privilege. However, it would be easy to imagine a kernel > > module exporting a /dev/time, which had the singular ability of allowing > > the mmaping of a page containing only the kernel's timer variables, > > permitting syscall-free precise time access from userland using atomic > > memory access calls. > > I think phk and I discussed this about a year ago, our idea was to > automatically map the segment in for each process (also allowing > things like getpid and such to be accessable). > > It would be nice to see happen either way (mmap'able /dev/time or > automatically) If it's a uni-processor machine, could you use the cycle counter register? I wrote a driver under FreeBSD 3.0 for the Datum bc635PCI which allowed a process to mmap() the device registers of this board. With two memory references, you'd get a timestamp with 100ns resolution, which was handy for a bunch of tasks. I don't know that a /dev/time would give you sufficient resolution, as convienient memory-based stuff would only be updated everytime hardclock() ran, at HZ times per second. The gettimeofday(), etc., routines do some other fiddling (like the TSC register, or reading other programmable timer devices). louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: React to ICMP administratively prohibited ?
> > On Sat, 18 Nov 2000, Jesper Skriver wrote: > > > On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote: > > > > > > Probably not, what if one started a stream of spoofed ICMP lying > > > about the state of the route between the two machines? I have > > > the impression that the Linux box wouldn't be able to connect > > > because of this behavior. > > > > Correct, a attacker could in theory make sure we couldn't connect to > > a given remote box, but as I see it, it's mostly in teory. > > > > We could only react to this if we had a TCP session where we was > > waiting for a SYN/ACK from this specific host, this only leaves a very > > narrow window for a attacker to abuse, as he had to know both > > destination and time. > > > > Do you agree ? > > > > /Jesper > > Well, if you honor such messages, don't you have to honor them in the > middle of a connection too? Then you could cause a connection drop at any > time. No, you don't. This is a replay of discussions that happened literally 20 years ago as the first TCP implementations were being done. I believe the acceptable practice at the time was to honor an ICMP advisory (e.g., pass it to TCP to have it abort the pending connection) while in SYN-SENT state. That is, when initially trying to open the connection, give up sooner based on the ICMP message, rather than waiting for an ACK timeout. If an ICMP message associated with a connection was received after the connection passed to ESTABLISHED state, then you could choose to pass an advisory to the application, but not abort the connection. The Berkeley network stack did this, and a variety of applications would give up and die should they get an error return from a read() or write() system call on the connection, even though it was still alive. I think that behavior may have changed, but I haven't check anytime recently. At the time, the anticipated source of ICMP messages were Destination Unreachable advisories, provoked by either permanant or transient routing failures to the destination. > It would seem simpler to have the ISP in question use proper RST > responses, or just stop filtering totally. This behavior, while widely implemented, is a hack and a kludge. An intermediate network element isn't supposed to spoof source address and return responses on behalf of some other system. This only works for TCP, and only if you can see the headers (e.g., not encrypted with IPSEC). louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: React to ICMP administratively prohibited ?
This patch seems like it will do the wrong thing for ICMP messages that are associated with non-TCP packets. It looks like ICMP unreachable messages for UDP packets will never get delivered to UDP sockets. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: React to ICMP administratively prohibited ?
It would seem more appropriate, somehow, to push the response to the ICMP message up into the protocols where they can take the appropriate action. Of course, the problem is that the PRC_* abstracted codes may not be rich enough to express all the semantics you'd wish to convey. So one goal might be to see if this sort of process could get pushed into netinet/tcp_sub.c:tcp_ctlinput(). Personally, I don't really like the idea of the icmp_input() function reaching into TCP's private state and doing stuff. There's too many potential interactions (e.g., what about IPSEC security associations?) I dunno, some of this is probably a matter of taste. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 4.2-RELEASE will not boot after install ?
I had the same problem on an old PPro box. The BIOS seemingly doesn't like the new (2 sector long) boot manager. If you fire up sysinstall again, and tell it to install the "standard bootblocks" (forgot the exact phrase), rather than the boot manager, you'll probably be OK. louie > Don't know if I should post here but > > I just installed 4.2-RELEASE onto a ppro 200 (had linux) the install > went without a hich. Then when I rebooted, the box just stopped. It > seemed like it could not read the mbr. So I booted again off the > floppies and I used the loader to switched the currdev to the harddrive > (disk1s1a) it found the hardrive. I then loaded the kernel from the > harddrive and booted off the harddrive. After I was up on the box I then > ran disklabel -B ad0 and thought that maybe the installation did not add > the boot reccord info. Rebooted agian to have the same problem as > before. I then tried it agian with the flags for the boot code, no > luck. Finally I dd out the first 512 blocks of the harddrive and ran > strings on it. Seems that thier was nothing their ! so I was lucky > enough to have another 4.2 box and I just copied its first 512 blocks. > Now it boots fine ! > > Is their a known issue with this ? or maybe I did something wrong ? > > thank you > > nathan > > > > 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: su root hangs when logged in via SSH
> Mike Tancsa wrote: > > > > Yeah, I had a similar problem to this in the past where syslogd was kind of > > hung, and the su was blocking waiting for I guess syslog to return. If you > > can login as root on the console, kill syslogd, restart it and see if su > > works once again. > > Nope, it does not work again. But after a couple of seconds after > restarting syslogd I've got this messages on the console: > "syslogd: timed out waiting for child" > > Another note, syslogd does not go with a normal kill, it needs a kill -9 > to make it into heaven. > > Could this be related to having a serial console? This sounds very familiar to me. I had a problem like this in the past, and it was a case of syslog blocking trying to write to /dev/console and blocking. The comconsole port starts a getty on /dev/console, which might be surprising if you also had one running on ttyd0. I don't recall the details, but I think that the serial console is definately related to your problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
> As I remember, way back in the mists of 1990 when I first encountered a NeXT > box, one of the principal reasons for selecting the Mach 2.x micro kernel was > "mach messaging". This was a unified mechanism for almost all IPC both within > one host or distributed over a network, where eg. sockets (netork or unix > domain), pipes etc. were seen as abstractions of the core messaging function. > This fitted very well with the general OO design philosophy of the company. > If anyone has access to a copy of the socket(2) man page from any NeXTSTEP > version, I dimly remember there being an informative paragraph about this > point. This is mostly true, but the Mach kernel they shipped definately wasn't what I'd call a "micro kernel". It was based on the earlier CMU monolithic 4.3BSD Mach kernel. At the time, we had a source license for their kernel (at least most of; not device drivers, feh!), and this was very clear. > Whilst Mach messaging was not commonly used directly in the Unix userland > which was pretty much stock BSD 4.3, it was very important in the AppKit --- > NeXT's real stock in trade. In fact, the IPC between the appkik/user processes and the Display PostScript server really made use of this, could result in very high performance when moving large bitmapped images, etc. I would love to have a UI available these days; it was worlds better than X at the time, and frankly, still better than what we have today. The afterstep and WindowMaker guys have made some progress emulating the visual interface. But can you imagine trying to run GNOME or KDE on a 25Mhz 68030 today? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: New netgraph features?
> Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > >I may not have caught the drift here, but if you send meta-data > >across the net, wouldn't some kind of authentication be needed? > > Yes, It must be. This is probably the next-in-thread request for > comments/suggestions. I'm still not sure if the whole thing would be useful, > so, the authentication methods seem too far to me at the present time. If you > have any comments about this... I think you know what to do :) Assuming you can use the administrative/policy model, you can probably use IPSEC AH and get this "for free." louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: polling for sio?
> On Thu, Apr 08, 2004 at 12:34:43PM -0600, M. Warner Losh wrote: > > In message: <[EMAIL PROTECTED]> > > Marcel Moolenaar <[EMAIL PROTECTED]> writes: > > : On Wed, Apr 07, 2004 at 03:36:02PM -0700, othermark wrote: > > : > I have a multi-port PCI card under puc and sio that has 4 19200 > > : > connections to it now, and when data is streaming across all of > > : > them at once, I get several silo overflows. Would it be better > > : > to run this under puc + uart? > > : > > : Not really. The problem is that puc(4) iterates over all ports in > > : the same way whether you use uart(4) or sio(4). So, puc(4) is > > : the problem more that sio(4) or uart(4). However, uart(4) has the > > : beginnings of an interface that puc(4) could use to figure out > > : which UART needs attention without actually calling the interrupt > > : routine for each of them. > > > > Yes, but at 19200 baud, his problems likely aren't related to the > > iteration. They are likely related to the fact that he said his > > interrupt is shared and therefore not fast. We have horrible > > interrupt latency in current when you want to get to the FIFOs of > > UARTs quickly :-(. > > Those cards are just what they are - cheap. > They have very small FIFOs and they don't use DMA. > IRQ sharing makes them even worse than traditional ISA stuff. > My advise for cost efficient and fast serials is getting USB ones. > Even noname USB serials do much better then puc(4) based. > E.g. the FT232BM (uftdi(4)) has 128 bytes send and 384 bytes receive > buffer plus your USB controller does DMA. > At best you would add a cheap OHCI card if your onboard USB is UHCI > based as OHCI is less CPU intensive. I used to use 9600 bps serial links on LSI-11/23 systems 20 years ago to run SLIP over. This was with dumb DL-11 serial adapters on way slower CPUs and busses than we have today. The difference was a much lower interrupt latency. You'd think that running serial links 10 times faster on CPUs that are a few hundred times faster wouldn't be too hard. louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: concurrent scp transfers (and a testing methodology ?)
> > I have read several documents on the number of > concurrent https sessions a FreeBSD system is capable > of. > > However, I wonder how well this relates to how many > ssh sessions (scp file transfers, specifically) that a > FreeBSD server can handle. Can anyone throw out some > basic numbers for this ? Assuming a 1ghz p3 and 2gigs > of RAM, and assuming that everyone is transferring a > totally different file. (so there is no amount of > cache hits - everything comes straight off the drives) > > I would think the major bottleneck would be disk - you > would start chugging the disks far before you used up > all the CPU on a 1ghz p3 ... but what is the second > bottleneck ? Is it cpu, or is it ram (or mbufs, etc.) > > Would it be a reasonable test to just start up scp > sessions from the machine to itself and then divide > the number of sessions you can acceptably create by > the number 2 ? Or is this somehow a flawed test ? > > Any additional comments (kernel tunes, settings, war > stories) are greatly appreciated. (like, does SMP help > a lot here, or just a little ?) What crypto algorithm are you using for your ssh/scp session? AES, DES, 3DES, arcfour? Any hardware assist for doing the crypto? Are you having the underlying SSH session try to compress the data? louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Status of encryption hardware support in FreeBSD
Hi, I just received shipping notification from UPS that my net4501 is in the shipping pipeline; can't wait for it to arrive. On a practical note: is there a mailing list or some other forum which will host net4501 users? Since it's likely that there will be a bunch of different operating systems running on this, it may not be that the existing OS-specific mailing lists would be best suited. A point of focus with a community of users that could help each other would be greatly appreciated, and likely reduce your involvement in offering support and answering questions. Just something to think about.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: perhaps one of phk's "intern" projects?
> Matthew Emmerton([EMAIL PROTECTED])@2001.07.26 16:50:52 +: > > On Thu, 26 Jul 2001, Matthew Jacob wrote: > > > > > It'd be nice if one could pass a time specification to at in the form of "next > > > reboot". > > > > > > -matt > > > > > > > Why not just write a script for the command and stick it in > > /usr/local/etc/rc.d? > > because a uid != 0 won't write a startup file there, won't he? ;-) Of course, he could use the crontab(1) command, and install an entry with a time of '@reboot'. RTFM: man 1 crontab man 5 crontab Sure, this starts something on *every* reboot, but that's the same as if you installed someting in /usr/local/etc/rc.d louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: libcurl in the base distribution of FreeBSD
FYI, curl is already available as a port: /usr/ports/ftp/curl even if it's not part of the base system. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: KNOTE()
> Daniel Eischen wrote: > > Why are you trying to push so much into the kernel? > > Rethink the problem you are trying to solve. > > See his other posting; he's living inside the constraints > of an existing library and API. Yes, except these are problems of his own making because the library and API were originally user-mode code and not in the kernel. Somewhere along the way a decision was made to push that function into the kernel, and all these bizzaro "problems" of calling back user-mode code from the kernel, etc. follow from that decision. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Unix Philosophers Please!
> > > "Nicpon, John" wrote: > > > > Please specifically define where data goes that is sent to /dev/null > > to the place where no data ever came back. > ..on those "blank" tapes on which you should be backing up the data you do care about. ..to help fight the secret, hidden war against entropy. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Measuring interrupt latency
> In message <[EMAIL PROTECTED]> "Louis A. Mamakos" writes: > : One a related, timekeeping note: is there any interest in updating or > : extending the SO_TIMESTAMP socket option to return higher resolution > : timestamps? Currently, it returns a struct timeval. > > I think that's a great idea. Something compatible with others would > be my first choice. My second choice would be phk's 64.64 idea. > > Warner I don't believe there is another SO_TIMESTAMP implementation with higher resolution timestamps (e.g., nanoseconds). I'll have a look at what exactly the Linux folks did; I think the code in ther other *BSD's is a port of the FreeBSD code. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Measuring interrupt latency
I did some experiments a few years ago with a FreeBSD 3.x system to try to measure interrupt latency (and latency jitter). The platform was a 233MHz Pentium, and I had a PCI board which implemented a high resolution timer (to 100ns resolution). The PCI board could be programmed to generate an interrupt at some given time, and one PCI bus access to a register on the board would latch the current value of the timer. So, I had the board programmed to generate interrupts every second (at roughly 500ms past the start of the second), and then in the interrupt service routine, grabbed the value of the timer and computed the delay based on how far the timer had advanced past the programmed alarm time. I then updated a histogram of the measured delays. Here's some sample data. The first set of data is where the PCI board asserted an interrupt which wasn't shared with any other peripherals. The second set is where the board was in a different slot, and shared with other devices (in the data shown, it was with an Adaptec 7880 SCSI controller and a UHCI USB controller). non-shared: 5us <= 250831 <6us 6us <= 751473 <7us 7us <=67305 <8us 8us <= 5032 <9us 9us <= 1467 < 10us 10us <= 877 < 11us 11us <= 518 < 12us 12us <= 369 < 13us 13us <= 165 < 14us 14us <= 112 < 15us 15us <= 469 < 16us 16us <= 199 < 17us 17us <= 18 < 18us 18us <=9 < 19us 19us <=5 < 20us 20us <= 12 < 22us 22us <= 12 < 24us 24us <=5 < 28us 32us <=1 < 35us 50us <=1 < 75us 100us <=2 < 250us to the shared version: 5us <=1 <6us 7us <= 32 <8us 8us <= 2116 <9us 9us <= 4468 < 10us 10us <=92421 < 11us 11us <= 187835 < 12us 12us <=22369 < 13us 13us <= 5725 < 14us 14us <= 5141 < 15us 15us <= 1073 < 16us 16us <= 188 < 17us 17us <= 130 < 18us 18us <= 134 < 19us 19us <= 122 < 20us 20us <= 469 < 22us 22us <= 80 < 24us 24us <= 45 < 28us 28us <= 11 < 30us 30us <=6 < 32us 32us <= 10 < 35us 35us <= 18 < 50us 50us <=3 < 75us 75us <=1 < 100us 100us <=5 < 250us The object of this excersise was to try to characterize the jitter in the interrupt response time latency. The primary application for the PCI board (a Datum bc635PCI/bc635CPCI) was to implement high-resolution network interface timestamping. As I mentioned previously, reading this clock is relatively cheap with 3 32 bit PCI bus cycles, and I was capturing timestamps of all the traffic arriving on a network interface. The clock on the board was externally synchronized to UTC using a 1PPS signal and IRIG-B timecode from a GPS synchronized clock, with an ovenized oscillator. I haven't tried to run the numbers again more recently on a more modern kernel. The device driver I did hasn't been ported to the NEWBUS infrastructure in 4.x, which is something I need to get back to doing. Other than CPUs that are much faster, I don't know if there are signifcant differences in kernel-level SPL-induced delays between 3.x and 4.x of the FreeBSD kernels. I've had no experience with any of the 5-current kernels, which are all different.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Measuring interrupt latency
One a related, timekeeping note: is there any interest in updating or extending the SO_TIMESTAMP socket option to return higher resolution timestamps? Currently, it returns a struct timeval. I did a quick survey, and it appears that there are applications which use this facility (though, surprisingly, not NTP despite the patch I sent off years ago). I suspect these applications would be surprised to discover a struct timespec. Also, NetBSD and OpenBSD have picked up this code and apparently Linux has a form of it as well. Based on some email from a week or two ago, I wonder if there's value in returning a timestamp in the 64.64 format that phk proposed previously, along with some additional status information. Related to the packet timestamping work I mentioned in a previous message, I added a SO_TIMESTAMP2 socket option which returned a higher resolution timestamp, along with auxilary data to identify the source of the timestamp where there might be more than one clock available, as well as some quality information (synchronized, estimated freq and phase error, etc.) If this interface was going to be extended, then it would be good to only revisit this once. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
timestamp offload [was Re: TCP&IP cksum offload on FreeBSD 4.2]
The cool thing I've always wanted to do with these programmable network adapters is to have them capture timestamps of when packets are received for high-accuracy latency measurements. The network adapter could drop a timestamp into some header when it's DMA'ed into the host's memory. The timestamp could come from some other PCI device (e.g., Datum bc635) which can provide a timestamp in 3 PCI bus cycles. The same sort of think could be done on transmit for suitably tagged packets. Some work I did a year or so ago measured the interrupt response time latency, and it was pretty impressive at how large and variable it could be. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
The other type of failure you might not catch are software errors; that is, where a packet is produced by the network stack and then is subsequently stomped on by a random store from some other code. Or a mis-programmed I/O card with scatter/gather capability doesn't pick up what was intended, etc. The Internet checksum is useful for detecting this class of error. Louis Mamakos To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> > Louis A. Mamakos writes: > > The other type of failure you might not catch are software errors; that > > is, where a packet is produced by the network stack and then is > > subsequently stomped on by a random store from some other code. Or > > a mis-programmed I/O card with scatter/gather capability doesn't pick > > up what was intended, etc. The Internet checksum is useful for > > detecting this class of error. > > > > No, you're missing the point almost entirely. The checksum is not > skipped. It is calculated by the DMA engine based on the data that's > transferred across the I/O bus on the receiver (and / or the sender). > If the data is incorrect as seen by the receiving nic, the checksum > will be wrong and the packet will be dropped. I was referring to the case on the transmit side where the wrong data get's gathered up by the DMA engine because of software related errors. You get a valid checksum, but for the wrong data. You might have the wrong data because a drive screwed up setting the DMA descriptors, or some other I/O transfer splatted over the buffer waiting in a transmit queue. > If the packet lands in the wrong place, you have much worse problems. Sure you do; a software checksum at least gives you an opportunity to detect these failures. While these are improbable failures, I know that I've experienced the class I described in my years of hacking on network platforms, and Ron has experienced the one he described. These are not impossible occurances; it's a matter of weighing the additional cost of the software checksum vs. the likelyhood (and cost/impact) of undetected corruption of the data. If you're running IPSEC or SSL up above all this, there's another mechanism to detect these types of failures. I just think back 10 or 15 years at the impact of Sun's decision to not compute UDP checksums on their NFS traffic, because the network adapter had a much stronger Ethernet CRC. It was a trade-off not worth making even then, with CPUs in the single-digit MIPS performance. We ought to at least consider the previous experience. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> > Louis A. Mamakos writes: > > > I was referring to the case on the transmit side where the wrong > > data get's gathered up by the DMA engine because of software related > > errors. You get a valid checksum, but for the wrong data. You might > > have the wrong data because a drive screwed up setting the DMA descriptors, > > or some other I/O transfer splatted over the buffer waiting in a > > transmit queue. > > What happens if that same i/o transfer splatted over the buffer > waiting in user space prior to the copyin, or sitting in > the socket buffer prior to a software checksum being done? > Software checksums are not quite the panacea you make them out to be. > And they're very expensive. > > Geez. All I wanted to do was pat Jonathan on the back for coming up > with what is apparently the most flexible and well though out > mechanism out there. And I don't disagree with you, it's wonderful work. What I guess I'm trying to get across is that like any tool, it ought to be used properly and in an informed way. For instance, you can mount a file system async or with soft updates, and each of these choices have their own trade-offs. Folks ought to consider the likelyhood of this class of data corruption, unlikely as it is, and weigh it along with the impact on your application, and the differences in performance and loading. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP&IP cksum offload on FreeBSD 4.2
> On Thu, 27 Sep 2001, Andrew Gallatin wrote: > > > Geez. All I wanted to do was pat Jonathan on the back for coming up > > with what is apparently the most flexible and well though out > > mechanism out there. > > it's great work. I was mainly curious to see if anyone had measured this > kind of problem. > > Thanks The paper that someone mentioned earlier in this thread had some statistics on various classes of errors. In a nutshell, they put packet sniffers on 4 different networks, and collected traffic. For each back packet (where the checksum and ethernet CRC differed), they then looked for retransmissions of the same data, and tried to characterize the different failure modes they observed. It's very interesting reading. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Imagestream WanIC-520 interface cards
> > We have been told by our rep at Time Warner Communications that those payments > are still continuing. TW (at least in PDX) does not have enough voice sales > to be able to get on that pig trough and is equally unhappy as we are that the > RBOC's are propping up what are in effect bankrupt CLECs. > > I used to have sympathy for the CLECs and their beef that the ILEC's are > screwing everyone by not allowing competition. But not any more - in our > market the CLEC's charge about 95% of what the ILEC charges for voice > services, so the customers gain nothing on the voice side of the house. > Instead, the way that the CLEC's get customers is by giving away Internet > service for free. In short, the call termination payments fund the > Internet service, instead of decreasing the cost of the voice service. > > Basically, the CLEC's have figured out how to use a poor government > regulation that needs changing to put their competition out of business. > It's no different than what Microsoft does when they use operating system > revenue to fund a variety of unprofitable and destructive ventures into > software applications like web browsers, web servers, ecommerce apps, etc. > > The only saving grace is that most of the CLECS are so ignorant when it > comes to networking that their Internet service is so awful that at least > the good customers are staying away from them for now. You have much of this backwards. This whole notion of "reciprocal compensation" for call termination was originally put into the telecom tariffs by the RBOCs to prevent competation in the local space. They figured that the call volume would be asymetrical, with the CLEC customer calling "the rest of the world" connected to the RBOCs. Thus, they created an unlevel playing field and changed the rules of the game. This "poor goverment regulation" is there solely because the RBOCs worked really hard to ensure it would be put there. Surprise, surprise, a bunch of folks came along and decided that the new game was one they could play, and used it to their advantage. D'oh! (And this was sweet, because these same telecom tariffs would be used by the RBOCs on a regular basis to whack their customers/competitors, with the excuse, "Our hands are tied!" Live by the tariff, die by the tariff. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Imagestream WanIC-520 interface cards
> I am perfectly aware of this. > > The RBOCs deserved to have those "fines" levied against them for a number > of years, to punish them for attempting to block the CLECs. However, it's > been long enough for this, and in fact the money from the RBOCs is no longer > being used to increase the CLEC's reach or service area (ie: infrastructure) > and being used by the CLECS to bash each other, instead of bashing the > RBOCS. The recip-comp charges have nothing to do with extending the reach of a CLEC's network. It's (supposed) to cover the cost of carrying or terminating an inbound POTS voice call. In in more generic view, recip-comp shows up in the "revenue" column of the balance sheet. To assume it's intended to be any more than that is imagination. > The situation is equivalent to Foreign Aid that the US pays to a country such > as Japan. (which we still do to the tune of millions and millions of dollars > a year) Japan has long since ceased being a poor relation that needs to be > bailed out. The reasons for them being paid off by the US have been > fulfilled. > Yet, the payments continue, and the money is being used to free up other > funding that's being spent on political - not necessary - things. Huh? You might also explain the situation as subsidizing the cost of providing Internet service. It's revenue coming into the business which would otherwise need to come from some other source, such as the customers. There are lots of other examples of charges and tariffs which telecom carriers charge each other because of the bizzare reality set up by FCC regulations. You simply siezed upon one with contemporary sex-appeal. If you want to rant about something, go take a look at how half-circuit pricing is done for international private lines. You think the US carriers are evil, go see what state-supported telecom monopolies get to do. Or the hoops which much be jumped through to get licenses to operate telecom, datacom, or Internet lines of business in some countries around the world. Disclaimer: I work for a big stupid phone company, and have unfortunately become aware of this and many other regulatory issues. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: SSH stalls (was: FreeBSD performing worse than Linux?)
> I am not using compression and netstat -s confirms that it is really > resending data. I examined it a bit more now and it seems OpenSSH 2.5 is > sending a burst of small packets, each with 100 or 116 bytes > > 14:30:46.232151 server.22 > client.1525: P 30977:31077(100) ack 1144 win 24820 > 14:30:46.233358 server.22 > client.1525: P 31077:31177(100) ack 1144 win 24820 > > and another 50 small packets just like them rapidly after eachother. > After this it will start to send bigger packets, 1076 or 1460 but its too > late and its likely that the server will have to resend part of the small > packets and connection will stall. This won't be a problem on a LAN but > over the internet it can be. SSH Inc sshd doesn't have this problem as it > always send 1460 bytes per packet when possible. I have not been able to > reproduce this with OpenSSH 2.3.0 because it seems to send 276-300 bytes > per packet. This might be because our OpenSSH disables Nagle's algorithm by turning on the TCP_NODELAY socket option. See packet.c:packet_set_interactive() for the code that does this. This certainly will cause a bunch of small TCP segments to be generated, back-to-back before an TCP ACK is received. It's also probably a bad idea to enable by default for every SSH interactive session. It looks like this gets turned on for X11 connection forwarding and for SSH sessions with a PTY at the server end. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: USB, select/poll for ucom
> In message: <[EMAIL PROTECTED]> > Danny Braniss <[EMAIL PROTECTED]> writes: > : > : > I'm able to use ppp with umodem/ucom. My brother uses ulpcom/ucom for > : > his ppp needs. I'm pretty sure that select is involved. :-) > : > > : > >From what I can see in the code, I'd expect that it would work because > : > the ttypoll routine is specified for the poll routine. Why do you > : > think it wouldn't work? > : > : well, for one, my program doesn't work :-), it works with the RS232 version. > : > : so i started to poke around, and did some reading, and as far as i could tell, > : the read(2) has to be initiated by the host, but my knowledge of usb is close > : to zero - it was zero 2 days ago, but still looking for some better docs, and > : polish my english - as far as i remember interrupt is not polling, but the > : ohci docs imply that :-) > > have fun. the mindshare book is good. however, it took me a long > time to get a usb 'aha' moment and understand its twisty maze was > really a workable design obscured by standardese... I suspect it is a > problem in the usb chipset driver for the com part. ttypoll just says > 'you have data in the buffer' so for some reason the data isn't making > into the tty buffer. I think the problem is that the USB hardware doesn't try to read data from the peripheral until the user-mode code does a read(2) system call. I had this problem with the ugen device. I would guess that the ucom/umodem devices could use the tty clist infrastructure as the intermediate buffer for data to be stuck into absent the user application doing a read. louie ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Minimalist FreeBSD 4.8
> Actually, I have a small script that does something like this. Here's
> a breif sketch.
>
> # prepare /cf
> make buildworld
>
> ${chroot} /bin/sh -${e}c "(cd $srcdir
> env MAKEOBJDIRPREFIX=$objdir make -m ${srcdir}/share/mk -f \
> Makefile.inc1 hierarchy DESTDIR=$dstdir NOMAN=yes
> (cd etc ; env MAKEOBJDIRPREFIX=$objdir make -m ${srcdir}/share/mk \
> distribution DESTDIR=$dstdir NOMAN=yes)
> for i in ${FreeBSDProgramDirs}; do
> echo \"==> \$i\"
> test -d \$i &&
> (cd \$i ; env MAKEOBJDIRPREFIX=$objdir make -m ${srcdir}/share/mk \
> install -DNOINFO -DNOMAN DESTDIR=$dstdir -DNOPROFILE)
> done)"
>
> Here's my current minimal list for a bootable system, although you
> might be able to trim it a little. Also, it is optimized for 4.5.
> There will some tweaks needed for 4.8. Also, I've done the buildworld
> with NOSHARED=no since we put both / and /usr on the same partition in
> our systems.
>
> My scripts are more complete, but also very specific to Timing
> Solutions' needs. I've used these scripts to build flashes that take
> up about 12M or so. There's about 2M that can be trimmed.
>
> Warner
>
> P.S. Maybe I should find some time to pull together these scripts in
> a releaseable format...
>
> P.P.S., Here's what I use to set FreeBSDProgramDirs to in an
> over-arching makefile.
I've used a hacked-on version of Warner's scripts to build a FreeBSD
based firewall distribution to run on the Soekris 4501 box. I was
able to get a running system for that application on an 8MB CF card.
Of course, the kernel was compressed and it was pretty stripped down..
I'm currently using a 32MB CF card, with two 16MB partitions for this
purpose (so I can back up to the previous version easily).
Of course, no gcc. And heavens, no VI! Got a microemacs on there
instead, whew!
I also built my system with NOSHARED=no to dramatically reduce the
space requirements for the root (and only) file system, and it works
great.
louie
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail + auth + ssl + freebsd
> Leo Bicknell wrote: > > >After searching the archives and looking at the source, I find > >myself more confused. I've been asked to set up sendmail + ssl + > >SMTP auth on a FreeBSD host. > > > >A quick "strings" on the sendmail binary shows a number of SSL > >functions, so I'm thinking the SSL bits are in there, but I'm not > >quite sure how to take advantage of them. Issuing "AUTH" to a > >stock -STABLE sendmail gets command unrecognized though, so I don't > >think that is there. > > > >If no one else has figured this mess out, I'll do it and write a > >page for the handbook. If someone else has, please clue me in, and > >if necessary I'll still write that handbook page. :-) It would be > >very nice if it was simple to make FreeBSD sendmail SSL and > >authenticate against the password file. > > > I've managed to set it up to use AUTH, however I have not yet found the > time to make it use SSL. > The only usefull documentation I have been able to find is this one: > http://www.sendmail.org/~ca/email/auth.html You have to generate a public key certificate and have the private key available to the sendmail daemon before it will do the STARTTLS thing. I've got a shell script around there that signs a certificate with a bogus CA which enable the use of STARTTLS. You can't validate the other end of the connection, but at least it negotiates an encrypted session. It's attached below, and it's a horrible blecherous hack and provides very little security other than allowing the session to be encrypted. It's at least obviously not able to protect against man-in-the-middle attacks since the CA signing the cert is completely bogus. It will make long distance phone calls when you're not looking, eat your food, and make rude remarks about your spouse. Use at your own risk. But it seems to do, er, something. At least it makes passive traffic sniffing less productive. louie make-sendmail-cert.sh Description: make-sendmail-cert.sh
Re: FreeBSD performing worse than Linux?
An underlying issue here is why applications decide to set TCP_NODELAY options on sockets, rather than just letting Nagle's algorithm do the right thing. I recall some handwaving about this in the X server some years ago to make mouse movements "smoother". For the problem at hand, if both the client and server machines didn't do TCP_NODLEAY, then there'd only be one packet smaller than the TCP MSS in flight between the transmitter and receiver at any one time. I think that poking OpenSSH to not set the TCP_NODELAY option "fixed" this problem. I was just pondering the TCP implementation in 4.5-PRERELEASE, and it doesn't look like there's any explicit delay after a write going on, other than Nagle's algorithm, in the TCP packetization code. So setting TCP_NODELAY is almost certain the Wrong Thing for most applications to do. Perhaps there ought to be a warning in the man page about being a poor network citizen, flooding the Internet with tinygrams and otherwise making the performance of your application generally suck. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
Disabling Nagle's algorithm for no good reason has very poor scaling behavior. This is what happens when TCP_NODELAY is enabled on a socket. If you look at the work function for most network elements, the part that runs out of gas first is per-packet forwarding performance. Sure, you need to have adequate bus bandwidth to move stuff through a box, but it's performing per-packet forwarding operations and policy which is the resource that's most difficult to make more of. I think this is true for toy routers based on PC platform as well as high-end boxes like the Cisco 12000 series. Juniper managed adequate forwarding performance using specialized ASIC implementions in the forwarding path. Of this statement, I'm sure; in my day job at UUNET, I talk to all the major backbone router vendors, and forwarding performance (and also reasonable routing protocol implementions) is a show-stopper requirement they labor mightily over. So here was have a mechanism with wonderful properties - it's a trivial yet clever implementation of a self tuning mechanism to prevent tinygrams from being generated by a TCP without all manner of complicated timers. It give great performance on LAN and other high-speed interconnects where remote echo type applications are demanding, yet over long delay paths where remote echo is gonna suck no matter what you do, it automatically aggregates packets. Nagle's algorithm and Van Jacobson's slow-start algorithm allowed the Internet to survive over congested paths. And they did so with a bunch of self-tuning behavior independent of the bandwidth*delay product of the path the connection was running over. It was and is amazing stuff. Likewise, the original problem in this thread is likely caused by some part of the USB Ethernet implementation having inadequate per-packet resources. It's probably not about the number of bytes, but the number of transactions. You see here a modern reimplementation of essentially the same problem that the 3COM 3C501 ISA ethernet card had 15 years ago - back to back packets were consistantly dropped because of the poor per-packet buffering implementation. It was absolutely repeatable. Sure, it's "legal" to generate streams of tinygrams and not use Nagle's algorithm to aggregate the sender's traffic, but it's just plain rude and on low bandwidth links, it sucks because of all the extra 40 byte headers you're carrying around. I'm sure TCP_NODELAY got added because it sounds REALLY C00L to make the interactive thing go better. But clearly people don't understand the impact of turning on the cleverly named option and how it probably doesn't really improve things. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
One possibility is that the code in icmp_input() processing the PMTU discovery-induced ICMP message could verify that the returned header in fact is associated with a connection on the host and maybe even has sane sequence numbers (for TCP segments). This would make it more difficult to just spray these packets at host and drop the MTU on routes. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
> I don't have the RFC handy, but aren't all Internet connected hosts > required to support a minimum MTU of 576 from end to end with no > fragmentation? Thus if we ever got an MTU less than 576 we should > ignore it. Right? No, all hosts are required to be able to reassemble IP datagram fragments of at least 576 bytes, but there's no lower bound on the MTU of the interface. Small MTUs first appeared on low-bandwidth SLIP links. Along with TCP header compression, this put a lower-bound on how long you'd have to wait for a single packet to be transmitted on the interface. If your network interface was clever, and looked at the TOS bits in the header or peeked at the TCP port numbers, you could arrange to queue interactive traffic (telnet, rlogin, now ssh) ahead of non-interactive traffic (FTP, SMTP, etc.) to improve the perceived response time with remote character echos. If the MTU was large, a large FTP packet might just be starting its way out the interface when you want to transmit interactive traffic; the small MTU limits the pain. (Digression: NORTEL (at least) had an interesting encapsulation on their multiservice frame relay switch trunks where they could interrupt a packet being transmitted and insert delay sensitive traffic in the middle of a larger packet. Cool hack.) Also, even though this is on a cloned route, someone could attack "well known" routes that might be on your computer. For instance, the route to well-known recursive name servers on a network, which are pretty easy to guess for dial-up users on a modem pool. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
what slice did I boot from?
I dunno if this has come up before or not, but thought I would ask. I've got one of the litle soekris net4501 boards that I use as a router/firewall/NAT box, and it works really good. I have a stripped down FreeBSD system that I run in a 16MB partition on an 32MB Compact Flash card plugged into the net4501. Actually, I have two 16MB slices, and my goal is to be running from one, and installing the "next" version into the second slice. That way, if the new one distribution screws up, I can back-out to the older on on the other partition. That problem is that I have to generate a distribution with the right /etc/fstab to reflect which of the two slices it will be installed into, which is ugly. What would be Really Nice is a version of the "compatibility" disk devices which would be associated with the "active" slice that was booted from, rather than the first FreeBSD slice found on the disk. This seems like one mechanism to get what I want. Unfortunately, this information doesn't seem to get propagated up to the slice code from what I can tell. Any suggestions on alternative mechanisms? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what slice did I boot from?
> On Fri, 4 Jan 2002, Louis A. Mamakos wrote: > > > I've got one of the litle soekris net4501 boards that I use as a > > router/firewall/NAT box, and it works really good. I have a stripped > > down FreeBSD system that I run in a 16MB partition on an 32MB Compact > > Flash card plugged into the net4501. Actually, I have two 16MB > > slices, and my goal is to be running from one, and installing > > the "next" version into the second slice. That way, if the new one > > distribution screws up, I can back-out to the older on on the other > > partition. > > I've actually been monkeying with this and ran into a bigger problem .. > boot2 only knows how to handle one FreeBSD slice. You have to play > loader(8) tricks to boot the second slice. > > Specifically... > . abort the kernel load > . 'set currdev=disk1s2a:' > . 'load /boot/kernel/kernel' (and so forth) > > Particularly if you are running -CURRENT you must compile in your device > hints, otherwise everything gets confused. Hmm.. I'm running a 4.4-STABLE based system on the hardware, and don't seem to have any problem booting off the other slice. Right now, it's runnong on the second slice of ATA Compact Flash disk: # kenv LINES="24" console="vidconsole" currdev="disk0s2a:" interpret="ok" kernel="/kernel" kernel_options="" kernelname="/kernel" loaddev="disk0s2a:" root_disk_unit="0" vfs.root.mountfrom="ufs:/dev/ad0s2a" # The other slice is ad0s1. And I checked, the kernel that's running actually did make it out of that slice, and not the first one. > For picking the appropriate slice, you are up a creek all right. > Assumably at some point you have to select a slice anyway, and you can use > that to rewrite fstab. Depending on the old compatibilty slice will > certainly get you in hot water. It would be just fine to have the boot0 boot manager be the mechanism to do all this. That's an easy toggle between the two alternatives, though harder to do an automatic fallback, perhaps. > I've been thinking about hacking up some forth to handle this switching > programatically, so you get a nice menu to pick which FreeBSD slice to > boot from if you enable the feature. Where this mechanism might be useful is to detect abnormal shutdowns (too many, too quickly) and use that to backup to the other partition. I dunno, that might be more complicated and automagic than I need for the moment, since the software seems fairly stable, and the hardware is accessable for manual diddling if necessary. I'm wondering if just generating the fstab on the fly might be sufficient; I should be able to use kenv to get the vfs.root.mountfrom loader variable (which strangely enough, isn't exported as a sysctl) and go from there. Hmm.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what slice did I boot from?
> On Sat, 5 Jan 2002, Louis A. Mamakos wrote: > > > Hmm.. I'm running a 4.4-STABLE based system on the hardware, and > > don't seem to have any problem booting off the other slice. Right > > now, it's runnong on the second slice of ATA Compact Flash disk: > > > > # kenv > > LINES="24" > > console="vidconsole" > > currdev="disk0s2a:" > > interpret="ok" > > kernel="/kernel" > > kernel_options="" > > kernelname="/kernel" > > loaddev="disk0s2a:" > > root_disk_unit="0" > > vfs.root.mountfrom="ufs:/dev/ad0s2a" > > # > > You're playing the same trick I am, just in more words :) Which slice is > loader.conf on? Sorry, I wasn't clear. I don't have any explicit configuration in my loader.conf; this is just the environment that the loader cooked up all by itself. Each slice has it's own own loader along with a complete root file system. > > It would be just fine to have the boot0 boot manager be the mechanism > > to do all this. That's an easy toggle between the two alternatives, > > though harder to do an automatic fallback, perhaps. > > You try boot0 ... that's where my problem showed up. One would boot but > the other says "Invalid partition." This is a heavily hacked install > though (since sysinstall won't let you put a second / into a second slice > when a first FreeBSD slice already exists). What you might try is making sure that the other partition starts on a cylinder boundary. I've noticed that the BIOS on some machines have real heartburn when the slice starts at some random location not coincident with a cylinder boundary. I don't know why, and I'm pretty sure I don't want to know :=) louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Hifn 7751/PowerCrypt status? (or: Paging jlemon...)
> Has anyone heard from Jon Lemon about Hifn 7751 support? He mailed my boss a > few months ago (January), saying that support was working, but we haven't > heard from him since, and jkh suggested trying here. > > -lee > On a related note, Sam Leffler just reported some success in porting the OpenBSD crypto framework to FreeBSD 4-STABLE. It's apparently still a work-in-progress in that the KAME IPSEC stack has not been modified to use it yet. I've attached a message he sent to the soekris-tech mailing list (for the net4501 small system that runs FreeBSD). louie --- Begin Message --- I've put together a simple packaging environment for installing PicoBSD/FreeBSD on net4501 systems. There is an extensive (but unfinished) set of instructions for working with the software and some sample configurations that demonstrate how things work. The tools let you configure images for network booting and installation into compact flash. There is a pxe-bootable installer image that walks you through installing an image to compact flash. Also included is a snapshot of my port of the openbsd crypto support that hooks the Hifn 7951 to /dev/random and provides a /dev/crypto device. This will eventually include mods to the KAME IPsec code to use the 7951. The package is available at http://www.errno.com/net4501/net4501.tgz. MD5 (net4501-20020318.tgz) = 95fd358cbcf9451337a26d7878c7afb4 All work has been done on the -stable brunch of FreeBSD. Please send feedback directly to me. Sam _ Soekris Engineering, technical discussion mailing list [un]subscribe: http://lists.soekris.com/mailman/listinfo/soekris-tech --- End Message ---
Re: ftp and mail much slower into fbsd 4.4 vs and old BSDi
>
> Yes, I can attest to this an I belive it is actually the case on both
> -current and -releng4 that disabling newreno improves TCP performance.
>
> I belive running an X11 application or scp(1) over a wavelan is a very
> good test-bed for this issue.
>
> --
> Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
I find this patch also improves performance of SSH on most network
media. Why so many applications go to the trouble to disable
Nagle's algorithm is beyond me. I suspect the socket option has
too seductive of a name.
louie
Index: packet.c
===
RCS file: /a/cvs/src/crypto/openssh/packet.c,v
retrieving revision 1.1.1.1.2.4
diff -u -r1.1.1.1.2.4 packet.c
--- packet.c28 Sep 2001 01:33:34 - 1.1.1.1.2.4
+++ packet.c2 Apr 2002 18:26:41 -
@@ -1281,9 +1281,11 @@
error("setsockopt IPTOS_LOWDELAY: %.100s",
strerror(errno));
}
+#if 0
if (setsockopt(connection_in, IPPROTO_TCP, TCP_NODELAY, (void *) &on,
sizeof(on)) < 0)
error("setsockopt TCP_NODELAY: %.100s", strerror(errno));
+#endif
} else if (packet_connection_is_ipv4()) {
/*
* Set IP options for a non-interactive connection. Use
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: more kernel programming style questions
I'm not holding this up as the best example of style, but take a look at the Bt848 driver in /sys/pci for one approach. Some years ago I contributed some patches that got integrated that turned those offset references into a structure definition. The structure definition was done with some macros so that you can hide compile byte-order dependencies.. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Advice on deriving accurate time values from the kernel?
I've done some work on measuring things like interrupt response times and the interval between two interesting events or steps in processing. A cheap way to do this is to use the TSC register in the CPU, though you then need to calibrate the frequency that the CPU really runs at. If you're willing to spend some money, you can get hardware to plug into a PCI slot that can return timestamps in 100ns units, as well as generating interrupt at some time in the future, etc. See http://www.bancomm.com/cbc637PCI.htm for one example of such hardware. I have a device driver for FreeBSD for this board which even allows user processes to get precise timing by mmap()'ing the device registers into user space for easy access. The driver will be contributed to the FreeBSD project "soon." I was pretty close to doing so just prior to the newbus conversion and now need to update the driver for a more recent -current. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> : Good point but I think it's like how much of 100Mhz a 100BaseTX > :can push. If it pushes 100%, then it might be wise to have a little more > :room for overhead. Kinda like a car, better to have reserve power when > :you need it then pushing it to the max. In regards to 1000BaseT, I > :thought there was no standards for that yet, atleast all the Gigabit stuff > :is all fiber and not copper. Quality of cable does matter, atleast in > :high-end audio/video it does and I'm sure data would be more picky than > :human ears. > : > : > :Cheers, > :Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ > :Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > > The copper gigabit standard isn't out yet, but I was under the impression > that they were pretty close. > > In regards to audio/video verses ethernet, you have to remember that > audio and video are *analog*, not digital. The cable quality matters > for analog, but it only needs to be "good enough" for digital. If you > don't get any bit errors (and you shouldn't) then a better cable is not > going to make a difference. One of the big deals with the different grades of cable is the degree of crosstalk between the transmit and receive pairs in the cable sheath. When you're talking about Category-3 or Category-5 cable systems, this INCLUDES the connectors, patch panels, cross-connect blocks and cross-connect cables. For instance, you have to work pretty hard to do better than 10Base-T with a Category-3 wiring system if you have type 66 punch blocks because of the impedence bump and crosstalk issues. Same sort of things apply at 100base-T and Category-5 cable systems. Using gold-plated "Monster Cable" is just pissing away money of the other components are also up to the same level of "quality" (har, har). And, as Matt said, if you're not getting CRC errors then it's good enough, and there's no point spending money to get better wire. louie (who uses #12 ROMEX cable for speaker wire.) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: gethostbyaddr() and threads.
> ---Steve Tarkalson said: > > this is solved by one of two methods: > >1-) require the caller of gethostbyaddr() to supply a pointer to > >a hostent struct which will be filled. > > or 2-) the library uses thread specific storage which is re-used in > >each call. > > > You could malloc() a struct hostent for each call to > gethostby*(), each time registering the hostent in some list along with the > thread's PID. If the same thread calls gethostby*, use the same buffer, or > allocate a new one if another thread calls it. Have a static function be called > atexit to free all the mallocs. Yuk! If you're writing a multithreaded program, a slightly different API for gethostbyname() is likely to be the least of your worries. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
> > Well, I am the person who has this problem. > > The RFCs does not explicitly say that we should not use underscore > > character > > as far as I understood. But it suggests which characters we should use. > > > RFC 952 > >1. A "name" (Net, Host, Gateway, or Domain name) is a text string up >to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus >sign (-), and period (.). Note that periods are only allowed when >they serve to delimit components of "domain style names". > > RFC 1101 > >The current syntax for network names, as defined by [RFC 952] is an >alphanumeric string of up to 24 characters, which begins with an >alpha, and may include "." and "-" except as first and last >characters. This is the format which was also used for host names >before the DNS. Upward compatibility with existing names might be a >goal of any new scheme. > > The above two documents limit the characters that may be used a a _ is not > one of them. FreeBSD behaves correctly in this manner. But the DNS is used to hold all sorts of information. For example, how do you reconcile domain names like: 42.10.202.144.IN-ADDR.ARPA in the DNS? It violates the "starts with alpha" "requirement" in 952 and 1101 that you quotes, yet we use these things all the time. In fact, you can send email to that domain name because it has an A record associated with it, as well as a PTR record. I've always thought that the code that barfs on these names in gethostbyname() really violates the "be conservative in what you send, and liberal in what you receive" thought that made the Internet work. Yeah, yeah, BIND does it, but that's no excuse, either. What do I know; I was just the first chair of the domain name working group in the IETF so many years ago before it got fashionable. grumble, louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: (2) hey
> > That IS a violation of the standard, since A records > are not valid for hosts in in-addr.arpa. > And next I suppose you'll tell me that PTR records are not valid outsize of the IN-ADDR.ARPA portion of the DNS namespace? What people really miss is that the DNS is a distributed database with delegation, used for all sorts of purposes. Some of them are widely known and almost universal (e.g., "look up and address for this host"). Some parts of the namespace are used as indicies for special purposes (e.g., translate a 4 octet IP address into a DNS name). The DNS can store names where the values used for each octet of a label in a DNS name can have any value at all between 0 and 255, including " ", ".", and other rude things. The general purpose mechansim can be (ab)sed for all sorts of purposes not originally envisioned (like Hesiod - you want to exclude "_" from user names?) While gethostbyname() and it's ilk are used for one limited, scoped purpose is no reason to break previously working configurations. That the ISC got a hair up their ass to break all those previously working names is just a shame. Depending on my application, I might just want to have some part of the DNS namespace return object that look like IP addresses for domain names which are not "hosts." The current implemention of bind makes that impossible unless I want to resort to using the raw resolver routines, which is just busy-work. This is just an example of "smart-ass" software that believes it knows better than the user does. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
[I'm catching up on a bunch of FreeBSD mail since being out on vacation, so perhaps I've missed the essence of this thread..] I've also had the desire to capture the output produced when /etc/rc is run for all the reasons mentioned. I always thought that perhaps init would simply capture stdout on the other end of a pipe, and logically do the "tee" thing with it. In fact, couldn't init logically exec a sh /etc/rc | tee /tmp/rc-output when invoking /etc/rc? (Where to put the output would seem to be one of the more difficult choices since you don't start with a writable file system mounted anywhere..) Or perhaps init could capture the output on the end of a pipe and subsequently syslog it while it's echoing it to /dev/console. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to shut down a TCP connection
> Hi, > > I'm doing TCP development on a custom operating system that I've > written and am using my FreeBSD box for testing my TCP stack. I'm in > the early stages right now and I have a lot of bugs. One of my bugs > is that I shut down a connection on my end but I'm doing something > wrong and the connection on the FreeBSD side stays up, i.e.: > > [bsd@vger]:/net- netstat > Active Internet connections > Proto Recv-Q Send-Q Local Address Foreign Address (state) > tcp0 0 vger.telnet bos.5000 ESTABLISHED > > 'vger' is my FreeBSD machine and 'bos' is my experimental OS. The > connecton on 'bos' at this point is actually closed. > > Does anyone know how I can manually shutdown the above connection on > 'vger' short of waiting a really long time or rebooting? Since this is a telnet session, you could find out what login session this connection is associated with it, and write something to the pty so data will need to be sent on the connection. The remote end with either respond with a RST segment aborting the connection, or eventually the connection wil die due to an ACK timeout. Typically, I just use the write(1) command to do this to an abandoned telnet session. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: running single freq monitors (fwd)
I've got a similar problem, not with a particular monitor, but with an application where the VGA console is connected to a cheapo VGA-to-NTSC base-band video converter. These things usually come with a windows driver which from what I can tell, simply causes the horizontal and vertical refresh rates to be configured correctly. I my application, I don't have to worry about what things look like before X gets up and running; nothing will be damaged by the non-standard sync frequencies - you can't can't see anything that's readable on the video display. In my /etc/XF86Config file, I've got sections like this: Section "Monitor" Identifier "PC/TV-1108" VendorName "AITech" ModelName "PC/TV-1108" HorizSync 31.5 VertRefresh 60-60 # 640x480 @ 60 Hz, 31.5 kHz hsync Modeline "640x480" 25.175 640 674 760 800 480 491 493 525 EndSection Section "Device" Identifier "motion771" VendorName "Number Nine" BoardName "FX Motion 771" VideoRam4096 s3RefClk16 Ramdac "ibm_rgb524" DACspeed220 EndSection Section "Screen" Driver "accel" Device "motion771" Monitor "PC/TV-1108" DefaultColorDepth 24 BlankTime 0 Subsection "Display" Depth 24 Modes "640x480" Invert_VCLK "*" 0 ViewPort0 0 EndSubsection EndSection In my configuration, I'm using an "old" Number 9 Motion 771 board, with 4MB of memory. This easily give me a 24 bit deep display, which is way overkill once you run it into the NTSC converter and then an RF modulator. In my application, I didn't have a bizzaro hardware interface on the display, so just about any old VGA board would probably work OK. If you're wondering, this is part of my home automation system; there's a TK application (actually, [incr tcl] and [incr widgets]) which displays interesting stuff like caller-id information, temperatures, stock quotes on channel 16 of the in-home RF distribution system. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PPPoE offer.
> [on PPPoE] > > Well... a few toronto people and I got together (I'm trying to find > email addresses) to discuss the problem. One particular thought that > we had was that it would be cool if a single ppp process could handle > a large number of connections. We also discussed the fact that you > may very well want some low-level routing of the PPPoE packets. > > The cost model with our telco (at least) is that each ethernet > connection costs $1500/mo. So... we need to be able to run somewhere > around 5K to 10K connections (users) down each pipe. This means that > a box on the front end to "route" the packets to multiple boxes is an > asset. So just use an Ethernet bridge. You could play some games with the discovery protocol (which uses broadcast MAC frames) with multiple servers are the remote end. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vmpfw in pine via NFS
> > > > /me shivers at the thought of my (easily) 500+ new messages a day > > and hundreds of thousands of messages being stored one file for each > > message... > > It's been done. It's called MS Exchange. You don't have to use vile language in public :-) MH has been storing mail in it's folders like this for years/decades. While it might be a little hard on the file system, it works great for the user. Sorta like emacs. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linux ioctl not implemented error
> >The console complaints about the ioctl are gone now. Unfortunately VMware > >still complains. I'll try to findout why. > > Try to load new vmware port from: > http://www.mindspring.com/~vsilyaev/vmware/files/vmware.tar.gz > > And reinstall it. I think this may fix the problem. > I'm trying the new port now. I seem to have a problem with the vmware emulator program dying due to some panic caused by an uncaught signal whenever I try to save a configuration. Right now, I opted to not save the configuration, and have proceeded on to booting a FreeBSD-3.3 release CDROM, and installing it in a VMware virtual machine. This is great. I dunno if it's just me, but this seems to provoke manical laughter from time to time. Next up: how long to do a 'make world' of the 3.3 system inside the emulator. So, is there a working network interface for the virtual machine? That would be very nifty, indeed. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Fwd: Re: kstat - an API for gathering kernel stats
> On Wed, 8 Dec 1999, Arun Sharma wrote: > > I'm interested in doing something like: > > > > kern.stats.cpu0.idle > > kern.stats.cpu0.nice > > ... > > kern.stats.cpu1.idle > > kern.stats.cpu1.nice > > ... > > > > and I want the nodes cpu0, cpu1 etc dynamically created. > > It would be better to have > > kern.stats.nice.cpu0 > kern.stats.nice.cpu1 > > or simply > > kern.stats.nice.0 Yes, please! It would be helpful if the kernel's MIB used instances (and there was easy support for creating them) like the MIBs many of us use SNMP to access in network elements. 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. 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: PR kern/15656
> > In this PR, regarding IP header checksums, it's stated that a checksum of > 0 is specified by the standard to be transmitted as all-1s (0x). (A > checksum of all 0s is taken to mean that the transmitting host did not > calculate a checksum.) > > Can anyone find a reference to this in the official docs, or perhaps find > an explanation why we do indeed send 0'ed checksums? I've replicated this > behavior on both 3.4-STABLE and 4.0-CURRENT, i386 and alpha. This behavior is certainly in RFC-791, which describes IP. Note that since the checksum is computed using 1's complement arithmetic, all-1's is a represetation of -0, which has the same arithmetic properties as the encoding of +0. In this application, the +0 encoding denotes "no checksump", which as far as I know, is only an option for the UDP checksum. An excerpt of RFC-791 says: Header Checksum: 16 bits A checksum on the header only. Since some header fields change (e.g., time to live), this is recomputed and verified at each point that the internet header is processed. The checksum algorithm is: The checksum field is the 16 bit one's complement of the one's complement sum of all 16 bit words in the header. For purposes of computing the checksum, the value of the checksum field is zero. This is a simple to compute checksum and experimental evidence indicates it is adequate, but it is provisional and may be replaced by a CRC procedure, depending on further experience. So, if you implemented as it is described, computing a sum of the packet contents who's result is 0x would then be complemented to 0x for inclusion in the packet header. A one's complement sum of values who's value is zero should always produce a +0 (all zero bits) rather than a -0 (all one bits), At least all right-thinking 1's complement hardware of the era (DEC, UNIVAC, etc) worked that way. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PR kern/15656
> Agreed; however, the PR states that should the checksum be 0x, the > complement of which is 0x, the checksum should still be sent as > 0x. Ok, I looked at the PR, which seems to refer to the TCP header checksum, rather than the checksum in the IP header. So please disregard the specific pointer to RFC-791. > Can anyone verify this? I can verify that BSD sends 0-checksums; I can't > on Solaris. For other than the intentional UDP-checksum is zero case (which shouldn't really occur), the stack shouldn't be sending checksums in the protocol headers valued 0x. Looking at the in_cksum code, it would appear that a test at the very final step might be necessary (if you presume that the intermediate computations might produce a -0). But that code is highly tuned, and more than a cursory examination is called for. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: HP Type C1559 problems
I'm using a HP SureStore 24x6 too, and have no problems talking to it with chio. I suspect there's some screwy optioning nonsense for the tape motion stuff that's wrong. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T1 / E1 PCI card for FreeBSD?
> Len Conrad wrote: > > > > [EMAIL PROTECTED] tells me their P1200 E1 card, with FreeBSD drive, can't > > work in channelized mode (like the etinc cards can't). Their LMC150xM > > cards can do channelized, but don't have a FreeBSD driver, but their > > FreeBSD guy is looking at it. > > > > Any hacker care to explain how a channelized T1/E1 (24 or 30 separate ip > > streams) would be seen within FreeBSD? ifconfig setup? Would we have to > > assign 30 fixed ip addresses to these "virtual/channel" ip interfaces? > > Fixed, DHCP, PPP-assigned, whatever. Individual addresses would certainly > be the easiest way to use them, unless you're going to do aggregation at the > link layer. Sorry, my knowlege of channelized T1 doesn't extend quite that > far down. You've got to look at what you're actually getting as a delivered capability. What you actually have is 24 (or 32 in the case of an E1) 64kb/s bearer channels. Some of them might be combined with others to provide Nx64kb/s coherent bearers. Some of them may be dedicated to framing, transport and signalling (e.g., the "D" channel of a 23B+D ISDN PRI T1). That these bearer channels happen to be delivered on a T1 (or E1) entrance facility as the handy carrying case is mostly orthoganal to how you'd treat each individual bearer channel. There might be configuration associated with the T1 (e.g., AMI or B8ZS line encoding), but it's mostly invisible to the bearer channels, other than enclosing them. So you'd probably end up with 24 network interfaces or devices (in the case of a T1), one for each 64kb/s channel, unless you combine them together somehow as Nx64K aggregate. On the other hand, how the hardware abstraction is presented or exposed by the OS might mask this. Consider an ISDN BRI; this is a 2B+D channelized facility, but due to the typical application it's used for, the completely general abstration may not be necessary. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: T1 / E1 PCI card for FreeBSD?
> Hi Louie, > > >You've got to look at what you're actually getting as a delivered capability. > > What we are looking for is just 30 x 64 kbit incoming ISDN channels for > remote access to Internet. "remote access concentrator". > > >channels. Some of them might be combined with others to provide Nx64kb/s > > I see the Portmaster 3 can bond channels even across PM3 chassis, but we > would not need anything so fancy as that, as least in the first > phase. This was different from what I had described, which is combining two or more 64kb/s channels into an aggregate channel of higher capacity; essentially a fractional-E1 (or T1). The "bonding" thing you referred to is really PPP multi-link where a packet is segmented, and sent in parallel over multiple links. > Much more "sellable" to our clients (paying metered access for > local time charges for ISDN in Europe) would be hardware STAC compression, > ie, Lucent sells a card for the PM3 for hardware-assisted compression, for > all 60 channels compressed in a 2 x E1 chassis. Is there a PCI > stac-compression card supported by fbsd? I dunno, if it was me, I'd just buy an Ascend/Lucent MAX or TNT box and declare success. I suppose you expose multiple devices, one per channel, like the sr driver does for one channel. But this is something of a different beast since you'll also need to do something about the ISDN signalling. I'm not too familiar with how the isdn4bsd code is structured. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Copy-on-write filesystem
> > > Imagine: cp file file2, file and file2 reference the same exact blocks, > > > but modified chunks of file2 would be given their own private blocks. > > > > This is not a microsoft innovation, actually, I believe it was a VMS > > innovation. It's called a generational filesystem. the original is > > stored, and later generations of the file are stored as diffs. > > As far as I know, VMS simply stores whole files - no diffs involved. Now > if you go back to for instance Univac 1100 and the Exec-8 OS (I suppose > it is OS-1100 now), you'll find a system that *did* store the diffs. In > the form of punched card images! :-) Well, not really. That was mostly an application convention rather than being done in the OS. And that all the applications wanted to use SIR$ SDF to read program file elements was just a coincidence :-) The cools part of Exec-8 that we still need (we already have sparse files) are the virtual filesystem bits. E.g., unloaded files. People have been struggling with multi-level storage architectures on UNIX for years, while this was pretty much a solved problem on these 1's complement 36 bit dinosars 30 years ago. (The notion was that if you didn't use a file in a while, the system would release the data blocks, and mark the file as "unloaded." When you "assigned"/opened one of these files, a system process would cause the current backup tape to be loaded, and the file restore. When you began to get low on disk space, likeway a systen process would start, and sort all files based on their priority for being unloaded - based on last reference time, do we have a current backup, who created it, etc. It would then begin to release the data blocks until you acheived a configured threshold.) louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Is FreeBSD dead? Well, not in theory...
> As long as they keep their grubbly little hands off of it, and dont let the > ciscos and uunets of the world (who both own a piece of bsdi) dictate > policy, and as long as several key developers dont go work for BSDI (they > would have already if they were going to I think)it shouldnt be much > different. As far as I know, UUNET had to divest their equity interest in BSDI at the time that we (UUNET) went public years ago (or maybe it was when we took some VC funding.. too long ago now.) The AT&T lawsuit was still simmering at the time, and that degree of uncertainty was deemed hostile to raising money. In retrospect, UUNET probably should have kept a piece. Over the past few years, UUNET has funded BSDI to add specific features (like doing the SPARC port) but that was a conceptually simple contracting arrangement that resulted in the code being available to all BSDI users. What's interesting in all this is to consider all the various Internet embedded application "wins" that FreeBSD and BSDI have. Just the ones that I can think about off the top of my head: Juniper Networks, Mirapoint, Whistle (FreeBSD) and Ascend in the GRF platform (BSDI). There are certainly others that escape me at the moment. BSDI has a nice embedded packaging of their product, and FreeBSD has gone in that direction too with things like PicoBSD. I think there's a big potential here to vigerously pursue that high-reliablity Internet infrastructure market with the combinations of the technology. In particular, BSDI can bring the support for those "vertical" applications for OEM's that want to buy it. These are obviously just my opinions, influenced by low blood sugar, and not necessarily those of UUNET's. louie (aka [EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining traffic on a socket - solution and security question
These approaches work well, so long as the 32-bit sequence space doesn't wrap. At 100Mb/s, this wraps in about 6 minutes. Sure, most connections don't carry more than 4GB of data but you might be interested in the ones that do. This also is a problem for the counters in struct if_data that are of type u_long and are going to wrap way too quickly on busy high-speed network interfaces. louie [EMAIL PROTECTED] said: > I have attached my final program which works on both FreeBSD 2.x and > FreeBSD 3.x (I don't have a FreeBSD 4.x box to test this on yet). > On FreeBSD 2.x one must be root to run this (to read /dev/kmem), but > on FreeBSD 3.x any user can run this. > I would argue that this is a potential security vulnerability. Some > clever user may be able to exploit this for some protocols to > determine the lengths of usernames and passwords (admittedly this is > unlikely to work with telnet unless in line mode). The sysctl calls > that extract things like TCP control blocks should require privileged > access (although the downside of this is that programs like netstat > would have to be setuid). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GPS heads up
> :Out of curiosity, how many people in this discussion are hams? > : > :--mike N8NVW > > -Matt KC6LVW louie WA3YMH (and elligble for QCWA this year, yikes!) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GPS heads up
> Warner Losh wrote: > > > > What I was trying to say was that SA is caused by the satellites > > reporting times that have a small offset added to or subtracted from > > them. Knowing where you are requires that you know what time it is to > > a very precise degree. Once you know what time it is, you can know > > where you are. That's why SA injects a pseudo random noise factor > > into the timing information that the satellites report. If you have > > an atomic clock and a GPS clock, you can measure the offset between > > the two fairly easily and graph the results. That is what I mean when > > I say you can compensate for the SA if you have a good atomic clock. > > This is what "Differential GPS" provides: a standard time source that > can be used to remove the SA meanderings from the GPS fix. Indirectly; the actual differential GPS corrections provide pseudo-range corrections. That is, the difference between what the actual distance to the satellite is at the reference station, and the distance you derive from the signal after it's been degraded. These days, thats primarily ionospheric effects. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Generic config file parser?
I usually just embed a TCL interpreter into tools that require a lot of configurability. You can then use that infrastructure to extend the tool as well. You can make config files which can just be eval'ed by TCL to configuration your application. louie > Wes Peters wrote: > > > > > I'm really want to make this thing generic and unite it with > > > others config file parsers (if memory serves me right, Daniel Sobral wrote > > > RW version for rc.conf style files). > > > > Not needed, there is such a parser library included in OpenSSL, which > > is included in FreeBSD by default as of 4.0. The documenation is > > non-existent, but I suspect it will show up sooner than yet another > > development effort would produce. > > Well, it _doesn't_ handle loader/rc.conf format, hosts format, > inetd.conf format, pccard.conf format, etc, which is what bp is talking > about. And, remember, _his_ library is already in the system too. > > But, alas, the format thing isn't even the beginning. That stuff doesn't > do HALF the stuff my own libconf does. It doesn't handle nested > sections, it doesn't handle multiple input files (which is pretty much > the way we decided to do things), it does _update_ the files, it doesn't > handle descriptions, it doesn't handle set/unset with comments, it > doesn't handle unset (commented-out) options for reference purposes, > doesn't handle multiple instances of a setting... and, then, it's access > methods are pitiable. You can't enumerate settings in a section, > enumerate sections, etc. > > Now, my library, which does all of the above, was shot down by msmith > because *IT* doesn't handle a lot of stuff that ought to be handled. > > > A better choice might be found in XML. Exploring the port of libxml > > (in ports/textproc) might be enlightening. > > As long as we don't have to change the format the options are in. :-) It > can get difficult once you are receiving input by NIS or NDAP, or the > file formats are beyond your control. :-) > > -- > Daniel C. Sobral (8-DCS) > [EMAIL PROTECTED] > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > "Sentience hurts." > > > 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
