RE: squeeze more performance out of natd? - some gprof stats
attached are some gprof stats - it seems that sendto() is taking most of the time... does this mean that nothing can be done about it? what affects the speed of sendto() returning... i have the following boosted kernel params: net.local.stream.sendspace: 8192 net.local.stream.recvspace: 8192 net.local.dgram.recvspace: 4096 net.inet.tcp.sendspace: 16384 net.inet.tcp.recvspace: 16384 net.inet.udp.recvspace: 41600 net.inet.raw.recvspace: 8192 and the ulimit -a shows a healthy max proc /fds... the kernel option maxusers is set to 1024. cpu time (seconds) unlimited file size (blocks) unlimited data seg size (kbytes) 524288 stack size (kbytes)65536 core file size (blocks)unlimited resident set size (kbytes) unlimited locked-in-memory size (kb) unlimited processes 16403 file descriptors 32808 socket buffer size (kb)unlimited i do note that sometimes the SendNeedIcmpFrag is called after sendto() - i guess thats due to the sendto() not happening atomically at that particular time. my earlier thoughts that it migt be select() don't seem to be reflected by the gprof output below? any advice from those with more profiling experience would be gratefully recieved. the top bit of gprof attched... --- gprof natd natd.gmon -- called/total parents index %timeself descendents called+selfname index called/total children [1] 99.90.23 24.49 main [1] 0.14 23.19 94551/94551 DoAliasing [2] 1.040.00 94552/94552 select [7] 0.000.08 1/1 ParseArgs [19] 0.040.00 189104/189104 bzero [28] 0.000.00 1/1 SetAliasAddressFromIfName [67] 0.000.00 1/2 PacketAliasSetMode [66] 0.000.00 1/1 PacketAliasInit [79] 0.000.00 1/1 printf [89] 0.000.00 2/4 socket [119] 0.000.00 2/3 siginterrupt [126] 0.000.00 2/3 signal [128] 0.000.00 1/1 openlog [150] 0.000.00 1/1 _bind [658] 0.000.00 1/1 _shutdown [663] 0.000.00 1/27362 __error_unthreaded [639] --- 0.14 23.19 94551/94551 main [1] [2] 94.30.14 23.19 94551 DoAliasing [2] 0.05 20.19 94551/94551 FlushPacketBuffer [3] 1.160.00 94551/94551 recvfrom [5] 0.050.91 50094/50094 PacketAliasOut [8] 0.040.79 44457/44457 PacketAliasIn [9] --- 0.05 20.19 94551/94551 DoAliasing [2] [3] 81.80.05 20.19 94551 FlushPacketBuffer [3] 20.190.00 94551/94552 _sendto [4] --- 0.000.00 1/94552 send [70] 20.190.00 94551/94552 FlushPacketBuffer [3] [4] 81.6 20.190.00 94552 _sendto [4] --- 1.160.00 94551/94551 DoAliasing [2] [5] 4.71.160.00 94551 recvfrom [5] --- 94551 SendNeedFragIcmp [6] 0.080.44 44457/94551 PacketAliasIn [9] 0.090.50 50094/94551 PacketAliasOut [8] [6] 4.50.170.94 94551+94551 SendNeedFragIcmp [6] 0.020.36 50094/50094 FindUdpTcpOut [14] 0.020.31 44457/44457 FindUdpTcpIn [17] 0.050.00 94551/94551 GetAckModified [26] 0.040.00 94551/94551 GetAliasAddress [29] 0.020.00 50094/50094 ProxyCheck [33] 0.020.00 50094/50594 GetAliasPort [32] 0.020.00 50094/50094 GetStateOut [34] 0.020.00 44457/44957 GetOriginalPort [35] 0.020.00 44457/44457 GetProxyAddress [36] 0.010.00 44457/44457 GetProxyPort [37] 0.010.00 44457/44957 GetOriginalAddress [44] 0.010.00
error writing routing socket, not enough buffer space.
After spending a few days, trying to find any scrap of information on the web and coming up empty, I make a last try here before nuking my freebsd box. I'm running FreeBSD 4.4 on an Duron 800, 256Mb ram, 3x3com 905c. The box is only running zebrad and bgpd. After booting the box, putting it on the network, and starting the bgpd and zebra, it seems to be working ok. But it does not route correctly, some traffic is working ok, but mostly it's not. I also get an error when trying to add/change a static route : error writing to routing socket : not enough buffer space and sometimes : disk quota exceeded when trying to do the same. Any pointers on where to look to fix this problem? Best regards Are Øhrn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Netgraph LMC T3 Support?
Does netgraph support the LMC T3 interface? I am having trouble getting netgraph to find the interface. Any reply would be greatly appreciated. Thanks in advance, Jay HoffmanMHO Networks(303) 584-9711
Bug in stateful code?
I've sent this to Luigi and a couple of other folks without reply, so here it is. I'm seeing what I believe to be a bug in the stateful filter code for ipfw/ip_fw. Here's my original message: = Running ipfw w/natd, connections through the gateway are dying. Two dynamic rules get instantiated for each connection through the gateway -- one with NAT'd addresses and one revealing the private addresses $on = external net = X.Y.Z/24 $in = internal net = A.B.C/24 (192.168.1.0/24) the external IP is X.Y.Z.23 the internal IP is A.B.C.1 firewall rules: [some static rules...] $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow tcp from $in to any setup keep-state $fw add allow udp from $in to any keep-state $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic rules to appear: 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 Note 02400 -- this connection timer seems to indicate that it is waiting for a completed 3-way handshake and hasn't seen the other SYN. The connection dies because the time counts down. The timer for 02200 doesn't count down because the keep-alives are resetting it. Any insight as to why this is happening? Seems like a bug in the state machine. I could be convinced otherwise, but it seems that these two rules should see the connection as being in the same state -- they both see the same packets. BTW, I could simplify this by safely allowing $fw add divert natd ip from any to any via $external_interface $fw add check-state $fw add allow ip from $in to any $fw add allow ip from any to $in $fw add allow tcp from $on to any setup keep-state $fw add allow udp from $on to any keep-state But the dynamic rule on the public side still seem to be using net.inet.ip.fw.dyn_syn_lifetime instead of net.inet.ip.fw.dyn_ack_lifetime. Comments? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
[Redirected to -net] On Thu, Feb 14, 2002 at 11:39:37AM -0500, Garrett Wollman wrote: > < said: > > > ping -s 127.1 1.2.3.4 > > telnet -S 127.1 1.2.3.4 > > If someone explicitly overrides source-address selection, they are > presumed to know WTF they are doing, and the kernel should not be > trying to second-guess them. > That "someone" could be a bad guy playing dirty games with your box and certainly knowing what he's doing. :-) So far, noone gave me a real example where using of net 127 outside loopback would be useful. If there such an example exists, we should wrap all three checks into a sysctl, including ip_input(), ip_output(), and in_canforward() parts, where ip_input() exists for almost a year, and in_canforward() existed since 1987. -- Ruslan, who just wants a consistency here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
On Thu, Feb 14, 2002 at 08:42:53AM -0800, Michael Sierchio wrote: > > I've sent this to Luigi and a couple of other folks without reply, > so here it is. the reply was that keep-state and natd are very hard to use together, and besides it is rather useless because natd is stateful by itself. This said, we have only so much time to do things. Sure, i do not exclude a-priori the possibility of a bug, but it sounds more lilely to be a misconfiguration of your ruleset, and since the example you are presenting has no reasonable application (that i can see -- again, i'm happy to be proved wrong), i do not feel like spending an hour or two trying to infer what is on your [some static rules], and i'll happily leave you the job to explain where the bug (which means reconstruct the flow of packets in and out of the ipfw and show which one is dealt in the wrong way). cheers luigi > I'm seeing what I believe to be a bug in the stateful filter code > for ipfw/ip_fw. Here's my original message: > > = > > Running ipfw w/natd, connections through the gateway are dying. Two > dynamic > rules get instantiated for each connection through the gateway -- one > with NAT'd addresses and one revealing the private addresses > > $on = external net = X.Y.Z/24 > $in = internal net = A.B.C/24 (192.168.1.0/24) > > the external IP is X.Y.Z.23 > the internal IP is A.B.C.1 > > firewall rules: > > [some static rules...] > > $fw add divert natd ip from any to any via $external_interface > > $fw add check-state > > $fw add allow tcp from $in to any setup keep-state > $fw add allow udp from $in to any keep-state > > $fw add allow tcp from $on to any setup keep-state > $fw add allow udp from $on to any keep-state > > > An ssh connection from A.B.C.4 to X.Y.Z.44 causes the following dynamic > rules > to appear: > > > 02400 15 3197 (T 16, slot 760) <-> tcp, X.Y.Z.23 1549<-> X.Y.Z.44 22 > 02200 45 9151 (T 296, slot 913) <-> tcp, A.B.C.4 1549<-> X.Y.Z.44 22 > > Note 02400 -- this connection timer seems to indicate that it is waiting for > a completed 3-way handshake and hasn't seen the other SYN. The connection > dies > because the time counts down. The timer for 02200 doesn't count down > because > the keep-alives are resetting it. > > Any insight as to why this is happening? Seems like a bug in the state > machine. > I could be convinced otherwise, but it seems that these two rules should > see the connection as being in the same state -- they both see the same > packets. BTW, I could simplify this by safely allowing > > > $fw add divert natd ip from any to any via $external_interface > > $fw add check-state > > $fw add allow ip from $in to any > $fw add allow ip from any to $in > > $fw add allow tcp from $on to any setup keep-state > $fw add allow udp from $on to any keep-state > > But the dynamic rule on the public side still seem to be using > net.inet.ip.fw.dyn_syn_lifetime instead of net.inet.ip.fw.dyn_ack_lifetime. > > Comments? > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-ipfw" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
Luigi Rizzo wrote: > the reply was that keep-state and natd are very hard to use > together, and besides it is rather useless because natd is stateful > by itself. natd is stateful, but provides no protection for inbound IP traffic that is destined for the filtering host itself. The ruleset *is* particularly useful, since the host in question is both a router for nat'd hosts and a dns and mail server. I'd like to preserve stateful filtering rules for packets that originate at and are destined for the host itself. > ..., i do not feel like spending > an hour or two trying to infer what is on your [some static rules], > and i'll happily leave you the job to explain where the bug (which > means reconstruct the flow of packets in and out of the ipfw and > show which one is dealt in the wrong way). I'd be happy to share the static rules -- and AFAIK I did give a hint as to what the problem is. What kind of evidence do you want, in particular? I have a tcpdump that shows the packet exchange, shows SYN from each host, and demonstrates that the dynamic rule is in the wrong state, using the wrong timer. This could easily have something to do with the interaction of ipfw and natd, but I'm just reporting the observable phenomena. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
gated config
Ok, I'm trying to use gated. Here's my setup... I have 2 machines in
different offices, each with an internal and external ethernet
interface. There is a gif0 tunnel between the external interfaces tied
down to a 10.x.x.x address assigned to lo1.
I've tried using the following config:
bgp off;
egp off;
ospf off;
rip on {
broadcast;
interface fxp0;
interface gif0;
interface fxp1 noripin noripout;
};
export proto rip interface gif0 {
proto direct {
10.20.0.0 mask 255.255.0.0 metric 1;
10.254.254.76 mask 255.255.255.252 metric 1;
};
};
export proto rip interface fxp0 {
proto direct {
10.20.0.0 mask 255.255.0.0 metric 1;
10.254.254.76 mask 255.255.255.252 metric 1;
};
};
import proto rip interface gif0 {
all;
};
import proto rip interface fxp0 {
all;
};
However, it doesn't seem to send out any routing updates over the gif0
tunnel. What am I doing wrong? I need to make sure it doesn't accept
or broadcast routes out the fxp1 interface also. And it also should
*not* broadcast a default route.
It needs to send routes acquired from other routers on each network
across the tunnel and be broadcast out to the other network.
I guess OSPF would work also. Does anyone have a working config for
this type of situation that they could post? (either ospf or rip)
Or any working config for that matter?
Thanks.
Jay
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
>>the reply was that keep-state and natd are very hard to use >>together, and besides it is rather useless because natd is stateful >>by itself. >natd is stateful, but provides no protection for inbound IP traffic >that is destined for the filtering host itself. I have personally looked at natd & stateful ipfw rules, and have concluded that it logically impossible to get it to work. Thus I made a ipfw rulelist that utilizes the statefulness of natd. I hope this helps you in making your own rulelist. tl0 is the interface on internal LAN lnc0 is the interface on external LAN #divert all http requests from internal network to quid cache add 00510 fwd 172.30.0.1 tcp from 172.30.0.0/16 to any 80 in via tl0 add 00520 fwd 172.30.0.1 tcp from 172.20.0.0/16 to any 80 in via tl0 add 00530 fwd 172.30.0.1 tcp from 192.168.0.0/24 to any 80 in via tl0 #allow all traffic to/from internal network add 01000 allow all from any to any via tl0 #translate incoming packets (NAT) add 3 divert natd all from any to in via lnc0 #allow incoming packets for hosts on internal network #(Since we translated them, we're sure they belong to existing #connection) add 30110 allow all from any to 172.20.0.0/16 in via lnc0 add 30111 allow all from any to 172.30.0.0/16 in via lnc0 add 30112 allow all from any to 192.168.0.0/24 in via lnc0 #allow SSH from add 30200 allow tcp from to 22 in via lnc0 add 30210 allow tcp from 22 to out via lnc0 #allow DNS queries to UUnet DNS servers add 30300 allow udp from 53 to in via lnc0 add 30310 allow udp from to 53 out via lnc0 add 30320 allow udp from 53 to in via lnc0 add 30330 allow udp from to 53 out via lnc0 #allow outgoing traffic from internal hosts #(use skipto 34000 instead of allow because they still need translation) add 31010 skipto 34000 all from 172.20.0.0/16 to any out via lnc0 add 31020 skipto 34000 all from 172.30.0.0/16 to any out via lnc0 add 31030 skipto 34000 all from 192.168.0.0/24 to any out via lnc0 #allow outgoing connections from local machine (using dynamic rules) add 32000 allow all from to any out via lnc0 keep-state #block and log everything that hasn't been allowed so far add 33000 deny log all from any to any Greets, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
At 22:25 14-2-2002 +0100, Rogier R. Mulhuijzen wrote: SNIP Oops, forgot a few rules at the end (bad copy/paste) So here it is again. tl0 is the interface on internal LAN lnc0 is the interface on external LAN #divert all http requests from internal network to quid cache add 00510 fwd 172.30.0.1 tcp from 172.30.0.0/16 to any 80 in via tl0 add 00520 fwd 172.30.0.1 tcp from 172.20.0.0/16 to any 80 in via tl0 add 00530 fwd 172.30.0.1 tcp from 192.168.0.0/24 to any 80 in via tl0 #allow all traffic to/from internal network add 01000 allow all from any to any via tl0 #translate incoming packets (NAT) add 3 divert natd all from any to in via lnc0 #allow incoming packets for hosts on internal network #(Since we translated them, we're sure they belong to existing #connection) add 30110 allow all from any to 172.20.0.0/16 in via lnc0 add 30111 allow all from any to 172.30.0.0/16 in via lnc0 add 30112 allow all from any to 192.168.0.0/24 in via lnc0 #allow SSH from add 30200 allow tcp from to 22 in via lnc0 add 30210 allow tcp from 22 to out via lnc0 #allow DNS queries to UUnet DNS servers add 30300 allow udp from 53 to in via lnc0 add 30310 allow udp from to 53 out via lnc0 add 30320 allow udp from 53 to in via lnc0 add 30330 allow udp from to 53 out via lnc0 #allow outgoing traffic from internal hosts #(use skipto 34000 instead of allow because they still need translation) add 31010 skipto 34000 all from 172.20.0.0/16 to any out via lnc0 add 31020 skipto 34000 all from 172.30.0.0/16 to any out via lnc0 add 31030 skipto 34000 all from 192.168.0.0/24 to any out via lnc0 #allow outgoing connections from local machine (using dynamic rules) add 32000 allow all from to any out via lnc0 keep-state #block and log everything that hasn't been allowed so far add 33000 deny log all from any to any #translate outgoing packets (NAT) add 34000 divert natd all from any to any out via lnc0 #allow translated packets to go out add 34010 allow all from 195.109.218.253 to any out via lnc0 #block and log whatever remains (shouldn't be anything) add 65000 deny log all from any to any Greets, Doc To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
On Thu, Feb 14, 2002 at 12:43:44PM -0800, Michael Sierchio wrote: > >..., i do not feel like spending > >an hour or two trying to infer what is on your [some static rules], > >and i'll happily leave you the job to explain where the bug (which > >means reconstruct the flow of packets in and out of the ipfw and > >show which one is dealt in the wrong way). > > I'd be happy to share the static rules -- and AFAIK I did give a hint > as to what the problem is. What kind of evidence do you want, in > particular? > I have a tcpdump that shows the packet exchange, shows SYN from each > host, and demonstrates that the dynamic rule is in the wrong state, > using the wrong timer. This could easily have something to do with the only reason why the rule can be "in the wrong state" as you say, is that the packet you are waiting for never reaches the rule. Whihc in turn boils down to a misconfiguration of the ruleset. A tcpdump alone, even taken on both sides, is not enough because the packet goes like this: input interface ip_input() ipfw up to the natd rule natd rest of ipfw ruleset ip_output() (if gateway is enabled) ipfw up to the natd rule natd rest of ipfw ruleset where is it dropped, you ight probably figure out with a bit of experimenting and lookinga at ipfw counters and possibly running natd in verbose mode. luigi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
MAC Layer of TCP/IP stack
Hi there.I am about to embark on a research project wherein some changes need to be made in the MAC layer of the TCP/IP stack.We have a wireless testbed running on FreeBSD.I had a few doubts.can i make the changes from the TCP/IP stack source code of FreeBSD?I dont know much about the source code of the stack.or would i need to be modifying the firmware of the wireless network card which probably has the mac layer code? Could use some help. Vinod __ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
MAC Layer of TCP/IP stack
< said: > i need to be modifying the firmware of the wireless > network card which probably has the mac layer code? The MAC layer is almost invariably implemented in hardware for modern network interfaces. In the case of wireless networks, that's usually firmware running on a microcontroller inside the card, although controllers differ as to the amount of functionality assumed by the firmware. FreeBSD's network stack implements support for Ethernet-like devices from the LLC sublayer up. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Bug in stateful code?
On Thu, Feb 14, 2002 at 08:42:53AM -0800, Michael Sierchio wrote: > > I've sent this to Luigi and a couple of other folks without reply, > so here it is. I _DID_ reply to you and on -net explaining why this does not work. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=13412+0+current/freebsd-net -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IPv6-over-IPv4 problems since the upgrade to 4.5
Greetings, Since the upgrade from 4.4 to 4.5 I have problems with my IPv6-over-v4-tunnel towards the freenet6-servers. The tunnel-setup goes fine, I can ping everything without a problem. But when I open an interactive session, after a short time weird things happen. The TCP-session itself goes fine, until the moment my machine starts sending out ICMP6 neighbor solicitation requests: TCP-session setup: 19:46:39.452386 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: S 1971097502:1971097502(0) win 65535 19:46:40.00 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: S 4240147676:4240147676(0) ack 1971097503 win 32768 19:46:40.077880 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: . ack 1 win 33220 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. 19:46:40.767713 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 1:63(62) ack 1 win 33120 [flowlabel 0x80114] 19:46:40.867511 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: . ack 63 win 33220 The neighbor solicitation packets: 19:46:44.697259 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:45.697183 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:46.697131 mavetju-k7.tsps1.freenet6.net > ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org user anonymous 19:46:47.201295 mavetju-k7.tsps1.freenet6.net.1761 > ftp6.netbsd.org.ftp: P 1:17(16) ack 63 win 33220 331 Guest login ok, type your name as password. 19:46:47.897276 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:46:50.147087 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:46:55.196847 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:47:05.256189 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:47:25.234907 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] 19:48:05.212334 ftp6.netbsd.org.ftp > mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 [flowlabel 0x80114] These TCP-packet never gets acknowledged and my packets never get send! I have done several tests, with FTP, SSH and plain telnet, everything goes fine until just after the neighbor solicitation. But ICMP-traffic, even large packets as 4Kb, go without a problem. FreeBSD 4.4 didn't, and still doesn't, have this behaviour. Can somebody please confirm that they have the same, or normal, behaviour under 4.5 when connecting to an IPv6 enabled site? Thanks, Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org [EMAIL PROTECTED] | Interested in MUDs? Visit Fatal Dimensions: --+ http://www.FatalDimensions.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IPv6-over-IPv4 problems since the upgrade to 4.5
> Edwin Groothuis writes: > Greetings, > Since the upgrade from 4.4 to 4.5 I have problems with my > IPv6-over-v4-tunnel towards the freenet6-servers. I don't have this problem (but using ipng.nl as IPv6 tunnel): 4636247 bytes received in 79.96 seconds (56.62 KB/s) ftp> 221- Data traffic for this session was 4636247 bytes in 1 file. Total traffic for this session was 4639803 bytes in 2 transfers. 221 Thank you for using the FTP service on ftp6.netbsd.org. Jean-Marc -- Jean-Marc Zucconi -- PGP Key: finger [EMAIL PROTECTED] [KeyID: 400B38E9] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
