From owner-freebsd-net@FreeBSD.ORG Thu Jul 17 06:19:44 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 501A01065675 for ; Thu, 17 Jul 2008 06:19:44 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from gaia.nimnet.asn.au (nimbin.lnk.telstra.net [139.130.45.143]) by mx1.freebsd.org (Postfix) with ESMTP id 275E88FC17 for ; Thu, 17 Jul 2008 06:19:40 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (smithi@localhost) by gaia.nimnet.asn.au (8.8.8/8.8.8R1.5) with SMTP id QAA20446; Thu, 17 Jul 2008 16:18:58 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 17 Jul 2008 16:18:57 +1000 (EST) From: Ian Smith To: Wasily Lin In-Reply-To: <487EACC5.1060109@keynet.com.cn> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: mpd5.1 MTU problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2008 06:19:44 -0000 On Thu, 17 Jul 2008, Wasily Lin wrote: > Hello, > I set up a PPPoE server on FreeBSD 7.0(amd64) with mpd 5.1 and it works > fine for all clients except for my FreeBSD 7.0(i386) Notebook. > Connecting has no problem and I get ip but all website can not be access > even on PPPoE server itself(Apache installed), so can not ftp site. > I've used mpd 5.1_1 and pppoe(built-in) as pppoe client but the > problem was same - can not access http/ftp..., only icmp works. I think > the problem is MTU then changed that but no effects. Now my configuration: > > PPPoE Server: > startup: > set netflow peer 127.0.0.1 1813 > set user admin xxxxx admin > set user operator xxxxx operator > set user user xxxxx user > set console open > > default: > load pppoe_server > > pppoe_server: > > create bundle template B > set ippool add pool 10.0.0.100 10.0.0.200 > set iface enable netflow-in > set iface enable netflow-out > set iface enable ipacct > set iface enable proxy-arp > set iface mtu 1460 <-----------------------! > set ipcp ranges 10.0.0.1/32 ippool pool > set ipcp dns 172.18.30.125 > > create link template common pppoe > set link enable pap > set link disable chap > set link enable multilink > set link action bundle B > load radius > > create link template em0 common > set link max-children 1000 > set pppoe iface em0 > set link enable incoming > > radius: > set radius server 127.0.0.1 xxxxxxxx 1812 1813 > set radius retries 3 > set radius timeout 3 > set radius me 127.0.0.1 > set auth max-logins 1 > set auth acct-update 300 > set auth enable radius-auth > set auth enable radius-acct > set radius enable message-authentic > > PPPoE client: > startup: > set user admin xxxxx admin > set console open > > default: > load pppoe_client > > pppoe_client: > create bundle static B1 > set iface route default > set ipcp ranges 0.0.0.0/0 0.0.0.0/0 > > create link static L1 pppoe > set link action bundle B1 > set auth authname xxxxxx > set auth password xxxxxx > set link max-redial 0 > set link keep-alive 10 60 > set pppoe iface em0 > set pppoe service "" For the same apparent problem, from my working mpd 4.1 client config: # needed? seems so, t23 had trouble with large tcp pkts .. yep, fixed .. set iface enable tcpmssfix which I see is still in http://mpd.sourceforge.net/doc5/mpd28.html cheers, Ian > open > > After connected: > > PPPoE server: > ng15: flags=88d1 metric > 0 mtu 1460 > inet 10.0.0.1 --> 10.0.0.115 netmask 0xffffffff > > PPPoE client: > ng0: flags=88d1 metric 0 > mtu 1460 > inet 10.0.0.115 --> 10.0.0.1 netmask 0xffffffff > > tcpdump output: > > PPPoE server: > pppoe# tcpdump -i ng15 -ln host 10.0.0.1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ng15, link-type NULL (BSD loopback), capture size 96 bytes > 10:08:44.469993 IP 10.0.0.115.60331 > 10.0.0.1.80: S > 2092758811:2092758811(0) win 65535 3,sackOK,timestamp 4639873 0> > 10:08:44.470056 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:08:47.469997 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:08:53.469978 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:09:05.469918 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:09:44.972709 IP 10.0.0.115.60331 > 10.0.0.1.80: F 1:1(0) ack 1 win > 8272 > 10:09:44.972744 IP 10.0.0.1.80 > 10.0.0.115.60331: R > 687014729:687014729(0) win 0 > > PPPoE client: > r00t# tcpdump -i ng0 -ln host 10.0.0.1 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ng0, link-type NULL (BSD loopback), capture size 96 bytes > 10:12:06.792399 IP 10.0.0.115.60331 > 10.0.0.1.80: S > 2092758811:2092758811(0) win 65535 3,sackOK,timestamp 4639873 0> > 10:12:06.793151 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:12:06.793178 IP 10.0.0.115.60331 > 10.0.0.1.80: . ack 1 win 8272 > > 10:12:09.793385 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:12:09.793414 IP 10.0.0.115.60331 > 10.0.0.1.80: . ack 1 win 8272 > > 10:12:15.793331 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:12:15.793358 IP 10.0.0.115.60331 > 10.0.0.1.80: . ack 1 win 8272 > > 10:12:27.793227 IP 10.0.0.1.80 > 10.0.0.115.60331: S > 687014728:687014728(0) ack 2092758812 win 65535 3,sackOK,timestamp 1602770998 4639873> > 10:12:27.793255 IP 10.0.0.115.60331 > 10.0.0.1.80: . ack 1 win 8272 > > 10:13:07.294273 IP 10.0.0.115.60331 > 10.0.0.1.80: F 1:1(0) ack 1 win > 8272 > 10:13:07.295358 IP 10.0.0.1.80 > 10.0.0.115.60331: R > 687014729:687014729(0) win 0 > > As you can see, tcp/ack from client can not go through but tcp/syn, > tcp/fin are fine. > > What's the reason? I've used the same client to connect to ISP's ADSL > and work fine so what I am sure is the server refused my tcp/ack. But why? > > Thanks all. > > BSD4LZX