Re: Win XP with mpd
On Tue, 5 Nov 2002, Dmitry A. Bondareff wrote: > I'll trying to setup mtu to 1400, why I don't see it by ifconfig command ? > > From mpd.conf: > > set link mru 1400 > set link mtu 1400 the link commands affect the links.. this sets teh fragment size that Mulitlink ppp will use.. externally you only see teh interface mtu, which is a different thing.. try: set iface mtu 1400 > > > #mpd -b > > #ifconfig -a: > ng0: flags=8890 mtu 1500 > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > After connecting: > #ifconfig -a: > ng0: flags=88d1 mtu 1500 > inet 1.1.1.1 --> 10.0.2.1 netmask 0x > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > After disconnected: > #ifconfig -a: > ng0: flags=8890 mtu 1496 > ng1: flags=8890 mtu 1500 > ng2: flags=8890 mtu 1500 > ng3: flags=8890 mtu 1500 > ng4: flags=8890 mtu 1500 > > > > - Original Message - > From: "Archie Cobbs" <[EMAIL PROTECTED]> > To: "Johan Larsson" <[EMAIL PROTECTED]> > Cc: "Archie Cobbs" <[EMAIL PROTECTED]>; "Dmitry A. Bondareff" > <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Sent: Tuesday, November 05, 2002 12:04 AM > Subject: Re: Win XP with mpd > > > > Johan Larsson writes: > > > > > For a long time many peoples discussed why Win XP don't work with > mpd. > > > > > May be you can help us ?? > > > > > Where I can find working configs ?? > > > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should > address. > > > > > > It might be MTU problems. But the problem occurs for example when i ping > > > the server from the windows xp machine, some pings get lost, some times > > > you must issue the ping command a few times, or run it with -t for a > while > > > to see them get lost. mpd-3.10 does not solve this problem > unfortunately. > > > > Try playing with the "set link mtu" and/or "set iface mtu" commands > > to manually set the MTU values. > > > > > I might be able to fix some dumps (from ethereal) under windows xp if > you > > > want it. And of course, these pings getting lost is just an easy way of > > > seeing the problem, you also get poor performance obviously. > > > > If you can tell where the packets are being dropped, that would be useful > > to know. > > > > -Archie > > > > __ > > Archie Cobbs * Packet Design * http://www.packetdesign.com > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
Hi, I had similar problems in the past and I found that, if the "Internet Connection Sharing" is enabled on the Windows BOX pptp doesen't work anymore in the right way. bye, Dmitry A. Bondareff wrote: When I used Win2000 client all works fine and fast. I've tested WinXp with mpd in two places. In one place do not work nothing. I see traffic on FreeBSD to Internet and from it, but on WinXP client no HTTP, no ICQ. And when i do telnet to some host I see answer from time to time. One time I see login: But after some seconds no answer. In the other place work fine HTTP from Explorer, but no ICQ. When I do in ICQ client "Auto configure ..." all fine and fast. But do not connecting. All firewalls I was set to ALLOW from ANY to ANY. With best regards, Dmitry. - Original Message - From: "Archie Cobbs" To: "Dmitry A. Bondareff" Cc: Sent: Monday, November 04, 2002 11:13 PM Subject: Re: Win XP with mpd >Dmitry A. Bondareff writes: > >>For a long time many peoples discussed why Win XP don't work with mpd. >>May be you can help us ?? >>Where I can find working configs ?? > >I've heard of some MTU problems, some of which mpd-3.10 should address. > >What's the specific problem you're having? > >-Archie > >__ >Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mbufs exchausted
Looking at the numbers, the messages about mbufs being exhausted do not make sense. Is this a known bug? Pete All mbuf clusters exhausted, please see tuning(7). All mbufs exhausted, please see tuning(7). All mbufs exhausted, please see tuning(7). > netstat -m 4296/4352/65536 mbufs in use (current/peak/max): 2242 mbufs allocated to data 6 mbufs allocated to packet headers 2048 mbufs allocated to socket names and addresses 2240/2292/16384 mbuf clusters in use (current/peak/max) 5672 Kbytes allocated to network (11% of mb_map in use) 96 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines > uname -a FreeBSD rms21.rommon.net 4.7-RELEASE FreeBSD 4.7-RELEASE #14: Thu Oct 17 18:57:59 EEST 2002 > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC 3390: Increasing TCP's Initial Window
--- Jeffrey Hsu <[EMAIL PROTECTED]> wrote: > >> I have patches lying around > >> that varies the initial window size from 2 to 4 depending on the MSS, > >> as specified in the RFC. > > > We could not apply those patches until we fix a bug serverside which > > increments snd_cwnd with 1 mss somewhere... > > Take a look on TCP session. > > No, no, I meant I wrote my own, which doesn't show this problem in the > traces I've examined. Just for clarification - this problem shows up on nonpatched fresh-installed system. > But, it's all rolled up into a bunch > of other congestion related stuff I'm still working on like SACK and, > more importantly, Limited Transmit, exactly because all this stuff > modifies and examines the same variables and so all the functionality > has to be tested together to make sure no part breaks any other part. Good stuff ;)) Do you plan to commit code anytime soon? --- Oleg > > Jeffrey __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
I'll trying to setup mtu to 1400, why I don't see it by ifconfig command ? >From mpd.conf: set link mru 1400 set link mtu 1400 #mpd -b #ifconfig -a: ng0: flags=8890 mtu 1500 ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 After connecting: #ifconfig -a: ng0: flags=88d1 mtu 1500 inet 1.1.1.1 --> 10.0.2.1 netmask 0x ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 After disconnected: #ifconfig -a: ng0: flags=8890 mtu 1496 ng1: flags=8890 mtu 1500 ng2: flags=8890 mtu 1500 ng3: flags=8890 mtu 1500 ng4: flags=8890 mtu 1500 - Original Message - From: "Archie Cobbs" <[EMAIL PROTECTED]> To: "Johan Larsson" <[EMAIL PROTECTED]> Cc: "Archie Cobbs" <[EMAIL PROTECTED]>; "Dmitry A. Bondareff" <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 12:04 AM Subject: Re: Win XP with mpd > Johan Larsson writes: > > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > > May be you can help us ?? > > > > Where I can find working configs ?? > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > > > It might be MTU problems. But the problem occurs for example when i ping > > the server from the windows xp machine, some pings get lost, some times > > you must issue the ping command a few times, or run it with -t for a while > > to see them get lost. mpd-3.10 does not solve this problem unfortunately. > > Try playing with the "set link mtu" and/or "set iface mtu" commands > to manually set the MTU values. > > > I might be able to fix some dumps (from ethereal) under windows xp if you > > want it. And of course, these pings getting lost is just an easy way of > > seeing the problem, you also get poor performance obviously. > > If you can tell where the packets are being dropped, that would be useful > to know. > > -Archie > > __ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
I think that packets droped on the WinXP side. - Original Message - From: "Archie Cobbs" <[EMAIL PROTECTED]> To: "Johan Larsson" <[EMAIL PROTECTED]> Cc: "Archie Cobbs" <[EMAIL PROTECTED]>; "Dmitry A. Bondareff" <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 12:04 AM Subject: Re: Win XP with mpd > Johan Larsson writes: > > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > > May be you can help us ?? > > > > Where I can find working configs ?? > > > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > > > It might be MTU problems. But the problem occurs for example when i ping > > the server from the windows xp machine, some pings get lost, some times > > you must issue the ping command a few times, or run it with -t for a while > > to see them get lost. mpd-3.10 does not solve this problem unfortunately. > > Try playing with the "set link mtu" and/or "set iface mtu" commands > to manually set the MTU values. > > > I might be able to fix some dumps (from ethereal) under windows xp if you > > want it. And of course, these pings getting lost is just an easy way of > > seeing the problem, you also get poor performance obviously. > > If you can tell where the packets are being dropped, that would be useful > to know. > > -Archie > > __ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MTU problems ...
tcpmssd is working great! thanks a lot!!! -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC 3390: Increasing TCP's Initial Window
>> I have patches lying around >> that varies the initial window size from 2 to 4 depending on the MSS, >> as specified in the RFC. > We could not apply those patches until we fix a bug serverside which > increments snd_cwnd with 1 mss somewhere... > Take a look on TCP session. No, no, I meant I wrote my own, which doesn't show this problem in the traces I've examined. But, it's all rolled up into a bunch of other congestion related stuff I'm still working on like SACK and, more importantly, Limited Transmit, exactly because all this stuff modifies and examines the same variables and so all the functionality has to be tested together to make sure no part breaks any other part. Jeffrey To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: RFC 3390: Increasing TCP's Initial Window
--- Jeffrey Hsu <[EMAIL PROTECTED]> wrote: > > Time to default net.inet.tcp.slowstart_flightsize to 4? > > A straight initial window of 4 is too big. I have patches lying around > that varies the initial window size from 2 to 4 depending on the MSS, > as specified in the RFC. > > Jeffrey We could not apply those patches until we fix a bug serverside which increments snd_cwnd with 1 mss somewhere... Server - CURRENT (source synced on Nov 02). Take a look on TCP session. There is local network and we should have initial window 4 mss. Notice how many packets it sent before first ACK came. 5 packets. 5 ck ~# sysctl net.inet.tcp.local_slowstart_flightsize net.inet.tcp.local_slowstart_flightsize: 4 6 ck ~# tcpdump port 80 tcpdump: listening on fxp0 18:57:28.854418 10.13.200.242.2356 > 10.13.200.240.http: S 2006596932:2006596932(0) win 16384 (DF) 18:57:28.854519 10.13.200.240.http > 10.13.200.242.2356: S 3851758649:3851758649(0) ack 2006596933 win 65535 (DF) 18:57:28.854698 10.13.200.242.2356 > 10.13.200.240.http: . ack 1 win 17520 (DF) 18:57:28.980517 10.13.200.242.2356 > 10.13.200.240.http: P 1:510(509) ack 1 win 17520 (DF) 18:57:28.981094 10.13.200.240.http > 10.13.200.242.2356: . 1:1461(1460) ack 510 win 65535 (DF) 18:57:28.981157 10.13.200.240.http > 10.13.200.242.2356: . 1461:2921(1460) ack 510 win 65535 (DF) 18:57:28.981216 10.13.200.240.http > 10.13.200.242.2356: . 2921:4381(1460) ack 510 win 65535 (DF) 18:57:28.981238 10.13.200.240.http > 10.13.200.242.2356: . 4381:5841(1460) ack 510 win 65535 (DF) 18:57:28.981287 10.13.200.240.http > 10.13.200.242.2356: . 5841:7301(1460) ack 510 win 65535 (DF) 18:57:28.981744 10.13.200.242.2356 > 10.13.200.240.http: . ack 2921 win 17520 (DF) 18:57:28.981822 10.13.200.240.http > 10.13.200.242.2356: FP 7301:7864(563) ack 510 win 65535 (DF) 18:57:28.981981 10.13.200.242.2356 > 10.13.200.240.http: . ack 5841 win 17520 (DF) 18:57:28.982171 10.13.200.242.2356 > 10.13.200.240.http: . ack 7865 win 17520 (DF) 18:57:29.102762 10.13.200.242.2356 > 10.13.200.240.http: F 510:510(0) ack 7865 win 17520 (DF) 18:57:29.102840 10.13.200.240.http > 10.13.200.242.2356: . ack 511 win 65535 (DF) ^C 1214 packets received by filter 0 packets dropped by kernel 7 ck ~# 7 ck ~# sysctl -w net.inet.tcp.local_slowstart_flightsize=1 net.inet.tcp.local_slowstart_flightsize: 4 -> 1 8 ck ~# tcpdump port 80 tcpdump: listening on fxp0 19:04:54.623558 10.13.200.242.2360 > 10.13.200.240.http: S 2118035397:2118035397(0) win 16384 (DF) 19:04:54.623657 10.13.200.240.http > 10.13.200.242.2360: S 1566520560:1566520560(0) ack 2118035398 win 65535 (DF) 19:04:54.623841 10.13.200.242.2360 > 10.13.200.240.http: . ack 1 win 17520 (DF) 19:04:54.767900 10.13.200.242.2360 > 10.13.200.240.http: P 1:510(509) ack 1 win 17520 (DF) 19:04:54.768484 10.13.200.240.http > 10.13.200.242.2360: . 1:1461(1460) ack 510 win 65535 (DF) 19:04:54.768545 10.13.200.240.http > 10.13.200.242.2360: . 1461:2921(1460) ack 510 win 65535 (DF) 19:04:54.769133 10.13.200.242.2360 > 10.13.200.240.http: . ack 2921 win 17520 (DF) 19:04:54.769218 10.13.200.240.http > 10.13.200.242.2360: . 2921:4381(1460) ack 510 win 65535 (DF) 19:04:54.769243 10.13.200.240.http > 10.13.200.242.2360: . 4381:5841(1460) ack 510 win 65535 (DF) 19:04:54.769267 10.13.200.240.http > 10.13.200.242.2360: . 5841:7301(1460) ack 510 win 65535 (DF) 19:04:54.769863 10.13.200.242.2360 > 10.13.200.240.http: . ack 5841 win 17520 (DF) 19:04:54.769927 10.13.200.240.http > 10.13.200.242.2360: FP 7301:7864(563) ack 510 win 65535 (DF) 19:04:54.770240 10.13.200.242.2360 > 10.13.200.240.http: . ack 7865 win 17520 (DF) 19:04:54.905359 10.13.200.242.2360 > 10.13.200.240.http: F 510:510(0) ack 7865 win 17520 (DF) 19:04:54.905438 10.13.200.240.http > 10.13.200.242.2360: . ack 511 win 65535 (DF) After I changed initial window size to 1 it started to send 2 packets before first ACK, then 3 packets before next ACK. Client side is working as supposed to. If I set net.inet.tcp.local_slowstart_flightsize to 1 it sends 1 packet before ACK. If I change it to 4 - it sends 4 packets before ACK. Please check it in your environment. I've got same results with 4.7 and 4.6 - same wrong TCP initial window. Oleg __ Do you Yahoo!? HotJobs - Search new jobs daily now http://hotjobs.yahoo.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MPD and MRU
Vincent Jardin writes:
> It looks like it is not possible to configure any MRU values with MPD, due to
> LCP_MRU_MARGIN (=20).
>
> For example, on the PPPoE links, the values between 1473 to 1491 are not
> possible.
>
> ...
> link.c:
> case SET_MRU:
> case SET_MTU:
> val = atoi(*av);
> name = ((intptr_t)arg == SET_MTU) ? "MTU" : "MRU";
> if (!lnk->phys->type)
> Log(LG_ERR, ("[%s] this link has no type set", lnk->name));
> else if (val < LCP_MIN_MRU)
> Log(LG_ERR, ("[%s] the min %s is %d", lnk->name, name, LCP_MIN_MRU));
> else if (val + LCP_MRU_MARGIN > lnk->phys->type->mru)
> Log(LG_ERR, ("[%s] the max %s on type \"%s\" links is %d",
> lnk->name, name, lnk->phys->type->name,
> lnk->phys->type->mru - LCP_MRU_MARGIN)); /* XX */
> else if ((intptr_t)arg == SET_MTU)
> lnk->conf.mtu = val;
> else
> lnk->conf.mru = val;
> break;
> ...
>
> I think that the LCP_MRU_MARGIN tests could be removed or LCP_MRU_MARGIN
> could be set to 0.
Yes, you're right.. that's a hold-over kludge from before.
I'll remove it in the next version. In the meantime, you can
just redefine it to zero.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
MPD and MRU
Hi,
It looks like it is not possible to configure any MRU values with MPD, due to
LCP_MRU_MARGIN (=20).
For example, on the PPPoE links, the values between 1473 to 1491 are not
possible.
...
link.c:
case SET_MRU:
case SET_MTU:
val = atoi(*av);
name = ((intptr_t)arg == SET_MTU) ? "MTU" : "MRU";
if (!lnk->phys->type)
Log(LG_ERR, ("[%s] this link has no type set", lnk->name));
else if (val < LCP_MIN_MRU)
Log(LG_ERR, ("[%s] the min %s is %d", lnk->name, name, LCP_MIN_MRU));
else if (val + LCP_MRU_MARGIN > lnk->phys->type->mru)
Log(LG_ERR, ("[%s] the max %s on type \"%s\" links is %d",
lnk->name, name, lnk->phys->type->name,
lnk->phys->type->mru - LCP_MRU_MARGIN)); /* XX */
else if ((intptr_t)arg == SET_MTU)
lnk->conf.mtu = val;
else
lnk->conf.mru = val;
break;
...
I think that the LCP_MRU_MARGIN tests could be removed or LCP_MRU_MARGIN
could be set to 0.
Regards,
Vincent
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
Re: MTU problems ...
On Mon, 4 Nov 2002, Steve Francis wrote:
> The problem below (which is still a problem in FreeBSD, but one that
> will be rarely encountered) was caused by a load balancer in front of
> the BSD boxes, that did not NAT part of the ICMP unreachable message
> payload to the BSD's address. (The ICMP includes part of the original
> datagram that caused the problem, and the load balancer did not
> translate the sequence numbers, I think.) Its still a BSD problem (I'd
> say) as if BSD hears the ICMP and reduces its MSS, it should not resend
> the original packet at a size > MSS.
>
> So this could be your issue if your ISP is forcing all your traffic
> through a proxy that does the same thing.
>
> A workaround would be disable PMTU-discovery.
>
>
> Agent Drek wrote:
> > hi,
> >
> > I'll start this off by claiming ignorance about the deep inner workings of
> > tcp/ip. As such, this is not going to be a really technically detailed
> > report. I will be more than happy to provide any info that might help in
> > tracking this problem down though!
> >
> > The problem manifests as large downloads hanging (ftp/http/scp). The only
> > way to make a download work is to choose an MTU setting on tun0 (this is
> > a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find
> > a value (1452, 1460, most things work at 1492 though) that makes the download
> > complete properly. Sometimes finding an MTU that works is just not possible.
> > The only icmp rule in ipfw is to allow all icmp so I am not unwittingly
> > disallowing anything important.
> >
> > Could this thread be related to my problem? and was there any resolution
> > with this?
> >
> >
>http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net
> >
> > According to my ISP (and a few other ISP's in the area) only FreeBSD systems
> > and certain IOS versions are experiencing this problem.
> >
> > What can I do to start debugging this? Please CC me as I am not subscribed
> > to net@.
> >
> > cheers,
> >
TCPMSSD(8) FreeBSD System Manager's Manual TCPMSSD(8)
NAME
tcpmssd - TCP Maximum Segment Size option corrector
SYNOPSIS
tcpmssd [-v] -p port {-i iface | -m mtu}
DESCRIPTION
tcpmssd is a program that adjusts outgoing TCP SYN packets so that the
maximum receive segment size is not greater than the amount allowed by
the interface MTU.
This is necessary in many setups to avoid problems caused by routers that
drop ICMP ``Datagram Too Big'' messages, thus breaking Path MTU discovery
algorithm (RFC 1191). Without these messages, the originating machine
sends data, it passes the rogue router then hits a machine that has an
MTU that is not big enough for the data. Because the IP ``don't
fragment'' option is set, this machine sends an ICMP ``Datagram Too Big''
message back to the originator and drops the packet. The rogue router
drops the ICMP and the originator never gets to discover that it must
reduce the Path MTU value or exclude the IP ``don't fragment'' option
from its outgoing data.
tcpmssd normally runs in the background as a daemon. It intercept TCP
packets from a divert(4) socket bound to the port specified with the -p
option and reduces the value of TCP MSS option if necessary so that the
incoming TCP messages will pass through this host without need to send
ICMP ``Datagram Too Big'' messages.
The maximum value for the TCP MSS option is determined based on a MTU
given either as an absolute value with the -m option or derived from a
network interface specified with the -i option.
If run with the -v option, tcpmssd does not detach from its controlling
terminal and writes various diagnostic messages to the standard error
output.
The following steps are necessary to run tcpmssd :
1. Build your kernel with the following options:
options IPFIREWALL
options IPDIVERT
Refer to the Handbook for detailed instructions on building a custom
kernel.
2. Make sure to redirect TCP traffic to the divert(4) port port. Refer
to the ipfw(8) manual page for details.
SEE ALSO
divert(4), ipfw(8).
AUTHORS
This program was written by Ruslan Ermilov <[EMAIL PROTECTED]> based on work
done by
Patrick Bihan-Faou <[EMAIL PROTECTED]>.
FreeBSD July 17, 2000 FreeBSD
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
RE: MTU problems ...
On Mon, 4 Nov 2002, Don Bowman wrote: > > From: Julian Elischer [mailto:julian@;elischer.org] > > There is a program that intercepts tcp session negotiation and > > artificially reduces the negotiated MTU but I can't find it > > right now.. > > I think it was called mssd or something. > > /usr/ports/net/tcpmssd err yeah, thanks.. > > --don ([EMAIL PROTECTED] www.sandvine.com) > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
RE: MTU problems ...
> From: Julian Elischer [mailto:julian@;elischer.org] > There is a program that intercepts tcp session negotiation and > artificially reduces the negotiated MTU but I can't find it > right now.. > I think it was called mssd or something. /usr/ports/net/tcpmssd --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MTU problems ...
There is a program that intercepts tcp session negotiation and artificially reduces the negotiated MTU but I can't find it right now.. I think it was called mssd or something. On Mon, 4 Nov 2002, Agent Drek wrote: > On Mon, 4 Nov 2002, Steve Francis wrote: > > > Date: Mon, 04 Nov 2002 09:00:47 -0800 > > From: Steve Francis <[EMAIL PROTECTED]> > > To: Agent Drek <[EMAIL PROTECTED]> > > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > > Subject: Re: MTU problems ... > > > > The problem below (which is still a problem in FreeBSD, but one that > > will be rarely encountered) was caused by a load balancer in front of > > the BSD boxes, that did not NAT part of the ICMP unreachable message > > payload to the BSD's address. (The ICMP includes part of the original > > datagram that caused the problem, and the load balancer did not > > translate the sequence numbers, I think.) Its still a BSD problem (I'd > > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > > the original packet at a size > MSS. > > > > So this could be your issue if your ISP is forcing all your traffic > > through a proxy that does the same thing. > > > > A workaround would be disable PMTU-discovery. > > > > hi, > > I didn't notice the pr until now: > http://www.freebsd.org/cgi/query-pr.cgi?pr=42137 > > In my case the "load balancer" is something at the telco that is probably > aggregating a bunch of stuff at the dslam. Thus I can't really fix the > bad router, and there is no option of going somewhere else. > > I think I want something like: > > net.inet.tcp.stupid_router_in_front_of_me_mtu_hack->1 > > but that may not be what I need. Is it rude to send mail to that same > pr? should I try and harvest more info first? > > disabling path mtu discovery just cause the problem to happen faster > for me :( > > cheers, > > -- >Derek Marshall > > Smash and Pow Inc > 'digital plumber' > http://www.smashpow.net > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
Murat Bicer writes: > I also have some problems: > > I get Error 742: connection does not support required encryption type. What does the mpd log trace say when this happens? > And even weirder thing is, it works on some XP machines without any > problem. And on win2k it works fine too. > > My mpd.conf: > > pptp_client0: > # create the bundle "vpn0" with link "pptp1" > new -i ng0 vpn0 pptp0 > > # single link > set bundle yes multilink > set iface disable on-demand > set iface idle 1800 > > # do VJ compression > set ipcp yes vjcomp > > # require Microsoft encryption > set bundle yes crypt-reqd > set ccp yes mppc > set ccp yes mpp-e40 > set ccp yes mpp-e56 > set ccp yes mpp-e128 > set ccp yes mpp-stateless > set link mtu 1490 > > set bundle yes compression > set ccp yes mpp-compress Don't use "set ccp yes mpp-compress". FreeBSD doesn't support MPPC compression. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
Johan Larsson writes: > > > For a long time many peoples discussed why Win XP don't work with mpd. > > > May be you can help us ?? > > > Where I can find working configs ?? > > > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > It might be MTU problems. But the problem occurs for example when i ping > the server from the windows xp machine, some pings get lost, some times > you must issue the ping command a few times, or run it with -t for a while > to see them get lost. mpd-3.10 does not solve this problem unfortunately. Try playing with the "set link mtu" and/or "set iface mtu" commands to manually set the MTU values. > I might be able to fix some dumps (from ethereal) under windows xp if you > want it. And of course, these pings getting lost is just an easy way of > seeing the problem, you also get poor performance obviously. If you can tell where the packets are being dropped, that would be useful to know. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
On Mon, 4 Nov 2002, Archie Cobbs wrote: > Dmitry A. Bondareff writes: > > For a long time many peoples discussed why Win XP don't work with mpd. > > May be you can help us ?? > > Where I can find working configs ?? > > I've heard of some MTU problems, some of which mpd-3.10 should address. It might be MTU problems. But the problem occurs for example when i ping the server from the windows xp machine, some pings get lost, some times you must issue the ping command a few times, or run it with -t for a while to see them get lost. mpd-3.10 does not solve this problem unfortunately. I might be able to fix some dumps (from ethereal) under windows xp if you want it. And of course, these pings getting lost is just an easy way of seeing the problem, you also get poor performance obviously. > > What's the specific problem you're having? > > -Archie > > __ > Archie Cobbs * Packet Design * http://www.packetdesign.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message > > -- Johan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
When I used Win2000 client all works fine and fast. I've tested WinXp with mpd in two places. In one place do not work nothing. I see traffic on FreeBSD to Internet and from it, but on WinXP client no HTTP, no ICQ. And when i do telnet to some host I see answer from time to time. One time I see login: But after some seconds no answer. In the other place work fine HTTP from Explorer, but no ICQ. When I do in ICQ client "Auto configure ..." all fine and fast. But do not connecting. All firewalls I was set to ALLOW from ANY to ANY. With best regards, Dmitry. - Original Message - From: "Archie Cobbs" <[EMAIL PROTECTED]> To: "Dmitry A. Bondareff" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, November 04, 2002 11:13 PM Subject: Re: Win XP with mpd > Dmitry A. Bondareff writes: > > For a long time many peoples discussed why Win XP don't work with mpd. > > May be you can help us ?? > > Where I can find working configs ?? > > I've heard of some MTU problems, some of which mpd-3.10 should address. > > What's the specific problem you're having? > > -Archie > > __ > Archie Cobbs * Packet Design * http://www.packetdesign.com > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Problem in High Speed and Long Delay with FreeBSD
> Your suggestion of increasing the -l seems to have made a positive > impact -- tests this morning with a higher buffer length size of 8192 > gave us a better throughput of 44Mbps. Now the time sequence plot > shows a window usage of 1.5MB as opposed to the previous 1MB usage. > > We still don't understand as to why we are not getting a larger > window usage when we are requesting a 3MB socket buffer. (BTW, > a typo in my example testing commands, left out a "0" in the > "-b".) Since *something* is making a difference, you may wish to try changing one independent parameter at a time. For instance, do you get different throughput numbers with -l = 16k, 32k, and so on? What is the limit? You will want to decrease the -n parameter correspondingly so as to not keep waiting longer and longer! Similarly try changing other limits one at a time. If you can, try to use the *same* non-FreeBSD machine at one end and characterize send and recv performance of FreeBSD separately. This ought to help you figure out where the bottleneck may be. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Win XP with mpd
Dmitry A. Bondareff writes: > For a long time many peoples discussed why Win XP don't work with mpd. > May be you can help us ?? > Where I can find working configs ?? I've heard of some MTU problems, some of which mpd-3.10 should address. What's the specific problem you're having? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MTU problems ...
On Mon, 4 Nov 2002, Steve Francis wrote: > Date: Mon, 04 Nov 2002 09:00:47 -0800 > From: Steve Francis <[EMAIL PROTECTED]> > To: Agent Drek <[EMAIL PROTECTED]> > Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> > Subject: Re: MTU problems ... > > The problem below (which is still a problem in FreeBSD, but one that > will be rarely encountered) was caused by a load balancer in front of > the BSD boxes, that did not NAT part of the ICMP unreachable message > payload to the BSD's address. (The ICMP includes part of the original > datagram that caused the problem, and the load balancer did not > translate the sequence numbers, I think.) Its still a BSD problem (I'd > say) as if BSD hears the ICMP and reduces its MSS, it should not resend > the original packet at a size > MSS. > > So this could be your issue if your ISP is forcing all your traffic > through a proxy that does the same thing. > > A workaround would be disable PMTU-discovery. > hi, I didn't notice the pr until now: http://www.freebsd.org/cgi/query-pr.cgi?pr=42137 In my case the "load balancer" is something at the telco that is probably aggregating a bunch of stuff at the dslam. Thus I can't really fix the bad router, and there is no option of going somewhere else. I think I want something like: net.inet.tcp.stupid_router_in_front_of_me_mtu_hack->1 but that may not be what I need. Is it rude to send mail to that same pr? should I try and harvest more info first? disabling path mtu discovery just cause the problem to happen faster for me :( cheers, -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: MTU problems ...
The problem below (which is still a problem in FreeBSD, but one that will be rarely encountered) was caused by a load balancer in front of the BSD boxes, that did not NAT part of the ICMP unreachable message payload to the BSD's address. (The ICMP includes part of the original datagram that caused the problem, and the load balancer did not translate the sequence numbers, I think.) Its still a BSD problem (I'd say) as if BSD hears the ICMP and reduces its MSS, it should not resend the original packet at a size > MSS. So this could be your issue if your ISP is forcing all your traffic through a proxy that does the same thing. A workaround would be disable PMTU-discovery. Agent Drek wrote: hi, I'll start this off by claiming ignorance about the deep inner workings of tcp/ip. As such, this is not going to be a really technically detailed report. I will be more than happy to provide any info that might help in tracking this problem down though! The problem manifests as large downloads hanging (ftp/http/scp). The only way to make a download work is to choose an MTU setting on tun0 (this is a pppoe session) of the FreeBSD server (currently 4.6.2-Rel) until I find a value (1452, 1460, most things work at 1492 though) that makes the download complete properly. Sometimes finding an MTU that works is just not possible. The only icmp rule in ipfw is to allow all icmp so I am not unwittingly disallowing anything important. Could this thread be related to my problem? and was there any resolution with this? http://www.freebsd.org/cgi/getmsg.cgi?fetch=61954+0+/usr/local/www/db/text/2002/freebsd-net/20020825.freebsd-net According to my ISP (and a few other ISP's in the area) only FreeBSD systems and certain IOS versions are experiencing this problem. What can I do to start debugging this? Please CC me as I am not subscribed to net@. cheers, -- Derek Marshall Smash and Pow Inc > 'digital plumber' http://www.smashpow.net To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: IN-KERNEL Proxy
If you mean in terms of transparently forward/redirecting packets then yes, see ipfw's fwd feature. On Monday 04 November 2002 04:35, soheil soheil wrote: > Hi list > i want to know if there is any in-kernel made proxy on BSD ??? > THANX > > > _ > Broadband? Dial-up? Get reliable MSN Internet Access. > http://resourcecenter.msn.com/access/plans/default.asp > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- Darcy Buskermolen Wavefire Technologies Corp. ph: 250.717.0200 fx: 250.763.1759 http://www.wavefire.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mbufs exhausted - kernel panic
I don't think that it will help - all 192.168.0.0/16 routes could possibly exhaust whole my RAM - besides kern.ipc.nmbufs is read-only :) and could be set only at boot time or in kernel config. But I think the problem here is in NFS client code in nfsm_reqh() (I've compiled DDB in the kernel) which is called from nfs_lookup and so on ... Mbufs exhaustion is just condition for this panic as I saw. On Mon, 4 Nov 2002, Lefteris Tsintjelis wrote: > You need to increase kern.ipc.nmbufs > > sysctl -w kern.ipc.nmbufs=... > > Iasen Kostov wrote: > > > > I've tested our LAN when I come to this: > > I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing > > > > "All mbufs exhausted, see tuning(7)". > > if you cancel execution of nbtscan - everything is ok but: > > > > 10112/10112/10112 mbufs in use (current/peak/max): > > 9822 mbufs allocated to data > > 128/130/2528 mbuf clusters in use (current/peak/max) > > 2788 Kbytes allocated to network (36% of mb_map in use) > > 161 requests for memory denied > > 0 requests for memory delayed > > 8 calls to protocol drain routines > > > > and second after kernel paniced. > > After reboot tried this again and nothing has happend. > > Then I mounted a NFS directory exported from the other computer on the > > network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced > > when I execute "ls" in the NFS mounted directory. > > > > Fatal trap 12: page fault while in kernel mode > > . > > . > > . > > current process = 272(ls) > > ... > > > > I can't use this machine for dumping kernel core becouse it's > > production server it should be up and running. But I'll try same at home. > > > > It seems that kernel mbuf are exhausted by the route cache or the > > arpresolver becouse I can see a lot of unresolved arp requests in the > > routing table. > > > > interface xl0 has 2 IPs > > inet 212.36.9.x netmask 0xfff8 broadcast 212.36.9.x > > inet 192.168.100.254 netmask 0x broadcast 192.168.255.255 > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > > with "unsubscribe freebsd-net" in the body of the message > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: mbufs exhausted - kernel panic
You need to increase kern.ipc.nmbufs sysctl -w kern.ipc.nmbufs=... Iasen Kostov wrote: > > I've tested our LAN when I come to this: > I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing > > "All mbufs exhausted, see tuning(7)". > if you cancel execution of nbtscan - everything is ok but: > > 10112/10112/10112 mbufs in use (current/peak/max): > 9822 mbufs allocated to data > 128/130/2528 mbuf clusters in use (current/peak/max) > 2788 Kbytes allocated to network (36% of mb_map in use) > 161 requests for memory denied > 0 requests for memory delayed > 8 calls to protocol drain routines > > and second after kernel paniced. > After reboot tried this again and nothing has happend. > Then I mounted a NFS directory exported from the other computer on the > network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced > when I execute "ls" in the NFS mounted directory. > > Fatal trap 12: page fault while in kernel mode > . > . > . > current process = 272(ls) > ... > > I can't use this machine for dumping kernel core becouse it's > production server it should be up and running. But I'll try same at home. > > It seems that kernel mbuf are exhausted by the route cache or the > arpresolver becouse I can see a lot of unresolved arp requests in the > routing table. > > interface xl0 has 2 IPs > inet 212.36.9.x netmask 0xfff8 broadcast 212.36.9.x > inet 192.168.100.254 netmask 0x broadcast 192.168.255.255 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
mbufs exhausted - kernel panic
I've tested our LAN when I come to this: I ran nbtscan 192.168.0.0/16 after a 2-3 secs kernel started printing "All mbufs exhausted, see tuning(7)". if you cancel execution of nbtscan - everything is ok but: 10112/10112/10112 mbufs in use (current/peak/max): 9822 mbufs allocated to data 128/130/2528 mbuf clusters in use (current/peak/max) 2788 Kbytes allocated to network (36% of mb_map in use) 161 requests for memory denied 0 requests for memory delayed 8 calls to protocol drain routines and second after kernel paniced. After reboot tried this again and nothing has happend. Then I mounted a NFS directory exported from the other computer on the network and tried nebtscan 192.168.0.0/16 again ... and kernel paniced when I execute "ls" in the NFS mounted directory. Fatal trap 12: page fault while in kernel mode . . . current process = 272(ls) ... I can't use this machine for dumping kernel core becouse it's production server it should be up and running. But I'll try same at home. It seems that kernel mbuf are exhausted by the route cache or the arpresolver becouse I can see a lot of unresolved arp requests in the routing table. interface xl0 has 2 IPs inet 212.36.9.x netmask 0xfff8 broadcast 212.36.9.x inet 192.168.100.254 netmask 0x broadcast 192.168.255.255 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: FEC : ng_fec & ng_one2many
> "Julian" == Julian Elischer <[EMAIL PROTECTED]> writes: Hello, (Sorry for replying late) Julian> I have committed it to 5.0 I will do 4.x in a day or so.. Thanks a lot, Julian> do you use it? I plan to use it on a box with a dfe570 (quad port ethernet), as soon as it's possible for me to get at the office where the box is located (Real Work overhead at the moment). Julian> it needs someone to write a man page.. Never done that before, but I could take a look. Eric Masson -- hier j ai sans le vouloirs j'ai envoyé un virus sur Internet qu'une personne mal intentionné m'avez donné pour tous . je leurs demande de m'excuser -+- RP in : GNU - Le retour du fils de la vengeance d'Henry -+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
IN-KERNEL Proxy
Hi list i want to know if there is any in-kernel made proxy on BSD ??? THANX _ Broadband? Dial-up? Get reliable MSN Internet Access. http://resourcecenter.msn.com/access/plans/default.asp To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
