Re: Is RFC1323 support flawed? (only with pf enabled)
On Mon, Jan 02, 2006 at 06:51:32PM +0100, Attila Nagy wrote: > Any ideas? RFC1323 support includes TCP window scaling (wscale), which affects pf stateful filtering. There have been bugs with that in the past, but the code in 6.x should contain all fixes for them. Maybe you found a new one. When you say "a simple pass only ruleset", do you mean a ruleset consisting of a single "pass all" rule (i.e. not creating state), or one that includes "pass keep state" (and possibly "scrub") rules? If the latter, there's one possible user mistake that could result in the effects you're seeing. If you filter statefully, but create state not on the initial SYN packet of each TCP connection, but a subsequent one, pf doesn't note the relevant wscale factors (seen only during the first two packets of the handshake), which can have precisely this effect, stalling connections after a while (when one peer starts to actually use large windows, making use of its negotiated wscale factor). It's also possible that this would occur more often with specific OS peers, as the OS (and TCP settings, like receive buffer size) influence the wscale factors being used. To rule this out, make sure you either don't create state at all, or create state on the first SYN when you do (look for any "pass" rules which don't also include "keep state"). pfctl -vss prints the wscale factors being honoured by pf for each state. If that's not it, can you enable pf debug logging (pfctl -xm), note pfctl -si output, then reproduce a failing connection, then run pfctl -si again, compare the output (looking for any counters increasing the obvious ones), and checking /var/log/messages for any lines from pf? Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Is RFC1323 support flawed? (only with pf enabled)
On Tue, Jan 03, 2006 at 09:45:51AM +0100, Daniel Hartmeier wrote: > To rule this out, make sure you either don't create state at all, or > create state on the first SYN when you do (look for any "pass" rules > which don't also include "keep state"). pfctl -vss prints the wscale > factors being honoured by pf for each state. Also note that there is an implicit (invisible) "pass" rule (without "keep state") at the bottom of every ruleset, matching when no rule matches at all. For instance, the following ruleset would show the problem: pass in all keep state Say, the machine has two interfaces and is IP forwarding a connection going through both (incoming on one, outgoing through the other). pf filters each packet on both interfaces (in on the first and out on the second, in on the second and out on the first). In this case, the initial SYN would come in on the first interface, match your explicit rule, and create state on the first interface. This state does NOT cover the packets flowing (in reverse direction) on the other interface, pf evaluates the ruleset again when the initial SYN leaves the second interface. Now the explicit rule does not match (the direction is out, not in), but the packet passes due to the implicit "pass" rule at the end (not creating state). Then the SYN+ACK comes back in through the second interface, doesn't match a state, causes ruleset evaluation, matches your explicit rule, and creates state. Now this state is created based on the SYN+ACK, and hasn't seen the initial SYN, hence pf doesn't properly track wscale factors in this state, and will/might stall the connection eventually. Make sure the implicit "pass" rule is never used, by adding an explicit rule matching everything (the default policy, either blocking everything or passing everything with "keep state") at the top of your ruleset. Daniel ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp performance
I have confirmed that there is no problem with settings of Dummynet. When Host-A/B uses Linux, the throughput of RTT=20ms (using Iperf) is same as that of RTT=0ms. Host-A/B use FreeBSD v6.0 release. Does anyone have experience/suggestion for achieving high throughput with FreeBSD? Michael Vince wrote: > Zongsheng Zhang wrote: > >> Hi, *, >> >> For testing throughput of a TCP connection, the following topology is >> used: >> Host-A ---GB Ethernet--- Dummynet ---GB Ethernet--- Host-B >> >> Host-A/B use FreeBSD v6.0. Sysctl parameters of Host-A/B are: >> kern.ipc.nmbclusters=32768 >> net.inet.tcp.inflight.enable=0 >> net.inet.tcp.sendspace=2097152 # 2M >> net.inet.tcp.recvspace=2097152 # 2M >> >> When RTT in Dummynet is set to 0ms, the throughput (A--B) is about >> 900Mbps. The buffer size is enough to fill a link bandwidth=800Mbps, and >> RTT=20ms. However, if RTT is set to 20ms, the throughput is only about >> 500Mbps. >> >> Are there other parameters which are necessary to adjust? Does anyone >> have suggestion for high throughput? >> >> Thanks in advance. >> >> >> > What are you following on your hosts? Release/stable or current? I only > use just release or stable. > > For your middle router try net.inet.ip.fastforwarding or net.isr.direct > but not at the same time, then try on top enabling polling. > Personally I found enabling polling worked best combined with > net.inet.ip.fastforwarding. > > Andre Oppermann claimed in a post just recently he gets best performance > using just net.inet.ip.fastforwarding without polling but that might be > for just -current, I am not sure. > > You could also try using current, but if I had to guess you already are? > > Regards, > Mike > > -- Zongsheng Zhang [EMAIL PROTECTED] ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Need help WFQ
Hi,
I hope you give me some advice or explaination about Dummynet.
I've googling/experiment for three a month to get the right answer how
to use WF2Q+ with Dummynet. I've a small internet cafe and after 4
years using FreeBSD+Dummynet with hardlink limiting policy. Here for
WF2Q+ implementation
in my internet cafe:
In /etc/rc.firewall look like:
# IP Address variable
ip_cl_01="192.168.0.1/32"
ip_cl_10="192.168.0.10/32"
ip_cl_11="192.168.0.11/32"
ip_cl_12="192.168.0.12/32"
ip_cl_13="192.168.0.13/32"
ip_cl_14="192.168.0.14/32"
ip_cl_50="192.168.0.50/32"
# Bandwidth variable
bw_share="152Kbit/s"
${fwcmd} add 104 queue 1 ip from ${ip_cl_01} to any via ${eth_1}
${fwcmd} add 105 queue 1 ip from any to ${ip_cl_01} via ${eth_1}
${fwcmd} add 106 queue 2 ip from ${ip_cl_10} to any via ${eth_1}
${fwcmd} add 107 queue 2 ip from any to ${ip_cl_10} via ${eth_1}
${fwcmd} add 108 queue 3 ip from ${ip_cl_11} to any via ${eth_1}
${fwcmd} add 109 queue 3 ip from any to ${ip_cl_11} via ${eth_1}
${fwcmd} add 110 queue 4 ip from ${ip_cl_12} to any via ${eth_1}
${fwcmd} add 111 queue 4 ip from any to ${ip_cl_12} via ${eth_1}
${fwcmd} add 112 queue 5 ip from ${ip_cl_13} to any via ${eth_1}
${fwcmd} add 113 queue 5 ip from any to ${ip_cl_13} via ${eth_1}
${fwcmd} add 114 queue 6 ip from ${ip_cl_14} to any via ${eth_1}
${fwcmd} add 115 queue 6 ip from any to ${ip_cl_14} via ${eth_1}
${fwcmd} add 116 queue 7 ip from ${ip_cl_50} to any via ${eth_1}
${fwcmd} add 117 queue 7 ip from any to ${ip_cl_50} via ${eth_1}
${fwcmd} queue 1 config pipe 3 weight 3 mask all
${fwcmd} queue 2 config pipe 3 weight 3 mask all
${fwcmd} queue 3 config pipe 3 weight 3 mask all
${fwcmd} queue 4 config pipe 3 weight 3 mask all
${fwcmd} queue 5 config pipe 3 weight 3 mask all
${fwcmd} queue 6 config pipe 3 weight 3 mask all
${fwcmd} queue 7 config pipe 3 weight 1 mask all
${fwcmd} pipe 3 config bw ${bw_share}
With that rule I want to limit every client (IN/OUT) with ratio:
for ex: client-01 => 3/19 * 152 Kbit/s = 24 Kbit/s
client-10 => 3/19 * 153 Kbit/s = 24 Kbit/s
etc..
I assume all of my client already active using internet. But sometime
"client-11" always get 100 Kbit/s. Does my rule is OK? if not, would
you give me example the right rule for this situation, of couse with
clarification (step by step).
FYI, I use FreeBSD 4.10-RELEASE & FreeBSD 4.11-STABLE.
Thanks You.
--
budsz
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reverse Path Filtering check in ip_input.c
Hello, On Tue, 03 Jan 2006, at 01:39, ?ukasz Bromirski wrote: > Hi, > > Following some short discussion on freebsd-pf I've written (mostly > copied, but let's skip that for a moment) short patch for ip_input.c, > that does uRPF check for incoming packets. > > In some simple words, it's exactly the function ipfw2 is calling when > You specify a rule with `versrcreach', but it's there in core > network processing path and it's controlled via sysctl, so You don't > need any packet filter in system to get the job done. > > If sysctl net.inet.ip.urpf is set to 0 check is disabled, and if > it's set to 1, checking of source address/interface against routing > table is in effect. Checks will skip packets coming on from > loopback or CARP interfaces. > > When the packet is going to be dropped, there's syslog message > generated with source IP address and input interface it came on, > and system counters are increased. > > Patch applies cleanly on ip_input.c version 1.301.2.3 dated 2005/10/09 > (latest RELENG_5 checkout). It will also work with latest RELENG_4 > checkout (ip_input.c version 1.130.2.55 dated 2005/01/02). > > Please note however, this code is for IPv4 only. > > http://lukasz.bromirski.net/projekty/freebsd/ip_input.urpf.diff > SHA1 (ip_input.urpf.diff) = c76319f619a43f1d031e729d361324d3a4d86daf Nice ! > Please also note, there's already similar sysctl in ip_input.c - > it's named ip_checkinterface and does subset of urpf checks, so > while I don't think this patch is going to make into source tree, > maybe it's time for someone wiser than me to review the code and > 'update' ip_input.c code? If this yet to be found wiser guy would not forget the loose check too (verrevpath in ipfw speaking), where packets matching the default route are ok ... :) Cheers, - yann ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Router + ADM64
Hi! What is there to gain in performance choosing AMD64 on a Dell PE1850 (Xeon EMT64) when used as router? /Jon ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reverse Path Filtering check in ip_input.c
Yann Berthier wrote: >If this yet to be found wiser guy would not forget the loose check >too (verrevpath in ipfw speaking), where packets matching the default >route are ok ... :) Actually it does that and will until we'll have option to have two or more default routes. Presently, if packets comes via interface and reply for it should be sent on the same interface (because default route points to it and there are no other routes pointing for the same destination to another interface) it will work. Check fails if there's either interface mismatch, or source is present in routing table but marked as RTF_REJECT/BLACKHOLE one. OpenBSD imported KAME mroute extension that enables them to have more than one route for given destination simultaneously in routing table. I'm looking into it now, as it's very attractive thing, however as Andre is doing rework of network code I'm sure we'll have it sooner or later and then maybe someone will revise old checks already marked as 'XXX' in the code ;) -- this space was intentionally left blank|Łukasz Bromirski you can insert your favourite quote here |lukasz:bromirski,net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reverse Path Filtering check in ip_input.c
On Tue, 03 Jan 2006, at 14:58, ?ukasz Bromirski wrote: > Yann Berthier wrote: > > >If this yet to be found wiser guy would not forget the loose check > >too (verrevpath in ipfw speaking), where packets matching the default > >route are ok ... :) > > Actually it does that and will until we'll have option to have two > or more default routes. > > Presently, if packets comes via interface and reply for it should be > sent on the same interface (because default route points to it and > there are no other routes pointing for the same destination to > another interface) it will work. > > Check fails if there's either interface mismatch, or source is present > in routing table but marked as RTF_REJECT/BLACKHOLE one. My bad, i didn't looked at your patch, I was misleaded by the verrevpath / versrcreach description. > OpenBSD imported KAME mroute extension that enables them to have > more than one route for given destination simultaneously in routing > table. I'm looking into it now, as it's very attractive thing, > however as Andre is doing rework of network code I'm sure we'll have > it sooner or later and then maybe someone will revise old checks > already marked as 'XXX' in the code ;) Amen - yann ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 6.0 release,
On Sat, Dec 31, 2005 at 02:52:14AM +, Paul wrote: > I've just installed FreeBSD 6.0 Release yesterday, I've spend the last > two days trying to resolve a networking problem, the problem is this: > when I try and connect to a domain or an IP for that matter, it takes > several minutes for it to connect + receive the content. It doesn't > seem to effect all addresses though, I've had no problems connecting > to ftp://ftp.freebsd.org to download software etc., nor have I had any > problems connecting to domains inside my LAN. > > As far as I can tell, it isn't a dns problem because I can ping > without any problems. I had a similar problem here, and it was due to IPv6. Grr, I hate it. What happened was: some router was allocating IPv6 prefixes, and so my network interface picks up an IPv6 address. However actually there is no working IPv6 connectivity here. As a result, whenever I try to connect to a site which has both IPv6 and IPv4 addresses, I get a long delay of several minutes while the IPv6 one is tried out, before it falls back to IPv4. To show if this is the problem, use 'ifconfig' to show if your interface has been polluted by an IPv6 address. Then use 'ping6 www.foo.com' where www.foo.com is one of the sites you're having problems with. The problem is hidden by ping because ping only asks the DNS for IPv4 addresses. You can check if a site has an IPv6 address using $ dig www.foo.com. or $ nslookup -q= www.foo.com. IMO, the best solution to this is to remove IPv6 entirely from your kernel (comment out 'options INET6' and recompile). Your life will be much happier. Of course this would not be a problem if the IP stack were to try IPv4 addresses first, falling back to IPv6 if it fails. Of course, if IPv4 were to have precedence over IPv6, then the IPv6 stack would never get exercised. This is one of several problems which have plagued me simply because IPv6 is enabled by default when I don't want or use it. However if that's not the problem, then maybe your problem is with reverse DNS. That is, when you connect from your address (x.x.x.x) to a remote site (y.y.y.y), the remote site may do a reverse DNS lookup for x.x.x.x to try to find your hostname; if it gets a hostname, it will then do a forward DNS lookup to see if it maps back to x.x.x.x. You won't notice this problem as DNS lookups with ping, because you're just mapping www.foo.com to y.y.y.y; you're not trying to convert your own address x.x.x.x back to a domain, as a remote webserver would do. The solution then is to fix your reverse DNS. If your own IP address is 192.0.2.1, then a PTR query for 1.2.0.192.in-addr.arpa. is where you should be looking. Probably you have a lame delegation somewhere in the tree. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: /usr/src/lib/libc/net/res_debug.c: compile problem fixed
On Mon, Jan 02, 2006 at 12:39:26PM +1030, Aluminium Oxide wrote: > Below is the output of `diff res_debug.org.c res_debug.c` > > I've also attached this. > = > 574,575c574,575 > < precsize_aton(strptr) > < char **strptr; > --- > > precsize_aton(char **strptr) > > /* char **strptr; */ > 616,618c616,618 > < latlon2ul(latlonstrptr,which) > < char **latlonstrptr; > < int *which; Suggestion: use unified diff (diff -u res_debug.org.c res_debug.c). It's *much* easier to read. Regards, Brian. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Writing a netgraph module
> probably not too much.. :-) > > has anyome actually looked at it? :-) > > > I can't get to Archie's doc on Daemonnews at the moment so here's my > copy: > http://people.freebsd.org/~julian/netgraph.html Great, Thanks! I did read this paper a while back (actualy, this what turned me on with netgraph to begin with) but the deamonnews article was down. I'll read it carfuly now, along with the source example, and of course, with any specific toungle I'll come back here. Thanks again guys. Squigly -- Squigly [EMAIL PROTECTED] -- http://www.fastmail.fm - Same, same, but different ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reverse Path Filtering check in ip_input.c
Łukasz Bromirski wrote: Yann Berthier wrote: If this yet to be found wiser guy would not forget the loose check too (verrevpath in ipfw speaking), where packets matching the default route are ok ... :) Actually it does that and will until we'll have option to have two or more default routes. Presently, if packets comes via interface and reply for it should be sent on the same interface (because default route points to it and there are no other routes pointing for the same destination to another interface) it will work. Check fails if there's either interface mismatch, or source is present in routing table but marked as RTF_REJECT/BLACKHOLE one. OpenBSD imported KAME mroute extension that enables them to have more than one route for given destination simultaneously in routing table. I'm looking into it now, as it's very attractive thing, however as Andre is doing rework of network code I'm sure we'll have it sooner or later and then maybe someone will revise old checks already marked as 'XXX' in the code ;) Several routes with the same dest would be interesting but how do you select between them? What I'm looking for is a way to make a machine use two totally separate routes depending on the socket address locally.. I'm currenty achieving this with ipfw fwd rules, bu that has side effects that are troublesome.. The vimage patches would do this for me but they are only for 4.x and I see no way to do what they do in a truely extensible manner that woruld work for 5.x and beyond.' ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Writing a netgraph module
Squigly wrote: probably not too much.. :-) has anyome actually looked at it? :-) I can't get to Archie's doc on Daemonnews at the moment so here's my copy: http://people.freebsd.org/~julian/netgraph.html Great, Thanks! I did read this paper a while back (actualy, this what turned me on with netgraph to begin with) but the deamonnews article was down. I'll read it carfuly now, along with the source example, and of course, with any specific toungle I'll come back here. Thanks again guys. Squigly remember that things changed a bit after teh 5.x transition. teh video referred to covers that change a bit. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tcp performance
Zongsheng Zhang wrote: I have confirmed that there is no problem with settings of Dummynet. When Host-A/B uses Linux, the throughput of RTT=20ms (using Iperf) is same as that of RTT=0ms. Host-A/B use FreeBSD v6.0 release. Does anyone have experience/suggestion for achieving high throughput with FreeBSD? In June 2005, a former fellow-student and me did such tests using FreeBSD 5.4. Our test setup was the same as yours. We used three Dell Poweredge 1850's (iirc) with dual Xeon processors, PCI-X gbit 'em' interfaces and we used iperf too. Performance was terrible with high RTT's. We tried all kinds of things: SMP or UP kernels, polling (and it's settings), fiddling with HZ on the dummynet-host, lowering and raising the IP input queue maxlen, etc. In the end we pinged the sending host over it's external/non-test interface. We saw enormous packet loss and latency up to 5 -seconds-. This lead us to believe the TCP or socket buffer code (but probably the former, since the socket buffer is appended to using a simple tail pointer) was that inefficient that the kernel wasn't doing much else than sending TCP packets. Sadly, we did not have any time to research it any more. Perhaps Andre Opperman can shed some light on this, seeing as he's hacking away at the TCP/IP code now.. In any case, when his work is committed, you should have a lot more performance :) -- Pieter ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Reverse Path Filtering check in ip_input.c
Julian Elischer wrote: > Several routes with the same dest would be interesting but how do you > select between them? Via some sort of load-balancing or policy routing mechanism on network stack level? There is so much we miss in current FreeBSD stack in this area it's hard to say some single feature will change everything completely. I only mentioned OpenBSD KAME import because they are clearly going for having multihomed router fully operable and we're lacking in this area. Also, Henning, Claudio and other team members push for routing protocols interoperability (OpenOSPFd and OpenBGPd integration) which again is far from what we're currently able to do and integrate. Andre as I understand is cleaning code and making everything run a lot faster (especially routing operation optimization is great thing), but I'm worried that being able to have things like administrative distance for various routing protocols (which would enable router with for example OSPF and BGP to choose routes from both protocols in clear selection process), ability to store few paths for the same destination via different interfaces or next-hops is a long road ahead. But there's always someone who has to do first step... ;) -- this space was intentionally left blank|Łukasz Bromirski you can insert your favourite quote here |lukasz:bromirski,net ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Client Load Balancing: LSNAT-router using IPFW and NATD on FreeBSD 6.0
Client Load Balancing: LSNAT-router using IPFW and NATD on FreeBSD 6.0
The Internet gateways must reside in different logical networks for this
configuration to work.
1. Compile Custom Kernel
options IPFIREWALL
options IPFIREWALL_FORWARD
options IPDIVERT
options IPFIREWALL_FORWARD_EXTENDED
2. Configure System (/etc/rc.conf)
firewall_enable="yes"
firewall_type="/etc/ipfw.rules"
ifconfig_ste0="195.16.87.38/29"
ifconfig_ste0_alias0="192.168.102.62/24"
ifconfig_fxp0="192.168.10.1/24"
defaultrouter="192.168.102.1"
gateway_enable="yes"
natd_enable="yes"
natd_flags="-f /etc/natd.conf"
3. Configure NATD (/etc/natd.conf)
instance default
alias_address 192.168.102.62
instance other
alias_address 195.16.87.38
port 8669
globalport 9000
4. Configure IPFW (/etc/ipfw.rules)
-f flush
add skipto 2 ip from any to 192.168.102.62 in via ste0
add skipto 3 ip from any to 195.16.87.38 in via ste0
add divert 9000 ip from any to any out via ste0
add skipto 4 ip from { 192.168.102.62 or 195.16.87.38 } to any out
via ste0
add prob .5 skipto 2 ip from any to any out via ste0
add skipto 3 ip from any to any out via ste0
add skipto 4 ip from any to any
add 2 divert natd ip from any to any
add skipto 4 ip from any to any
add 3 divert 8669 ip from any to any
add skipto 4 ip from any to any
add 4 check-state
add deny ip from 192.168.10.0/24 to any via ste0
add allow ip from me to me via lo0 keep-state
add deny ip from me to any in
add allow ip from 195.16.87.38 to { me or 195.16.87.32/29 or
192.168.102.0/24 or 192.168.10.0/24 } keep-state
add forward 195.16.87.33 ip from 195.16.87.38 to any keep-state
add allow ip from me to any keep-state
add deny ip from me to any
add allow icmp from any to me icmptypes 3,4,8,11 keep-state
add deny ip from any to me
add allow ip from 192.168.10.0/24 to any keep-state
add deny ip from 192.168.10.0/24 to any
add allow icmp from any to 192.168.10.0/24 icmptypes 3,4,11 keep-state
add deny ip from any to 192.168.10.0/24
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Unexpected EADDRINUSE
Some of our regression tests fail randomly on FreeBSD with an unexpected EADDRINUSE error. We didn't see this problem with 4.7, but we see it in 4.11, 5.4, and 6.0. We don't see this behavior on any of our other supported platforms. We investigated the problem, and managed to come up with a way to reproduce the problem outside of our regression test suite. To reproduce, first start the sink with "python sink.py". Then run "python conn.py". When we do this, we get EADDRINUSE after a short time. Since we're binding the connecting socket to the wild port, this shouldn't happen. If the s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) call is removed, the problem seems to go away. The setting of SO_REUSEADDR is there because that's what some perhaps too-generic make-a-socket library code did; we realize it's not technically needed. Nevertheless, we don't see why it should fail either :). I looked at the differences between 4.7 and later kernels but didn't manage to figure out how the changes caused this change in behavior. Regards, /Bob ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Unexpected EADDRINUSE
Sorry my attachments didn't make it :)
#
# sink.py
#
import socket
import traceback
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 12345))
s.listen(5)
while True:
try:
n = s.accept()[0]
d = None
while d != '':
d = n.recv(100)
n.close()
except socket.error:
pass
#
# conn.py
#
import socket
import traceback
n = 0
while True:
try:
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 0))
print s.getsockname()
s.connect(('127.0.0.1', 12345))
s.close()
n += 1
if n > 0 and n % 1000 == 0:
print n
except Exception, e:
traceback.print_exc()
break
print n
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Direct routing
I'd like to do something like described on the LVS pages http://www.linuxvirtualserver.org/VS-DRouting.html, that is route requests to another server and answer from this second server directly to the client. How can I do it on FreeBSD? -- Thanks, Karel Miklav ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Direct routing
Karel Miklav wrote: > I'd like to do something like described on the LVS pages > http://www.linuxvirtualserver.org/VS-DRouting.html, that is route > requests to another server and answer from this second server > directly to the client. How can I do it on FreeBSD? You can use lsnat. http://www.enterasys.com/products/whitepapers/load-sharing-nat/ -redirect_address localIP[,localIP[,...]] publicIP These forms of -redirect_port and -redirect_address are used to transparently offload network load on a single server and distribute the load across a pool of servers. This function is known as LSNAT (RFC 2391). For example, the argument tcp www1:http,www2:http,www3:http www:http means that incoming HTTP requests for host www will be trans- parently redirected to one of the www1, www2 or www3, where a host is selected simply on a round-robin basis, without regard to load on the net. http://www.freebsd.org/cgi/man.cgi?query=natd ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
