Re: ftp limits bandwidth
It looks like filezilla uses several transfert at the same time to reach 1Mo/s however each transfert is ~400Ko/s as for OpenBSD's FTP client. Maybe the bandwith limit per file transfered is limited from the server side ? Is there any way to make multiple transferts at the same time with mget since that would accelerate some transfers in some cases. Regards, JF 2009/6/20 Jean-Frangois SIMON jfsimon1...@gmail.com Hi, I forgot to tell you more sure, however the crystal ball worked very well. It's a 12M ADSL that works at approximately 1300 ko/s at max speed. When downloading with a browser a client such as filezilla it works at full speed but when I type ftp and use OBSD's one it is rather 350/380 max never more. Actually if anything would limit the bandwith the other client would be so. That's stange, I changed sysctl inet.tcp recv/send to 65536 but it's still same transfer speed. I use it on ftps that are rather fast so it looks like ftp is somewhere limited in my configuration. Regards, JF 2009/6/20 Marcos Laufer mar...@ipv4networks.com This is a very interesting subject. Is there any official paper describing how to tune TCP on OpenBSD? Googling i found this two interesting links, but none specifically mentions OpenBSD: Enabling high performance data transfers http://www.psc.edu/networking/projects/tcptune/ TCP tuning cookbook http://proj.sunet.se/E2E/tcptune.html This other paper is about OpenBSD, but i do not know how accurate is it: Network and speed performance guide (OpenBSD) https://calomel.org/network_performance.html Opinions? Marcos Markus Hennecke escribis: Jesus Sanchez schrieb: Jean-Frangois SIMON escribis: Hi all, It looks like the max bandwidth of ftp is somehow 350 Kb/s. Is this normaland if so can it be increased ? ?? it must be your bandwidth limit, there's nothing about a 350 kb/s limit anywhere. please, read carefulle the ftp manpage. As there are some information missing, I look into my crystal ball and see that Jean-Frangois is downloading with help of the ftp program via DSL which is either 6Mbit or faster. Due to the latency of the DSL line the standard settings for net.inet.tcp.recvspace (see sysctl) are not correct for this kind of setup. He should try to increase it, for me 65536 works on 6Mbit DSL. Please tell me in case this is all wrong so that I can order a new crystal ball! Enough guessing, HTH Markus
Re: ftp limits bandwidth
2009/6/21 Jean-Frangois SIMON jfsimon1...@gmail.com It looks like filezilla uses several transfert at the same time to reach 1Mo/s That indeed appears to be the case. From http://itmanagement.earthweb.com/entdev/article.php/3802111/FileZilla-One-Swe et-Free-FTP-Client.htm : A multiple transfer function for example can support more than one transfer thread at a time; that's a big help when manipulating numerous smaller files. If multiple threads aren't enough, FileZilla will go you one better by allowing multiple instances. That is, more than one copy of Firezilla can be up and running at the same time. In practice this offers the possibility of uploading to multiple FTP servers or connecting to a single FTP server as more than one user. Multiple FTP transfers yay or nay are a tough call -- on the one hand, it's not nice, it's cheating. OTOH, everybody and their grandmother have been doing multiple transfers for ages. In Filezilla, if you go to Edit -- Settings -- Transfers and set Maximum simultaneous transfers to 1, does Filezilla still transfer faster than OpenBSD's stock ftp(1)? regards, --ropers
Re: ftp limits bandwidth
Hi, Thanks for clarification. Never said stock ... OBSD's brilliant. Thnks ;) 2009/6/21 ropers rop...@gmail.com 2009/6/21 Jean-Frangois SIMON jfsimon1...@gmail.com It looks like filezilla uses several transfert at the same time to reach 1Mo/s That indeed appears to be the case. From http://itmanagement.earthweb.com/entdev/article.php/3802111/FileZilla-One-Swe et-Free-FTP-Client.htm : A multiple transfer function for example can support more than one transfer thread at a time; that's a big help when manipulating numerous smaller files. If multiple threads aren't enough, FileZilla will go you one better by allowing multiple instances. That is, more than one copy of Firezilla can be up and running at the same time. In practice this offers the possibility of uploading to multiple FTP servers or connecting to a single FTP server as more than one user. Multiple FTP transfers yay or nay are a tough call -- on the one hand, it's not nice, it's cheating. OTOH, everybody and their grandmother have been doing multiple transfers for ages. In Filezilla, if you go to Edit -- Settings -- Transfers and set Maximum simultaneous transfers to 1, does Filezilla still transfer faster than OpenBSD's stock ftp(1)? regards, --ropers
pfctl no longer showing table details in 4.5
Hi,
I've just finished upgrading one of our systems from OpenBSD 4.2 to 4.5.
I've run into a small problem with pfctl as it's no longer showing the
details for each individual IP address in our tables, just the date the
table was last cleared.
/etc/pf.conf:
=
table test { 1.1.1.1/32 1.1.1.2/32 }
pass in from test
pass out to test
# pfctl -T show -t test
1.1.1.1
1.1.1.2
# pfctl -T show -t test -vv
1.1.1.1
Cleared: Sun Jun 21 15:07:38 2009
1.1.1.2
Cleared: Sun Jun 21 15:07:38 2009
On OpenBSD 4.2 typing the last command would show more details, such as the
number of states, in/out pass, in/out block, etc. for each IP address in
the table.
--
Egbert Krook
System/Network Engineer
Amarin Printing and Publishing Public Co., Ltd.
Re: pfctl no longer showing table details in 4.5
* Egbert Krook egbert.kr...@amarin.co.th [2009-06-21 11:58]: I've run into a small problem with pfctl as it's no longer showing the details for each individual IP address in our tables, just the date the table was last cleared. really. reading the manpage would solve your confusion. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg Amsterdam
scrub - match scrub
I updated my home gateway from 4.5-stable to -current and consequently had to update the scrub part of my pf.conf. Old: scrub on enc0 inet6 all max-mss 1362 scrub on enc0 inet all max-mss 1398 scrub in all scrub out on $ext4 all max-mss 1440 New: match on enc0 inet6 all scrub (max-mss 1362) match on enc0 inet all scrub (max-mss 1398) match out on $ext4 all scrub (max-mss 1440) Let's see how this works on enc0 (.1, ::1 is the gateway): 13:23:29.872301 (authentic,confidential): SPI 0x394de551: 172.16.1.98 172.16.1.1: 172.16.1.98.7007 172.16.0.1.22: S [tcp sum ok] 1091414420:1091414420(0) win 16384 mss 1460,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 1529218902 0 (DF) (ttl 64, id 55274, len 64) (DF) (ttl 64, id 57618, len 84) 13:23:29.872456 (authentic,confidential): SPI 0x96c33c4f: 172.16.1.1 172.16.1.98: 172.16.0.1.22 172.16.1.98.7007: S [tcp sum ok] 734342523:734342523(0) ack 1091414421 win 16384 mss 1398,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3492388531 1529218902 (ttl 64, id 60777, len 64) (ttl 64, id 2922, len 84, bad cksum 0!) Weird. Why is max-mss only applied in the outgoing direction? Let's try IPv6: 13:24:35.948035 (authentic,confidential): SPI 0x05c55eb6: 2001:6f8:124a:1:20e:35ff:fee5:1333 2001:6f8:124a:1::1: 2001:6f8:124a:1:20e:35ff:fee5:1333.37002 2001:6f8:124a::1.22: S 146265356:146265356(0) win 16384 mss 1440,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3373752058 0 [flowlabel 0x73dae] (len 44, hlim 64) (len 84, hlim 64) 13:24:35.948203 (authentic,confidential): SPI 0x3add16a2: 2001:6f8:124a:1::1 2001:6f8:124a:1:20e:35ff:fee5:1333: 2001:6f8:124a::1.22 2001:6f8:124a:1:20e:35ff:fee5:1333.37002: S 608163183:608163183(0) ack 146265357 win 16384 mss 1476,nop,nop,sackOK,nop,wscale 0,nop,nop,timestamp 3665143149 3373752058 (len 44, hlim 64) (len 84, hlim 64) Huh, max-mss isn't applied at all. Are there any configuration pitfalls I missed? Or is scrub max-mss really broken? -- Christian naddy Weisgerber na...@mips.inka.de
Re: pfctl no longer showing table details in 4.5
On Thu, Jun 18, 2009 at 04:16:02PM +0700, Egbert Krook wrote: Hi, I've just finished upgrading one of our systems from OpenBSD 4.2 to 4.5. I've run into a small problem with pfctl as it's no longer showing the details for each individual IP address in our tables, just the date the table was last cleared. You need the counters option for each table. -- Jason Dixon DixonGroup Consulting http://www.dixongroup.net/
Check out Neuters.net
Hello My Good Friend, I'm happy to inform you about my success in getting those funds transferred under the cooperation of a new partner from GERMANY. Presently i'am in GERMANY for investment projects with my own share of the total sum. meanwhile,i didn't forget your past efforts and attempts to assist me in transferring those funds, despite that it failed us some how. Your Draft check of 900,000.00USD has been deposited with Mr.Ken Elvis Of Finance Bank Plc. E-mail: mrkenel...@icq.ir I will not be chance to check my mail and therefore you should contact him and receive your fund that is currently with him. Please contact him asap for immediate delivery. Yours Faithfully, Mr.Joseph Obialo. This message was generated by a visitor to the Neuters.net web site at www.neuters.net.
Re: Activation of TrueType hinting in 4.5
I give up! I wasn't able to have good looking msfonts without antialias. So, I activated font antialias in my desktop. In this way the msfonts in normal mode are rendered correctly, that is they appear exactly as they would under Windows. The problem is with the bold texts: they take up more space, the characters seems to be more spaced, then under Windows. Is it a known difference? Is there a way to make bold fonts appear exactly as they do in Windows? Thanks. Federico Giannici wrote: For my work I have to look at web pages EXACTLY as they appear on Windows (with the same appearance, dimension and spacing). With OpenBSD 4.1, I disabled fonts antialias and recompiled the FreeType library with the patented TrueType hinting. It worked perfectly, and msttcorefonts appear exactly as they do on Windows. Now I tried to upgraded my desktop PC to OpenBSD 4.5, but I wasn't able to activate the TrueType hinting. I have commented out the #define TT_CONFIG_OPTION_UNPATENTED_HINTING line in xenocara/lib/freetype/include/freetype/config/ftoption.h and recompiled the library. The change had some effect because the library changed it's size, but there was NO change in font appearance. I tried with Firefox, Thunderbid, Pidgin... They all continue to show ugly fonts (without hints). What I missed? Please give me any hint, I cannot remain with 4.1 forever... :-( Thanks. -- ___ __ |- giann...@neomedia.it |ederico Giannici http://www.neomedia.it ___
Re: ftp limits bandwidth
On 2009-06-20, Markus Hennecke markus-henne...@markus-hennecke.de wrote: Jesus Sanchez schrieb: Jean-Frangois SIMON escribis: Hi all, It looks like the max bandwidth of ftp is somehow 350 Kb/s. Is this normaland if so can it be increased ? ?? it must be your bandwidth limit, there's nothing about a 350 kb/s limit anywhere. please, read carefulle the ftp manpage. As there are some information missing, I look into my crystal ball and see that Jean-Frangois is downloading with help of the ftp program via DSL which is either 6Mbit or faster. Due to the latency of the DSL line the standard settings for net.inet.tcp.recvspace (see sysctl) are not correct for this kind of setup. He should try to increase it, for me 65536 works on 6Mbit DSL. 65535 works better in the presence of certain broken network equipment (because it avoids bumping wscale).
sendmail: restrict sender domain for authenticated users
Hi all I have sendmail on 4.4 as MX and relay for outgoing mail using smtp auth. Now some users started using arbitrary from: addresses in their mail clients. I would like to restrict those sender addresses to the local domains, i.e. allow them to send mail from u...@my.domain or u...@my.other.domain, and reject their mails from u...@foreign.domain, preferably during the smtp dialog between MUA and sendmail. I've searched the sendmail docs and google, but can't find how to do this. Is it possible at all? thx /markus
Re: scrub - match scrub
Christian Weisgerber na...@mips.inka.de wrote: Or is scrub max-mss really broken? This has been resolved. It has been pointed out to me that tcpdump sees the packets before pf, so the inbound mss fixup hasn't been applied yet. Looking at packets routed to another host shows that max-mss scrubbing for v4 works in both directions. max-mss for v6 is indeed missing, but this is being fixed. -- Christian naddy Weisgerber na...@mips.inka.de
Re: routing/network question
*aham* ... was this a really stupid question? Maybe I just wrote too many words. In simple terms, once a new route has been added to the routing table, all traffic should consider the new route right? So, is the ppp interface treated differently when it comes to routing in OpenBSD? --patrick On Sun, Jun 14, 2009 at 9:21 AM, patrick keshishianpkesh...@gmail.com wrote: Hello, I ran into an interesting problem trying to port some code to linux and thinking about it a bit, I am not sure which has the more desirable behavior: linux or openbsd. Say host h1 starts exchanging some packets with host h2, which is on a remote network (n2). As this is going on, h1 establishes a ppp connection where h3 is the remote end point (and also in network n2). There is a route added for n2 with gateway h3. so from this point on, any traffic to any host within n2 will/should go through the ppp interface. right? netstat -rnfinet shows: ... 1x8.18x.200/23 B B 1x8.18x.201.136 B B UGS B B B B 0 B B B B 0 B B - B B 8 ppp0 1x8.18x.201.136 B B 1x8.18x.201.132 B B UH B B B B 1 B B B B 0 B B - B B 4 ppp0 ... Where 1x8.18x.201.132 is the local ip assigned to h1 via ppp and 1x8.18x.201.136 is the remote host (h3) ip (and gateway for n2). Sending further packets, using the same socket descriptor, from h1 to h2 should go through which interface? the ppp interface or the real physical interface which was being used prior to the ppp connection (xl0, etc.)? openbsd and linux seem to behave differently (a shocker, I am sure). in linux, any further traffic between h1 and h2 is now routed through the ppp interface. however, in openbsd the packets continue being sent over the same initial interface. to solve the (my?) problem on linux, i have to add a static route to h2 specifying the default gateway for h1's network (not h3). --patrick
mettre � jour vos informations de compte
Sicuriser votre compte Orange! Cher client Orange ., Sont en mesure de sicuriti dans d'autres afin de protiger nos clients des renseignements sur toute activiti suspecte. Pour garantir votre Optus compte s'il vous plant visitez le lien ci-dessous: http://r.orange.fr/r/Oid_identification Nous nous excusons pour tout disagriment et nous vous remercions de votre soutien pour nous aider ` mieux vous servir, avec l'intigriti de l'ensemble de Orange .. Pour vous aider, cliquez sur le lien vers votre compte Orange . et de mettre ` jour votre compte. ) 2009 Administration Orange Pty Limited
exec/unexec
Hello! I'm trying to create some customised packages, and noticed that many ports use exec/unexec. I did search through archives and found that, in 2007 Marc Espie says; http://www.techtalkz.com/openbsd/79003-post-install-script-execution-package.html But using @exec/@unexec is more or less like an INSTALL since you can execute commands on installation of the package, am I right ? yes, @exec and @unexec are *still* dangerous, and you *still* must think twice before using them. So, i checked through documentation, and couldn't find a way to execute these scripts with user permisions or a way to disable. By default, port installation run @exec while doing make install or pkg_add. Maybe i'm missing something, could someone please advise? Regards, Cem
Re: exec/unexec
On Sun, Jun 21, 2009 at 12:39 PM, Cem Kayalicemkay...@eticaret.com.tr wrote: Hello! I'm trying to create some customised packages, and noticed that many ports use exec/unexec. I did search through archives and found that, in 2007 Marc Espie says; http://www.techtalkz.com/openbsd/79003-post-install-script-execution-package.html But using @exec/@unexec is more or less like an INSTALL since you can execute commands on installation of the package, am I right ? yes, @exec and @unexec are *still* dangerous, and you *still* must think twice before using them. So, i checked through documentation, and couldn't find a way to execute these scripts with user permisions or a way to disable. By default, port installation run @exec while doing make install or pkg_add. Maybe i'm missing something, could someone please advise? I believe: $ man pkg_add /-I -I If scripts exist for a given package, do not execute them. also, you said you were trying to create some customised packages, in which case you can remove the @exec/@unexec lines from PLIST if you so desire. --patrick
Re: exec/unexec
Hi, Thanks for your reply. -I If scripts exist for a given package, do not execute them. This does not work... I will re-check, but pkg_add -vvvI shows that scripts are executed. Well, one of my client would like to run any 3rd party script only as regular user. Regards, Cem patrick keshishian, 06/21/09 22:54: On Sun, Jun 21, 2009 at 12:39 PM, Cem Kayalicemkay...@eticaret.com.tr wrote: Hello! I'm trying to create some customised packages, and noticed that many ports use exec/unexec. I did search through archives and found that, in 2007 Marc Espie says; http://www.techtalkz.com/openbsd/79003-post-install-script-execution-package.html But using @exec/@unexec is more or less like an INSTALL since you can execute commands on installation of the package, am I right ? yes, @exec and @unexec are *still* dangerous, and you *still* must think twice before using them. So, i checked through documentation, and couldn't find a way to execute these scripts with user permisions or a way to disable. By default, port installation run @exec while doing make install or pkg_add. Maybe i'm missing something, could someone please advise? I believe: $ man pkg_add /-I -I If scripts exist for a given package, do not execute them. also, you said you were trying to create some customised packages, in which case you can remove the @exec/@unexec lines from PLIST if you so desire. --patrick
Re: routing/network question
On Sun, Jun 21, 2009 at 10:36 AM, patrick keshishianpkesh...@gmail.com wrote: *aham* ... was this a really stupid question? Well, you elided useful data by only including part of the netstat output, you obfuscated it to make it harder to read, you failed to even mention what version of OpenBSD you're running, *and* you actually have a solution to your problem. Why should anyone bother to answer? Maybe I just wrote too many words. In simple terms, once a new route has been added to the routing table, all traffic should consider the new route right? So, is the ppp interface treated differently when it comes to routing in OpenBSD? Does this quote from the netstat(8) manpage explain the behavior? Connection oriented protocols normally hold on to a single route for the duration of a connection while connectionless protocols obtain a route while sending to the same destination. Philip Guenther
Bringing OpenVZ-style capabilities to OpenBSD
Hi, Recently some Linux-based VPS servers that I have hosting on were cracked, with the servers' kernels removed and the servers rebooted - some even had the VPS data trashed. This highlights some of the security vulnerabilities in Linux-based solutions and the fact that most OpenVZ servers uses older kernels in production doesn't help matters. It has also been a vision of mine to run OpenBSD-based VPS, though at this point the only way to achieve that is by true virtualization - hence, I would like to propose that we attempt to bring OpenVZ capabilities to the OpenBSD kernel. The biggest problems lie in allowing the kernel to be forked and virtual devices supplied to it, and allowing new instances of the kernel to be forked under the higher security levels. In fact, even allowing the kernel to be forked at all opens a can of worms security wise (recall the Blue Pill POC?). I am well aware of the bsd-mult project, however this focuses on single processes and is unsuitable for these purposes as it only creates a separate memory space and no additional virtual devices. I have created a list for discussing what needs to be done. You can access this list at http://groups.google.com/group/openbsd-virt - I hope to get some open dialog going on and possibly getting a project going. Thanks Regards -- Aaron Mason - Programmer, open source addict - Oh, why does everything I whip leave me?
Re: routing/network question
On Sun, Jun 21, 2009 at 3:42 PM, Philip Guentherguent...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:36 AM, patrick keshishianpkesh...@gmail.com wrote: *aham* B ... was this a really stupid question? Well, you elided useful data by only including part of the netstat output, you obfuscated it to make it harder to read, you failed to even mention what version of OpenBSD you're running, *and* you actually have a solution to your problem. B Why should anyone bother to answer? ouch... but thanks for taking the time to reply. well, you have some good points there, but if you read carefully, my post wasn't of the Hey everyone please help me! flavour. It was of the form I notice this on openbsd and this on this other platform, I wonder which is the expected behavior? I don't have a problem on openbsd per se; the issue was on linux for which I had a workaround for. But, the more I think about this situation, I think I should be seeing the same issue on openbsd as well, but i'm not (yet). I put issue in quotes because I think it isn't really an issue but rather the expected behavior. This was noticed on periodically-updated openbsd macppc-snapshots since pre 4.4 release until one from 2 months ago, which I'm currently running. Maybe I just wrote too many words. In simple terms, once a new route has been added to the routing table, all traffic should consider the new route right? So, is the ppp interface treated differently when it comes to routing in OpenBSD? Does this quote from the netstat(8) manpage explain the behavior? B B Connection oriented protocols normally hold on to a single route B B for the duration of a connection while connectionless protocols obtain a B B route while sending to the same destination. ah, yes. this is good, as it confirms part of my observation; note that i was not specific on the type of socket used, because it did not make a difference. I simply said same socket descriptor, indicating one created prior to the establishment of the new route. e.g., I can start a ping going for the particular host on the remote network, next establish the route and the pings continue out on the physical interface. If I start a new ping, those packets, now, go through the ppp0 interface. As verified with tcpdump. So, it seems, based on my observations, routes are sticky with respect to sockets; even non-TCP sockets, which seems bit odd. Do you not agree? --patrick
Re: routing/network question
On Sun, Jun 21, 2009 at 5:57 PM, patrick keshishianpkesh...@gmail.com wrote: On Sun, Jun 21, 2009 at 3:42 PM, Philip Guentherguent...@gmail.com wrote: On Sun, Jun 21, 2009 at 10:36 AM, patrick keshishianpkesh...@gmail.com wrote: *aham* ... was this a really stupid question? Well, you elided useful data by only including part of the netstat output, you obfuscated it to make it harder to read, you failed to even mention what version of OpenBSD you're running, *and* you actually have a solution to your problem. Why should anyone bother to answer? ouch... but thanks for taking the time to reply. well, you have some good points there, but if you read carefully, my post wasn't of the Hey everyone please help me! flavour. It was of the form I notice this on openbsd and this on this other platform, I wonder which is the expected behavior? Sure, but how should someone decide that the behavior is expected when you leave out chunks of the information that describes your setup? Do I need to have a multipath + ppp setup to be able to help? This was noticed on periodically-updated openbsd macppc-snapshots since pre 4.4 release until one from 2 months ago, which I'm currently running. So you're now running some undisclosed version of 4.5-current? Wait, does that until one from 2 months ago mean that the behavior changed when you most recently updated the snapshot you're running?!? Maybe I just wrote too many words. In simple terms, once a new route has been added to the routing table, all traffic should consider the new route right? So, is the ppp interface treated differently when it comes to routing in OpenBSD? Does this quote from the netstat(8) manpage explain the behavior? Connection oriented protocols normally hold on to a single route for the duration of a connection while connectionless protocols obtain a route while sending to the same destination. ah, yes. this is good, as it confirms part of my observation; note that i was not specific on the type of socket used, because it did not make a difference. I simply said same socket descriptor, indicating one created prior to the establishment of the new route. Sigh. Was it really too hard to say this occurs with both TCP and UDP and even straight ICMPs from ping in your original note? HTH were we supposed to know that *this* time, packets really meant all three of those and wasn't just being used as a shorthand for whatever was being run at the moment? You may be 100% accurate in your use of language, but you're posting to a list where many people are more careless about terms, so the default expectation is that unless someone uses precise terms, they probably haven't considered the distinctions. e.g., I can start a ping going for the particular host on the remote network, next establish the route and the pings continue out on the physical interface. If I start a new ping, those packets, now, go through the ppp0 interface. As verified with tcpdump. So, it seems, based on my observations, routes are sticky with respect to sockets; even non-TCP sockets, which seems bit odd. Do you not agree? Still asking for people to state expectations on zero data. My crystal ball says that that netstat info would have been interesting, but since you apparently only are interested in responses from people that happen to have multipath setups and use ppp, I guess I can't help you. Good luck! Philip Guenther
