From owner-freebsd-net@FreeBSD.ORG Thu Jul 17 08:14:31 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 84F7D106566C for ; Thu, 17 Jul 2008 08:14:31 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id F14928FC08 for ; Thu, 17 Jul 2008 08:14:30 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 169862789; Thu, 17 Jul 2008 10:14:29 +0300 Message-ID: <487EF154.5070808@FreeBSD.org> Date: Thu, 17 Jul 2008 10:14:28 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <1216275783.00099216.1216262401@10.7.7.3> In-Reply-To: <1216275783.00099216.1216262401@10.7.7.3> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Wasily Lin 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 08:14:31 -0000 Wasily Lin wrote: > set iface enable netflow-in > set iface enable netflow-out > set iface enable ipacct Strange combination. > set iface enable proxy-arp Are you sure you need it? > set iface mtu 1460 <-----------------------! That's not a problem, but usually 1492 used for PPPoE. Also in some situation 'set iface enable tcpmssfix' could help. > 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? As soon as all packets are very small I don't think it is an MTU problem. I would recommend you to use tcpdump on Ethernet interface to understand which side actually drops the packets and probably why. Also check that you are not using any firewall and try to disable some features on server side like ipacct. -- Alexander Motin