From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-21-ewr.dyndns.com (mxout-132-ewr.mailhop.org [216.146.33.132]) by lists.bufferbloat.net (Postfix) with ESMTP id 6CA902E0419 for ; Sun, 17 Apr 2011 17:21:59 -0700 (PDT) Received: from scan-22-ewr.mailhop.org (scan-22-ewr.local [10.0.141.244]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id CB59241FE for ; Mon, 18 Apr 2011 00:21:58 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 117.20.11.230 Received: from mail.cc.com.au (mail.cc.com.au [117.20.11.230]) by mail-21-ewr.dyndns.com (Postfix) with ESMTP id F27651FB4 for ; Mon, 18 Apr 2011 00:21:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.cc.com.au (Postfix) with ESMTP id 9A9563E030 for ; Mon, 18 Apr 2011 10:17:04 +1000 (EST) X-Virus-Scanned: Debian amavisd-new at mail.cc.com.au Received: from mail.cc.com.au ([117.20.11.230]) by localhost (mail.cc.com.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkdUkaamtX5K for ; Mon, 18 Apr 2011 10:16:52 +1000 (EST) Received: from [129.127.55.141] (web-test.adelaide.edu.au [129.127.55.141]) (Authenticated sender: kim@hawtin.net.au) by mail.cc.com.au (Postfix) with ESMTPA id 0C3D13E02B for ; Mon, 18 Apr 2011 10:16:51 +1000 (EST) Message-ID: <4DAB840F.3070903@hawtin.net.au> Date: Mon, 18 Apr 2011 09:51:35 +0930 From: Kim Hawtin User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.16) Gecko/20110307 Icedove/3.0.11 MIME-Version: 1.0 To: bismark-devel@lists.bufferbloat.net References: <97EDD940-729E-4700-92B1-04DD7121CAB2@cc.gatech.edu> <4DAAFD3E.1050509@taht.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Bismark-devel] switching issue on device X-BeenThere: bismark-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: BISMark related software development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 00:22:00 -0000 On 18/04/11 00:22, Nick Feamster wrote: > On Apr 17, 2011, at 10:46 AM, Dave Taht wrote: >> I'm mildly confused as to your topology here. Diagram? >> >> You are behind NAT by default, so if you try to ping through the WAN > port to something anything inside the LAN, those machines will be unreachable. > You should however, be able to ping from the wireless to anywhere wired, > LAN or WAN port. If you have AP isolation turned on in the wireless side, > you cannot ping any other wireless connection, and I'm unsure what the > behavior is for wired to wireless in that case. > > I'm just talking about my LAN here: > > SERVER<----(2.4 GHz wireless, SSID "foo") ----> WNDR3700<---- (wired LAN port) ----> Access Point 2 > > * When I associate to AP2, I can ping SERVER, and resolve MDNS names. > * When I log into WNDR, I can ping SERVER > * When I associate to the WNDR3700, I can neither ping the server, nor resolve MDNS names. > > So, isn't it strange that everything works when I'm connected via AP2, > but not via the WNDR? By my reasoning, all of the traffic that I'm > sending when I'm connected via AP2 would have to go through the WNDR anyhow... I am not sure how relevant my experience is here, as I am not using a WNDR3700. I have seen this behavior on other APs. I have a hunch that its related to how ARP is treated on the AP. In my case specifically on WPA2 on a modern Billion device that does ADSL2+/AP/VoIP. This behavior generally does not seem to be an issue on an open network or using WEP. I noticed this last weekend when I was setting up my server at home to to builds on, transfering files around with rsync/scp/etc Only when *both* hosts on the wireless have ping'd the AP can then you ping the other hosts from wireless to wireless... ([laptop A], [laptop B]) --wifi-wpa2--> [AP] <--wired-- [server] For example I can not ping [laptop B] from [laptop A], both being on the wireless using WPA2, until I ping the AP from both laptops. I can however ping the [server] from both laptops. However I can not ping either latptop from [server] until the laptop has ping'd [AP]. There is currently no mdns in use by any of these devices. Perhaps the AP is building an internal table using mdns to allow/identify traffic across its interfaces? regards, Kim