SSL connections not working.
I have a problem which I don't think is strictly a FreeBSD problem, but frankly I don't know where else to ask right now. Hopefully someone here can either help, or point me to the right forum. I have a FreeBSD 4.8-RELEASE box, with saslv2 (from the ports tree) and sendmail 8.13.3 (built by hand) installed. One of the things they are configured to do is accept connections on port 465, that is a native SSLv3 connection. This setup has been working for some time. All the sudden clients (Outlook, Mulberry) that connect to port 465 simply hang after the connection is made. Mail is never sent. There is nothing in the sendmail logs, and the clients report a generic timeout error. I tried reinstalling sendmail, reinstalling sasl, and creating new certificates, and nothing changes the behavior. I can connect (locally) with openssl's s_client and get what appears to be a normal and correct sendmail dialog. I'm now at a loss. I don't know which bit of software (FreeBSD, sendmail, openssl, sasl, Outlook, Mulberry) might be at fault, much less what might be the right place to ask questions about this interaction. I've searched google near and far and can find no one with the same issue. I've tried rebuilding and reconfiguring things several different ways now based on different pages I found, but they all result in the same behavior. Any help, even if it's just pointing me to a more appropriate forum, would be greatly appreciated. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpU6mFfrNShA.pgp Description: PGP signature
Busy BIND + 5.2.1 = UDP Packet Loss
I recently upgraded a fairly busy nameserver to FreeBSD 5.2.1, and I'm seeing packet loss from time to time on the box. I've done some digging, and the box seems to be dropping UDP packets. Netstat output: udp: 177604011 datagrams received 0 with incomplete header 7 with bad data length field 2735233 with bad checksum 83753 with no checksum 205540 dropped due to no socket 1917 broadcast/multicast datagrams dropped due to no socket 10627437 dropped due to full socket buffers 0 not for hashed pcb 164033877 delivered 169793422 datagrams output The "dropped due to full socket buffers" seems to be the issue. I am also concerned by the number of packets with bad checksums, but I have no previous data point. I am seeing loss with DNS, but also with ping and given the few pauses in my ssh sessions with TCP as well. I don't see anything remarkable with the TCP or ICMP statistics. I don't think there's anything wrong in MBUF land, statistics here for reference: % netstat -m mbuf usage: GEN cache: 0/256 (in use/in pool) CPU #0 cache: 335/672 (in use/in pool) Total: 335/928 (in use/in pool) Mbuf cache high watermark: 512 Maximum possible: 51200 Allocated mbuf types: 291 mbufs allocated to data 14 mbufs allocated to ancillary data 16 mbufs allocated to fragment reassembly queue headers 14 mbufs allocated to socket names and addresses 1% of mbuf map consumed mbuf cluster usage: GEN cache: 0/152 (in use/in pool) CPU #0 cache: 289/400 (in use/in pool) Total: 289/552 (in use/in pool) Cluster cache high watermark: 128 Maximum possible: 25600 2% of cluster map consumed 1336 KBytes of wired memory reserved (49% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines The only other thing I found of interest was some interrupt drops: % sysctl -a | grep drops net.inet.ip.intr_queue_drops: 13981 So, given the traffic profile (nameserver, heavy UDP) and the info here can someone help point me in the right direction? I'm not sure where to go from here? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpzwe3aLq5FX.pgp Description: PGP signature
Re: Article on Sun's DTrace
In a message written on Thu, Jul 08, 2004 at 06:28:22PM +0200, Dag-Erling Smørgrav wrote: > Avleen Vig <[EMAIL PROTECTED]> writes: > > They said "6 staff-years". > > No, they said three engineers working full-time for two years. I will also point out that many software "features" exhibit an exponentially decaying re-implementation time. The next implementation might take two people 6 months, the one after that two people 2 months, and so on. I for one, look forward to this technology. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpeLHmaguzEq.pgp Description: PGP signature
Re: /bin/ls sorting bug?
In a message written on Mon, Jun 21, 2004 at 10:16:49AM +0100, Paul Robinson wrote: > For what it's worth the original patch looked good to me. The nanosecond > patch is fine too. Please, no more intimate discussion of a command line I'd like to put forth a different argument why the nanosecond patch is a better patch. While I think the particular sort order (current behavior vrs non nano patch vrs nano patch) is largely unimportant, I think consistency is very important. It's quite common to do things like using diff on the output of commands like ls (indeed, I think several of the built in periodic scripts to this), and for that having a _reproduceable_ order is important. Since today, for almost all users nanos is 0 there's no impact on most of the users. For the few users where nanos isn't 0, the impact is that if we do the non-nanos patch now, and then at some point in the future add the nanos patch, at that transition old and new ls will produce different output for the nanos users. So, if we're going to alter the output and make people look at their diffs (or whatever) once with puzzlement, we should make sure it's only once. Put another way, the man page says: -t Sort by time modified (most recently modified first) before sort- ing the operands by lexicographical order. Since it doesn't have a resolution, if I was a nanos user and it didn't sort by nanos, I'd be a bit annoyed. Having -t work correctly is the right option. The fact that there is no way to display nanos is a separate bug. Don't let the existance of one bug prevent you from fixing another one. Note, I advocate -T display nanos. Humm, I didn't want to debate command line options (as the parent suggested) but I put two in my post. Can't win 'em all. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgpkVmPPYkvt3.pgp Description: PGP signature
Re: Yes, send-pr results in virus emails
In a message written on Wed, Jan 28, 2004 at 04:38:54PM +0100, Dag-Erling Smørgrav
wrote:
> No, you need to realize that spam will happen no matter how careful
> you are, and take appropriate countermeasures.
Wearing a seatbelt and defensive driving are not mutually exclusive.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Yes, send-pr results in virus emails
In a message written on Tue, Jan 27, 2004 at 01:47:57PM -0600, Brandon D. Valentine wrote: > I'm afraid there's not much that FreeBSD can do about this. All PRs are > forwarded to the public freebsd-bugs mailing list and on any public > mailing list there are inevitably n > 1 Microsoft clients subscribed. There's no reason the sender address needs to go to the mailing list or be visable on the web, is there? That is, the sender address could be stored in the PR database, visable only to those who can change the status of a PR (I assume they have some password protected web/e-mail interface). When forwarded to a mailing list it could come from [EMAIL PROTECTED] or something. While spam is a fact of life, in some cases we need to reevaluate plastering an e-mail address everywhere just because we can. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: dhclient & dynamic DNS updates
I'm replying to my own message for the sake of list archives.
I just tried the new dhclient (3.0p12), and dynamic DNS works just fine.
Looks like this was a bug that was fixed. The man page has also been
updated and it now works just as documented in the man page.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Where is FreeBSD going?
In a message written on Thu, Jan 08, 2004 at 10:35:47AM -0700, Nick Rogness wrote: > Perhaps this could be done through a company that contracts just > FreeBSD developers. I know of no such company. I guess I will > have to be satisfied with -jobs for now. https://www.rentacoder.com/ Maybe someone could get them to make a FreeBSD section, where only people with commit bits can apply for jobs or something -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
I'm going to propose a different solution that was brought up about two years ago (although I can't find it now). You start with something like the CD boot image mentioned, that is a 3-5 Meg iso image that basically contains what is now on the floppies (perhaps with a few more drivers/modules) and nothing more. Downloading and burning to CD would be the primary method of install. Then, to replace the current floppy process, a new floppy installer is created. It may or may not be based on FreeBSD, but what it needs to be able to do is boot, load a network driver, configure the network, and ftp the above mentioned iso into ram, and then jump into the kernel from the iso as if it had been loaded from a CD. Yes, I'm grossly oversimplifing the process, but it removes all of sysinstall from the floppy, all the need for crunchgen and all that, as it should be fairly easy (again, perhaps not with a full kernel) to support a number of network drivers and a basic FTP client on a single floppy. The only real direct freebsd issue is to make the kernel able to boot itself from memory, and then treat that memory as a ram disc on boot. It would require a whole new floppy booter setup, but I can see other OS projects using something like this as well, so perhaps some cross work with NetBSD or OpenBSD, or even the Linux camp could make an open source "load an image" floppy, that since it just loaded an ISO could load about anything. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 10:22:44AM -0500, Lanny Baron wrote: > Just what we are wondering. Where is all the FreeBSD community support > for a Server company that fully supports FreeBSD? It certainly is not in > this letter. Disclaimer: Until this message I didn't know www.FreeBSDsystems.com existed, and I know nothing about them other than what the front page of their web server has on it. I believe you've missed the point completely. Building a new server farm is an important, but specialized niche. Sure I can buy hardware that is only 100% fully supported. I may have to pay a little more, but to some degree that's ok. The point is that the person trying FreeBSD at home (where Linux is a competitor), or wanting to put it on their desktop at work (where IT just gave them a PC with windows, and the boss will let them run FreeBSD, but won't buy yet another PC to do it) suffer. OS's like FreeBSD and Linux make their way into the enterprise from the ground up, running on the old leftover box in the corner. So, do I support companies like (but not specifically) www.freebsdsystems.com, sure. Does that mean the freebsd development team can forget about all the other hardware out there in massive quantities, heck no. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Where is FreeBSD going?
In a message written on Wed, Jan 07, 2004 at 02:09:33AM +0100, Brad Knowles wrote: > FreeBSD-5 was always going to be problematical. There have > probably been more things changed for this major version than for any > previous major version in history, maybe even for all previous major > versions combined. They bit off a great big honking whackload with > this version, and they knew it. That's why we're so far behind the > original release timetable (one year? two years?). > > Any reasonable production-oriented plan would have been to stick > with 4.x until such time as 5.x has been declared "STABLE", and then > wait for another minor release or two after that. Timetables can > (and do) slip, so you'd have to build that into the picture. Speaking with a user hat on, I'll comment on what I believe is the crux of the 5.x issue. You are 100% right, in that all documentation, communication from FreeBSD developers and soforth has pointed to remain on 4.x for "production" machines until 5.x has a stable release, and that it will be a while. From a practical point of view that has been rapidly breaking down over the last 6-12 months. People need features in 5.x. Various people have decided (for good reason, I'm not questioning the decisions) that a large number of features go into 5.x, and because of the difficulty in back porting don't go into 4.x. Indeed, the only reason I'm running -current now is I need support for an Atheros wireless card. The take away I see is that this was too big of a chunk. The next bite planned needs to be smaller. You can't delay one year or two years in a production environment. New hardware needs drivers in that time. New protocols become production deployed in that time. I am also a firm believer that having all the developers focused so much on meeting deadlines for all this new complexity leaves them out of time to deal with the PR's that have been piling up. For FreeBSD to appeal to the masses it must install on the latest and greatest Dell or Gateway or whatever, which means it must include drivers for today's cheaper-by-the-gross parts from China. Driver updates in particular need to be very regular, and in the active -STABLE release, which for now means back-ported to 4.x, even if that means a complete rewrite because of how different the kernels are. Otherwise people get forced to run 5.x for a few driver issues, and then complain like crazy about all the other stuff that's not ready for prime time. Mom said it best, small bites, chew with your mouth closed. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: ipfw2 problem
In a message written on Sun, Jan 04, 2004 at 05:32:17PM +0800, Ganbold wrote: > me what will happen when net.inet.ip.fw.dyn_count reaches > net.inet.ip.fw.dyn_max value? As a random passing thought... Anytime a new dynamic rule is denied due to reaching dyn_max, a new counter, eg, "dropped_dyn_rules" should be incremented, so the user can at least verify the limit is the problem. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: natd + ipfw question
Original broken case: In a message written on Tue, Dec 23, 2003 at 03:17:12PM -0500, Leo Bicknell wrote: > > ipfw add 1000 divert natd ip from any to any recv fxp0 > > ipfw add 1001 divert natd ip from any to any xmit fxp0 In a message written on Tue, Dec 23, 2003 at 12:28:09PM -0800, Luigi Rizzo wrote: > The names are reasonably intuitive... [snip] > the flow diagram near the beginning of the ipfw manpage should > clarify things a bit (i agree that the wording of 'recv/xmit/via' > section is a bit confusing, so if you have better suggestions they > are welcome) I did some more poking with my broken rules above. With them natd appears to get the packet each way once (based on nat debugging turned on), so it's not my first fear that the packets would go through twice without in and out with these rules. Natd simply (per it's debugging) doesn't change anything. 1918 space in, 1918 space out. If I add the "in" and "out" keywords it magically starts working. Now, if I understand the diagram right a packet might be processed by rule 1000 twice, since recv matches on input or output, but I don't actually ever see received packets (I think) since the xmit side isn't doing the outbound part of the nat (if the packet leaves with 1918 space source, insted of my outside source, I'll never get it back). Now that I've used IPFW2 for something more complicated than simple host filtering I see that the syntax and structure makes something like a firewall/nat box for any moderately interesting config way too complicated with way too many pitfalls. This whole "the packet may hit your rule between 0 and 4 times, depending on a pile of stuff" just doesn't fly, and add in the need for "one_pass=0" to make dummynet traffic shaping work right, which adds some complication to the firewall rules and things are just all kinds of strange. That's no knock on the authors, backwards compatability is important, and a lot has been grafted onto IPFW since it started (like divert/nat and the dummynet stuff). I'll strongly recomend though that IPFW3 have a whole new, from the ground up, redesigned config language. :) And yes, I'm willing to help. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: natd + ipfw question
Well, I found the solution to my problem by random chance (futzing with other things), and it still doesn't make sense. Works: > ipfw add 1000 divert natd ip from any to any via fxp0 Doesn't work: > ipfw add 1000 divert natd ip from any to any recv fxp0 > ipfw add 1001 divert natd ip from any to any xmit fxp0 Works: ipfw add 1000 divert natd ip from any to any in recv fxp0 ipfw add 1001 divert natd ip from any to any out xmit fxp0 I must not be clear on what "in" "out" "recv" and "xmit" mean, and after reading the manual page 3 times I'm now even more confused. I'd love for someone to explain to me why the middle one doesn't work (or, why in and out are required). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
natd + ipfw question
Can someone explain to me why: ipfw add 1000 divert natd ip from any to any via fxp0 works, and yet: ipfw add 1000 divert natd ip from any to any recv fxp0 ipfw add 1001 divert natd ip from any to any xmit fxp0 doesn't? Yes, I want to do something fancier treating inbound and outbound traffic differently, but this basic case doesn't seem to work, and it seems to me like it should. What am I missing? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: adding more ram
In a message written on Thu, Dec 11, 2003 at 02:42:12AM -, Sparrevohn, Thomas wrote: > The /var size should properly stay as recommended. But a sanity > check on the available space when enabling crash dumps might be a > good idea Right, I didn't want to change the default suggestion, just put near that recomendation that crash dumps may greatly increase /var need, and also mention that in the swap sizing section as to why swap == ram should probably be a minimum (otherwize you can't turn on crash dumps without repartitioning). -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: adding more ram
Speaking of tuning, it should probably mention a swap partition
must be larger than RAM to support crash dumps, and /var needs to
have space for nxRAM dumps, where n is how many you want to keep.
I've seen too many people with 2G RAM and 1G swap, or a 1G machine
with crash dumps enabled and a 128M /var, as recomended.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
dhclient bug
I've identified what appears to be a bug in the dhclient code, but I'm a bit stuck on how to actually fix the issue. I've talked with a couple of ISC people, and can't get anyone to look at it, at least not for several weeks. So, I'm trying the next best thing, are there any FreeBSD people who've bug-fixed dhclient in the past who might be able to help me make a proper patch? If so, please contact me off-list as this is not a FreeBSD issue per-se. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
healthd oddities
With my FreeBSD current system I decided to try healthd again, it didn't work with my previous motherboard. It seems to work with my new motherboard (Intel Serverworks of some sort, I can get a model number later if it matters), however all the numbers are just out of range. Pardon the HTML, but it's the easiest way to get them labeled: # healthdc -H 10.42.42.1 Content-type: text/html healthd 10.42.42.1 Chip Set Temperature255.0 CPU #0 Temperature 0.0 CPU #1 Temperature 0.0 CPU #0 Cooling Fan CPU #1 Cooling Fan Case Fan Cooling Fan CPU #0 Core Voltage4.08 CPU #1 Core Voltage4.08 3.3 Volt4.08 5 Volt6.85 12 Volt15.50 -12 Volt-14.16 -5 Volt-6.12 Note 3.3 volt is 4.08, 5 volt is 6.85, etc. The system is not over clocking or doing anything else wierd. They are enough out of range healthd warns on them by default to syslog. Anyone seen this before? Do I have a problem I didn't know I had? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Making a FreeBSD DVD
In a message written on Mon, Nov 24, 2003 at 03:00:12PM +1030, Daniel O'Connor wrote: > make release will make an directory suitable to put on a CD or DVD. It's just > that if you use a DVD you can fit a lot more packages/distfiles on the disk > (which make release doesn't do for you anyway). Well, what I'm really interested in is the install + live file system on a single DVD, which is how the DVD's at FreeBSD mall are advertised (I've never bought one, myself). So, I can build an install CD, I (think I) can build a live file system CD. How do you get them both on a DVD, and give the user a boot choice? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Making a FreeBSD DVD
I'd like to make my own distribution DVD's. I know how to make CD's, but looking at release(7) I see lots of documentation for CD's, and none for DVD's. Googling turns up nothing of interest in the first three pages. Can anyone point me to the documentation on how to build DVD's, a-la what they sell on FreeBSD mall? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: dhclient & dynamic DNS updates
In a message written on Sun, Nov 02, 2003 at 03:13:36PM -0500, Brian Reichert wrote: > I've never tried to make use of this feature. The manpage for > dhclient.conf(5) says: > > "The fqdn.encoded option may need to be set to on or off, depending > on the DHCP server you are using." > > Which tells me that your client isn't sending the updates, but is > asking the DHCP server to send the updates, which obviously depends > on who's DHCP server you're talking to. Actually, I believe the fqdn.server-update variable controls if the server does the update or not, the fqdn.encoded just needs to be set the same as the server. I'm working on two test cases. 1) dhcpd does the forward and reverse updates for the client. This works fine, and works great with dhclient (with fqdn.server-update on). This proves a couple of things, including that my DDNS nameserver config is ok. 2) dhclient does a forward update only (basically same config with the key and zone sections added to dhclient.conf, and server-update set to off). Under no set of flipping options have I been able to get dhclient to generate a DNS packet of any sort, much less a valid DDNS update. > The dhclient.conf(5) does go on the describe a method of doing DNS > updates in the DHCP client script. I'm afraid I'm going to have to fall back to an external script, which seems silly since dhclient is supposed to be able to do the update itself. > Myself, I've configured my DHCP server to honor 'send host-name' > directives, and update my nameservers. That way, even the most > unsophisticated DHCP clients (re: Windows boxes) can make use of > my infrastructure... Agreed. The end goal for config #2 though is boxes on the end of cable modem or DSL lines using dhcp. In that case I don't control the DHCP server, I just want the client to add it's address to a nameserver I do control so there is a way to get to it remotely. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
dhclient & dynamic DNS updates
I'm having problems getting dhclient to do dynamic DNS updates. I'm wondering if anyone else has gotten this working. I want dhclient to dynamically update a forward zone. I can't have the server do it, as I don't control the server (cable modem setup). I know I have named set up right, as I can have dhcpd update (at a different site) update the server just fine. So, my basic dynamic DNS config seems to be ok. I put the same key config and zone config in /etc/dhclient.conf. Right off the bat I noticed something odd, in dhcpd.conf 'secret' (in key) takes an argument in double quotes, qutoes in dhclient.conf give an error. With no quotes there's no error. Similarly for 'key' (in zone). Beyond that the only other things I've added are: prepend domain-name-servers 127.0.0.1; supersede domain-name "my.example.com"; send fqdn.fqdn "hostname.my.example.com."; send fqdn.encoded on; send fqdn.server-update off; Best I can tell from the config this should make dhclient send a dynamic DNS update to the server listed as "primary" in the zone section adding hostname.my.example.com. However, tcpdump shows no DNS update packets of any kind coming from the machine running dhclient. What's the magic to get dhclient to emit a dynamic DNS update? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: 5.x kernel config changes?
In a message written on Thu, Oct 30, 2003 at 02:55:50PM -0500, John Baldwin wrote: > > 3) There seems to be no more LINT or other listing of all the options. > >Why? In particular I needed "options NETATALK" but couldn't remember > >the name and there was no file to quickly grep. Has the list of > >options been moved somewhere else? > > sys/conf/NOTES and sys//conf/NOTES I'll reply to this message although I got this from three other people privately. All pointed me towards /usr/src/UPDATING, and for reference: 2621: Scott Flatman <[EMAIL PROTECTED]> sent in a decent write-up on the config file update procedure. http://people.freebsd.org/~imp/config-upd.html NOTE: LINT is gone. It has been replaced with NOTES. NOTES isn't buildable. However, you can generate a LINT file: cd /sys//conf && make LINT So I looked in sys/i386/conf/NOTES which, well, had nothing of interest in it. Turns out the things I needed are in sys/conf/NOTES since it has been split. Someone with a commit bit should update the comment in UPDATING to say NOTES is now in two parts as well. :) Other than that, thanks much, I'm off to be a happy 5.x user now. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
5.x kernel config changes?
I just built my first 5.1-RELEASE box requiring a custom kernel, and noticed some interesting things. 1) It appears IPFW just works (eg, configure it in /etc/rc.conf). It used to be you had to compile it in. What's interesting to me is that IPFW options are not in generic, and I didn't think "options" could be done in LKM's. What am I missing? 2) IPDIVERT is missing / doesn't work, so while my IPFW config seemed to take/work natd did not work. If IPFW is just going to work having IPDIVERT just work seems like a good idea as well. 3) There seems to be no more LINT or other listing of all the options. Why? In particular I needed "options NETATALK" but couldn't remember the name and there was no file to quickly grep. Has the list of options been moved somewhere else? 4) Due to the way the makefiles now work it seems impossible to build a new kernel after changing just "options" statements and install it without also rebuilding all the modules...which takes quite some time. This seems to be because it moves the whole directory out of the way in /boot. This seems a little suboptimal to me. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Loading a kernel module before the installer.
I have a system today with a vinum disk setup. I'd like to install new FreeBSD (5.1) with the same disk layout. Here's what I'm wondering: Can I load the vinum module before the installer from the install CD, thus allowing the installer to see the existing file systems? I think if I can do this I should be able to tell the installer to newfs them and do an install saving a lot of trouble over the more manual vinum install procedure. If this should work, how do I load the kernel module from the new boot loader? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: non-root process and PID files
In a message written on Mon, Oct 27, 2003 at 10:31:18AM -0500, Dan Langille wrote: > Any suggestions? Here's a slightly backwards concept. We're all familar with how you can open a file, remove it from the directory, and not have it "go away" until the application closes it. Well, extend those semantics to the namespace. That is, have a directory where any name that does not exist can be opened RW, any name that does exist can be opened RO. A file is automatically removed when no one has an open descriptor to it anymore. So, the "server app" does: open(pidfile) write(pid, pidfile) flush(pidfile) [go do all the server stuff, and then at shutdown] close(pidfile) All other apps just read it, but can't overwrite it because it's RO. I'm not sure how useful this sort of file system change would be in practice, but it would solve the problem, no? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: 802.11 AP Status?
In a message written on Thu, Oct 09, 2003 at 04:59:46PM -0500, Mike Silbersack wrote: > Note that if you're willing to run -current, your options are even > better: According to the ath manpage, the Atheros based cards support BSS > mode, they're a/b/g capable, and they're true PCI/cardbus cards, so they > should perform better. Hey, this is looking like a really good option. The only thing that's not clear to me is can you do b and g at the same time (eg, have a 54M g and 11M b client off the same AP) with a single card, or would you need to have two cards, one running in each mode? I get the impression if you run an AP in 802.11g mode then 802.11b clients "just work", but it doesn't say that explicitly. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
802.11 AP Status?
I need to make a FreeBSD box be a proper 802.11 AP (BSS Mode). I've got a pile of Orinoco cards here, but they seem to still not be supported. What ever happened to that effort? Assuming they still aren't supported any recomendations on a cheap PCMCIA and/or PCI 802.11 card that is well supported in BSS Mode on FreeBSD? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Changing the NAT IP on demand?
In a message written on Sun, Oct 05, 2003 at 08:11:05PM -0600, Nick Rogness wrote: > In addition to keeping your NAT translations (as suggested by > Wes), you need to also keep routes for those entries as well, so > that preserved traffic remains to route out the right ISP even if > a switch occurs. You're right, however I would go with a different mechanism, but one I've also never tried to do. What you want is routing based on the source address of the packet, not the destination as per usual. You want to be able to say "source a.a.a.a goes out link A". I've never tried to do it on FreeBSD (it's easy on say Cisco's, with a bit of a performance hit on some platforms). In a message written on Mon, Oct 06, 2003 at 05:28:57PM +0400, Yar Tikhiy wrote: > Just a random thought: If natd(8) were taught to change its default > alias address on the fly (it's just a single variable,) then the > desired effect would be achieved exactly. That's because any session > already having its own entry in natd's aliasing table would use its > old alias address kept in the entry. BTW, one could switch between > even more than 2 external connections in that manner. And that's > just a step away from session-aware load-balancing with natd(8). That's exactly what I was thinking, and more or less why I asked. Note, I think this configuration would be useful in a lot of other applications as well. Consider someone who can get, say, a 128k symmetric DSL line, and a 56k up 1M down satellite link. If using this "trick" you could direct latency sensitive (ssh, telnet, ntp) traffic over the DSL line, and send bulk data (http, ftp) over the satellite link that could be quite useful. I think I'm going to have to set up a lab box now and dig into this at a deeper level. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Changing the NAT IP on demand?
In a message written on Sun, Oct 05, 2003 at 01:43:01PM -0700, Wes Peters wrote: > Leo, you may be able to do this with ipfilter's ipnat. Nat rules are > traditionally processed with 'ipnat -CF', the -C clears the rules and > the -F option clears the currently active NAT mappings. You should > experiment with rewriting the rules and instantiating them with -C > only. This should leave the existing stateful mappings to the formerly > preferred interface while creating all new mappings on the newly > preferred interface. That's interesting. I've never used ipnat before with ipfilter, but from some quick man page reads that looks good. Save a second problem I just noticed...see below. > This might tend to confuse UDP-based services, which might see the next > request as a different 'session', but I doubt those are much a problem > across the internet. TCP only is good for my application. In a message written on Sun, Oct 05, 2003 at 02:29:11PM +0100, Paul Robinson wrote: > Depends on how much money you have, but had you considered getting your > own address range and BGP peering with your ISPs? I'd consider talking > to them about it. It'll take some time to setup, but it means your > "switching" is done at the router, not at the NAT box, which is the > wrong place to do it anyway. This application is for cheap + fast redundancy. Think getting 2xDSL line, or DSL + Cable modem for a quick conference / classroom deal and wanting some redundancy. In a message written on Sun, Oct 05, 2003 at 11:54:31AM -0300, Fred Souza wrote: > If I understood what Leo asked correctly, what's needed is to change > the default route on the FreeBSD gateway whenever an event tells it > to (in this case, the increase/decrease in performance for the ISPs). > The concern here is to keep currently-stablished connections alive, so > the process is carried out seamlessly. Actually, no not exactly, but this brings up a new problem. If you have box with link A, and IP a.a.a.a, and link B, and IP b.b.b.b I want a packet with source address b.b.b.b to have a "default route" out link B, and a packet with source a.a.a.a to route out link A. I then want NAT to be able to switch, on the fly from using a.a.a.a, or b.b.b.b. So, in network speak I want to "policy route", and the do NAT to two different IP's, with only one active at a time. I'd then do some external monitoring to decide which IP to use. Again, think like 2xDSL line, 1 (possibly dynamic) IP from each. Do the policy route (eg if you wrote an application on the box to bind to a.a.a.a or b.b.b.b it would use only that link) thing, and then have NAT pick an IP on the fly. They key is when nat switches not to dump the existing connections so it appears to be a "seamless" switch over. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Changing the NAT IP on demand?
I'm considering options for a new project, and I think I've discovered what I think is the best idea, but I don't think current software supports the config. I'd like to get some confirmation, and comments on if it would be hard to implement. Consider: ISP #1---\ \ FreeBSD BoxLAN / ISP #2---/ In this case the LAN would be 1918 space, the two ISP's would each provide a public IP for the FreeBSD box. Now, NAT would be required. What I want to do is write an external application to decide the performance of ISP #1 and ISP#2, and somehow tell NAT which outside address to use. That, by itself, is not hard. Here's the trick. I want the switch to be seamless. That is, if NAT is translating to ISP #1 and the application says switch to #2 the existing translations to #1 (until they go away naturally) should be kept, while new ones go to #2. The only ways I know to change the outside address seem to tear down all existing connections. Is it possible to make this work today? Would it be hard to fix if it doesn't work today? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Ugly Huge BSD Monster
In a message written on Tue, Sep 02, 2003 at 01:07:34PM +0200, Sten Daniel S?rsdal
wrote:
> all dependencies are as packages (in my case, i have several
> light-weight servers/routers that have no gcc/make capabilities).
On things without gcc/make perhaps using pkg_add with binary packages
would be a far superior solution to using the ports tree.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Non-executable mappings now in NetBSD too
In a message written on Sun, Aug 31, 2003 at 12:06:28AM +0100, Pedro F. Giffuni wrote: > Well, we only have a JIT JVM for the i386, and on the particular case of the > i386 we cannot enforce full protection anyways so there is probably a > workaround if we do need it. I'm not sure I want to suggest this, as I can't decide if it's a "hack" or a good solution. I'm feeling bold though, so I'll throw it out there. Honestly, I don't know the kernel internals enough to know if this would eliminate the problem. Could a new malloc (and friends) set of functions be defined, for argument I'll call them "emalloc" that executes memory that is executable? The JIT type apps could use that for the instructions (and the instructions only) allowing them to be executable, and all existing code would continue to be executable. Seems like this would protect all existing code, and give a nice way for the apps that need it to "label" to executable bits outright, so they both don't loose functionality but also so the execute right is tightly scoped. Note, I do understand you can do this with syscall wrappers, but that seems to introduce a performance penalty no one likes. Wrappering it in a new malloc (sbrk?) interface to the kernel might allow the same thing with much less penalty. Of course, we'd need multiple platforms to make developers use it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: dd to floppies broken?
In a message written on Sun, Aug 24, 2003 at 01:04:08PM -0700, David O'Brien wrote: > Since FreeBSD 4.0 we haven't had block devices. rfd0 is an alias for fd0 > now. You also don't need to specify the 'c' partition as the 'fd0' is > already the entire media device -- rather than just the FreeBSD portion > of it. Thanks for the info. I figured out what worked back with 0.8 NetBSD and have stuck with it ever since. :) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: dd to floppies broken?
In a message written on Thu, Aug 21, 2003 at 02:34:21PM -0400, Brian Reichert wrote: > # dd bs=8192 of=/dev/fd0 if=memtest86-2.9/precomp.bin > 10+1 records in > 10+1 records out > 84480 bytes transferred in 3.775199 secs (22378 bytes/sec) fd0 is block buffered. Try: dd bs=18k of=/dev/rfd0c if=memtest86-2.9/precomp.bin I forget why, but 18k maximizes performance on (some?) floppies. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: file size different from ls to du
In a message written on Tue, Jul 29, 2003 at 05:27:14PM +0200, Bogdan TARU wrote:
> I have tried to create some files of myself, with 'spaces' in them
> (holes?), but they don't act like this. So could you please explain what
> 'sparse' means, and the 'trick' to create them?
% cat sparse.c
#include
#include
#include
#include
int main(void) {
int fd;
fd = open("sparse-file", O_RDWR|O_CREAT);
lseek(fd, 1024*1024*1024, SEEK_SET);
write(fd, "0123456789", 10);
close(fd);
}
% cc -o sparse sparse.c
% ./sparse
% ls -lag sparse-file
-r-xr- 1 bicknell bicknell 1073741834 Jul 29 11:52 sparse-file*
% du -k sparse-file
48 sparse-file
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Network pipes
In a message written on Thu, Jul 24, 2003 at 12:48:23PM -0700, Tim Kientzle wrote: > Another approach would be to add a new option to SSH > so that it could encrypt only the initial authentication, > then pass data unencrypted after that. This would > go a long way to addressing the performance concerns. ssh -c none? Note, you don't want to use password authentication in this case, but public key should still be ok. You could also set up something like kerberos and use krsh or similar... -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: mbuf cluster shortage caused kernel panic
I had a crash a few days ago on a 4.8-RELEASE box that I hadn't looked into yet, but when I saw your message I went back to take a look. I also ran out of mbuf clusters. First time on this machine, and since I've used it to test a number of high bandwidth*delay paths I've at times had the socket buffers cranked and really exercised MBUF's but good. At the time of the panic the limits were sane (32k send/receive tcp). Note also the SCSI reset in the middle, my box didn't reboot properly because one of the (old, not in use) SCSI drives wouldn't spin up on the reboot and was keeping the bus from resetting properly. I had to remove it before the box would boot. # gdb -k kernel.0 vmcore.0 GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...(no debugging symbols found)... SMP 2 cpus IdlePTD at phsyical address 0x003d8000 initial pcb at physical address 0x00328aa0 panicstr: sbappendaddr panic messages: --- panic: sbappendaddr mp_lock = 0001; cpuid = 0; lapic.id = 0300 boot() called on cpu#0 syncing disks... 19 1 1 1 1 1 1 1 All mbuf clusters exhausted, please see tuning(7). 1 1 All mbuf clusters exhausted, please see tuning(7). 1 1 1 All mbuf clusters exhausted, please see tuning(7). 1 1 1 All mbuf clusters exhausted, please see tuning(7). 1 1 All mbuf clusters exhausted, please see tuning(7). 1 All mbuf clusters exhausted, please see tuning(7). 1 1 All mbuf clusters exhausted, please see tuning(7). giving up on 1 buffers All mbuf clusters exhausted, please see tuning(7). All mbuf clusters exhausted, please see tuning(7). All mbuf clusters exhausted, please see tuning(7). All mbuf clusters exhausted, please see tuning(7). Uptime: 77d1h20m39s (da2:sym0:0:2:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da2:sym0:0:2:0): UNIT ATTENTION asc:29,2 (da2:sym0:0:2:0): Scsi bus reset occurred dumping to dev #da/0x20001, offset 3145463 dump 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 471 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 420 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 369 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 318 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 267 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 216 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 176 175 174 173 172 171 170 169 168 167 166 165 164 163 162 161 160 159 158 157 156 155 154 153 152 151 150 149 148 147 146 145 144 143 142 141 140 139 138 137 136 135 134 133 132 131 130 129 128 127 126 125 124 123 122 121 120 119 118 117 116 115 114 113 112 111 110 109 108 107 106 105 104 103 102 101 100 99 98 97 96 95 94 93 92 91 90 89 88 87 86 85 84 83 82 81 80 79 78 77 76 75 74 73 72 71 70 69 68 67 66 65 64 63 62 61 60 59 58 57 56 55 54 53 52 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 --- #0 0xc0163bfa in dumpsys () (kgdb) where #0 0xc0163bfa in dumpsys () #1 0xc01639cb in boot () #2 0xc0163e24 in poweroff_wait () #3 0xc0184ad5 in sbappendaddr () #4 0xc01c85a1 in udp_input () #5 0xc01bbb18 in ip_input () #6 0xc01bbb77 in ipintr () #7 0xc0292631 in swi_net_next () #8 0xc0185d83 in sendit () #9 0xc0185e86 in sendto () #10 0xc02a0e51 in syscall2 () #11 0xc028e53b in Xint0x80_syscall () #12 0x8061d3e in ?? () #13 0x8061b54 in ?? () #14 0x80894fb in ?? () #15 0x8060bb3 in ?? () #16 0x804b54a in ?? () (kgdb) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Correct way to call execve?
You know, my own thinking made me figure this one out:
% cat exec.c
#include
#include
#include
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { _PATH_BSHELL, NULL };
execve(_PATH_BSHELL,execargv,NULL);
return 0;
}
% cc -fwritable-strings -Wcast-qual -Wwrite-strings exec.c
%
There you go. By default strings are read-only, and indeed smart
compilers use that to compress them and do other nifty tricks. However,
in this case you really want a string to be "char *", eg writable.
So, tell the compiler to do that with "-fwritable-strings", poof,
strings are now "char *", the cast away the cost problem goes away,
"-Wcast-qual" works fine.
It always seemed to me a lot of things included -fwritable-strings for
no good reason, maybe this is part of the reason. :)
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 11:24:43AM -0700, Tim Kientzle wrote: > I was hoping that someone knew a standard way to > say "yes, I really do mean to cast away that const," > akin to C++ const_cast. I'm missing something here. You can do that, but you can't do that with say "-Wcast-qual", which is basically a flag to say "I don't care what the code says, tell me about those situations". > Basically, there is no const-correct way to > invoke execvp using literal strings for argv except > to copy the strings. In particular, the > FreeBSD implementation of popen(), for example, cannot be > compiled with strict warnings. Depends on what you call correct. "cc" compiles it quietly. "cc -Wall" compiles quietly. "cc -ansi" compiles quietly. "cc -pedantic" compiles quietly. Sure, there are options you can turn on that show you these /warnings/, but that doesn't mean those options are actually showing you problems with your code. Just because you can run "cc -nostdlib" doesn't mean all code that fails to compile is "broken", it means you used the wrong option. Similarly, if you do things in your program that require constants to not be, then turning on an option to warn you about that seems a bit backwards as well. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 11:15:38AM -0600, Chad David wrote:
> Try cc -Wwrite-strings -Wcast-qual exec.c.
>
> You cannot simply cast away a const.
Grumble, will someone give me all the warnings you want turned on so I
can work around all of them? :)
% cat exec.c
#include
#include
#include
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { strdup(_PATH_BSHELL), strdup(NULL) };
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings -Wcast-qual exec.c
% cc -Wall exec.c
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Correct way to call execve?
In a message written on Mon, Jul 21, 2003 at 08:53:53AM -0700, Tim Kientzle wrote:
> Actually, this example passes -Wall if you declare
> "execargv" as simply "char *[]". However, I'm looking
> for something that passes gcc -Wwrite-strings, which this
> example does not.
% cat exec.c
#include
#include
int main(int argc, char *const argv[], char *const envp[]) {
char *execargv[2];
execargv[0] = (char *)_PATH_BSHELL;
execargv[1] = (char *)NULL;
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
% cc -Wwrite-strings exec.c
% cc -Wall exec.c
Looks good to me.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: Correct way to call execve?
In a message written on Sun, Jul 20, 2003 at 02:13:52PM -0700, Tim Kientzle wrote:
> If I declare argv as "const char *",
> then the call to execve() warns about
> "incompatible pointer type" for the
> second argument.
Almost, but the other order is important here, this passes gcc -Wall:
#include
#include
int main(int argc, char *const argv[], char *const envp[]) {
char *const execargv[] = { _PATH_BSHELL, NULL };
execve(_PATH_BSHELL,execargv,envp);
return 0;
}
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
Re: tcsh / tset problem on 4.7 only?
In a message written on Mon, Jul 07, 2003 at 07:51:29PM +0300, Peter Pentchev wrote:
> What terminal are you using? Could you post the 'runme' file resulting
> from the 'tset -s -Q' command?
I see the problem with both xterm and vt100.
% tset -s -Q
set noglob;
setenv TERM xterm;
setenv TERMCAP
'xterm|vs100:li#65:kh=\EOH:@7=\EOF:kb=^H:kD=^?:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:rs=\E>\E[?1;3;4;5l\E[?7;8h:kI=\E[2~:kN=\E[6~:kP=\E[5~:k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:k5=\E[15~:ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:al=\E[L:dl=\E[M:mi:dc=\E[P:AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:LE=\E[%dD:ct=\E[3g:st=\EH:co#80:le=^H:bs:am:if=/usr/share/tabset/vt100:ho=\E[H:ac=llmmkkjjuuttvvwwqqxxnnpprr\140\140aa:ks=\E[?1h\E=:ke=\E[?1l\E>:ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:@8=\EOM:K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:pt:vt#3:xn:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:RA=\E[?7l:SA=\E[?7h:';
unset noglob;
In a message written on Mon, Jul 07, 2003 at 11:26:37AM -0700, Tim Kientzle wrote:
> The problem seems to be triggered by a
> {{ or {[ within '' within ``. (The termcap entry
> for vt100 contains {{ in the ac capability. Removing
> that capability is a workaround for this bug.)
> Hope this helps someone to track the problem down.
I think you've tracked down the problem, probably a tcsh parser
error with eval. I wonder if there is a tcsh guru around.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
pgp0.pgp
Description: PGP signature
tcsh / tset problem on 4.7 only?
I have a script that I've been using since the dawn of time that seems to fail on 4.7-RELEASE boxes, but not on anything before or after. To duplicate: Run the stock (/bin/tcsh) tcsh binary, and do: % eval `tset -s -Q` Missing ]. Similarly: % tset -s -Q > runme % eval `cat runme` Missing ]. However, then a: % source runme Works just fine. So, it appears eval'ing the output of "tset -s -Q" fails, but only on 4.7. Again, I've been using this for about 10+ years on all sorts of systems, including 4.8 and 5.0 boxes, but I can reliably make it fail on 4.7. I checked the cvs logs for both /etc/termcap, and for tset, and see nothing that would have changed between those releases. I even looked briefly at csh aka tcsh, and saw nothing obvious. Anyone have any idea why this is broken on 4.7? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: floppy.. Was: Drawing graphics on terminal
In a message written on Mon, Jun 16, 2003 at 12:37:08PM -0700, Julian Elischer wrote: > On Mon, 16 Jun 2003, Leo Bicknell wrote: > > Some of this could be done in the current installer, if there wasn't > > an effort to make it still fit on a floppy. Mind you, I'd like to see > > the floppy based install stick around for a while, but I think FreeBSD > > needs to embrace the CD reality. > > We have over a thousand machines in teh field with no CD but they do > have floppies.. > we use the floppy when we upgrade.. It's still are requirement as far as > I'm concerened :-) Oh, absolutely, which is why I said it needs to stick around for a while. All I'm saying is it's clear a fancier installer needs more space than a floppy can provide, and since PC standards are going to a floppy-less PC it seems like making a bootable CD image is the way of the future. I don't think anyone argues that, my only suggestion is FreeBSD get there sooner rather than later, and do that by making a "minimal" install CD, rather than the complete CD's available today. Perhaps this can be done with a new GUI based installer as well, letting the new "CD-install" run in parallel with the "floppy install" for the 2-4 major versions necessary for it to be fully baked. Another idea is to make a floppy just smart enough to load the installer over the network, since PC's generally have more memory these days... -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: Drawing graphics on terminal
In a message written on Mon, Jun 16, 2003 at 03:10:24PM -0400, Eric Jacobs wrote: > I don't think the advantage of a GUI-based installer would be > "eye-candy". libdialog looks fine IMO. It would be to increase the > ease of use, allow more flexibility in installations, and add more > troubleshooting/diagnostic options (disabling/enabling/loading > device drivers, etc.) Some of this could be done in the current installer, if there wasn't an effort to make it still fit on a floppy. Mind you, I'd like to see the floppy based install stick around for a while, but I think FreeBSD needs to embrace the CD reality. A problem, as I see it, is that the only bootable ISO is the full FreeBSD CD. For someone who wants to do a minimal net-install on a CD only computer that's too much. What I think needs to be done is the current installer enhanced (a few more tools for the emergency holographic shell, more help, etc), and produced in ISO form, eg a 3 to maybe 10 meg ISO image you could burn on CD and use like a floppy is used today. This frees up the size restrictions on the installer, and lets people without a floppy install easily, all without making anyone download a 600M file to do so. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: boot without user and password
In a message written on Thu, Mar 20, 2003 at 04:18:43PM +, Emilio Manuel wrote: > I wan to do this under Xwindows because I pretend to use this box as a > "dumb X terminal" that can display messages send from another UNIX machine. If you really want to use it as an xterminal, you probably want to look into the man page for Xserver, some sample command lines for you to try: Start a session on a remote host: X -query other-host.your.net Find all machines on the local network that will accept a session: X -broadcast Ask another host on the network for a list of servers to start a session with: X -indirect other-host.your.net For the last option you may need to configure the "chooser" on the other server, and all options may require changing some access permissions on the other boxes you want to query. Once you find what you like you can put it in a startup script somewhere. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
Re: C coding editor
In a message written on Fri, Feb 21, 2003 at 03:49:06PM +0200, Peter Pentchev wrote: > that people might be used to. Basically, vi and cc need just one > terminal, no more :) I'll insert one editor comment. While it becomes obvious to most people who use emacs (doubly true for emacs native in X, or xemacs) that emacs can do /everything/, it also often seems to people that vi can do "nothing". I won't suggest vi can do everything that emacs can do, but about once every 6 months I reread several vi references, and always learn a half dozen new things. There are really an amazing number of useful vi "features" that are not immediately obvious. Since there are no easy menu's or an easy to understand programming language they are often missed. Of course, my personal belief is that you should always know multiple tools. Program in vi for a while. Then emacs, then kdevel. You'll find a feature in one that spawns an idea in another, and knowing something about all of them helps you interact with people who only use one of them. Indeed, I have been known at times to use vi for all e-mail, and emacs for all coding, or vice versa. It really doesn't take that much time, and teaches you so much more. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org pgp0.pgp Description: PGP signature
DNS / UDP Port Logging Wierdness
I've been getting errors like the ones below, well, for as long as I can remember: Jan 25 16:27:43 myhost /kernel: Connection attempt to UDP 10.0.0.1:2663 from 10.1.0.1:53 Jan 25 16:27:43 myhost /kernel: Connection attempt to UDP 10.0.0.1:2683 from 10.1.0.1:53 Jan 25 16:28:53 myhost /kernel: Connection attempt to UDP 10.0.0.1:2705 from 10.0.0.1:53 Jan 25 16:28:53 myhost /kernel: Connection attempt to UDP 10.0.0.1:2707 from 10.0.0.1:53 Jan 25 16:28:53 myhost /kernel: Connection attempt to UDP 10.0.0.1:2716 from 10.0.0.1:53 Jan 25 16:28:53 myhost /kernel: Connection attempt to UDP 10.0.0.1:2737 from 10.0.0.1:53 Jan 25 16:28:58 myhost /kernel: Connection attempt to UDP 10.0.0.1:2706 from 10.1.0.1:53 Jan 25 16:28:58 myhost /kernel: Connection attempt to UDP 10.0.0.1:2708 from 10.1.0.1:53 Jan 25 16:28:58 myhost /kernel: Connection attempt to UDP 10.0.0.1:2734 from 10.1.0.1:53 Jan 25 16:28:58 myhost /kernel: Connection attempt to UDP 10.0.0.1:2751 from 10.1.0.1:53 myhost == 10.0.0.1, which is a nameserver. 10.1.0.1 is also a nameserver. They are they two nameservers listed in /etc/resolv.conf. Any ideas why these would occur so often? I get them all day, every day. Long ago I assumed they were caused by any number of programs running on the box that might ask for a DNS query, but then timeout/quit before the reponse was returned. I can't see any other programs having problems resolving names, or erroring out on a frequent basis. Any theories or other things I should look at? While searching for last night's attacks this finally annoyed me enough to do something about it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg39406/pgp0.pgp Description: PGP signature
Re: Reading rc.conf from C programs?
In a message written on Thu, Jan 02, 2003 at 12:18:55PM -0800, Tim Kientzle wrote: > rc.conf is _not_ a list of variable=value > pairs. It is a shell script that sets > a number of shell variables. Nothing > less than a full-fledged implementation > of /bin/sh is gauranteed to work in all > cases. Might it be worth restricting rc.conf to be a (very small?) subset of sh syntax so that it remains both a valid sh script and also easier to parse in a program? Clearly things like the end of /etc/defaults/rc.conf would have to be handled differently, but that might be a good trade off to make the file more easily parseable in many languages. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg38941/pgp0.pgp Description: PGP signature
Re: Perl issue on freebsd 4.x?
I opened a bug report with the perl people, and I got back the following
response from Slaven Rezic:
] This does not seem to be a problem in 5.8.0's Sys::Syslog. According
] to the documentation, by default the types tcp, udp, unix, stream,
] console are tried in order. It also seems to work on my FreeBSD 4.7
] system (syslogd is started with -s flag) without specifying
] setlogsock().
Perl 5.8 does not seem to be a part of 4.x, is it in 5.0 or
-CURRENT?
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
msg38815/pgp0.pgp
Description: PGP signature
Re: Perl issue on freebsd 4.x?
In a message written on Sat, Dec 21, 2002 at 03:03:53AM +1100, Andrew wrote: > This is to maintain historical behaviour. Sys::Syslog never used to know > how to do unix sockets at all so to not change behaviour of old scripts > inet had to be the default. While of course only my opinion, but this to me seems a prime case of someone making a mistake early on that should be corrected, even at the expense of some backwards compatability. That said, I suspect making unix the default will not only fix some things, but it's unlikely to break anything. The current code does not allow you to specify the (inet) destination, it does a gethostname and then does a DNS lookup. How many boxes have a hostname that doesn't look up right in DNS so this fails, and thus the code fails? It should have been coded to 127.0.0.1, if it was going to do the inet thing. Since I don't see any flags to syslog to turn off unix domain sockets (although there is one to locate it at a different path) it seems assuming that exists is far safer than inet, where there are flags to turn it off, default security options in a base install that turn it off, and recomendations running around to turn it off. All things considered, if it's not going to be changed the documentation needs to be updated. The man page claims: NAME Sys::Syslog, openlog, closelog, setlogmask, syslog - Perl interface to the UNIX syslog(3) calls Note that syslog(3) in libc does not know how to do inet sockets at all. Thus it's not a perl interface to syslog(3), it should rather be called "Perl implementation of the syslog protocol, similar to syslog(3)." It may be picking at nits, but when I see something called an interface to...I assume it has the same semantics as the base code. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg39138/pgp0.pgp Description: PGP signature
Re: Perl issue on freebsd 4.x?
In a message written on Fri, Dec 20, 2002 at 07:37:14AM +, Matthew Seaman wrote: > > > I've used syslogging with FreeBSD 4.4/4.5. Have not tried it lately. > > > > /usr/bin/perl as shipped on 4.4, 4.5, and 4.7. > > The perl-5.6.1 and perl-5.8.0 ports show exactly the same behaviour on > 4.7. I think I'm going to submit this is a perl bug in the end. Turns out I had a misunderstanding of how the C-library syslog worked, which carried over into perl. I thought both used inet sockets by default (which perl is clearly documented to do), and that syslog -s merely said only listen to things from your local ip (eg, -s was the same as -a box.ip -a 127.0.0.1). In reality, the libc syslog only knows how to do unix domain sockets (see /usr/src/lib/libc/gen/syslog.c, in particular connectlog). For some reason perl has chosen the opposite behavior as the default, to do inet sockets. For anyone running any sort of "secure" syslog this results in failure. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg38789/pgp0.pgp Description: PGP signature
Re: Perl issue on freebsd 4.x?
In a message written on Fri, Dec 20, 2002 at 11:10:36AM +1100, Andrew wrote: > I notice the C versions of these function return void and I see no mention > of any return values in Sys::Syslog so it might be worth checking the > Sys::Syslog code to see if testing the return value is meaningful. Interesting. Openlog, at least on the machine I'm looking at simply passes through the return value of connect, which I would expect to be meaningful. However, it seems that it is not. So after running into a simple problem I made it over-complicated by checking a return value that evidently is meaningless. Code as you posted works, which means I can fix my script. Thanks. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org msg38782/pgp0.pgp Description: PGP signature
Re: Perl issue on freebsd 4.x?
In a message written on Thu, Dec 19, 2002 at 05:45:34PM -0600, GB Clark wrote: > What version of Perl is this? > > I've used syslogging with FreeBSD 4.4/4.5. Have not tried it lately. /usr/bin/perl as shipped on 4.4, 4.5, and 4.7. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Perl issue on freebsd 4.x?
In a message written on Thu, Dec 19, 2002 at 08:36:40AM +0100, Hellmuth Michaelis
wrote:
> Syslogd on the machine listens on an "*.syslog" udp4 socket. The machine
> is multihomed. The "-s" flag to syslogd is explained as "Do not log
> messages from remote machines" - perhaps the perl process is considered
> to be remote ?
% uname -r
4.7-RELEASE
% ps ax | grep syslog
76 ?? Ss 0:04.80 /usr/sbin/syslogd -s
% cat syslogtest
#!/usr/bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
setlogsock('unix');
openlog('syslogtest', 'cons,pid', 'mail') || warn "openlog: $!";
syslog('info', 'this should go into the mail log') || warn "syslog: $!";
closelog() || warn "closelog: $!";
setlogsock('inet');
openlog('syslogtest', 'cons,pid', 'mail') || warn "openlog: $!";
syslog('info', 'this should go into the mail log') || warn "syslog: $!";
closelog() || warn "closelog: $!";
% ./syslogtest
openlog: at ./syslogtest line 6.
closelog: Bad file descriptor at ./syslogtest line 8.
openlog: Bad file descriptor at ./syslogtest line 11.
closelog: Bad file descriptor at ./syslogtest line 13.
I get the exact same behavior on another machine, which insted of
-s uses the -a feature (access list) allowing 127.0.0.1, the
machine's own IP, and several remote IP's.
My test box (that I could run syslog without -s on) is down for
the moment, I'll poke at it as soon as it's fixed. That said,
everything else on both of these machines syslogs just fine, and
since the failure seems to be in openlog (which I believe just
creates a unix domain or UDP socket, both of which should succeed
even if syslog isn't running) I don't think the security makes a
difference. I also find it odd that I can get no error out of
openlog, and when I dig into it with the perl debugger I can't tell
anything other than it's call to create the socket fails, but I
have no idea why.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
msg38766/pgp0.pgp
Description: PGP signature
Perl issue on freebsd 4.x?
I have a script where I attempt to use Sys::Syslog, and while it
works on several platforms it does not work on FreeBSD 4.x (well,
4.5 and 4.7 is what I have confirmed on) even though all works
fine. I've also passed my version of perl debugging, and don't
see why it's failing.
Test code, lifted right from the Sys::Syslog man page:
use Sys::Syslog;
openlog($program, 'cons,pid', 'user');
syslog('info', 'this is another test');
syslog('mail|warning', 'this is a better test: %d', time);
closelog();
If you add "|| die" to the end of each one you'll find it dies on
the openlog call, digging down with the debugger it can't establish
a socket to the syslog server. I get the same behavior if I tell
it to use a unix domain socket rather than an inet socket.
One machine runs syslog -s, the other -a with all IP's and localhost
in the ACL. I suppose it could be a security thing but all other
apps syslog just fine so I suspect perl should work.
While probably a perl issue, FreeBSD does seem to be the only place
it's broken for me, which is why I thought I'd try here. Anyone
got an idea?
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
msg38753/pgp0.pgp
Description: PGP signature
Re: How can I post a pr when my IP can't be reverse-resolved?
In a message written on Fri, Dec 13, 2002 at 08:24:02AM -0800, Terry Lambert wrote: > Probably, the correct thing would be to accept the submission, > and pend it for review, before it became active as a real PR. > This would require that a human look at the pending PRs, and > make a decision. Or, do the mailing-list confirm thing. Receive all pr's, send e-mail back to the "from" asking for confirmation. If received put into the queue, if not delete after n days. That way you could send a pr from a quite screwed up box with a from of your normal e-mail, and then simply confirm it. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inet_aton() Bug or feature?
In a message written on Fri, Oct 04, 2002 at 11:19:16AM +0930, Daniel O'Connor wrote: > I would imagine this behaviour is like it is because that is how atoi > and friends work.. Absolutely. I think this is the unintended consequence sort of bug, not the programmer goofed sort of bug. :) I'd definately call the poster's original problem a bug though, IMHO. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inet_aton() Bug or feature?
In a message written on Thu, Oct 03, 2002 at 12:55:15PM -0700, Crist J. Clark wrote: > This is a feature not a bug since it is documented in inet_aton(3), > > All numbers supplied as ``parts'' in a `.' notation may be decimal, > octal, or hexadecimal, as specified in the C language (i.e., a leading 0x > or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- > wise, the number is interpreted as decimal). While I agree it's documented, does it agree with practice? The earliest reference I could find was RFC 952 (ftp://ftp.isi.edu/in-notes/rfc952.txt): 2. Internet Addresses are 32-bit addresses [See RFC-796]. In the host table described herein each address is represented by four decimal numbers separated by a period. Each decimal number represents 1 octet. There are several other references to this format, including some later RFC's with BNF forms that have similar specifications. It would seem some people believe "dotted quad" format addresses are always composed of /decimal/ components. While I had no idea things like "0xff00" were just handded to inet_aton (although it makes some sense), it would seem to me much better if: 0xff00 was hex, 0123456701234567 was octal, 010.010.010.010 was 4 decimal parts I was very surprised from the poster that 192.168.0.010 might actually be 192.168.0.8. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Insider's scoop: Why FreeBSD is dying
In a message written on Sun, Aug 18, 2002 at 02:48:55AM -0700, Terry Lambert wrote: > Examining the headers, it looks like Hotmail has a full class "B" > (64.4/16); that's surprising. Why the heck do they have a full They seem to have 64.4/18. 64/8 and 65/8 are being chopped up for smaller allocations by the registries. > class B?!? If you are using load balancers for distribution, then > you basically need only enough IP addresses to provide publically > accessible VIPs to the various public services you export as seperate > entities. There's no *way* they have 65,534 (subtracting out the > unusable ones) of those! No one providing network services should ever be required to use any technology other than plain IP to provide it. That includes NAT and load balancers. If they want to have 10,000 machines (which, by the way, I believe they have well over from some press stuff on them) exposed to the Internet, and merely have a front end web server that directs users to the appropriate server more power to them. Having seen first hand the disaster that most NAT and load balancers create I know I'd avoid them if at all possible. > Maybe it's just so that if a host gets RBL'ed or otherwise > blacklisted, they can switch IPs, and won't have an interruption > of email service to their customers? If that's the case, that I'd point out most black lists are fairly good at checking registry allocation data, and blocking all the mail servers in a block if Spam continues. So if that were a problem you'd see 64.4/18 on the block list. ARIN has guidelines for allocating IP's. I don't agree with all of them, but they are fully documented on www.arin.net. I don't believe Microsoft was able to get around that process. So they are playing by the same rules and guidelines as anyone else. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Using FreeBSD as a base station
I have for some time using a Orinoco card as a "base station" at home. For those familiar with the wi driver, you know that it does not operate in AP mode with FreeBSD, but rather Ad Hoc. I believe progress is being made, but not done yet. I now have a need to set up a couple of systems as AP's, and I'm thinking I should pick a card with better functionality. What's the recomendation on the best supported card to make a FreeBSD AP? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: what causes a userland to stop, but allows kernel to continue ?
In a message written on Sun, May 05, 2002 at 04:31:36PM -0700, Patrick Thomas wrote: > So, based on a previous thread, it looks like I have a server whose > userland halted, essentially, but the kernel continued running. I've seen something similar to this before on an Ultrix box. What happened is on a busy machine the swap disk became unplugged. Remember when all drives were external? Anyway, for the most part things in memory (including logged in users at just a shell prompt) continued to work. New telnet / ssh connections hung right after connect (couldn't load login without touching swap, I think), some httpds worked (enough in memory) others hung waiting for a swap page. The system limped long in this strange state for nearly two minutes until the drive was plugged back in, when it went back to swapping and all was well again. No idea if it is related, but the semi-hung machine isn't a new occurrence. :-) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Difference between RELENG_* and RELENG_*_BP
In a message written on Fri, May 03, 2002 at 11:15:58AM -0700, JJ Behrens wrote: > The online documentation for PHP allows users to post comments at the end of > every page of the online documentation. Often times, these comments serve to > enlighten others about various quirks of the libraries. Perhaps doing the same > thing with the FreeBSD handbook pages (only online) might be a good idea. Allowing random comments (alone) isn't useful. More often than not PHP comments are not useful, or outright wrong. That said, we need to break down the barriers to good documentation. I think we could learn something from slashdot.org here, in that the right solution might be not only to have comments, but also to have moderators. In this way the user community can not only submit comments, but also rank them so we separate the wheat from the chaff. In the case of documentation it would also be essential to remove highly moderated comments as they are integrated into the documentation. At the end of the day, we need to lower the barrier to adding documentation, while increasing the quality. Far from an easy task. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: GPS time.
In a message written on Fri, Mar 29, 2002 at 06:04:11PM -0600, Paul Halliday wrote: > I just connected my gps (garmin gps III plus) to my serial port > and realized that simply cat'ing cua0 displays date/time/position of the > unit. (neato). Anyway, how accurate would it be to use the time from this > output for ntp as opposed to my current setup using ntp servers. Your NTP servers are better. I tested a III Plus, and without a 1 PPS source (which that model doesn't provide) it's accurate to about 100ms, give or take. Since real NTP servers are < 1ms, they really aren't that good. It's not that the time isn't accurate, it's that they were not designed to communicate with that accuracy to an external device. If you NTP off the Internet, and want a local backup clock it might be an acceptable solution. However clocks that can achieve < 1ms accuracy can be had for < $1000, so if you really care you should get one of those. You might want to do some searches for NTP in google. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: RFC: style(9) isn't explicit about booleans for testing -- an actual analysis of the code!
In a message written on Thu, Mar 07, 2002 at 03:27:49PM -0500, Garance A Drosihn wrote:
> As to the wording, PHK suggested that the wording for this
> rule in style(9) be changed:
> - - -
> get rid of the word boolean, ie: change
> Do not use ! for tests unless it is a boolean, e.g. use
> to
> Do not use ! for tests unless it is an integer type, e.g. use
Although C doesn't have the type "boolean", I believe this is a
conceptual distinction. That is, we don't want to allow this:
if (!uid) {
/* do thing only root can do */
}
Because UID is not a boolean type. It takes a range of values,
and should be:
if (uid == 0) {
/* do thing only root can do */
}
The only proper use of "!" is on a boolean type, defined as a type
that has two values, 0, and everything else.
Personally, I would clarify boolean in the document as follows:
C does not provide a proper boolean type. As a result, FreeBSD
uses integers for a boolean type. The boolean values are 0 for
false, and all other values for true. All code using a boolean
type must not depend on "true" having any specific value.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cannot get more than 32 PTYs in 4.4-RELEASE
In a message written on Tue, Mar 05, 2002 at 07:52:09AM -0600, Paul Halliday wrote: > pty*) > class=`expr $i : 'pty\(.*\)'` > case $class in > 0) offset=0 name=p;; > 1) offset=32 name=q;; > 2) offset=64 name=r;; > 3) offset=96 name=s;; > > interestingly enough the command "./MAKEDEV pty3" will create (as > indicated) heh.. I was assuming too much, something is screwy here. > > *confused* > > it actually only created 64 terminals. Added the line: > > 4) offset=192 name=t;; > > ~# ./MAKEDEV pty4 && kill -HUP 1 > > interesting, now I have 96, but can only use 64. Reboot.. I think if you look at a more recent MAKEDEV, you'll find your answer: pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=32 name=q;; 2) offset=64 name=r;; 3) offset=96 name=s;; # Note that xterm (at least) only look at p-s. 4) offset=128 name=P;; 5) offset=160 name=Q;; 6) offset=192 name=R;; 7) offset=224 name=S;; # This still leaves [tuTU]. So: sh MAKEDEV pty0 # 0-31 sh MAKEDEV pty1 # 32-63 sh MAKEDEV pty2 # 64-95 sh MAKEDEV pty3 # 96-127 sh MAKEDEV pty4 # 128-159 xterm won't recognize by default sh MAKEDEV pty5 # 160-191 xterm won't recognize by default sh MAKEDEV pty6 # 192-223 xterm won't recognize by default sh MAKEDEV pty7 # 224-255 xterm won't recognize by default It's fairly trival to patch xterm to look for additional letters. It may have made it in the XFree source already. *shrug* -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multicast problem with sis interface?
In a message written on Fri, Mar 01, 2002 at 03:56:23AM -0800, Luigi Rizzo wrote: > ok, these three drivers behave as follows: > > "ed" pads with whatever is left in the transmit buffer from > earlier transmissions; > "vr" pads with whatever is available in the mbuf after the actual data; I point out both of these are security risks. Granted, fairly minor, but they allow someone to get all/part of a previous packet's data, when they should have it. This sort of thing has been used as an attack vector before. I think fixing these to pad with some generated (0's, 1's, /dev/random, whatever) should be a top priority. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clearcase and FreeBSD
In a message written on Wed, Feb 20, 2002 at 10:19:01PM -0600, Mike Meyer wrote: > Not necessarily. The client is free, and in the ports tree. That > includes the server with an evaluation license, which limits it to two > clients and two users. Perforce offers Open Source software projects > free multiuser - which means unlimited clients - licenses. See http://www.perforce.com/perforce/price.html > and search for "open > source" on the page. They even point to the FreeBSD license as a good > choice for a candidate. While necessary for a project like FreeBSD, this is not sufficient. FreeBSD (and BSD in general) has outlived a number of companies and technologies, and if Perforce went down the tubes and there was no source we could have a major problem. Now, where did I put my SCCS copy of the tree... -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: JKH - Jr. Kernel Hacker task
In a message written on Thu, Jan 31, 2002 at 10:59:24AM -0500, Robert Watson wrote:
> I'm sorry Warner, but your submission has been rejected on the basis that
> you are a Senior Kernel Hacker. :-)
I've never submitted a kernel patch before, so...
Index: sio.c
===
RCS file: /cache/ncvs/src/sys/dev/sio/sio.c,v
retrieving revision 1.362
diff -u -r1.362 sio.c
--- sio.c 17 Jan 2002 20:05:47 - 1.362
+++ sio.c 31 Jan 2002 05:35:16 -
@@ -431,6 +431,7 @@
SYSCTL_PROC(_machdep, OID_AUTO, conspeed, CTLTYPE_INT | CTLFLAG_RW,
0, 0, sysctl_machdep_comdefaultrate, "I", "");
+TUNABLE_INT("machdep.conspeed", &comdefaultrate);
#define SET_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) | (bit))
#define CLR_FLAG(dev, bit) device_set_flags(dev, device_get_flags(dev) & ~(bit))
Wow, this kernel hacking stuff is easy. :-)
Apologies to Warner. :-)
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Fri, Jan 11, 2002 at 11:33:49AM -0800, Terry Lambert wrote: > I'm guessing that, even though you are not saying it, that the DTR > drop occurs *immediately* after the probe and attach, and not some > short time after the init scripts have fully rung, and the getty's > are started, initiating "first opens" (this is an educated guess > from looking at the code). No, this is wrong. The probe comes and goes, and I see a long list of probes after it. The drop is after the last kernel probe, and before the first non-kernel message (verified for both single user and multi-user now). Again the best way I know to describe this is that the drop occurs when the "boot sequence" switches from bold print to normal print on a CRT. Hooking up a crt to the same spot, and comparing messages with what I see on the serial port shows this is when it happens. What I have now realized is that this is long before getty runs, since it is not run on the console until the boot scripts complete. I now suspect the bios is leaving DTR high, and when init sets up stdout (for the rc scripts) and/or "opens the console" is when DTR is momentarily dropped. I'll be darned if I can see where that happens in init though. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Fri, Jan 11, 2002 at 09:48:10AM -0700, Lyndon Nerenberg wrote: > Okay, on the terminal server side wire DSR, DTR, and CD together. This > should let you open the port at any time ragardless of the state of > the remote sio port. But this will break the 'type exit and the connection drops behavior', because the terminal server will ignore that as well. The software is clearly lowering DTR on the console briefly between the kernel probes and init running. That is the issue here. Yes, it can be hacked around, breaking other things in the process. I'd like to zero in on why the software is doing this and fix it though. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 07:58:58PM -0800, Terry Lambert wrote: > If you could describe *exactly* what behaviour you wanted and > *exactly* when you wanted it, someone could probably give you > a better approach to what you are trying to do thatn futzing > with the gettytab. Ok, let me add some detail, because I think this is a fairly common setup: I have a Cisco terminal server (think 2511) connected to the console of a PC running FreeBSD. I am using the standard Cisco 9 pin adapter on the PC. The terminal server is configured a la: line modem Host transport input telnet stopbits 1 flowcontrol hardware On the PC, I do "-P" in /boot.config, "set console=comconsole" in /boot/loader.rc (which I am told is redundant with -P), and I changed the console line in /etc/ttys to: console "/usr/libexec/getty std.9600" unknown on secure Now, consider a fully booted PC (with no keyboard, so it used the serial console). If I connect to the terminal server (telnet termserv 200) I get the console login prompt. I can log in, and do normal unixy things. Most importantly, when I type "exit" the telnet session automatically closes. The terminal server is catching some signal (DTR, I believe) and terminating the telnet session. So far this is _exactly_ what I would like. Now, consider the machine is turned off. You cannot connect to the terminal server, because it never gets a signal from the PC (DTR again, I believe). I can live with that. It means if you want to catch the loader prompt you have to keep trying over and over when the tech turns it on, annoying but probably hard to work around (and leave my above logout functionality). So, I get in and see all of the kernel boot messages. As soon as the kernel spawns init (the change from bold to normal video on a CRT) the terminal server closes the connection. You can in fact jump right back in and see the other boot script messages (fsck, network config, etc). You end up right back at the login prompt. It is the getting kicked out between the kerkel and init starting that is bothering me. Something is changing the serial port settings at that time in a bad way. This is a fairly minor problem, but since it works so well "out of the box" with the default Cisco parts, it seems we should be able to make it work 100%. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 05:49:56PM -0700, Lyndon Nerenberg wrote: > > No dammit, tell your stupid serial console device thingy to ignore > > carrier detection :P > > Or just wire CD to DTR on the offending device. For reference, I'm 96% sure the problem in this case is the termainal server paying attention to DTR, I believe the way it's configured now it ignores CD. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 04:16:07PM -0800, John Baldwin wrote: > Yes, that's what most of us do. :) ~. in tip/cu isn't but so bad, and > ^E c . in conserver is fairly quick. No no no. We need to improve the system! :) I did some digging. init does nothing with the terminals, and although I didn't look I'm going to assume the kernel doesn't given when it's happening (would happen after the serial port probe, if the kernel was initializing wrong). So that leaves getty. I'm a bit confused here, but it appears getty (for the console) looks like this: initialize to getty defaults initialize to configured values (from gettytab) log in user I believe the problem is occuring with the initalize to defaults. I think that's causing the port to lower DTR, and hang up the session, then it gets the gettytab values and is good to go again. I'm not sure if the defaults are needed for some reason (there are a lot of oddball terminals out there), but I find it likely the right thing to do is a single init, that is: get default values merge in configured values (from gettytab) init with default+merged values getty is a bit, well, cryptic to someone who doesn't normally write terminal code, is there a getty expert in the house? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 04:08:48PM -0800, Alfred Perlstein wrote: > No dammit, tell your stupid serial console device thingy to ignore > carrier detection :P But then when I log out I'll have to disconnect separately. :-) I want to have my cake and eat it too! -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 02:23:22PM -0800, John Baldwin wrote:
> > Setting nohup means that when I log out it won't hangup though,
> > right? I like that behavior, what I don't like is the hangup on
> > the switch from kernel mode to {single,multi}-user mode.
>
> You can't have your cake and eat it, too. Pick one or the other. :)
Of course I can, I have the source! :-)
What confuses me is I thought the hup/nohup was a function of the
shell exiting, but it seems to be a function of init/getty (which
is why it happens when init starts).
Even if it's a part of init, it looks like it would be relatively
simple to tell it not to send the hup the very first time, regardless
of the config which would fix my problem.
Is that an unreasonable behavior? I want to make sure I'm going down
the right road, before I dig in code to patch/fix it. :-)
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: serial console + boot blip
In a message written on Thu, Jan 10, 2002 at 12:47:44PM -0800, John Baldwin wrote:
> > As as aside, I'm also thinking it might be useful to have a prompt
> > at that point (on serial console anyway) asking if you want to go
> > into single user mode, since you don't get to select that earlier
> > with a serial console.
>
> Sure you can. Interrupt the loader and do 'boot -s' just like you would on a
> video console.
Ok, maybe I'm just not getting in soon enough to see that then,
due to it not letting me in until DTR is high.
> > Have others noticed this behavior? Does anyone know a way to
> > work around it? Does some init genuis know why this happens?
>
> I have not had this behavior before, but as Alfred mentioned, I do use nohup on
> my terminals.
Setting nohup means that when I log out it won't hangup though,
right? I like that behavior, what I don't like is the hangup on
the switch from kernel mode to {single,multi}-user mode.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
serial console + boot blip
I have a few machines configured for serial consoles (my first), and have found an oddity. Basically I did the "-P" boot.config thing, and the 'set console=comconsole' in loader.rc. This works fine. I then run a getty on the 'console' in ttys. When connected to a Cisco terminal server, all works well. I telnet to the port, get the serial console, can log in. Most importantly for the problem below when I log out the terminal server automatically drops the telnet connection. I believe this is due to DTR going down after the shell exits, but I'm not positive so it may be some other control signal. Anyway, to the problem. This creates two issues, one I can live with, one I want to fix. 1) If the machine is off, you can't open a telnet connection (no DTR high, I believe). So, when someone first turns it on you have to log in quickly, and miss the first few lines of boot. I can live with this. 2) Once you get in while it's booting, you can watch the boot message. However, when the kernel messages are done and the scripts start (eg, the change from bold to regular on a normal CRT) the connection is closed. It looks like init starting resets the serial port in a way that makes it die again. This is what I would like to fix. As as aside, I'm also thinking it might be useful to have a prompt at that point (on serial console anyway) asking if you want to go into single user mode, since you don't get to select that earlier with a serial console. Have others noticed this behavior? Does anyone know a way to work around it? Does some init genuis know why this happens? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Overriding ARG_MAX
Ok, there are several issues here that I just have to point out. :-)
In a message written on Sat, Jan 05, 2002 at 09:48:40PM +0100, Oliver Fromme wrote:
> ls | grep '\.out$' | wc -l
One process shorter: find -name "*.out" -maxdepth 0 | wc -l
> ls | grep '\.data$' | xargs grep something
Two problems, first use find, second use /dev/null:
find -name "*.data" -maxdepth 0 | xargs grep something /dev/null
> ls | grep '\.foo$' | xargs cat | grep somethingA
A completely unnecessary use of cat.
One of the often missed things is the use of /dev/null on grep in
this case. If you grep a single file ("grep string file") then it
prints the matches. If you grep multiple files ("grep string file1
file2") it prints the matches with the file name prepended.
When using xargs, if the number of things to search results in just
one being left for the last call to grep you will get all of your
results prepended with the file name, except for the last file
which will be just the results. Adding /dev/null insures grep
always has 2 or more files.
Another fix would be:
find -name "*.data" -maxdepth 0 | xargs grep -H something
I don't believe old grep's had -H though, which is where the /dev/null
trick came from.
In any event, using find is much better, not so much for this example,
but because it allows you to do things like check permissions in a
portable way:
find -name "*.data" -perm 444 | xargs grep -H something
You can't do that with ls | grep, since only the filenames make it
to grep.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
In a message written on Sat, Jan 05, 2002 at 01:14:24AM +0100, Rogier R. Mulhuijzen wrote: > >I suppose so, but then you won't be able to connect to machines with > >miniscule path MTU's, and that should definately be a warning. But then > >it beats Linux which allows the path MTU to be reduced to 69 bytes (ouch!). > > Ouch indeed. Well default would be what we have now, but you'd be able to > tune it. The way I see it is that the attack would be most common on the > internet, and minuscule MTUs would most probably occur in specialistic > environments. Admins of potential targets would raise the minimum to a nice > value (say 512 or 1024), and print a message when something requests > something below this minimum, for troubleshooting ease. Or maybe a soft > limit and a hard limit. Soft limit triggers a message, hard limit is > enforced. ftp://ftp.isi.edu/in-notes/rfc791.txt ]Every internet module must be able to forward a datagram of 68 ]octets without further fragmentation. This is because an internet ]header may be up to 60 octets, and the minimum fragment is 8 octets. And ]Every internet destination must be able to receive a datagram of 576 ]octets either in one piece or in fragments to be reassembled. Not as good as I hoped. So, it would seem the roadmap would look something like this: 1) Insure FreeBSD won't allow an MTU < 68 bytes ever. (ifconfig, icmp mtu messages, anything) 2) Implement a warning if the MTU is set smaller than some minimum value (perhaps 576 for the global internet) if admins which to see such things. 3) Allow admins to enforce a higher minimum size for servers in attack situations, knowing this violates the RFC. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 04:03:35PM -0800, William Carrel wrote: > RFC 879 (http://www.rfc.net/rfc879.html) would tend to disagree... > > (10) Gateways must be prepared to fragment datagrams to fit into the > packets of the next network, even if it smaller than 576 octets. Hmm, I'd swear there was a defined minimum, I may have the wrong one. For reference, it appears Cisco IOS based devices won't allow MTU smaller than 128 to be configured. I have no idea if that's based on some standard. It seems like there should be a minimum global standard. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
In a message written on Sat, Jan 05, 2002 at 01:14:45AM +0100, Rogier R. Mulhuijzen wrote: > If we're on the internet yes. If you're in an environment other than one > connected to the internet (do those even exist ) no. > Hence my tuneable sysctl idea. I'll support a sysctl, however I'll also be quite insistant that our defaults match the Internet. I'm fairly sure more FreeBSD boxes are connected to the Internet than any other network. :-) -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 01:26:54PM -0800, William Carrel wrote: > See now you've made me curious, and I ask myself questions like: How > robust is PMTU-D against someone malicious who wants to make us send > tinygrams? Could the connection eventually be forced down to an MTU so > low that no actual data transfer could occur, or TCP frames with only > one byte of information? 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? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
In a message written on Fri, Jan 04, 2002 at 03:35:35PM -0800, Terry Lambert wrote: > Of course, now you've let the dirty little secret out of the > bag: the MTU is on the *route*, which means on the next hop, > so a spoof that got through would frag basically all traffic > out of the victim machine down to 296 bytes... I might be assuming something here, but I want to clarify. It is _NOT_ the case that a box with say, only a default route, would limit _ALL_ TCP connections to the lowest returned MTU. The MTU is on the *route*, where *route* == the cloned route, correct? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD performing worse than Linux?
In a message written on Mon, Dec 31, 2001 at 02:44:42PM -0800, Matthew Dillon wrote: > * I never said the server was the problem. To the contrary, I've > been saying that the client is the problem.. USB ethernet is > broken, period. I think several people are trying to say the same thing off this point but not saying it the same way, so: * Hacking TCP (or pretty much anything else) is the _wrong_ solution to this problem. The solution is to "fix" USB ethernet and/or not use it. * Since this is a fairly well defined, easy to reproduce packet loss situation that TCP seems to not handle particularly well, it might be worth using it to investigate if there is a generic TCP improvment that could be made. Fair enough? -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail + auth + ssl + freebsd
In a message written on Wed, Dec 19, 2001 at 11:43:04PM -0500, Louis A. Mamakos wrote: > 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. This all seems to make sense, and mirrors the SSL web stuff fairly closely in steps, which only makes sense. >From another suggestion, on a FreeBSD-stable box: %sendmail -bv -d0.13 postmaster Version 8.11.6 Compiled with: MAP_REGEX LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS QUEUE SCANF SMTP STARTTLS TCPWRAPPERS USERDB XDEBUG So the STARTTLS is compiled into the base binary, add to that: %strings /usr/libexec/sendmail/sendmail | grep SSL | wc -l 56 And it would seem all the SSL bits are there, I think I will play with that. In a message written on Thu, Dec 20, 2001 at 01:58:53PM +, Dominic Mitchell wrote: > There are also details given in /etc/defaults/make.conf on my > 4.4-STABLE system, although that file appears to have gone from > current... > > # Setting the following variables modifies the build environment for > # sendmail and its related utilities. For example, SASL support can be > # added with settings such as: > # > # SENDMAIL_CFLAGS=-I/usr/local/include/sasl -DSASL > # SENDMAIL_LDFLAGS=-L/usr/local/lib > # SENDMAIL_LDADD=-lsasl It appears that this would enable SMTP AUTH with SASL. Are there any plans to make SASL be part of the base distribution so this could be made the default? I, for one, think it would be really cool if saying "sendmail="YES"" in /etc/rc.conf gave you a sendmail that could authenticate against the password file, and if you gave it a certificate do SSL. I think that would get a lot more people interested in both options. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: sendmail + auth + ssl + freebsd
In a message written on Thu, Dec 20, 2001 at 03:43:12AM +0100, Roger 'Rocky' Vetterberg wrote: > http://www.sendmail.org/~ca/email/auth.html I found that too, and I'm sure I could build it from scratch and make it work. My desire here is to make it work with the sendmail shipped with the base FreeBSD (if possible) for a number of reasons though. As I said before, it seems to have the SSL stuff in it, although I can't figure out how to activate it. I'm unsure about auth. Wanting to use something from the base distribution is also why I am uninterested in postfix, at this time. If I can't do it I might go to postfix. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
sendmail + auth + ssl + freebsd
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. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Thu, Dec 06, 2001 at 11:05:15AM -0500, Mike Silbersack wrote: > This discussion about shipping mulitple kernels is getting silly, as > nothing in this discussion has addressed why we need multiple kernels. As > of 4.4, nearly every important setting can be tuned through options in > loader.conf; I updated the tuning manpage to recognize this a few weeks > ago. Give it a look over, I think most everything can be done with those > settings. I'm not stuck on the idea of doing it with a kernel, using loader.conf is fine. I do think there are a number of relatively statically configured things (most of them dependant on maxusers by default) that loader.conf probably can't change now. Put generically, I want to see a way for users to have FreeBSD make better use of their hardware with at-most them having to select a single option of a menu of 4-5 choices. The guy who just bought a gig of ram because it came in a cracker jack box should be able to click the 'use an obscene amount of memory to make everything faster' button, without having to understand the 300+ things he could tune in a kernel, or loader.conf, or whereever else you can set things. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Thu, Dec 06, 2001 at 10:49:48AM -0500, Michael R. Wayne wrote: > There needs to be an >automatic< way to help the new user get a > better kernel on his box. Matt Dillon provided a man page, now > what's needed is a program (call it autotune) that looks at the > machine and, possibly after asking the user some questions about > proposed machine use, builds OPTIMIZED and generates changes for > system files (e.g. adding softupdates to /etc/fstab). Would it not be simple to create say, GENERIC-64M, GENERIC-128M, GENERIC-256M (or small medium large, or whatever), tune a number of critical parameters, and just ship them as part of /bin? Surely the code to have the installer check the sysctl for the amount of ram in the machine and hard link that one to /kernel would be trival, and at least give us something. Just by changing a few memory settings and making a "guess" about maxusers (and the cascade of changes that has) based on total RAM would be a crude but useful start. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Thu, Dec 06, 2001 at 06:23:31AM -0800, Terry Lambert wrote: > > I'd suggest our target should be a P-III 600 with around 256M of > > RAM as what Generic should be tuned for > > Can't. The static allocations for that much assumed RAM would > result in the machine not booting, with the amount of RAM for > the page tables alone ~1/4M. By default, the 120M KVA space > mappings are arguably overlarge for small memory machines. Would result in what machines not booting? As long as a 64M PC can boot (even if it has only 10 Meg free for user apps) that's ok in my book. If we're still trying to boot on 4, 8, or 16 meg machines that's just dumb. As I've said before, there are two types of FreeBSD users. There are "users", who want something to replace windows and who really like the Linux distro's with KDE and all that. These people are unlikely to build a kernel, and as time goes by are even less likely to know what a kernel is. They are also likely to have a < 3 year old PC, probably that they are dual booting. Linux recognized this, and targest this sort of hardware out-of-the-box. The second type of user is someone like you, or me, or most of the people on this list. They will build a custom kernel no matter how appropriate the default settings. They will tune things for odd application boxes, like IRC and News servers and the like. The defaults are virtually irrevelant for these people, provided sysinstall can finish. As far as I'm concerned any machine with < 64M these days falls into the second catagory, where someone should have to futz with it to make it work. When 256M DIMMs are $18 we need to get with the program. This is one area where Microsoft got it right. Worrying about the hardware isn't worth your time. It will continue to grow at moores law, making the bloat unimportant. Target what's being sold now, as if you target last years computers by the time your OS is on them next year they will be retired. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 10:15:30PM -0800, Terry Lambert wrote: > > and ordinary user will find FreeBSD is slower, could we let user to > > select which kernel to install at installing time? > > It's a possibility that I've considered, given that sysinstall > had a hard time supporting installing FreeBSD from a single CDROM > image to support both developers and the end product with a single > "golden" system image. > > The problem with doing this is that it sort of grates against the > idea of a "GENERIC" entirely. The problem with GENERIC is it is the lowest common denominator. While it's really cool we can still boot on a 386 with 4 meg of RAM, making the compromises to make that happen is not terribly useful. GENERIC should be tuned _above_ the median PC, because after it's out PC's will continue to be upgraded. If we want to retain the (easy) ability to boot on a 4 meg machine we can supply a second MICRO-GENERIC. For some random thoughts, MAXMEM should be 256M minimum, 1G preferably. MAXUSERS should be perhaps 128 or 256 out of the box. I'd suggest our target should be a P-III 600 with around 256M of RAM as what Generic should be tuned for -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Wed, Dec 05, 2001 at 03:12:29PM -0800, Crist J . Clark wrote: > 4.5-RELEASE is only a month and a half away. By the time this "while" > passes, we'll be there. If people have lived this long with the bugs, > they can last until late January. I find it hard to argue with that. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Can TCP changes be put in RELENG_4?
On Tue, Dec 04, 2001 at 11:48:52AM -0500, Jim Durham wrote: > I know that only security fixes are supposed to go in RELENG_4, but > the recent changes in the TCP stuff seem important enough that > perhaps they could be put in RELENG_4 for those of us who run > productions servers on -RELEASE ? After reading the replies a bit, I'm going to suggest some middle ground. I think the changes should sit in stable for "a while", and while they are there we should make notes of it in a few different places and have people beat up on the changes with various tests. I think this is very good stuff, and that most of the people tracking RELENG4_4 would want it, but only if it is 210% fully tested and helps out 99.999% of all people. So let's verify both of those and then revisit the issue. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
random + large IRQ's + SMP
It appears there was a bug documented in http://lists.openresources.com/FreeBSD/freebsd-smp/msg00503.html where FreeBSD wouldn't allow IRQ's greater than 16, which SMP machines can have. I suddenly have several machines on 4.2-RELEASE showing this problem. What I need to know is when this was fixed (assuming it was). I tried to look through i386/i386/mem.c, per the messages to find the fix, but somewhere between when that message was posted and now random (and a few other things) were ripped out of there and scattered across several machine independant files. If someone knows when it was fixed, or could just point me to the right file to hunt in it would be a huge help. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP Performance Graphs
On Tue, Dec 04, 2001 at 12:48:45PM +0100, Nicolas Souchu wrote:
> Question, what is RTT? The subject seems interesting but without the
> background... :)
Round Trip Time. The time it takes for a segment to travel to the
destination, be processed, and an ack returned.
--
Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - [EMAIL PROTECTED], www.tmbg.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP Performance Graphs
On Fri, Nov 30, 2001 at 05:48:16PM -0800, Luigi Rizzo wrote: > On Fri, Nov 30, 2001 at 08:39:05PM -0500, Leo Bicknell wrote: > > Note that if we implement a 'fair share' buffering scheme we would > > never get a failure, which would be a good thing. Unfortuantely > > fair share is relatively complicated. > > i don't get this. There is no relation among the max number > of mbufs and their potential consumers, such as network interfaces, > sockets, dummynet pipes, and others. And so it is unavoidable > that even giving 1 mbuf each, you'll eventually fail an allocation. Well, this is true. If the number of sockets exceeds the number of MBUF's you will run out, no matter how well you allocate them. A corner case that should be handled delicately, no doubt, but one much less likely to happen. If each client was limited to one, or even two MBUF's total throughput would be so slow that the admin of the box would notice. That, added to that fact that there are thousands of MBUF's by default makes it nearly impossible that the "ignorant sysadmin" (aka desktop it should just work user) would run into this case. So, I will rephrase. I think a fair-share scheme would solve this for at least 5 9's of the problem. > But note that what you say about bad failures is not really true. > Many pieces of the kernel now are pretty robust in the face of > failures -- certainly dummynet pipes, and the "sis" and "dc" drivers I'm my 'bad failures' is not so much that the box would crash or otherwise completely break itself. Rather my experience with exhausing MBUF's is that you can experience a sort of "capture" situation, where one or more busy connections can essentially starve out inactive connections. Those inactive connections may well be your ssh session where you're trying to fix it. Network performance when MBUF's are exhausted is eratic at best, and at worst completely stopped for a large number of processes on the system today. The nasty QoS word popped up when we talked about this before, that a QoS scheme could insure some connections go MBUF's, or even if there were more connections than MBUF's insure that connections got two at a time in a 'round robin' fashion or some other sheme to keep everything moving. If I could redesign buffering (from a TCP point of view) from the ground up I would: - Make the buffer size dymanic. Perhaps not at interrupt, but in a "unified vm" network should be able to take resources if it is active. - Make the buffers dynamically track individual connections. - Implement a fair-share mechanism. - Provide instrumentation to track when connections are slowed for lack of MBUF's. - Provide tuning parameters and maybe QoS parameters to be able to manage total buffer usage, individual connection buffer usage, and connection priorities. -- Leo Bicknell - [EMAIL PROTECTED] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
