Re: sis900 : sis0 attach returned 6
Matt, It looks like the 8201L PHY was first supported in 4.6-RELEASE, but the PR wasn't updated to reflect this. Guido, if possible, could you try with 4.6.2-RELEASE and see if your card gets detected? I am running 'FreeBSD 4.6.2-RELEASE #0: Wed Aug 14 21:23:26 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC' This is the only version I tried up to now. -- Guido Van Hoecke [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes: I also have a partition with freebsd-current from two or three days ago, and all the latest versions of the ports. Every time I try to start vmware2 on the newer system, the hardware dies. Sometimes it automatically reboots, other times it freezes up and I have to force-reboot it (sometimes by unplugging it from the wall). See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
I have found that if you create a jail in FreeBSD 4.6.2, and then log into that jail ... if you are root you can scp and ssh just fine. However if you are not root and you attempt to ssh or scp, you get this error: PRNG is not seeded Hmmm. A few details - first, I created my jail by simply using the dump command to dump my / filesystem, and then restoring that inside the jail. Not elegant, but it works - so the jail in question has a full /dev and everything. Second, I used the exact same method in 4.6.1 and did not have problems. I saw a usenet post that recommended solving the problem with this: chmod a+r /dev/*rand* You seem to be on the right track in assuming it is a /dev/[u]random problem. Can you confirm this by (as a pleb user) dumping some random output? $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C (and same for /dev/urandom). Please also give a ls -l /dev/*random. however I tried that, and now when I try to ssh or scp from a non root user inside the jail, I get: Host key verification failed Does anyone know why this happens, why it didn't happen prior to 4.6.2, and how I can fix it ? The random device has not changed, but the OpenSSL code has. Maybe OpenSSL's internal PRNG is doing something naughty. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. True, it won't fix the problems you reported with raw disks, but it stops vmware from instantly panicking on recent -currents and that is the first problem you will encounter with the port. I tend to run vmware either diskless or with virtual disks, so I wouldn't notice the raw disk issues. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Mark Santcroos wrote: I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. You are right. The quick and dirty hack I had in mind was less quick and more dirty than I expected ;-) What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, reads of raw disks using an unbuffered linux_read() might be sector size times slower than they should be. You are right. The quick and dirty hack I had in mind was less quick and more dirty than I expected ;-) What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) It's well documented in the mail-archives actually. The short story: 1. We don't in general assign a special vnode type to device modes, instead we assign multiple device nodes, SCSI tapes is an example of this. 2. The vnode layer already have enough trouble aliasing /dev/fd0, /mnt/dev/fd0, /usr/jail/dev/fd0, /cdrom/dev/fd0 (you get the idea), we do not need to make it even harder by also aliasing /dev/fd0 and /dev/rfd0. 3. Write ordering on buffered devices were unspecified. In other words, you cannot use it for anything which even remotely smells of transactions, because you have no way to know when your writes have hit the disk and in which order they did so. 4. No write errors were reported back to userland. (Given 3 and 4, it follows that use of block devices for any sort of data you happen to like is a very bad idea.) 5. Block devices was in the way of getting DEVFS working in an architecturally sane manner. So they were removed, and good riddance. If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
inet_aton() Bug or feature?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello freebsd-hackers, Recently i spent almost two hours trying to find error in my several shell and perl sripts. These scripts are to process large list of ip addresses stored in text file and do some stuff with boxes with given addresses on my local network. Result: scripts was correct, problem was with some standard utilities such as ping and arp which has been called from my script. To my great surprise I found out that: ping 192.168.0.26, ping 192.168.0.032, and even ping 192.168.0.0x1a - all correct commands doing the same thing: pinging 192.168.0.26. That was my problem. IP addresses was stored in text file in the form of 192.168.000.032, and after issuing command: arp - -s 192.168.000.032 xx:xx:xx:xx:xx:xx (which actually was treated as arp -s 192.168.0.26) I had a great headache. After some investigation I found that both ping and arp use inet_aton() libc call to interpret their command arguments intonetworkformat.Futher,inet_aton()uses strtoul(c,endptr, 0) for each octet in IP address to convert string representation of number to unsigned long. Why not to use strtoul(x, x, 10) and fix aforementioned confusing thing with arp/ping/...? Does anybody write command arguments to ping using octal or hex format :)? I am not hacker. Just curious. - -- Best regards, Artem mailto:[EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.0 (MingW32) iD8DBQE9nD92bOuJ0KL1C+MRAgTDAJ4uMLZV3KuX0nwO+GtOPFhA6Jn+mgCeKJu4 wjt97cct6tAwV1iu5TYJORE= =Imv8 -END PGP SIGNATURE- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Need a former MaxAttach/creativedesign.com FreeBSD hacker
A company I am working fo has a problem with a FreeBSD-based 19 NFS server called MaxAttach 4000. We need to fiddle with their apparently home-grown striping/mirroring system and I would like to talk to somebody who knows something about this. Thanks Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mark Santcroos writes: On Thu, Oct 03, 2002 at 09:50:45PM +1000, Bruce Evans wrote: Unbreaking block devices would be a better solution. Without buffering, ... What was the reason for the removal of block devices anyway? It would be nice if you would tell me some background about that.. :) It's well documented in the mail-archives actually. The short story: Shorter story: phk didn't like them. 1. We don't in general assign a special vnode type to device modes, instead we assign multiple device nodes, SCSI tapes is an example of this. 2. The vnode layer already have enough trouble aliasing /dev/fd0, /mnt/dev/fd0, /usr/jail/dev/fd0, /cdrom/dev/fd0 (you get the idea), we do not need to make it even harder by also aliasing /dev/fd0 and /dev/rfd0. Aliases that differ in type are slightly easier to handle than aliases that differ by name or mount point. They are diferent devices so they have different vnodes, and the aliasing problems for them are quite different than the vnode aliasing problems caused by having the same device under different mount points. E.g., slices and partitions allow configuring 31*7 aliases per drive for hard drives (31 slices with 7 configuring partitions each). Slices and partitions may overlap, giving something more complicated than aliases. The vnode layer doesn't understand any of this. 3. Write ordering on buffered devices were unspecified. In other words, you cannot use it for anything which even remotely smells of transactions, because you have no way to know when your writes have hit the disk and in which order they did so. This is no different than for regular files. 4. No write errors were reported back to userland. Actually, write errors were reported at fsync() and close() time in the same way as for regular files. fsync()'s handling of write errors was broken for both regular files and buffered devices at the time buffered devices were axed. (Given 3 and 4, it follows that use of block devices for any sort of data you happen to like is a very bad idea.) It follos similarly that use of fil systems is a bad idea :-). You You should only use a databases on raw disks if you value your data. 5. Block devices was in the way of getting DEVFS working in an architecturally sane manner. This can be considered a feature. So they were removed, and good riddance. If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Bruce Evans writes: If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. And we're close to the point where it can happen... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
Ian Dowse wrote: In message p05111710b9c1484025de@[128.113.24.47], Garance A Drosihn writes: I also have a partition with freebsd-current from two or three days ago, and all the latest versions of the ports. Every time I try to start vmware2 on the newer system, the hardware dies. Sometimes it automatically reboots, other times it freezes up and I have to force-reboot it (sometimes by unplugging it from the wall). See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. you also might try to look at the patch in PR port/41784 http://www.freebsd.org/cgi/query-pr.cgi?pr=41784 i'm running vmware2 on my not so -current with the patch. if this is outdated feel free to close the PR. thanks, max To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
It was desired, and was sort of promised. I never understood why removal of block devices was allowed in the first place. phk's reasons don't seem strong enough to any unix wizard I have talked to. Did the majority of the core really think the change was warranted? Removing compatibility when the change _doesn't_ bring a *substantial* improvement doesn't seem right. How hard would it be to bring back block devices without GEOM? Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
At 10:11 AM +0200 10/3/02, Mark Santcroos wrote: On Thu, Oct 03, 2002 at 09:04:04AM +0100, Ian Dowse wrote: See the patch I posted in: http://www.FreeBSD.org/cgi/getmsg.cgi?fetch=0+6285+/usr/local/www/db/text/2002/freebsd-emulation/20020908.freebsd-emulation There may still be further issues, but it allowed me to use vmware2 on a current from a week or two ago. That's only for virtual disks, and that is not where the problem is (was). For most people this is not a solution. I have an almost-ready patch that implements linux_read() syscall. This will check if we are reading from a raw disk and in that case it will enlarge the read() to the next sector boundary. I have it working in the kernel but I have problems returning the right read buffer to userland. Hmm. I might not be any good for the raw-disk testing. All I use are virtual disks. (I have a 32-gig disk with a bunch of 2-gig virtual-disks on it. With that many systems, it's much easier for me to deal with files than a whole bunch of small partitions on the raw disk). The patch from Ian sounds like it would be interesting for me. I'll have to try that. It would be great if I could get back to regularly running an up-to-date current. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 09:37:07AM -0700, Bakul Shah wrote: Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Bakul, there's been ample discussion of what GEOM is in the last year. I suggest you read the list archives. Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37218/pgp0.pgp Description: PGP signature
Re: vmware reads disk on non-sector boundary
In message [EMAIL PROTECTED], Bakul Shah writes: I never understood why removal of block devices was allowed in the first place. You are welcome to peruse the mail-archives to find out such historically interesting decisions. You are not welcome to build another bikeshed over it. How hard would it be to bring back block devices without GEOM? Not at all hard, pretty trivial in fact. Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). Man 4 geom is a good place to start. There will also be a tutorial friday afternoon about GEOM at BSDCONeuro2002 in amsterdam next month. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Ok, here you are - as a normal user (non root) inside the jail, I have run: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C dd: /dev/stdout: Permission denied $ ls -asl /dev/stdout 0 crw--- 1 root wheel 22, 1 Sep 3 21:46 /dev/stdout All of this was _after_ I ran the `chmod a+r /dev/*rand*` command. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) I hope this is useful, and thank you for your help. I have found that if you create a jail in FreeBSD 4.6.2, and then log into that jail ... if you are root you can scp and ssh just fine. However if you are not root and you attempt to ssh or scp, you get this error: PRNG is not seeded Hmmm. A few details - first, I created my jail by simply using the dump command to dump my / filesystem, and then restoring that inside the jail. Not elegant, but it works - so the jail in question has a full /dev and everything. Second, I used the exact same method in 4.6.1 and did not have problems. I saw a usenet post that recommended solving the problem with this: chmod a+r /dev/*rand* You seem to be on the right track in assuming it is a /dev/[u]random problem. Can you confirm this by (as a pleb user) dumping some random output? $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C (and same for /dev/urandom). Please also give a ls -l /dev/*random. however I tried that, and now when I try to ssh or scp from a non root user inside the jail, I get: Host key verification failed Does anyone know why this happens, why it didn't happen prior to 4.6.2, and how I can fix it ? The random device has not changed, but the OpenSSL code has. Maybe OpenSSL's internal PRNG is doing something naughty. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
related jail topic - /dev/null often and regularly reverts permissions...
If you run a jail, and inside that jail is a /dev with the file /dev/null in it, the normal 0666 permissions of /dev/null will often get changed to 0600. I cannot see any reason why this would happen - I thought maybe there was something in /etc/rc that would do it, but there is not. Further, the reversions seem random and irregular - happens in some jails, doesn't in others. I have witnessed this on multiple jails in multiple different physical machines, on versions from 4.4 to 4.6.2. Anyone have any ideas why this happening ? Has anyone else seen this ? Perhaps /dev/null is not the only one this happens to, but just the most noticable one ? (many programs break when /dev/null is 0600) _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: related jail topic - /dev/null often and regularly reverts permissions...
Hi, I've experimented this when I've rebuilt my world just after the announce of 4.7-RC. mergemaster asked me if I wanted to run MAKEDEV since it had changed. I think it's this which broke up /dev/null, then i re-runed sh ./MAKEDEV and everything was fine :) I don't know if my second run of MAKEDEV solved the problem (maybe it was fixed before I run it again, I don't exactly know) -- Aurélien On Thu, Oct 03, 2002 at 12:25:15PM -0700, Firsto Lasto wrote: If you run a jail, and inside that jail is a /dev with the file /dev/null in it, the normal 0666 permissions of /dev/null will often get changed to 0600. I cannot see any reason why this would happen - I thought maybe there was something in /etc/rc that would do it, but there is not. Further, the reversions seem random and irregular - happens in some jails, doesn't in others. I have witnessed this on multiple jails in multiple different physical machines, on versions from 4.4 to 4.6.2. Anyone have any ideas why this happening ? Has anyone else seen this ? Perhaps /dev/null is not the only one this happens to, but just the most noticable one ? (many programs break when /dev/null is 0600) _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message msg37222/pgp0.pgp Description: PGP signature
FreeBSD Developer Status Report: July 2002 - August 2002
July - August 2002 Status Report Introduction Throughout July and August, the FreeBSD Project has been working on pulling together the last few major pieces of new functionality for FreeBSD 5.0-RELEASE. At this point, the release appears to be on track for late November or early December. Work on fine-grained locking continues, especially in the VFS, as with improved support for threading through the KSE work; features such as GEOM, UFS2, and TrustedBSD MAC are maturing, and the new ia64 and sparc64 hardware ports are approaching production quality. In the next two months, we have a lot to look forward to: additional 5.0 developer preview snapshots, additional locking and threading improvements, and many cleanups on the new supported architectures. Firewire support has been imported into the main tree, and substantial cleanup of the ACPI/legacy PCI code is also in the works. Also, expect the import of new IPsec hardware acceleration support in the near future. When new developer previews are posted, please give them a try! While we know that 5.0-RELEASE will be for early adopters, the more testing we get out of the way now, the less we have to tidy up later. The new features are extremely exciting, and understanding when and how to deploy them properly will be important. In the next two months, among other things, the release engineering team will post updated release schedules, as well as guidance for FreeBSD consumers as to how to decide what releases of FreeBSD will be right for them. Keep an eye out for this, and provide us with feedback. Also, for those of you in Europe -- we look forward to seeing you at BSDCon Europe in a couple of months! Scott Long, Robert Watson * Bluetooth stack for FreeBSD (Netgraph implementation) * ATAPI/CAM Status Report * BSDCon 2003 * Fast IPsec Status * FreeBSD C99 POSIX Conformance Project * FreeBSD Donations Team * FreeBSD GNOME Project * FreeBSD Security Officer Team * French FreeBSD Documentation Project * GEOM - generalized block storage manipulation * Hardware Crypto Support Status * jp.FreeBSD.org daily SNAPSHOTs project * jpman project * KSE * Libh Status Report * Lottery Scheduler for FreeBSD -STABLE * Netgraph ATM * Network interface cloning and modularity * New SCSI Target Emulator * RAIDFrame for FreeBSD * Release Engineering * The FreeBSD Brazilian Portuguese Documentation Project * TrustedBSD Mandatory Access Control (MAC) * UFS2 - 64bit UFS with native extended attributes * VM issues in -stable Bluetooth stack for FreeBSD (Netgraph implementation) URL: http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020909.tar.gz URL: http://bluez.sf.net Contact: Maksim Yevmenkin [EMAIL PROTECTED] I'm very pleased to announce that another engineering release is available for download at http://www.geocities.com/m_evmenkin/ngbt-fbsd-20020909.tar.gz This release features several major changes and includes support for H4 UART and H2 USB transport layers, Host Controller Interface (HCI), Link Layer Control and Adaptation Protocol (L2CAP) and Bluetooth sockets layer. It also comes with several user space utilities that can be used to configure and test Bluetooth devices. Also there are several man pages. Service Discovery Protocol (SDP) is now supported. This release includes SDP daemon, configuration tool and user space library (ported from BlueZ-sdp-0.7). RFCOMM is now supported. This release includes rfcommd daemon that provides RFCOMM service via pseudo ttys. Not very useful for legacy application, but it is possible to run PPP over Bluetooth now. This was ported from old BlueZ-rfcommd-1.1 (no longer supported by BlueZ) and still has some bugs in it. Next step is to fix current RFCOMM support and work on new in-kernel RFCOMM and BNEP (Bluetooth Network Encapsulation Protocol) implementation. Also user space need more work (better tools, libraries, documentation etc.). -- ATAPI/CAM Status Report URL: http://www.cuivre.fr.eu.org/~thomas/atapicam/ Contact: Thomas Quinot [EMAIL PROTECTED] The ATAPI/CAM module allows ATAPI devices (CD-ROM, CD-RW, DVD drives, floppy drives such as Iomega Zip, tape drives) to be accessed through the SCSI subsystem (CAM). ATAPI/CAM has been integrated in -CURRENT. The code should be fairly functional (it has been used by many testers as patches against -STABLE and -CURRENT over the past eight months), but there are pending issues on SMP machines. Testers most welcome. A MFC of this feature will probably happen after the end of the 4.7 code freeze.
Re: vmware reads disk on non-sector boundary
On Thu, 3 Oct 2002, Bakul Shah wrote: It was desired, and was sort of promised. I never understood why removal of block devices was allowed in the first place. phk's reasons don't seem strong enough to any unix wizard I have talked to. Did the majority of the core really think the change was warranted? Removing compatibility when the change _doesn't_ bring a *substantial* improvement doesn't seem right. He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. How hard would it be to bring back block devices without GEOM? Even WITH geom it would be possible. Is there a write up somewhere on what GEOM is and its benefits? I'd hate to see it become the default without understanding it (and no, reading source code doesn't do it). The concept is good. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Using devfs, one can export the 'top suface' of the stack as accessible devices. Theoretically the latyers can apply themselvces as a device is recognised and each layer type 'probes' the device to figure out it it belongs there. It's not rocket science as far as an idea goes. The trick is in the implementation. Locking and access control of parts gets quite tricky. for a similar idea look in the cvs tree for the now removed 'slice' code that did teh same thing. /sys/dev/slice It supported black and character device nodes for each partition. Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Developer Status Report: July 2002 - August 2002
I'd like to acknowledge the help of Scott Long in getting the report out this month--he did all that hard work :-). The next status report will cover September-October, 2002, and reports will be due around November 15. Depending on the 5.0 release process, we might slip it slightly. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Hi You only sent me a third of what I asked for :-) M Ok, here you are - as a normal user (non root) inside the jail, I have run: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C dd: /dev/stdout: Permission denied $ ls -asl /dev/stdout 0 crw--- 1 root wheel 22, 1 Sep 3 21:46 /dev/stdout All of this was _after_ I ran the `chmod a+r /dev/*rand*` command. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) I hope this is useful, and thank you for your help. I have found that if you create a jail in FreeBSD 4.6.2, and then log into that jail ... if you are root you can scp and ssh just fine. However if you are not root and you attempt to ssh or scp, you get this error: PRNG is not seeded Hmmm. A few details - first, I created my jail by simply using the dump command to dump my / filesystem, and then restoring that inside the jail. Not elegant, but it works - so the jail in question has a full /dev and everything. Second, I used the exact same method in 4.6.1 and did not have problems. I saw a usenet post that recommended solving the problem with this: chmod a+r /dev/*rand* You seem to be on the right track in assuming it is a /dev/[u]random problem. Can you confirm this by (as a pleb user) dumping some random output? $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C (and same for /dev/urandom). Please also give a ls -l /dev/*random. however I tried that, and now when I try to ssh or scp from a non root user inside the jail, I get: Host key verification failed Does anyone know why this happens, why it didn't happen prior to 4.6.2, and how I can fix it ? The random device has not changed, but the OpenSSL code has. Maybe OpenSSL's internal PRNG is doing something naughty. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inet_aton() Bug or feature?
On Thu, Oct 03, 2002 at 04:00:26PM +0300, Artem Okounev wrote: To my great surprise I found out that: ping 192.168.0.26, ping 192.168.0.032, and even ping 192.168.0.0x1a - all correct commands doing the same thing: pinging 192.168.0.26. Yep. That was my problem. IP addresses was stored in text file in the form of 192.168.000.032, and after issuing command: arp - -s 192.168.000.032 xx:xx:xx:xx:xx:xx (which actually was treated as arp -s 192.168.0.26) I had a great headache. That should be pretty easy to fix in your script. After some investigation I found that both ping and arp use inet_aton() libc call to interpret their command arguments intonetworkformat.Futher,inet_aton()uses strtoul(c,endptr, 0) for each octet in IP address to convert string representation of number to unsigned long. Why not to use strtoul(x, x, 10) and fix aforementioned confusing thing with arp/ping/...? Does anybody write command arguments to ping using octal or hex format :)? I am not hacker. Just curious. 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). People use this notation all of the time, # ifconfig if0 172.16.1.10 netmask 0xff00 ^^ -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Developer Status Report: July 2002 - August 2002
On 2002-10-03 15:38 -0400, Robert Watson [EMAIL PROTECTED] wrote: July - August 2002 Status Report -- FreeBSD Security Officer Team URL: http://www.freebsd.org/security/ Contact: Jacques Vidrine [EMAIL PROTECTED] In September, the FreeBSD Security Officer published a new PGP key (ID 0xCA6CDFB2, found on the FTP site and in the Handbook). This aligned the set of those who possess the corresponding private key with the membership of the security-officer alias published on the FreeBSD Security web site. It also worked around an issue with the deprecated PGP key being found corrupted on some public key servers. The key in the published handbook remains: pub 1024R/73D288A5 1996-04-22 FreeBSD Security Officer [EMAIL PROTECTED] This was verified from the www copy of the handbook as well as the FTP site. The key is also unavailable from pgpkeys.mit.edu. Where can I get this new key? -- Gregory S. Sutter Heisenberg might have been here. mailto:[EMAIL PROTECTED] http://www.zer0.org/~gsutter/ hkp://wwwkeys.pgp.net/0x845DFEDD msg37228/pgp0.pgp Description: PGP signature
Re: related jail topic - /dev/null often and regularly reverts permissions...
Well, what I am seeing is the /dev/null changing permissions _after_ the build/installation of the jail. That is, either it is changing at some random time while the jail is running, or it changes after the jail is stopped, then started again. And it happens over and over, that is, if I reset it to 0666, at some time in the future it will revert to 0600 Any idea why ? Hi, I've experimented this when I've rebuilt my world just after the announce of 4.7-RC. mergemaster asked me if I wanted to run MAKEDEV since it had changed. I think it's this which broke up /dev/null, then i re-runed sh ./MAKEDEV and everything was fine :) I don't know if my second run of MAKEDEV solved the problem (maybe it was fixed before I run it again, I don't exactly know) -- Aurélien On Thu, Oct 03, 2002 at 12:25:15PM -0700, Firsto Lasto wrote: If you run a jail, and inside that jail is a /dev with the file /dev/null in it, the normal 0666 permissions of /dev/null will often get changed to 0600. I cannot see any reason why this would happen - I thought maybe there was something in /etc/rc that would do it, but there is not. Further, the reversions seem random and irregular - happens in some jails, doesn't in others. I have witnessed this on multiple jails in multiple different physical machines, on versions from 4.4 to 4.6.2. Anyone have any ideas why this happening ? Has anyone else seen this ? Perhaps /dev/null is not the only one this happens to, but just the most noticable one ? (many programs break when /dev/null is 0600) _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message attach3 _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Sorry, here is the rest:
Here is the output of the `dd` command using urandom:
dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6
|.i.|.2.!.z3.h...|
512 bytes transferred in 0.000472 secs (1084588 bytes/sec)
0010 31 73 32 99 d1 4b ce 64 06 da b3 85 d9 e2 e6 a5
|1s2..K.d|
0020 fe 75 b6 f8 0b 4a 81 fd ae 0c d6 27 4a bd 34 69
|.u...J.'J.4i|
0030 bf bb 3a 71 af 01 61 c4 88 86 e3 8b 2a 0c 8a a7
|..:q..a.*...|
0040 35 57 d5 3b ec fc ac 55 9d 52 8b b8 4d 54 ff 95
|5W.;...U.R..MT..|
0050 7b 92 e0 ef c8 70 f5 07 73 5a a1 8f b5 09 72 3a
|{p..sZr:|
0060 7d 56 f6 69 bb 07 18 d1 24 d8 ba ce f7 b1 5c f6
|}V.i$.\.|
0070 ff a6 56 8e 44 cd 07 0f e3 2a 34 d1 b5 ed e7 54
|..V.D*4T|
0080 cb 0c 7e dd 69 82 20 e5 b8 58 c7 4c d1 64 a1 8d |..~.i.
..X.L.d..|
0090 4d bf df 57 bb 8c d2 06 a2 05 93 e5 ce 3f 0f 8e
|M..W.?..|
00a0 b2 74 97 d9 a7 53 b0 a4 d2 85 dc f9 16 82 5c 21
|.t...S\!|
00b0 61 ec 2f 72 89 13 37 bf 2d b0 f0 4d 29 da 95 03
|a./r..7.-..M)...|
00c0 87 ba 51 57 05 cd d3 d4 96 23 4c de 50 70 8c 73
|..QW.#L.Pp.s|
00d0 cc 92 4a 12 f6 aa eb 71 62 8c af de 7f a5 f7 14
|..Jqb...|
00e0 c9 c2 87 a4 37 a5 ec e7 e0 49 6b c2 9e b5 61 14
|7Ik...a.|
00f0 68 d5 94 67 fa 53 8b 9d 40 b7 b5 af ae 13 c4 5b
|h..g.S..@..[|
0100 ad bc 32 bd bb 3c 8f 17 5e 3d fc f8 88 35 25 34
|..2^=...5%4|
0110 9f 88 4f ec e5 04 77 f6 f7 da 72 6b 25 fd 0c 4e
|..O...w...rk%..N|
0120 26 3f d7 00 1d 33 cb 0b b1 3d 6d da 49 99 5d 2f
|?...3...=m.I.]/|
0130 89 07 12 9e 5d 9c 56 78 f6 e6 0d b3 96 36 05 d0
|].Vx.6..|
0140 1e 12 11 71 1c aa 35 f7 95 aa ab de a4 34 5d 31
|...q..5..4]1|
0150 21 8e f2 11 dc 56 90 68 a8 2d 1f 4c 18 53 81 79
|!V.h.-.L.S.y|
0160 fc 0d d3 97 85 79 99 47 70 0b 39 e3 7f 25 ee b4
|.y.Gp.9..%..|
0170 ad 87 0f 60 d7 f0 97 84 41 f5 3f 91 be 5b f2 5c
|...`A.?..[.\|
0180 8c b6 52 75 82 d3 ac e4 54 e3 b5 5f b6 6d b9 09
|..RuT.._.m..|
0190 58 02 47 62 c6 57 a7 7e c1 c0 78 63 81 11 f4 d8
|X.Gb.W.~..xc|
01a0 3c ee 9c 22 22 b2 31 88 64 fc 4f c5 9a e3 9f bb
|...1.d.O.|
01b0 20 d8 c9 12 34 40 6d 62 1c ac 96 c4 6f 10 d6 7b |
[EMAIL PROTECTED]{|
01c0 c9 c3 69 d4 e1 b6 3a 68 bd 65 3f 4e d1 b8 e4 c5
|..i...:h.e?N|
01d0 d5 3c 33 df 49 78 16 df 1d 76 72 9b 66 69 ac 82
|.3.Ix...vr.fi..|
01e0 6f e8 9c 35 43 5e 8a 62 17 6d 1a c0 c5 5e 4f c3
|o..5C^.b.m...^O.|
01f0 c7 dc 38 e6 b9 19 2e a1 68 66 c1 86 bb a4 8f f5
|..8.hf..|
0200
Again, this is after I chmodded /dev/stdout to 0666 instead of the 0600 that
it was.
And here is the ls output:
$ ls -l /dev/*rand*
crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random
crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom
thank you for your help.
Hi
You only sent me a third of what I asked for :-)
M
Ok, here you are - as a normal user (non root) inside the jail, I have
run:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
dd: /dev/stdout: Permission denied
$ ls -asl /dev/stdout
0 crw--- 1 root wheel 22, 1 Sep 3 21:46 /dev/stdout
All of this was _after_ I ran the `chmod a+r /dev/*rand*` command.
So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your
`dd`
command and got:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
0+0 records in
0+0 records out
0 bytes transferred in 0.36 secs (0 bytes/sec)
I hope this is useful, and thank you for your help.
I have found that if you create a jail in FreeBSD 4.6.2, and then
log
into
that jail ... if you are root you can scp and ssh just fine.
However if
you
are not root and you attempt to ssh or scp, you get this error:
PRNG is not seeded
Hmmm.
A few details - first, I created my jail by simply using the dump
command to
dump my / filesystem, and then restoring that inside the jail. Not
elegant,
but it works - so the jail in question has a full /dev and
everything.
Second, I used the exact same method in 4.6.1 and did not have
problems.
I saw a usenet post that recommended solving the problem with this:
chmod a+r /dev/*rand*
You seem to be on the right track in assuming it is a /dev/[u]random
problem.
Can you confirm this by (as a pleb user) dumping some random output?
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
(and same for /dev/urandom).
Please also give a ls -l /dev/*random.
however I tried that, and now when I try to ssh or scp from a non
root
user
inside the jail, I get:
Host key verification failed
Does anyone
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Sorry, here is the rest: Here is the output of the `dd` command using urandom: dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6 |.i.|.2.!.z3.h...| ... etc. Looking good. $ ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom Also good. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) Can you try a few of these while furiously abusing your keyboard? I'm trying to see if /dev/random can be persuaded to give _any_ aoutput at all. Maybe do it on a vty instead of in X. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
I can't seed it by banging on the keyboard - it is a headless server in a
rack thousands of miles from me :)
Perhaps there is another way to do it ?
Date: Thu, 03 Oct 2002 21:54:30 +0100
Sorry, here is the rest:
Here is the output of the `dd` command using urandom:
dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6
|.i.|.2.!.z3.h...|
... etc. Looking good.
$ ls -l /dev/*rand*
crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random
crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom
Also good.
So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your
`dd`
command and got:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
0+0 records in
0+0 records out
0 bytes transferred in 0.36 secs (0 bytes/sec)
Can you try a few of these while furiously abusing your keyboard?
I'm trying to see if /dev/random can be persuaded to give _any_
aoutput at all.
Maybe do it on a vty instead of in X.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Slow I/O responsiveness with UDMA133
On Mon, 30 Sep 2002, Sean Farley wrote: On Thu, 26 Sep 2002 21:14, Mike Silbersack wrote: Rumor has it that newer drives cannot write a single sector at a time, and instead must read a whole cluster of sectors, add in the new sector, and write back the whole cluster. That behavior sounds like it would hurt sequentual performance substantially, as it would become a lot of read-modify-write operations. That is interesting. I had not heard of that issue, even as a rumor, before. I see this hurting byte writes, but block writes may not be hurt by it. The concept isn't that ridiculous. If the drive cannot write 1 byte at a time, why should it be able to write 4096 bytes at a time, or 8192 bytes, etc. Unfortunately, I doubt that any drive manufacturer will tell us the exact figures. :) You would not happen to have a non-RAID, UDMA100+, non-VIA system that you could run bonnie++ (-s256) on? It would at least show to me if my system is really all that far from the norm. Sean Nope, not here. Maybe someone else on the list can send you results... Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
I can't seed it by banging on the keyboard - it is a headless server in a
rack thousands of miles from me :)
Perhaps there is another way to do it ?
Yes.
You need to find sources of entropy in interrupts. Look at a
dmesg, and note which IRQ's your network device(s) and mass
storage controller(s) (both SCSI and ATA). Use any other
irq's that aren't too busy and may be somewhat random.
Staring at a 'systat 2 -vmstat' screen (right hand side)
may give some clues.
Then use rndcontrol(8) to set up the seeding. There is a knob
in rc.conf to make this setting survive the next reboot.
M
Date: Thu, 03 Oct 2002 21:54:30 +0100
Sorry, here is the rest:
Here is the output of the `dd` command using urandom:
dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C
1+0 records in
1+0 records out
a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6
|.i.|.2.!.z3.h...|
... etc. Looking good.
$ ls -l /dev/*rand*
crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random
crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom
Also good.
So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your
`dd`
command and got:
$ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C
0+0 records in
0+0 records out
0 bytes transferred in 0.36 secs (0 bytes/sec)
Can you try a few of these while furiously abusing your keyboard?
I'm trying to see if /dev/random can be persuaded to give _any_
aoutput at all.
Maybe do it on a vty instead of in X.
M
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
_
Chat with friends online, try MSN Messenger: http://messenger.msn.com
--
o Mark Murray
\_
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: PRNG not seeded - error in non-root ssh inside 4.6.2 jails...
Ok, I am not sure how I can do that though - I cannot successfully run `rndcontrol -s X` inside a jail. On the other hand, I already have: rand_irqs=9 10 11 13 14 In my rc.conf on the underlying host machine, and have done several boots with that in place. So presumably I should be seeded just fine, but if I am not, I cannot change that in the jail because it seems I cannot set that (I assume it is a sysctl issue). Willing to try whatever you can think of next :) I can't seed it by banging on the keyboard - it is a headless server in a rack thousands of miles from me :) Perhaps there is another way to do it ? Yes. You need to find sources of entropy in interrupts. Look at a dmesg, and note which IRQ's your network device(s) and mass storage controller(s) (both SCSI and ATA). Use any other irq's that aren't too busy and may be somewhat random. Staring at a 'systat 2 -vmstat' screen (right hand side) may give some clues. Then use rndcontrol(8) to set up the seeding. There is a knob in rc.conf to make this setting survive the next reboot. M Date: Thu, 03 Oct 2002 21:54:30 +0100 Sorry, here is the rest: Here is the output of the `dd` command using urandom: dd if=/dev/urandom of=/dev/stdout bs=512 count=1 | hexdump -C 1+0 records in 1+0 records out a0 69 1a 7c 8f 32 e5 21 ae 7a 33 14 68 0b 8e a6 |.i.|.2.!.z3.h...| ... etc. Looking good. $ ls -l /dev/*rand* crw-r--r-- 1 root wheel2, 3 Sep 3 21:46 /dev/random crw-r--r-- 1 root wheel2, 4 Sep 3 21:46 /dev/urandom Also good. So then, as root I ran: `chmod 0666 /dev/stdout` and then I ran your `dd` command and got: $ dd if=/dev/random of=/dev/stdout bs=512 count=1 | hexdump -C 0+0 records in 0+0 records out 0 bytes transferred in 0.36 secs (0 bytes/sec) Can you try a few of these while furiously abusing your keyboard? I'm trying to see if /dev/random can be persuaded to give _any_ aoutput at all. Maybe do it on a vty instead of in X. M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn _ Send and receive Hotmail on your mobile device: http://mobile.msn.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Thu, Oct 03, 2002 at 05:57:56PM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Bruce Evans writes: If a buffered access-mode on block devices is desired, it should be implemented either as an ioctl controllable feature, or as a GEOM module. The latter is probably by far the easiest way. It was desired, and was sort of promised. And we're close to the point where it can happen... So 'ignoring' the historic facts, and assuming that we just want block devices, we can do such a thing in GEOM in the future? Is this something you will be doing yourself Poul, or is it just that you are saying that it is possible? If not, I really would like to help to get vmware back, but I don't know anything more about GEOM than option\t\tGEOM. Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
On Fri, Oct 04, 2002 at 12:53:52AM +0200, Mark Santcroos wrote: So 'ignoring' the historic facts, and assuming that we just want block devices, we can do such a thing in GEOM in the future? Is this something you will be doing yourself Poul, or is it just that you are saying that it is possible? If not, I really would like to help to get vmware back, but I don't know anything more about GEOM than option\t\tGEOM. There's a pretty good man page, man geom. Cheers, Joe -- As far as the laws of mathematics refer to reality, they are not certain; and as far as they are certain, they do not refer to reality. - Albert Einstein, 1921 msg37237/pgp0.pgp Description: PGP signature
breakage on zero copy send
__ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com 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: inet_aton() Bug or feature?
On Fri, 2002-10-04 at 11:08, Leo Bicknell wrote: 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. I would imagine this behaviour is like it is because that is how atoi and friends work.. All of this stuff was written by C programmers and it shows 8-) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inet_aton() Bug or feature?
On Thu, 3 Oct 2002, Leo Bicknell wrote: 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): It agrees with the SUS definition of inet_addr(), and inet_aton() should probably be consistent with that: http://www.opengroup.org/onlinepubs/007904975/functions/inet_addr.html Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: related jail topic - /dev/null often and regularly reverts permissions...
I use jails intensively, but never give a possibility for that type of changes. 2 ways: - chflags schg /path/to/jail/dev/* - mount -r /reduced_set_of_dev /path/to/jail/dev first for full featured jails and second for light weight jails. (actually I always mount dev in jail directory because of /path/to/jail is nodev mounted, but that is another story) Well, what I am seeing is the /dev/null changing permissions _after_ the build/installation of the jail. That is, either it is changing at some random time while the jail is running, or it changes after the jail is stopped, then started again. And it happens over and over, that is, if I reset it to 0666, at some time in the future it will revert to 0600 Any idea why ? Hi, I've experimented this when I've rebuilt my world just after the announce of 4.7-RC. mergemaster asked me if I wanted to run MAKEDEV since it had changed. I think it's this which broke up /dev/null, then i re-runed sh ./MAKEDEV and everything was fine :) I don't know if my second run of MAKEDEV solved the problem (maybe it was fixed before I run it again, I don't exactly know) -- Aurélien On Thu, Oct 03, 2002 at 12:25:15PM -0700, Firsto Lasto wrote: If you run a jail, and inside that jail is a /dev with the file /dev/null in it, the normal 0666 permissions of /dev/null will often get changed to 0600. I cannot see any reason why this would happen - I thought maybe there was something in /etc/rc that would do it, but there is not. Further, the reversions seem random and irregular - happens in some jails, doesn't in others. I have witnessed this on multiple jails in multiple different physical machines, on versions from 4.4 to 4.6.2. Anyone have any ideas why this happening ? Has anyone else seen this ? Perhaps /dev/null is not the only one this happens to, but just the most noticable one ? (many programs break when /dev/null is 0600) _ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message attach3 _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: vmware reads disk on non-sector boundary
phk writes: You are welcome to peruse the mail-archives to find out such historically interesting decisions. I am aware of the technical arguments discussed via -arch, -current -hackers. I just don't agree with them (seems like most hackers who are afraid to cross you). You are not welcome to build another bikeshed over it. If block devices are trivial to build with geom, they should've been not removed until geom was in place. Oh well. I am not going to argue about this over and over and over again. But I was hoping sanity would prevail (my hopes were raised with perl-5's removal and Julian Bruce piping up). Man 4 geom is a good place to start. Thanks. More on this in a separate email. There will also be a tutorial friday afternoon about GEOM at BSDCONeuro2002 in amsterdam next month. Too far to travel :-) Julian writes: He had some backing, for example Kirk made a good argument for removing them. The arguments about not being able to do devfs and geom without removing them are of course specious as it can and was done before by others. Hmm.. I don't recall Kirk McKusick's argument for removing a buffered block device. One provides a stacking system for disk geometries wand layouts where the upper interface is the same as that provided by the actual disk. Thanks! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
unsubscribe donbrearley@hccgwy.mnscu.edu
unsubscribe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
