Re: ssh to freefall broken
On Thu, Apr 20, 2000 at 12:58:42PM -0700, Archie Cobbs wrote: Just updated to -current.. previously, when ssh'ing to freefall, no password was required at all -- it just worked. Now I get this: $ ssh [EMAIL PROTECTED] Warning: Server lies about size of server host key: actual size is 1023 bits vs. announced 1024. Warning: This may be due to an old implementation of ssh. Warning: identity keysize mismatch: actual 1023, announced 1024 Agent admitted failure to authenticate using the key. Authentication agent failed to decrypt challenge. Enter passphrase for RSA key '[EMAIL PROTECTED]': This wouldn't be a big problem except for CVS_RSH=ssh .. meaning every cvs operation requires a password. Any ideas what I'm doing wrong? You're using OpenSSH - I think removing the approprate entry from your ~/.ssh/known_hosts, then logging in once and saving the "new" hostkey fixed that problem. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ssh strangeness in -current...
On Tue, Mar 07, 2000 at 03:55:52PM +0100, Brad Knowles wrote: I've been following this thread for a while, and I'd like to ask a related question -- can anyone else successfully use scp with OpenSSH? On the one machine on which I've installed OpenSSH so far, it appears that scp into the machine is totally broken. Of course, this machine isn't running FreeBSD, so I don't expect you folks to help me try to work this problem out, but I am wondering if scp with OpenSSH under FreeBSD does actually work. It works fine for me, I just tested scp in both ways between 2 machines running: - FreeBSD 2.2.8 from Dec. 1998, using SSH 1.2.25 without RSAREF from the ports - FreeBSD 3.4 as of Dec. 27th 1999, using OpenSSH 1.2.1 installed as a port bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: UDF
On Fri, Jan 14, 2000 at 09:29:58AM +0100, Soren Schmidt wrote: It seems Brian Beattie wrote: I have been looking at UDF ( the filesystem used on CD-RW and DVD's ). I was wondering if anybody was working on it. I'm thinking about trying to implement it for CD-RW's and would like to avoid duplication of effort and the anoyance of getting half way through the effort and having somebody else show up with a completed implementation. I have it on my TODO list, but I'm not started yet, and probably wont for some time to come. The reason I've put it on the backburner for now, is that DVD's can be read using the cd9660 filesystem, and that is sufficient for my needs for the time being. I was under the impression that this was only possible as long as the DVDs actually had an ISO9660 filesystem as well - which all of my DVDs have, but which still doesn't mean that there are no DVDs with only UDF, but no ISO9660 filesystem. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipfw optimizations
On Fri, Jan 07, 2000 at 11:37:02AM -0700, Nate Williams wrote: One of the things I would do to optimize ipfw is: - instead of keeping one list with all the rules, split the list (the internal one) by interface and by direction (one list for ed1 incoming, one list for ed1 outgoing, etc.). one skipto rule is enough to switch between two rulesets depending on direction, so this is not really worthwhile. I agree that having a `switch' type of rule for selecting interfaces would be a reasonable gain of efficiency (but then again.. how many interfaces is one using!) It doesn't matter, it has to do the lookup on a per-interface basis. On my firewall box, I have 11 interfaces. Two ethernet, one loopback, 4 slip, and 4 tunnel. I could easily see a speedup from using per-interface lists. I haven't looked at the firewalling-code in the kernel, but couldn't you gain exactly this speedup by issuing this stuff manually? Add a bunch of "skipto" rules at the very beginning of your ruleset and have them branch to rule 5000, 1, 15000 etc. and then setup your per-interface rules beginning at exactly these rules. In fact, isn't that what Linux' "ipchains" are all about? You split up the rules and branch to one of your rulesets at the beginning. I've never seen anything special in this feature, since ipfw does that as well (you just don't have magical names for your rules but numbers instead). bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Woa! May have found something - 'rl' driver and small packets (was Re: Odd TCP glitches in new currents)
On Wed, Dec 22, 1999 at 10:18:56PM -0800, Matthew Dillon wrote: I'm adding Bill Paul to the list specifically. Hmm. Now this is odd! I think I may have found something! All of my 'rl' driver cards fail this test: apollo# linktest -m 0.1:0.2 -s 16 -f16 lander lander# linktest -m 0.1:0.2 -s 16 -f16 apollo They get about 1% packet loss with the test. Always. 100BaseTX full or half duplex, or 10BaseT -- I still get failures. I can't repeat this with a RealTek 8039 (that's an 'ed'-NIC) and a RealTek 8139 (that's the 'rl'-one) running 10BaseT. Note that I am _NOT_ running -CURRENT on any of these machines, they both run 2.2-STABLE (rev. 1.17 of rl.c). The packetloss when using small packets is exactly 0 - that is no packetloss occured during the minute or so which I was running linktest. I just started it again and will leave it running for a couple of hours, but I doubt that this will make a change. Whoops, I in fact experienced packet loss now: overdose(194.94.249.94)-foobar.franken.de lost 1/1606 overdose(194.94.249.94)-foobar.franken.de lost 2/2702 foobar.franken.de-overdose(194.94.249.94) lost 1/3412 overdose(194.94.249.94)-foobar.franken.de lost 3/3829 Note that was playing PCM-files via NFS at this time, so there was additional network traffic of ~180 KByte/s. These here now occured although there was no additional network traffic: overdose(194.94.249.94)-foobar.franken.de lost 4/5491 overdose(194.94.249.94)-foobar.franken.de lost 5/5692 overdose(194.94.249.94)-foobar.franken.de lost 6/7277 overdose(194.94.249.94)-foobar.franken.de lost 7/8661 overdose(194.94.249.94)-foobar.franken.de lost 8/9412 overdose(194.94.249.94)-foobar.franken.de lost 9/11393 overdose(194.94.249.94)-foobar.franken.de lost 10/13699 foobar.franken.de-overdose(194.94.249.94) lost 2/13728 overdose(194.94.249.94)-foobar.franken.de lost 11/16426 It seems as if this was roughly the same amount of packetloss as you experienced. rl0: RealTek 8139 10/100BaseTX irq 11 at device 3.0 on pci0 rl0: Ethernet address: 00:50:ba:d1:89:05 miibus0: MII bus on rl0 All of my 'fxp' driver cards succeed with the above test perfectly. If I test an fxp machine verses an 'rl' machine, linktest shows that the 'rl' cards can transmit small packets just fine but they lose out trying to receive them! Nope, it's the other way round for me. overdose has the 'rl'-NIC, foobar has the 'ed'-NIC. I hope to be able to do a few additional tests soon. Methinks there is something going on with the 'rl' driver and/or the RealTek cards! My experience with those cards isn't the best, so I'd place my bets on the cards. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: how to avoid bullets in the feet (was Re: HEADS UP: sigset_t changescommitted)
On Thu, Sep 30, 1999 at 09:19:47AM +0200, Marcel Moolenaar wrote:
Alfred Perlstein wrote:
What's really needed is some warning sort of like what we
did when the AOUT-ELF convertion happened, there has
to be a simple way to test this as part of installworld.
Yes, that's exactly what I had in mind. Details still need to be worked
out, though.
This is what I was thinking of when I mentioned "fixing things".
Going the "good old way" (make world, _then_ build a new kernel)
doesn't have to _work_, the problem right now is that it will
complete, but in the end you'll have a non-running system (and,
the way I understood, it would be non-repearable without a new
binary installation).
An interruption of the build-process at the beginning, displaying
a message ("Please build and install a new kernel first") in this
case would be suficient.
bye,
Harold
--
Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein.
Wed Mar 4 04:53:33 CET 1998 #unix, ircnet
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: sigset_t changes committed
On Wed, Sep 29, 1999 at 11:55:23AM -0700, Doug wrote: On Wed, 29 Sep 1999, Marcel Moolenaar wrote: I just finished committing the sigset_t changes I worked on for the last 5 weeks. Before attempting to build world, you must make and install a new kernel. The new kernel will contain new syscalls that are needed during build world. doscmd is currently not being build because it needs fixing first. Is there any way at all that we can change this process so that building the kernel first is not required? Those of us involved in educating users about the make world process spend a lot of time telling them not to do this. It's amazing how long and how tenaciously "one-time" exceptions like this stick in their minds. Those users shouldn't track (or run) -CURRENT. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
On Wed, Apr 14, 1999 at 10:24:38PM +0900, Daniel C. Sobral wrote: Motomichi Matsuzaki wrote: The patch gzip+uuencoded is following. Do you know of any problems resulting from applying this patch? I'm not sure if this applys to _this_ patch, but a couple of months ago I took some 3.0-patches and backported them to 2.2. They had the problem of using the Joliet extensions when mounting a hybrid-CD (a CD with Joliet and RockRidge extensions). Perhaps an option to mount_cd9660 would be the best idea, similar to the already existing -r it could get a -j which would make mount_cd9660 ignore the Joliet extensions. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: kern/5038: FreeBSD can't read MS Joliet CDs.
On Thu, Apr 15, 1999 at 02:17:36AM +0900, Motomichi Matsuzaki wrote: From: Harold Gutch lo...@foobar.franken.de logix I'm not sure if this applys to _this_ patch, but a couple of logix months ago I took some 3.0-patches and backported them to 2.2. logix They had the problem of using the Joliet extensions when mounting logix a hybrid-CD (a CD with Joliet and RockRidge extensions). Would you tell me what kind of problem? From what you say below, I guess that your patches do not have this problem. What I meant, was, that if you use a CD with both Joliet AND RockRidge extensions on it, my patches would give you the Joliet extensions. Yours however would show the RockRidge extensions, which _I_ prefer (I would like to be able to see the Joliet extensions if I explicitely specify so on the commandline though, say by using the -r option, which the normal mount_cd9660 already has. Changes from Joachim's: * With Joliet and RockRidge CD, Joachim's see Joliet, mine see RockRidge. logix Perhaps an option to mount_cd9660 would be the best idea, similar logix to the already existing -r it could get a -j which would make logix mount_cd9660 ignore the Joliet extensions. -j is also available for my patch. bye, Harold -- Shabby Sleep is an abstinence syndrome wich occurs due to lack of caffein. Wed Mar 4 04:53:33 CET 1998 #unix, ircnet To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
