Sorry, late to the party here.

I am sending this through my OpenBSD 3.5 wireless access point with
ral(4) HostAP which has been serving my home network since release 3.3
(I think) for a few years now (it's on 3.5 because I'm lazy and
haven't been bothered upgrading!)

ral0 at pci0 dev 15 function 0 "Ralink RT2560" rev 0x01: irq 5,
address 00:13:d3:6a:bb:9d
ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525

The Ralink has been remarkably stable, I will say, and note that
hostapd(8) is not required.

The one downside is the lack of support for 802.11 Power Saving Mode
in HostAP mode which is well documented. I have found that Windows
clients and even my Nokia E61i allow turning off Power Saving Mode, so
no dramas at all for them. Neither MacOS X nor Apple's iOS provide
this functionality, however, so if you have Macs, iPhones or (I
suspect) iPads on your network then this could be a serious problem
for you. As for other operating systems and devices, check to see if
they support deactivating 802.11 Power Saving Mode if their
connectivity is important to you.

For example, it's meant that my wife's iPhone is configured to use the
3G phone network at all times, which obviously costs more in terms of
her phone bill.

I've found my 3 year old MacBook Pro turns off Power Saving Mode on
its Airport Extreme Card when plugged into the Mains, whereas
(strangely) my friend's 2 year old MacBook does not and so is quite
unusable on my network. Running the following command on the Mac in
the background seems to keep the Airport card from going into Power
Saving Mode and hence packet loss is kept to a minimum:

# sudo ping -i 0.3 <YourOpenBSDAccessPoint>

A kludge that consumes battery power quickly, but a workaround nevertheless!

Best wishes with it.

2010/12/14  <[email protected]>:

> From: Lists Account <[email protected]>
> To: [email protected]
> Date: Mon, 13 Dec 2010 13:29:14 +0100
> Subject: Re: OpenBSD Access Point? (Summary)
> Hi All,
>
> Summarising, for future reference...
>
> I received some six responses. Overall the feedback was a little
> disappointing. Three responses suggested that it would be easier/less
> time consuming/more stable to simply connect a consumer access point
> device via Ethernet. Of course, I wouldn't learn as much by doing this
> :-(. The background to this seems to be mostly issues with the
> configuration and stability of drivers e.g. ath and ral.
>
> At least a couple of the respondents are successfully using ALIX boards,
> including the desired 2D13. None of the responses related to the
> specific wireless devices that I asked about. Some of those mentioned as
> having been used included the AR5212 and AR5413 (with ath) and the
> RT2561C (ral).
>
> A couple of responses indicated that OpenBSD doesn't support 802.11n. I
> got my initial information from the athn manual page. It begins:
>> ...
>> NAME
>>     athn - Atheros IEEE 802.11a/g/n wireless network device
>> ...
>>     The athn driver provides support for a wide variety of
>>     Atheros 802.11n devices ...
>
> Which I incorrectly took to mean that "n" networking was supported...
>
> However, further down in the same man page, under caveats, it states:
>> ...
>>     The athn driver does not support any of the 802.11n capabilities
>>     offered by the adapters.  Additional work is required in
>>     ieee80211(9) before those features can be supported.
>> ...
>
> That should teach me (yet again) to read the whole man page :-)
>
> Cato Auestad provided a very helpful link to a description of his
> working (ral based) OpenBSD configuration:
>    http://bleakgadfly.com/notes/openbsd_wifi.html
>
> There he mentions that support from the hostap daemon - hostapd(8) - is
> also necessary for such a configuration. Something else that I hadn't
> realised.
>
> So, based on the feedback, it looks like while this might be a fun
> project, it could be hard to create a stable "production" access point.
> Thanks for all the info.

Reply via email to