Installing FreeBSD on a 20Gb disc on a laptop with old BIOS
Hi, I have an old IBM thinkpad 560 that I want to runt FreeBSD on. The original drive is only 2Gb so I upgraded to a 20Gb. Now it turned out that the BIOS was to old to support this and the laptop locked-up during the initialization phase before booting. DDO(Dynamic Drive Overlay) from OnTrack solved this since it tricks the BIOS to believe it has a much smaller drive. But It seems to trick FDISK in the FreeBSD installation as well. I have tried a lot of different ways to come around this but somehow I always end up with a non-working system :-( If I just install DDO on the drive and then start the FREEBSD installation FDISK thinks the drive starts at sector -63 and gets very confused. I solved this by letting the IBM Disk Manager, the software that I use to install DDO, to create a FAT partition in the beginning of the drive, only 100 MB. Now I can use the rest of the disk in FDISK to make it a FREEBSD partition, but it wont boot. Changing the first 100MB partition to FreeBSD type, does not help, the label editor cant use it, says Unable to create partition. Too big?. Anyone that have succesfully managed to install FreeBSD on a large drive that isnt supported by the BIOS and use the entire disk for FreeBSD? Any tips would be very welcome! Kalle To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: tx driver
Hi! I'd like to apologize for my cross-posting: if there is some following debate I'd like to move it to freebsd-hackers. the usual problem with this kind of performance with any driver is failed full/half duplex negotiation. Please try manually forcing your card to half or full duplex Add one of -mediaopt full-duplex or -mediaopt half-duplex depending on the setting of your switch to your ifconfig line in /etc/rc.conf This is the single most common cause of really low ethernet performance. I have had good experiences with the tx driver on 4.3 ond 4.4 releases. Well - this is the answer I got from almost everybody. My answer for this is: no, it's not about the duplex problems :-(. I should have describe those problems in more detailed way: - this is not general behavior: the card gets about 11,6 MBps throughput using netperf tests - this problem arises in quite obscure conditions: - either on routers (FreeBSD machine with this SMC card is acting as PC router) where the network load rises over certain values (but this is hard to simulate :-( ) - when I check out large CVS tree on my own machine with this card: the symptoms here are 1) rather fast start 2) then it gradually reduces speed (even much less than mentioned 200 kBps - it decreases to few kBps) 3) end up with overall run time more than 10x higher than it is on all other comparable machines :-( So - is there anybody experiencing similar problems? Best regards and thanks, Petr Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 2 Institute of Compt. Science 10200 Praha, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: [EMAIL PROTECTED] phone: +420-5-41512278 e-mail: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Processing IP options reveals IPSTEALH router
Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, 19 Dec 2001, Yar Tikhiy wrote: Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. -- Yar The fix looks good on the surface, but it probably should be tested before committing just to make sure. Mike Silby Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. PS I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. /PS Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
Hello Yar, On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote: On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. Good point! Indeed, just ignoring IP options would let a third party to identify a FreeBSD host as a stealthy router. I think it's safe to move doing IP options to after identifying an IP packet as destined for this or another host. I'll make a patch and show it here. PS I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. /PS In fact, IPSTEALTH does already have a sysctl knob: net.inet.ip.stealth, which is initially zero (i.e. don't be stealthy.) To my mind, the stealth name fits its purpose better since just leaving TTL untouched is insufficient for a router to achieve really stealthy behaviour. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? imho there are not. I've asked because ru's net.inet.ip.decttl means do not decrement TTL but not hide the fact of the routing. As for source routing, I believe a stealthy router should just drop such packets as though it were a host. Of course, source-routed packets destined for the router itself should be accepted. So there are three IPSTEALTH cases: 1/ the dst address is not ours, net.inet.ip.sourceroute=0, net.inet.ip.forwarding=1: process ip options by ip_dooptions(). 2/ the dst address is ours: process ip options by ip_dooptions(), 3/ in other cases do not process ip options. By the way, is it correct to forward the packet with incorrect ip options? Now we do not. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: On 19:49+0300, Dec 19, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? Are there any reasons for a router not to decrement IP TTL besides trying to stay invisible to a third party? imho there are not. I've asked because ru's net.inet.ip.decttl means do not decrement TTL but not hide the fact of the routing. Nope, my net.inet.ip.decttl is the decrementor, it may be 1 (by default), 0 (to hide this router), or 2, 3, etc. Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
init code in dynamic libraries
How can I add initalisation code to a library without needing to call a function in the using application? What I saw is that libc does something like this but havn't found the starting point of this. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
Given the amount of code that IPSTEALTH adds (only a few lines), eliminating it as a compile time option and making it a knob is a win. Also, I know that there is an issue for system using cards from ETinc: enabling IPSTEALTH causes them to panic. ETinc has taken the stand that this feature is not supported as it is not in the base release. I'd like to see that objection go away. /\/\ \/\/ On Wed, Dec 19, 2001 at 05:33:13PM +0200, Ruslan Ermilov wrote: On Wed, Dec 19, 2001 at 06:19:29PM +0300, Yar Tikhiy wrote: I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. What if the packet is directed to us? I think we should still process options in this case, and the patch in the PR doesn't seem to do it. PS I was going to replace IPSTEALTH functionality with the net.inet.ip.decttl knob. Setting it to 0 would match the IPSTEALTH behavior, the default value will be 1. /PS To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Enhancing the CS461x audio driver...
On Tuesday 18 December 2001 12:59, you wrote: Hi there, if you have docs that actually specify how to control the spdif output, send them to me and i'll include it in a future driver version. -cg Unfortunately it seems I jumped to soon over it, the PDFs available on the Cirrus site don't contain any info about SPDIF, but I recall that the linux driver they have on their did contain the register addresses in a .h file, although I've seen that the ALSA driver for my card (4624 actually) is not able to enable digital output. I've gone to the cirrus site but somehow can't figure out how to download the linux driver (that or maybe is their javascript playing nasty with opera) and don't remember where I did put the copy I downloaded some time ago, but I would swear there is info on the spdif registers in the linux driver, I'll try to download it from a *gasp* windows box laster this evening and will look at it. Yours, -- Miguel Mendez - [EMAIL PROTECTED] EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: init code in dynamic libraries
Bernd Walter wrote: How can I add initalisation code to a library without needing to call a function in the using application? What I saw is that libc does something like this but havn't found the starting point of this. There are two special functions for that : _init() which will be called when the object is loaded, and _fini() which will be called when it is released. Maxime -- Don't be fooled by cheap finnish imitations ; BSD is the One True Code To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
the crash screen usually after 4 to 13 days not good...
What happens is the network card on xl0 going to down and its light goes off on the hub and I get this crash address straight after. It's a 3Com 900TPO 10Mbps Usually it reboots but its locked this time with it on the screen Fatal trap 12: page fault while in kernel mode Fault virtual address = 0xb0 Fault code = supervisor read, page not present Instruction pointer = 0x8:0xc02d7507 Stack pointer = 0x10:0xc4f8ae50 Frame pointer = 0x10:0xc4f8ae84 Code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11999 (sh) interrupt mask = none trap number = 12 panic: page fault syncing disks... 10 done uptime: 2d18h27m28s when I reboot it I will be able to send this e-mail I hope:) any help is more than welcome Bri, To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: init code in dynamic libraries
On Wed, Dec 19, 2001 at 08:06:20PM +0100, Maxime Henrion wrote: Bernd Walter wrote: How can I add initalisation code to a library without needing to call a function in the using application? What I saw is that libc does something like this but havn't found the starting point of this. There are two special functions for that : _init() which will be called when the object is loaded, and _fini() which will be called when it is released. I can see that symbol defined in libc.so.5 but no reference in the libc source code. All I see are several *_init functions. Are they all called from within an autocreated _init function? If yes in which order? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 07:23:55PM +0300, Maxim Konovalov wrote: Hello Yar, On 18:19+0300, Dec 19, 2001, Yar Tikhiy wrote: Hi there, I ran into an absolutely clear, but year-old PR pointing out that a router in the IPSTEALTH mode will reveal itself when processing IP options: kern/23123. The fix proposed seems clean and right to me: don't do IP options at all when in the IPSTEALTH mode. Does anyone have objections? If no, I'll commit the fix. First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? I would assume IPSTEALTH is thought to be for firewalls. Allowing source routing thru firewalls is a Bad Thing(TM) anyway, right? -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
IP options (was: Processing IP options reveals IPSTEALH router)
On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: By the way, is it correct to forward the packet with incorrect ip options? Now we do not. No RFC seems to specify that particularly. However, RFC 1812 reads in general: (1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources. Meanwhile more IP option issues came to my attention... Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: if a source-routed IP packet reachs the end of its route, but its destination address doesn't match a current host/router, whether the packet should be discarded, sent forth through usual routing or accepted as destined for this host? FreeBSD will route such a packet as usual. Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with Source Route Failed ICMPs to source-routed IP packets if source route processing is prohibited using net.inet.ip.sourceroute or net.inet.ip.accept_sourceroute. To my mind, it may be deduced from RFC 1122 that a host must stay silent in this case... -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Wed, Dec 19, 2001 at 10:32:42PM +0100, Wilko Bulte wrote: First of all we should decide what IPSTEALTH is for. Is it just a Ruslan's net.inet.ip.decttl or it should really stealth the fact of the routing? If the latter how do we behave in source routing case? I would assume IPSTEALTH is thought to be for firewalls. Allowing source routing thru firewalls is a Bad Thing(TM) anyway, right? Source routing itself is a Bad Thing, as is TELNET or rlogin. However, this isn't a reason strong enough to drop all such stuff from FreeBSD completely. That's why we're trying to consider every possible case. IMHO increasing the number of FOO is incompatible with BAR situations is no good. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: IP options (was: Processing IP options reveals IPSTEALH router)
Morning, On 00:35+0300, Dec 20, 2001, Yar Tikhiy wrote: On Wed, Dec 19, 2001 at 08:54:50PM +0300, Maxim Konovalov wrote: By the way, is it correct to forward the packet with incorrect ip options? Now we do not. No RFC seems to specify that particularly. However, RFC 1812 reads in general: (1) A router MUST verify the IP header, as described in section [5.2.2], before performing any actions based on the contents of the header. This allows the router to detect and discard bad packets before the expenditure of other resources. Meanwhile more IP option issues came to my attention... Neither RFC 791 nor RFC 1122 nor RFC 1812 specify the following: if a source-routed IP packet reachs the end of its route, but its destination address doesn't match a current host/router, whether the packet should be discarded, sent forth through usual routing or accepted as destined for this host? FreeBSD will route such a packet as usual. Stevens, TCP Ill. vII, p.257 says: If the destination address of the packet does not match one of the local addresses and the option is a strict source routing (IPOPT_SSRR), an ICMP source route failure error is sent. If a local address isn't listed in the route, the previous system sent the packet to the wrong host. This isn't an error for a loose source route (IPOPT_LSRR); it means IP must forward the packet toward the destionation. That is what ip_input does near the line 1193. Then, a FreeBSD host (net.inet.ip.forwarding=0) will respond with Source Route Failed ICMPs to source-routed IP packets if source route processing is prohibited using net.inet.ip.sourceroute or net.inet.ip.accept_sourceroute. To my mind, it may be deduced from RFC 1122 that a host must stay silent in this case... -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: init code in dynamic libraries
Apparently, On Wed, Dec 19, 2001 at 09:46:46PM +0100, Bernd Walter said words to the effect of; On Wed, Dec 19, 2001 at 08:06:20PM +0100, Maxime Henrion wrote: Bernd Walter wrote: How can I add initalisation code to a library without needing to call a function in the using application? What I saw is that libc does something like this but havn't found the starting point of this. There are two special functions for that : _init() which will be called when the object is loaded, and _fini() which will be called when it is released. I can see that symbol defined in libc.so.5 but no reference in the libc source code. All I see are several *_init functions. Are they all called from within an autocreated _init function? If yes in which order? The _init and _fini functions call global constructors and destructors (in c++). There's a gcc extension for making a constructor in C, put __attribute__((constructor)) in the prototype. The dynamic linker will call them when it loads the library. I don't know if the order that they're called in is defined or not. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step )
In article [EMAIL PROTECTED], Sergey Babkin [EMAIL PROTECTED] writes By the way the journaling filesystems don't neccessary guarantee that you won't need fsck: for example, if VXFS crashes at a particularly bad moment, it will require you to do fsck -o full which is as slow as the fsck on traditional UFS. JFS still scores against traditional Unix file systems on large volumes, (e.g. Terabytes), as it requires very small amounts of virtual memory during a full fsck. ttfn, Tony To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Processing IP options reveals IPSTEALH router
On Thu, Dec 20, 2001 at 12:50:39AM +0300, Yar Tikhiy wrote: Source routing itself is a Bad Thing, as is TELNET or rlogin. Telnet with Kerberos or other security options can be a fine thing. -- Ben An art scene of delight I created this to be ... -- Sun Ra To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
nullfs and unionfs
[replies sent directly to me may timeout and bounce, since I'm not online as often as I should be, but I'll check the list archives] Hej Is it safe (relatively speaking) to use the null and the union filesystems? The LINT kernel config file still includes dire warnings, as do the man pages, but so far I've successfully mounted a handful of filesystems without panicking my system, though I've been careful to do it read-only when possible However, I have found a bug. What I'm trying to do is to share the FreeBSD system source on one disk with several OSen keeping it unchanged from how it gets updated by cvsup, but still make changes for building. I do this by keeping the actual source read-write for cvsup in /usr/local/system, which I then mount_null read-only on /usr/src. (Likewise ports and stuff) Over top of this nullfs /usr/src I mount read-write my own directory which gets my changes in /usr/local/source-hacks. (I also discovered to get both mounts to work in /etc/fstab I seem to need to specify the mountpoint differently, lest mount -t union -a fail to do anything, like /usr/local/system/src /usr/src null ro /usr/local/source-hacks /usr/src/ union rw ) ^ This gives a /usr/src that I seem to be able to play in, plus I can readily see every file I've changed by running `find' in /usr/local/source-hacks -type f. (There are logical issues concerning undoing my hacks when no longer needed, but I'll deal with that later somehow) The bug is that apparently when a union-mounted fs is mounted atop a null-mounted fs, `pwd' in subdirectories fails spectacularly. (Works fine in the mountpoint) dastardly# cd /usr/src dastardly# pwd /usr/src dastardly# cd sys dastardly# pwd pwd: .: No such file or directory (commands like `dirs' succeed) `ls -a' shows the `.' directory, of course. This also means that `make' does not want to work Hang on, this seems to be a csh/tcsh problem: bash-2.05a# cd /usr/src/ bash-2.05a# pwd /usr/src bash-2.05a# cd sys bash-2.05a# pwd /usr/src/sys bash-2.05a# sh # pwd /usr/src/sys # csh csh: No such file or directory csh: Trying to start from /root dastardly# Of course, `make' fails no matter what the shell du jour As far as I can remember, I had no similar problems in a normal union mount and null mounts have given me no problems. thanks barry bouwsma 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: sendmail + auth + ssl + freebsd
On Wed, Dec 19, 2001 at 09:26:54PM -0500, Leo Bicknell wrote: 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. Well, my first suggestion would be to use postfix. It's *very* easy to setup with SASL auth and SSL. It uses the Cyrus libraries and OpenSSL. Go out and use your favorite search engine. I just used google and turned up instructions on the sendmail.org site for configuring it to use the Cyrus SASL libs. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail + auth + ssl + freebsd
Leo Bicknell wrote: After searching the archives and looking at the source, I find myself more confused. I've been asked to set up sendmail + ssl + SMTP auth on a FreeBSD host. A quick strings on the sendmail binary shows a number of SSL functions, so I'm thinking the SSL bits are in there, but I'm not quite sure how to take advantage of them. Issuing AUTH to a stock -STABLE sendmail gets command unrecognized though, so I don't think that is there. If no one else has figured this mess out, I'll do it and write a page for the handbook. If someone else has, please clue me in, and if necessary I'll still write that handbook page. :-) It would be very nice if it was simple to make FreeBSD sendmail SSL and authenticate against the password file. I've managed to set it up to use AUTH, however I have not yet found the time to make it use SSL. The only usefull documentation I have been able to find is this one: http://www.sendmail.org/~ca/email/auth.html -- R 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
boot0/boot0.s
Hi. I'm reading the code /usr/src/sys/boot/i386/boot0/boot0.s. And i've found that the FreeBSD Boot Manager is really smart cool. But i've got some problems in this source code. I got puzzled from this line: cmpb cmpb NHRDRV,%al. I don't know what it's for and got no idea about the following code either. Could anyone give me hint a point? Or any resources where i could get more info? Thanks. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail + auth + ssl + freebsd
Try nroff -me /usr/src/contrib/sendmail/doc/op/op.me for a starting place. Jim Flowers - EZNets, Inc. [EMAIL PROTECTED] - Original Message - From: Leo Bicknell [EMAIL PROTECTED] To: Roger 'Rocky' Vetterberg [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, December 19, 2001 9:46 PM Subject: 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 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Re: boot0/boot0.s
Mike Smith has written If you're confused about what the code is doing there; it's comparing the number of hard drives in the system (stored in the BIOS data area at 0x475) with the drive number that's in al to verify whether the drive number is valid according to the BIOS. Thanks for your help, Mike. So stupid i am, i treated 0x475 as an immediate operand ! Now i know that's an address. The code is not very clear (being written for compactness), but if you are familiar with how PCs boot, it's pretty straightforward. I'm now learing the PCs boot procedure by reading boot0.s. So far as konw, after BIOS's POST, it would load the 512 byte of MBR to 0x7c00. And the code there would then make a copy of itself at 0x600 and then make a jump. But i've got no idea about the process _between_ the BIOS POST procedure and BIOS load MBR procedure. As you said, BIOS would save the number of hard drives at 0x475 in this 'between' procedure. And from the following code: .. ... # # Check what flags were loaded with us, specifically, Use a predefined Drive. # If what the bios gives us is bad, use the '0' in the block instead, as well. # main: testb $0x20,_FLAGS(%bp) # Set number drive? jnz main.1 # Yes testb %dl,%dl # Drive number valid? js main.2 # Possibly (0x80 set) .. ... That means that BIOS saves the current drive number in register %dl?? Could you give a hint about _where_ BIOS stores _what_?? I've searched the google.com, but got no valuable resource. Thanks. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: sendmail + auth + ssl + freebsd
Leo Bicknell wrote: After searching the archives and looking at the source, I find myself more confused. I've been asked to set up sendmail + ssl + SMTP auth on a FreeBSD host. A quick strings on the sendmail binary shows a number of SSL functions, so I'm thinking the SSL bits are in there, but I'm not quite sure how to take advantage of them. Issuing AUTH to a stock -STABLE sendmail gets command unrecognized though, so I don't think that is there. If no one else has figured this mess out, I'll do it and write a page for the handbook. If someone else has, please clue me in, and if necessary I'll still write that handbook page. :-) It would be very nice if it was simple to make FreeBSD sendmail SSL and authenticate against the password file. I've managed to set it up to use AUTH, however I have not yet found the time to make it use SSL. The only usefull documentation I have been able to find is this one: http://www.sendmail.org/~ca/email/auth.html You have to generate a public key certificate and have the private key available to the sendmail daemon before it will do the STARTTLS thing. I've got a shell script around there that signs a certificate with a bogus CA which enable the use of STARTTLS. You can't validate the other end of the connection, but at least it negotiates an encrypted session. It's attached below, and it's a horrible blecherous hack and provides very little security other than allowing the session to be encrypted. It's at least obviously not able to protect against man-in-the-middle attacks since the CA signing the cert is completely bogus. It will make long distance phone calls when you're not looking, eat your food, and make rude remarks about your spouse. Use at your own risk. But it seems to do, er, something. At least it makes passive traffic sniffing less productive. louie make-sendmail-cert.sh Description: make-sendmail-cert.sh
Re: userland program panics freebsd 4.3
On Tue, Dec 18, 2001 at 03:29:17PM -0500, Michael Scheidell wrote: I have a userland program that canpanic/reboot a freebsd 4.3 system. Can you upgrade to 4.4-STABLE and test whether the problem persists? Chances are it's either a) fixed, or b) hardware-related. Kris msg30305/pgp0.pgp Description: PGP signature
Re: the crash screen usually after 4 to 13 days not good...
On Wed, Dec 19, 2001 at 08:17:58PM -, [EMAIL PROTECTED] wrote: What happens is the network card on xl0 going to down and its light goes off on the hub and I get this crash address straight after. It's a 3Com 900TPO 10Mbps Usually it reboots but its locked this time with it on the screen Fatal trap 12: page fault while in kernel mode Please see the FAQ and the handbook about obtaining debugging crashdumps so this problem can be debugged. You also forgot to mention which version of FreeBSD you're running. Kris msg30306/pgp0.pgp Description: PGP signature
Thanx and another question
Mike Smith has written: I'm now learing the PCs boot procedure by reading boot0.s. Ooh, that's bad. Not a really good place to start. 8) But for your help insight, it would have been bad. :) Besides the PCs boot procedure, i wanted to learn more about assembly language (ATT syntax) and how the FreeBSD Boot Manager works inside. So i've been reading and learning that code. Hope this helps! That does help a lot. Thanks so much for your hint and two links. Now i think i've got a basic knowledge about the BIOS data area. But reading the code of boot0.s, i got another question as in the following code: main.5: incw dx # Next item addb $0x10,bl # Next entry jnc main.3 # Till done The partition table in MBR only has 4 items, why check for 16 times?? Thanks so much. _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
