Re: help: smmsp
On Mon, Oct 31, 2005 at 05:35:31AM +, Edy Purnomo wrote: > i keep having the "smmsp" daemon shows on the ps aux list. > so it fills up my clientmqueue directory. > how to rid off this thing ? Disable the sendmail cronjob: $ sudo crontab -l|grep sendmail # sendmail clientmqueue runner #*/30 * * * * /usr/sbin/sendmail -L sm-msp-queue -Ac -q > i've sendmail disabled already. Not finished yet ;-) Regards Simon
Re: dhclient woes
This is more a "me too" than a solution, I'm afraid. On 10/31/05, Hannah Schroeter <[EMAIL PROTECTED]> wrote: > If I include an alias directive in /etc/dhclient.conf, dhclient exits > after having acquired a lease, the syslog messages are like this: This is quite similar to something I also experienced [1,2] on a machine that gets a public IP from a DSL provider while still wanting to locally talk to the DSL modem. Unfortunately, I have no solution, but I can verify that the problem exists (an exiting dhclient) in 3.7, as well as it did in 3.6. [2] also includes my configuration on the machine in question. Unfortunately, I never got around to providing a more detailed report than that as I could happily leave the DSL modem on its own. I suspect running with a debugger may provide a few clues as well. Regards, Rogier References: 1. MARC 'dhclient and multiple networks (/24 alias) fails (bug?)' http://marc.theaimsgroup.com/?l=openbsd-misc&m=110088400431506&w=2 2. MARC 'dhclient suddenly exiting together with arpresolve: can't allocate llinfo' http://marc.theaimsgroup.com/?l=openbsd-misc&m=110061784801356&w=2 -- If you don't know where you're going, any road will get you there.
help: smmsp
hi, i keep having the "smmsp" daemon shows on the ps aux list. so it fills up my clientmqueue directory. how to rid off this thing ? i've sendmail disabled already. thanks in advance. -edy-
Problems installing 3.8 on SS5.
I received my 3.8 CDs on Friday, and tonight I am installing it on my SparcStation 5. During boot, there was a huge stream of "phy not configured" error messages for a quad-hme SBus card, and install refused to continue when it could not find any disks. I saw the lines in dmesg for sd0 and sd1, but when I examined /var/run/dmesg.boot everything before the huge stream of messages was gone... which is why the installer died. I've removed the quad-hme card from the system and the install is moving along happily now - but I'm curious what caused the problem. Could that be a hardware problem with the quad ethernet card? is the buffer used to capture the dmesg too small to handle a lot of error messages? I suspect I'll get flamed for not providing a dmesg, but I honestly don't think my question requires it, and securing it (given that the dmesg being written to file is verifiably incomplete) is not trivial. -- Matthew Weigel
Re: dhclient woes
Hello!
On Mon, Oct 31, 2005 at 02:55:47AM +0100, Hannah Schroeter wrote:
>[...]
>Oct 31 02:48:27 mamba dhclient[29778]: bound to 82.212.35.55 -- renewal in
>1800 seconds.
>Oct 31 02:48:27 mamba dhclient[23056]: connection closed
>Oct 31 02:48:27 mamba dhclient[23056]: exiting.
When running with an alias directive setup.
>[...]
Addition: Using -current dhclient source code doesn't change much:
Oct 31 03:03:23 mamba dhclient[26338]: bound to 82.212.35.55 -- renewal in 1800
seconds.
Oct 31 03:03:23 mamba dhclient[20829]: buf_read (connection closed)
Oct 31 03:03:23 mamba dhclient[20829]: exiting.
dhclient.conf is this:
media "media autoselect";
request subnet-mask, broadcast-address, routers;
supersede domain-name-servers 127.0.0.1;
script "/sbin/dhclient-script";
alias { interface "ne0"; fixed-address 192.168.1.1; option subnet-mask
255.255.252.0; }
Kind regards,
Hannah.
dhclient woes
Hello! This is on an OpenBSD 3.7-release, freshly upgraded (in fact, reinstalled and merged etc and so on). If I include an alias directive in /etc/dhclient.conf, dhclient exits after having acquired a lease, the syslog messages are like this: Oct 31 02:48:27 mamba dhclient[29778]: bound to 82.212.35.55 -- renewal in 1800 seconds. Oct 31 02:48:27 mamba dhclient[23056]: connection closed Oct 31 02:48:27 mamba dhclient[23056]: exiting. There's no intervening message, even after changing syslog.conf to log daemon.debug, too. The message connection closed seems to come from the privsep code. If I remove the alias directive, it works and continues running in the background. However, I need the alias thing, and it's a documented feature. Same woe when I remove the alias directive from dhclient.conf and instead adding the alias manually using ifconfig ne0 alias ... In the very moment I add the alias, dhclient exists with the "connection closed" and "exiting" messages in /var/log/daemon. And same thing if I add the alias from /etc/hostname.ne0 in a second line after the line saying dhcp. So seems the dhclient privsep code fails when dhclient "notices" either the alias addition itself, or an associated routing table change. Current workaround is restarting dhclient from crontab every 15 minutes, but that's no good thing having that forever. Kind regards, Hannah.
Re: Extend a partition onto another disk?
Robert Jacobs wrote: > Please pardon my ignorance, I had difficulty finding an answer > to this in the faqs/archives. How can I extend an FFS partition > onto a second hard drive? Add a symlink. # Han
Re: Extend a partition onto another disk?
On Sun, Oct 30, 2005 at 06:38:45PM -0500, Robert Jacobs wrote: > Hi, > > Please pardon my ignorance, I had difficulty finding an answer to this in > the faqs/archives. How can I extend an FFS partition onto a second hard > drive? > > Say I have /var on a dedicated 20ggb hard drive and it got filled up and I > need to extend all of /var (not mount additional space inside of var) to > another disk. I was looking at raid/raidframe for this, but is there a way > to simply extend the partition onto another disk? Not raid0 or anything. > > thanks, > Robert You may want to look into ccd(4), which is like RAID but built into the kernel and simpler. Pretty much complex enough for your needs, though. To the best of my knowledge, there's no way to tell ffs 'this is the end of the disk, please see /dev/wd1 for the rest'. Joachim
Extend a partition onto another disk?
Hi, Please pardon my ignorance, I had difficulty finding an answer to this in the faqs/archives. How can I extend an FFS partition onto a second hard drive? Say I have /var on a dedicated 20ggb hard drive and it got filled up and I need to extend all of /var (not mount additional space inside of var) to another disk. I was looking at raid/raidframe for this, but is there a way to simply extend the partition onto another disk? Not raid0 or anything. thanks, Robert
Re: hide NAT with OpenBSD
Szechuan Death wrote: > Okay, misc: As near as I can tell (been talking with Alexey offlist), Okay, misc, I'm a dumbass. My Russian is really remarkably rusty. Alexey wants to prevent some benighted ISP from counting hosts behind a NAT device; the problem is that they're wise to the trick of setting TTLs to 255 and block packets with that TTL. There is also a host on the NATted network with some ridiculously large default TTL, something like 245. I have recommended setting the minimum TTL to a lesser value, say 245-254. However, on the off chance that this doesn't work, a revised question; is there any means in pf of "setting" TTL values in outbound packets directly to a value - e.g. "128", or whatever - not just bringing them up to a minimum? If there isn't, I believe that Alexey has offered to write a patch, if he has time to do so. >;-> Sorry for the miscommunication. -- (c) 2005 Unscathed Haze via Central Plexus <[EMAIL PROTECTED]> I am Chaos. I am alive, and I tell you that you are Free. -Eris Big Brother is watching you. Learn to become Invisible. | Your message must be this wide to ride the Internet. |
Re: Problem instaling OpenBSD on IBM xSeries 336
> Can you try booting the i386 GENERIc kernel with pcibios disabled? > And like Stuart Henderson suggested, can you also try the GENERIC.MP > kernel. If that gets stuck at pcibios too, try disabling it on the mp > kernel as well. The original poster doesn't seem to be replying, but I am having the same problems. Additionally, I am unable to mount cdroms, which is a significant issue as I want to run OpenBSD off a cdrom. I have been posting about this problem on this mailing list. I have tried disabling pcibios i386 GENERIC kernel. It boots successfully, but my cdrom problem still exists. I haven't tried GENERIC.MP, as I couldn't find the mp kernel on the install cd. Stephen
Re: scp/sftp performance myths
hmm, on Sun, Oct 30, 2005 at 04:04:52PM -0500, Nick Holland said that
> I find that interesting, too.
> I was just explaining to my GF's six-year-old niece yesterday that you
> shouldn't believe everything someone says.
hello Nick, thanks for the tip :)
you surely realize you are 'someone' as well? ;-)))
(just to poke you a bit, i certainly don't believe everything anyone says)
> Been doing some interesting tests recently...
> scp'ing large (100M+ files) from a Celron 566 to a PIII-750 went at
> about 4MB/s, using fxp cards on both sides. Somewhat less than half
> wire speed. Room for improvement, certainly, but not three times. And
> that's on two-generation old hardware! (and several switches, a router,
> and a firewall between them)
yes, i was expecting someone coming up with the hardware side,
esp. the NIC's. i do not doubt these facts, crappy NIC's have
crappy throughputs.
but.
i normally get 2.5-3MB/s on my lan scp-ing, where the router is a
cpu0: Intel Celeron ("GenuineIntel" 686-class, 128KB L2 cache) 375 MHz
but on the same box 6-7MB/s copying thru samba. ftp the same.
yuck. i enabled it just to make some tests. (i dont even dare
to use the word benchmark: it is not, just some silly end-user tests).
so i don't believe all is hardware, certainly the cards can do
better.
here is the thing: as i said before, noone excepts the same of
scp as of samba or ftp. i write these mails simply because
i don't know what to expect. what could be a normal transfer
rate for my machine? is it my processor that can't do more?
if yes, wouldn't it make sense after all making a cipher=none
option for the data part? ssh is _the_ standard, and it openly
aims to replace ftp. will we have to turn on ftp just to
transfer (3x as fast) some big files which are not confident
and turn it off again after?
also, what do other people say, could someone test with high
end machines where CPU is not an issue? where does ssh top out?
and if it was only a CPU issue, the HPN-SSH couldn't make the
claims they make. even if they are not true in all cases ;)
what about tunnels? maybe around rsync? what's the transfer
rate there? is it the same as scp? or some other tunneling.
could anybody comment on this?
> > i think it would be very nice to have a performance page on the openssh
> > site describing what should be expected, what is "normal" and the
> > intended performance of ssh to clear up possible misunderstandings.
> > (like mine here)
>
> too many variables.
true. i did not think this over.
but the numbers don't have to be absolute, more like informative...
> Oh, and OpenSSH is very multi-platform...again, more variables.
well, isn't ftp? i know the RNG of a particular system plays
a big role, but this is something which could be tested by
cipher=none ;-)
-f
--
name a psychological rock group? pink freud!
Re: device timeout when mounting cd
Andrew Daugherity wrote: I completely missed that you're running amd64 (I saw Intel Xeon, and thought i386). You might try an i386 kernel (maybe the bsd.rd installer, as you don't want to mix libs between i386 and amd64) to see if the CD-ROM works there. If it works under i386, then it looks like a bug somewhere in the amd64 kernel, and might be worth filing a bug over (or perhaps adding comments to PR4570). I wasn't using the i386 kernel as it hangs when probing PCI devices. I managed to get past this by disabling pcibios, but it has the same problem as the amd64 kernel when it comes to reading the CDROM, so nothing gained other than showing that the problem is not amd64 specific. More data is good. If you can swap the drive, that would be a good test. Also, testing other BSDs can't hurt -- NetBSD, OpenBSD, and FreeBSD share some code, Net and Open more so than Free; although they've diverged quite a bit, sometimes drivers (and bugfixes) are ported between them. Note that saying "but it works in NetBSD, fix it!" isn't likely to get you much help here, but "it's also broken in NetBSD" might help track down the bug. I'm not an OpenBSD developer, so if someone who is one chimes in, take their word over mine. :-) I have two machines, both with the same problem, so it's not the drive. I've tried using NetBSD, and the amd64 2.1 kernel works fine. How can I bring this to the attention of a developer? I'm guessing that with the release tomorrow developers are a little busy, but once 3.8 is out what should I do to get this fixed? I have some experience with c, but not enough to fix the problem myself. I would be able to apply patchs etc to help deduce the problem though. Thanks for your help, Stephen
Re: scp/sftp performance myths
On Sun, Oct 30, 2005 at 02:41:25PM +0100, frantisek holop wrote: > hi there, > > poking around in the HP ssh docs, one can see the following in the FAQ: > > Q: How is the performance of HP-UX Secure Shell? > A: Compared with conventional file transfer methods, the scp command >is 2 - 3 times slower than rcp, and sftp is 2 to 3 times slower than >ftp. This is because HP-UX Secure Shell authenticates both the server >and users, and encrypts both the data and the password. In addition, >HP recommends you use the /dev/random device on your system to >significantly speed up program initialization. > > i find it interesting that most of the user community perceives > scp/sftp multiple times slower then their not encrypted counterparts. > > now, not taking into consideration the HP-UX itself is a bottleneck > on its own (not mentioning their RNG interface) i think some of us prngd also helps if you can't get a real /dev/random for your system, or can't afford downtime to install the device driver. > agrees that scp/sftp is "kind of slower" when it comes to bulk data > transfer. nobody expects scp to be as fast as samba or ftp of course, > the encryption has a great overhead, especially for older machines > (which my local network router is) Selecting a fast cipher/mac pair can make a significant difference. Of the standard ones, arcfour and hmac-md5-96 are usually fastest. > but a couple of months ago a link appeared here describing a HPN > (as in hihg performance enabled) ssh patch. i kept that mail for > a very long time because i was very much interested in the answers > of the ssh developers, but there was none. and so i assumed it must > be rubish or something. It's not rubbish, but it only helps in certain situations (ie when you have a "long, fat pipe"). The breakpoint is when the amount of data in the pipe gets to about 64kb, which is a RTT of about 5ms on a 100Mb/s network or 50ms on a 10Mb/s one. > so before anyone tags this mail as a trolling flamebait > (which it is not), i just would like to ask > -have others tried HPN-SSH? > -have ssh developers tried it? I have. The current one has a couple of problems: the main one being that it is slower in situations where you have more bandwidth than CPU (10% to 25% in my experiments) and uses more CPU and memory under most conditions. There's no fundamental reason why this should be so since you're not doing any more work, just making better use of the available bandwidth. It also has a few stylistic issues (duplicated code inline rather than in its own function, some slightly convoluted logic, unnecessary changes in scp and use of sizeof(somebuffer) for read limits where the somebuffer is unrelated but just happens to be the right size). I've proposed some changes to address these, but since I don't have a suitable link to test it on (and attempts to simulate one have given inconsistent results) I can't tell if my changes still work as expected. The PSC folks were going to test them but that was a few weeks ago and I've not heard from them since. Most of the discusstion was over on the openssh list. Code review with some proposed changes: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112316226728255 Thread on performance issues: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=112884429502318 The patch attempting to address this is not in the thread: http://bugzilla.mindrot.org/attachment.cgi?id=1013 > i think it would be very nice to have a performance page on the openssh > site describing what should be expected, what is "normal" and the > intended performance of ssh to clear up possible misunderstandings. > (like mine here) http://www.openssh.com/faq.html#3.3 covers authentication times but not throughput. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
ipsecadm tunnel
Hello. I want to set up tunnel between 2 networks 192.168.40.0/28 and 192.168.1.0/24 like bellow: (a.a.a.a)pubIP<--(NAT)gw1<--172.16.0.0/12<--(NAT)gw2<--192.168.40.0/28 | WAN | (b.b.b.b)pubIP<--(NAT)gw3<--192.168.1.0/24 i don't have access to 172.16.0.0/12 network and gw1 I was trying to set it up like this: --gw2-- ipsecadm new esp -enc 3des -forcetunnel -src a.a.a.a -dst b.b.b.b \ -spi 1234 -key ipsecadm new esp -enc 3des -forcetunnel -src b.b.b.b -dst a.a.a.a \ -spi 4321 -key ipseaadm flow -src a.a.a.a -dst b.b.b.b -addr 192.168.40.0/28 192.168.1.0/24 -out -require ipseaadm flow -src a.a.a.a -dst b.b.b.b -addr 192.168.1.0/24 192.168.40.0/28 -in -require --gw3-- ipsecadm new esp -enc 3des -forcetunnel -src a.a.a.a -dst b.b.b.b \ -spi 1234 -key ipsecadm new esp -enc 3des -forcetunnel -src b.b.b.b -dst a.a.a.a \ -spi 4321 -key ipseaadm flow -src b.b.b.b -dst a.a.a.a -addr 192.168.1.0/24 192.168.40.0/28 -out -require ipseaadm flow -src b.b.b.b -dst a.a.a.a -addr 192.168.40.0/28 192.168.1.0/24 -in -require If for eg. i do ping 192.168.1.6 from 192.168.40.2 machine, on gw3 'netstat -sn' shows me 1 packet out and in for ESP, but nothing comes back to me (192.168.40.2)... pf isn't blocking any traffic. Is it possible to build tunnel in that kind of network enviroment ? Sorry for my english ;) -- raff
Re: Help
On 10/30/05, PARAMVIR DHINDSA <[EMAIL PROTECTED]> wrote: > > But CPU fan (constantly running) has never been a > problem on MS-Windows and FreeDOS. In fact it seldom > runs on these OSs if never. Your comparison of "it works on X" is not really worthwhile as it is unlikely to solve your problem with OpenBSD. If your system manipulates the fans through ACPI, OpenBSD will not be able to manipulate your fans. At least, not until ACPI support is present in OpenBSD. It is being worked on in -current, though. > Can the problem be resolved with some configurable settings in OpenBSD? It's mainly a matter of support being available or not, not one of turning knobs. You may want to quiet your system through other means (e.g. through a large heatsink with a fan that you can physically tune to a lower speed). Cheers, Rogier -- If you don't know where you're going, any road will get you there.
Re: scp/sftp performance myths
frantisek holop wrote: > hi there, > > poking around in the HP ssh docs, one can see the following in the FAQ: > > Q: How is the performance of HP-UX Secure Shell? > A: Compared with conventional file transfer methods, the scp command >is 2 - 3 times slower than rcp, and sftp is 2 to 3 times slower than >ftp. This is because HP-UX Secure Shell authenticates both the server >and users, and encrypts both the data and the password. In addition, >HP recommends you use the /dev/random device on your system to >significantly speed up program initialization. > > i find it interesting that most of the user community perceives > scp/sftp multiple times slower then their not encrypted counterparts. I find that interesting, too. I was just explaining to my GF's six-year-old niece yesterday that you shouldn't believe everything someone says. Been doing some interesting tests recently... scp'ing large (100M+ files) from a Celron 566 to a PIII-750 went at about 4MB/s, using fxp cards on both sides. Somewhat less than half wire speed. Room for improvement, certainly, but not three times. And that's on two-generation old hardware! (and several switches, a router, and a firewall between them) scp'ing the same large files from the same PIII-750 to an AMD64 3000 processor on the same subnet (though with a LOT of switches between them) managed over 8MBs (sk(4) chip on the amd64, 100Mbps network). Not going to get much better than that. (Well..actually, I *did* get impatient, as there was several hundred gig to transfer, so I pulled the disk out of the PIII and put it in the amd64 and did a disk-to-disk copy). > i think it would be very nice to have a performance page on the openssh > site describing what should be expected, what is "normal" and the > intended performance of ssh to clear up possible misunderstandings. > (like mine here) too many variables. I'd like to grab another amd64 system and a gigabit switch and try my test again, but on modern HW, you should be moving a fair chunk of data. There are some things you should just test yourself, and find your own bottlenecks. BTW: that PIII-750 had a very slow disk system for its age -- UDMA2. The cables were way too long to run at a more respectable rate. Note the difference in the network. And so on and so on. Oh, and OpenSSH is very multi-platform...again, more variables. The people complaining that they didn't get the "expected" performance they saw on such a page would be a never ending nightmare. For example, when I first started writing this, I forgot that the my two test cases involved one common machine, but two very different network paths... Nick.
Re: scp/sftp performance myths
frantisek holop wrote: so before anyone tags this mail as a trolling flamebait (which it is not), i just would like to ask -have others tried HPN-SSH? -have ssh developers tried it? -or simply, has ssh hit its performance limit and can't get any better? the "HPN" patch greatly improves throughput for long and fat (high bandwidth, high latency) connections, but slows things down significantly for low latency connections. One of the OpenSSH developers saw around a 15% slowdown on LAN to LAN copies. It needs work. -d
Re: Help
--On 30 October 2005 11:25 -0800, PARAMVIR DHINDSA wrote: But CPU fan (constantly running) has never been a problem on MS-Windows and FreeDOS. In fact it seldom runs on these OSs if never. Can the problem be resolved with some configurable settings in OpenBSD? Your fans are probably controlled by acpi, which isn't supported by OpenBSD.
Re: scp/sftp performance myths
On Sun, 30 Oct 2005, Matthew Weigel wrote: SNIP > HPN-SSH improves OpenSSH performance in situations that you and I don't > deal with. Maybe I'm mistaken... do you have an OC-3 connection you're > trying to scp files across? If you are dealing with T-1s and 100Mbps nope, but will OC-48 or 10G suffice? ;-) I went to his presentation at SC last year in Pittsburgh, not sure if the principle investigator is going to be in Seattle for this years SC. For what it's worth, anyone else going to be at SC this year? I assist in setup and teardown of the ASC booth every year, well at least for the last 5 years. g.day diana
Re: scp/sftp performance myths
frantisek holop wrote: but a couple of months ago a link appeared here describing a HPN (as in hihg performance enabled) ssh patch. i kept that mail for a very long time because i was very much interested in the answers of the ssh developers, but there was none. and so i assumed it must be rubish or something. It's not, but there's not much we can tell you that isn't on the PSC site. In fact, most of my reply is going to be telling you things from their site. The shortest way to say it is: you're barking up the wrong tree. HPN-SSH improves OpenSSH performance in situations that you and I don't deal with. Maybe I'm mistaken... do you have an OC-3 connection you're trying to scp files across? If you are dealing with T-1s and 100Mbps LANs (and maybe Gigabit LANs, I'm not sure), then HPN-SSH doesn't matter to you. It's unfortunate that the patch has not yet been incorporated, but if *you* want faster performance for *your* servers, use faster processors and crypto accelerators, because that's what makes SSH slow for *you*. -- Matthew Weigel
Re: Help
> But CPU fan (constantly running) has never been a problem on MS-Windows and FreeDOS. In fact it seldom runs on these OSs if never. Can the problem be resolved with some configurable settings in OpenBSD? >--- Ted Unangst <[EMAIL PROTECTED]> wrote: > if your fans are controlled by acpi, there's not > much you can do. > On 10/29/05, PARAMVIR DHINDSA <[EMAIL PROTECTED]> > wrote: > > 29.10.2005 > > Dear Sir, > > I installed the OpenBSD 3.7 on my Compaq PC. I'm > > facing a problem. The CPU fan runs constantly > > (non-stop) whenever I boot on OpenBSD which has > become > > a nuisance for me as well as my near and dear > ones. > > Although top command shows that my CPU is sitting > > idle, yet the fan keeps on running until I stop my > PC. > > Can you help me out. > > >--
Re: hide NAT with OpenBSD
Okay, misc: As near as I can tell (been talking with Alexey offlist), one of the things he wants is to get an OpenBSD router to not decrement the TTL for packets that it is forwarding. That behavior seems to me to be against RFCs, but I'll ask on the off chance that it's there: is there an option in OpenBSD - config option, sysctl, or other - to tell the kernel to not decrement the TTL on forwarded packets? The other question Alexey was asking; is it possible to do NAT on a transparent bridge? Archives suggest that the answer is "no", that NAT needs an address on both interfaces to operate (making the bridge non-transparent) but I again ask the question on the off chance that there's some magical packet-mangling fuckery that OpenBSD is capable of and that neither I nor Google was previously aware of. I will post updates as I have them. English isn't his first language and Russian isn't mine, so I'm kind of stumbling in the conversation, but I think I have the gist of it okay. Thanks, misc! -- (c) 2005 Unscathed Haze via Central Plexus <[EMAIL PROTECTED]> I am Chaos. I am alive, and I tell you that you are Free. -Eris Big Brother is watching you. Learn to become Invisible. | Your message must be this wide to ride the Internet. |
Re: tried 3.0 not 3.7 and still can't get very far
You should find somebody local that has a bit of experience, as you are having problems that others do not have. btinternet.com is in the UK, so you might try our two UK user groups, at http://www.openbsd.org/groups.html#United (If you're in another country, go to the top of the page and find the country link.) See also the PC notebooks page, http://www.openbsd.org/i386-laptop.html P.S. ports@ is the wrong list for that type of query, so I'm redirecting to [EMAIL PROTECTED] when I purchsed 3 there were all kinds of problems with loading on a laptop Now I purchsed 3.7 and it looks like this is the final end of the road for openbsd and me I tolerated figuring out the wireless settings and even though there is some reason for a huge time lag installing packages my main concern is there is NO flexibility in getting it setup 1. every other download has some kind of 'serious' error yet the package loads 2. OK finally fed up with instaling upteen seperate packages to get something to work i.e. gnome then atttempted to dowload everything and install what I want. Well the ftp blows up. 3. just have no sure way of knowing when this system will start doing some real work. spending all my time with problems and have no single docuement to help Just pissed off that I blew my money on an impossible system to get running right
Re: tried 3.0 not 3.7 and still can't get very far
paul, >when I purchsed 3 there were all kinds of problems with loading on a laptop > >Now I purchsed 3.7 and it looks like this is the final end of the road >for openbsd and me > >I tolerated figuring out the wireless settings and even though there is >some reason for a huge time lag installing packages my main concern is >there is NO flexibility in getting it setup try posting a dmesg for the laptop you're running on and/or the log/debugging outputs that are relevant to your errors. > >1. every other download has some kind of 'serious' error yet the package >loads >2. OK finally fed up with instaling upteen seperate packages to get >something to work i.e. gnome then atttempted to dowload everything and >install what I want. Well the ftp blows up. >3. just have no sure way of knowing when this system will start doing >some real work. spending all my time with problems and have no single >docuement to help > "no single document to help"? that's hardly the case. take a look at the openbsd FAQ, http://openbsd.org/faq/index.html , or look at the manual pages. openbsd is not windows or linux. you really should give the FAQ and manual pages a thorough reading when you're confused. remain calm :). cheers, jake
Re: scp/sftp performance myths
On 10/30/05, frantisek holop <[EMAIL PROTECTED]> wrote: > but a couple of months ago a link appeared here describing a HPN > (as in hihg performance enabled) ssh patch. i kept that mail for > a very long time because i was very much interested in the answers > of the ssh developers, but there was none. and so i assumed it must > be rubish or something. > > > so before anyone tags this mail as a trolling flamebait > (which it is not), i just would like to ask > -have others tried HPN-SSH? > -have ssh developers tried it? > -or simply, has ssh hit its performance limit and can't get any better? my understanding is that the patch works, but it's not "right".
Re: Help
On 10/29/05, PARAMVIR DHINDSA <[EMAIL PROTECTED]> wrote: > 29.10.2005 > Dear Sir, > I installed the OpenBSD 3.7 on my Compaq PC. I'm > facing a problem. The CPU fan runs constantly > (non-stop) whenever I boot on OpenBSD which has become > a nuisance for me as well as my near and dear ones. > Although top command shows that my CPU is sitting > idle, yet the fan keeps on running until I stop my PC. > Can you help me out. if your fans are controlled by acpi, there's not much you can do.
Re: hide NAT with OpenBSD
- WinXP - scrubed - FreeBSD - passing + WinXP - passing + FreeBSD - scrubed
Re: hide NAT with OpenBSD
On Sun, 30 Oct 2005 08:17:21 -0800 Geoff Sweet <[EMAIL PROTECTED]> wrote: > That's why you set min-ttl to it's highest value. You could also look > at 'reassemble tcp'. It modifies ttl setting in the session as well. > But it's meant more for normalizing traffic. look that: [anti-nat] | | | | min-ttl 128--> [NAT on OpenBSD]+ | || | || | || | || [WinXP] [FreeBSD] [bla-bla-bla OS with bla-bla-bla TCP options] (128) (64) (245) WinXP - scrubed FreeBSD - passing bla-bla-bla - passing and droping by anty-nat systems if i'm set TTL on my OpenBSD == 255 - it's blocked too, becouse anti-nat systems "understand" this "tricks".. whats wrong?
Re: hide NAT with OpenBSD
That's why you set min-ttl to it's highest value. You could also look at 'reassemble tcp'. It modifies ttl setting in the session as well. But it's meant more for normalizing traffic. -Geoff Alexey S. Malyshev wrote: > On Sun, 30 Oct 2005 10:00:25 -0500 > Jeff Quast <[EMAIL PROTECTED]> wrote: > > >>scrub on $ext_if min-ttl 255 >> >>On 10/30/05, Alexey S. Malyshev <[EMAIL PROTECTED]> wrote: >> >>>Hi misc@ >>> >>>How to set TTL to certain value on a certain interface in order to hide >>>presence of LAN behind NAT? >>> >>> > > > hmm... but if TTL == 128 and min-ttl == 64, than packets not scrubed by PF... > and anti-NAT systems block this ip > > FreeBSD has `IPSTEALTH', OpenBSD have anything to do this? > > sorry, my english is very, very bad =(
Re: hide NAT with OpenBSD
On 2005/10/30 19:50:10, Alexey S. Malyshev wrote: > How to set TTL to certain value on a certain interface in order > to hide presence of LAN behind NAT? Does min-ttl do what you want? See pf.conf(5).
Re: hide NAT with OpenBSD
On Sun, 30 Oct 2005 10:00:25 -0500 Jeff Quast <[EMAIL PROTECTED]> wrote: > scrub on $ext_if min-ttl 255 > > On 10/30/05, Alexey S. Malyshev <[EMAIL PROTECTED]> wrote: > > Hi misc@ > > > > How to set TTL to certain value on a certain interface in order to hide > > presence of LAN behind NAT? > > > > hmm... but if TTL == 128 and min-ttl == 64, than packets not scrubed by PF... and anti-NAT systems block this ip FreeBSD has `IPSTEALTH', OpenBSD have anything to do this? sorry, my english is very, very bad =(
Re: hide NAT with OpenBSD
On Sun, 30 Oct 2005 10:00:25 -0500 Jeff Quast <[EMAIL PROTECTED]> wrote: > scrub on $ext_if min-ttl 255 > > On 10/30/05, Alexey S. Malyshev <[EMAIL PROTECTED]> wrote: > > Hi misc@ > > > > How to set TTL to certain value on a certain interface in order to hide > > presence of LAN behind NAT? > > > > yeah, sorry...
Re: hide NAT with OpenBSD
scrub on $ext_if min-ttl 255 On 10/30/05, Alexey S. Malyshev <[EMAIL PROTECTED]> wrote: > Hi misc@ > > How to set TTL to certain value on a certain interface in order to hide > presence of LAN behind NAT?
hide NAT with OpenBSD
Hi misc@ How to set TTL to certain value on a certain interface in order to hide presence of LAN behind NAT?
Re: rdr clarification
On Saturday 29 October 2005 03:34 pm, ed wrote: > > rdr pass on $ext_if proto tcp from to $ext_ad3 port > > ldap -> $server_1 port ldap > > > > ...where $server_1 is on the other side of $int_if, still needs a > > pass out rule on $int_if. The "rdr pass" does not extend through to > > the destination but only through the interface the rdr rule is > > applied to. > > I think this depends on your block rules. If you have a block rule > else where, it may not permit the return packets. With "pass" added (rdr pass) filtering rules are supposed to be skipped, so a later block shouldn't matter. Plus, since "rdr" rules keep state the return trip should be guaranteed - the state table is examined and filtering rules are skipped. So it appears that the "pass" and the state keeping only apply to the named interface and not through to the destination. Chris
Re: RAID cards
The 3/DC works for sure since it was my development board. The megaraid 1600 is equivalent and should also work. On Sun, Oct 30, 2005 at 08:48:07AM -0500, marrandy wrote: > Hello. > > Ref the new bioctl RAID management inteface. > > Has the Dell perc3/dc and the megaraid elite 1600 been tested and proved to > work as I need to get a machine with supported RAID. > > Regards...Martin
RAID cards
Hello. Ref the new bioctl RAID management inteface. Has the Dell perc3/dc and the megaraid elite 1600 been tested and proved to work as I need to get a machine with supported RAID. Regards...Martin
scp/sftp performance myths
hi there, poking around in the HP ssh docs, one can see the following in the FAQ: Q: How is the performance of HP-UX Secure Shell? A: Compared with conventional file transfer methods, the scp command is 2 - 3 times slower than rcp, and sftp is 2 to 3 times slower than ftp. This is because HP-UX Secure Shell authenticates both the server and users, and encrypts both the data and the password. In addition, HP recommends you use the /dev/random device on your system to significantly speed up program initialization. i find it interesting that most of the user community perceives scp/sftp multiple times slower then their not encrypted counterparts. now, not taking into consideration the HP-UX itself is a bottleneck on its own (not mentioning their RNG interface) i think some of us agrees that scp/sftp is "kind of slower" when it comes to bulk data transfer. nobody expects scp to be as fast as samba or ftp of course, the encryption has a great overhead, especially for older machines (which my local network router is) but a couple of months ago a link appeared here describing a HPN (as in hihg performance enabled) ssh patch. i kept that mail for a very long time because i was very much interested in the answers of the ssh developers, but there was none. and so i assumed it must be rubish or something. so before anyone tags this mail as a trolling flamebait (which it is not), i just would like to ask -have others tried HPN-SSH? -have ssh developers tried it? -or simply, has ssh hit its performance limit and can't get any better? i think it would be very nice to have a performance page on the openssh site describing what should be expected, what is "normal" and the intended performance of ssh to clear up possible misunderstandings. (like mine here) -f -- i'm so broke i can't even pay attention.
Re: [Fwd: Re: Your web comment on docs.hp.com]
hmm, on Tue, Oct 25, 2005 at 02:56:44PM -0400, Daniel Ouellet said that > Some feedback already. well, i did not get any feedback at all. perhaps hp *does* hate dhl after all ;-) anyway the docs are fixed now, even the BSD license gets its 15 minutes of fame. http://www.docs.hp.com/en/T1471-90015/ch01s02.html thanks for everyone who sent in their message. -f -- i couldn't repair your brakes so i made your horn louder.
