From owner-freebsd-questions@FreeBSD.ORG Sun Aug 28 14:04:33 2011 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A799A106564A for ; Sun, 28 Aug 2011 14:04:33 +0000 (UTC) (envelope-from cyberleo@cyberleo.net) Received: from paka.cyberleo.net (paka.cyberleo.net [66.219.31.21]) by mx1.freebsd.org (Postfix) with ESMTP id 66C228FC08 for ; Sun, 28 Aug 2011 14:04:33 +0000 (UTC) Received: from [172.16.44.4] (den.cyberleo.net [66.253.36.39]) by paka.cyberleo.net (Postfix) with ESMTPSA id 4209728405; Sun, 28 Aug 2011 10:04:32 -0400 (EDT) Message-ID: <4E5A4AEF.7050104@cyberleo.net> Date: Sun, 28 Aug 2011 09:04:31 -0500 From: CyberLeo Kitsana User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110822 Lightning/1.0b3pre Thunderbird/3.1.10 MIME-Version: 1.0 To: Paul Beard References: <51754C95-3688-4B33-BD98-7DED5F28DC0E@gmail.com> <4E59BA7F.305@cyberleo.net> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: "freebsd-questions@FreeBSD. ORG" Subject: Re: wireless access point in FreeBSD 8.2p2 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2011 14:04:33 -0000 On 08/27/2011 11:08 PM, Paul Beard wrote: > > On Aug 27, 2011, at 8:48 PM, CyberLeo Kitsana wrote: > >> tcpdump(1) is your friend; it seems cryptic and obtuse at first glance, >> but it will help immensely >> > I wasn't sure there was any reason to use that yet: I can't even ping it from another host. It is especially useful when you cannot ping, as it can tell you if the packets are even arriving. In my case, it helped indicate that packets were arriving, but that, because I had re-used the SSID, the client was applying encryption settings (from the old AP) that the new AP was not expecting, and so the packets were arriving horribly mutilated. >> wlan0 itself will not assign v4 addresses to clients; you need a DHCP >> server for that >> > I plan to use static addresses as I do already (this is just a backup in case my WRT54G develops any issues). Static is just fine; just covering all points that came to mind. >> The hostap machine must be explicitly told to route packets, by setting >> gateway_enable="YES" in rc.conf and adding the appropriate routes >> > > I have that and the existing wired interface has the route set (I am connecting through that to make this work). This raises the question of whether I am expecting the functionality of a bridge without having specifically made one. Bridging using if_bridge(4) is a different beast, but one that seems much easier to set up in comparison. I am using it in a slightly different configuration for another project, and it's pretty straightforward. Bridging does not require gateway mode to be enabled, as the packet forwarding is performed within the bridge driver, instead of within the network stack. Because of this, however, proper firewalling of wired and wireless clients is more difficult, and can weaken the security of your implicitly trusted cat5 cables. >> If you're intending this to be a home gateway, you will likely also need >> NAT. > > > I think NAT is handled by the telco hardware (on cable) for now. > > Hmm, starting to think this may not work as I expect. It might be fine as an additional AP but not as a replacement without some configuration changes that I will have forgotten how to make by then. The WRT box runs the PPPoE connection for DSL which I should be switching back to. I'm sure it can be done with this but I think I'm asking for trouble. I cannot say this is an easy task, given the number of components involved in a functioning gateway. I can say that it is quite possible given the software involved, though, since I've been running a homebrew FreeBSD-based gateway for years, and just yesterday introduced built-in wireless to replace the aging WRT54G AP and reduce power requirements further. > So maybe this is a solution in search of a problem. Might be to just find a spare WRT54G or its modern equivalent. That would probably be the easiest solution; perhaps not the most satisfying, though. > But that doesn't mean I don't want to figure this out. Getting the wireless component functional by itself seems to be the biggest hurdle at the moment; after that, it's just one block atop another. I did recall one more potential issue: during testing with a Gentoo machine with an iwlagn adapter, my adjustments frequently confused the adapter so thoroughly that it refused to function correctly without a reset, even when the settings were correct. It's more annoying, but a full reset of all hardware involved after each change might help isolate any changes that put the hardware into an inconsistent state. Hope this helps! -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/