I'm sorry. CDMA is not correct, I messed up my abbreviations. CRDA is the true acronym. http://linuxwireless.org/en/developers/Regulatory/CRDA

Central Regulatory Domain Agent
CRDA acts as the udev helper for communication between the kernel and userspace for regulatory compliance. It relies on nl80211 for communication. CRDA is intended to be run only through udev communication from the kernel. The user should never have to run it manually except if debugging udev issues.
(and further down:) 
If you do not want to install CRDA on a host, you can simply enable the CONFIG_CFG80211_INTERNAL_REGDB on your kernel. Once enabled you can place the db.txt from the wireless-regdb into net/wireless/db.txt. The downside to using this option is that you will need to rebuild your kernel for any regulatory updates, therefore using CONFIG_CFG80211_INTERNAL_REGDB is not recommended.

So maybe we're getting somewhere close? I am not set up to rebuild kernels from scratch, yet. I'm looking to see if there is a way to disable this without rebuilding the kernel.

Here's a tutorial on how to make your own region. Not sure about legality, but it may be useful... I haven't tried this.
http://deckardt.nl/blog/2011/01/20/regulatory-limitations-in-linux-wireless/

Here's another example of someone else having the problem.
http://www.linuxforums.org/forum/slackware-linux/171903-avoid-calling-crda.html

OK so maybe something is flawed with the CRDA subsystem, then. Disabling it entirely may be against FCC regulations but would give us a chance to test it out.

Thoughts? Has anyone tried mucking around with CRDA?

Sincerely,
Blaine



On Wed, Feb 29, 2012 at 3:35 PM, Blaine Booher <bgbooher@gmail.com> wrote:
The plot thickens....

We got in a brand new USB dongle today. It uses the RTL8187 kernel module which, lucky for us, is already present on our overo build. All we did was plug it in and we were good to go. Signals strength is much stronger than with the overo (67/70 vs 45/70). Our network was up and running. We were celebrating the easy solution to our annoying wifi problem...
... until the same problem occurred 20 minutes later. An "updating CDMA regional settings" message displayed on the screen, and we lost network connectivity. (No longer associated)

So now this leads me to believe that the problem may actually be in the wireless subsystem, not the driver. (Wired connections have never been an issue).

We're going to try a newer image to see what happens. I hope this helps.

Sincerely,
Blaine



On Wed, Feb 29, 2012 at 11:51 AM, Steve Sakoman <sakoman@gmail.com> wrote:
On Wed, Feb 29, 2012 at 8:16 AM, Blaine Booher <bgbooher@gmail.com> wrote:
> Oops. Here was the message we were getting.
>>
>> Calling CRDA for country: US
>
> But that might be a side effect of simply dropping the connection.
>
> We just checked our hardware, both our server and client (both are overos)
> disconnected last night.
> We turned on full debugging in the libertas module, this is what we saw.
>
> Our "client":
> libertas enter: lbs_process_event()
> libertas cmd: EVENT: link lost
> libertas enter: lbs_mac_event_disconnected()
> libertas enter (INT): lbs_hard_start_xmit()
> libertas tx (INT): lbs_hard_start_xmit lined up packet
> libertas leave (INT): lbs_hard_start_xmit(), ret 0
> libertas leave: lbs_mac_event_disconnected()
> libertas leave: lbs_process_event(), ret 0
>
> Our "server":
> libertas enter: lbs_process_event()
> libertas cmd: EVENT: link lost
> libertas enter: lbs_mac_event_disconnected()
> libertas leave: lbs_mac_event_disconnected()
> libertas leave: lbs_process_event(), ret 0

What kind of network traffic is going one during this test?

I have a feeling that this is going to be tough to debug unless I can
reproduce the issue here.

Perhaps we can start by using the same image.  Is yours sharable or
does it rely on custom hardware?

Same question for Mike if he is listening . . .

Steve

> On Wed, Feb 29, 2012 at 10:42 AM, Blaine Booher <bgbooher@gmail.com> wrote:
>>
>> Thanks Steve. I've heard from Don @ Gumstix that you're the man to talk to
>> about this. See inline.
>>
>>
>>
>> On Tue, Feb 28, 2012 at 11:54 PM, Steve Sakoman <sakoman@gmail.com> wrote:
>>>
>>> On Tue, Feb 28, 2012 at 8:18 PM, roystonvasey <mikestocks@madasafish.com>
>>> wrote:
>>> > Dear Blaine,
>>> > I still have the problem.
>>> > I ran out of time trying to resolve the problem.
>>> > We have 25 Overo Fire based units in the field. They all exhibit the
>>> > same
>>> > problem though the up time varies between different units. The worst
>>> > one
>>> > looses connection every 2 - 3 minutes the best one normally stays up
>>> > for
>>> > about 28 hours, most stay up for 7 - 10 minutes.
>>>
>>> A number of people have reported this and I have been trying to
>>> reproduce it without success.
>>>
>>> Can you tell me a little more about your setup (not just Mike but
>>> anyone who has the issue)?
>>>
>>> 1. What kernel version (and is it a standard Gumstix build or have you
>>>
>>> modified it)?
>>
>>
>> Linux overo 2.6.34 #1 Wed Oct 20 10:22:48 PDT 2010 armv7l GNU/Linux
>> After having problems with newer builds, we found that our stock build was
>> best.
>>
>> Newer builds manifested other wifi problems, such as not being able to
>> connect at all, wifi not being recognized, etc.
>>
>> When our wifi chip works, it works great... until it stops working (blue
>> led turns off).
>>
>>
>>>
>>> 2. What brand(s) of access point are you using in your installations?
>>
>>
>> Rosewell (recently new), D-Link, and two of unknown brand (but I could
>> really check if necessary)
>>
>>>
>>> 3. Are you using open or secured networks, if secured what type?
>>
>> Tried with open, WEP, and WPA-2. All three have failed.
>>
>>>
>>> 4. Are you using the standard Gusmtix antenna?
>>
>> Yes.
>>
>>>
>>> 5. Have you noticed any correlation between signal strength and rate
>>> of connection loss?
>>
>> I thought this may have been the case, but I don't know if it is any more.
>> We moved our router to across the building but it did not make the problem
>> worse.
>>
>>>
>>> 6. Are there any "interesting" console messages around the time the
>>> connection is lost (i.e. CRDA update messages)?
>>
>>
>> The only one we ever have seen, and this was a month ago and no longer is
>> the case, was the following:
>>
>>>
>>> 7. Any other observations that might help me to reproduce this?
>>>
>>> I'd love to get to the bottom of this, but my test systems have been
>>> running for many days connected to Airport and Netgear APs with no
>>> connection loss.
>>>
>>> Steve
>>>
>>> > As you observed after a connection is lost ifconfig and iwconfig still
>>> > report the interface to be up.
>>> > I run a cron job every 5 minutes to check that there is still a
>>> > connection
>>> > by pinging 'always up' and restarting the network if needed.
>>> >
>>> > #!/bin/sh
>>> > # Tests network configuration
>>> > # Restarts any failed connections
>>> >
>>> > wifi_alive()
>>> > {
>>> >        if ping -q -w 2 -c 2 "${ALWAYS_UP_IP}" >/dev/null 2>&1; then
>>> >                echo "WiFi network is up."
>>> >        else
>>> >                echo "WiFi network is down."
>>> >                /etc/init.d/networking restart
>>> >        fi
>>> > }
>>> >
>>> > ALWAYS_UP_IP="4.2.2.1"
>>> >
>>> > if  /sbin/ifconfig | /bin/grep -q wlan0; then
>>> >        echo "Using wifi (wlan0) for connectivity."
>>> >        wifi_alive
>>> > fi
>>> >
>>> >
>>> > Cheers Mike.
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> > http://gumstix.8.n6.nabble.com/Overo-Wifi-is-turned-off-after-2-3-minutes-of-inactivity-tp1590552p4530055.html
>>> > Sent from the Gumstix mailing list archive at Nabble.com.
>>> >
>>> >
>>> > ------------------------------------------------------------------------------
>>> > Virtualization & Cloud Management Using Capacity Planning
>>> > Cloud computing makes use of virtualization - but cloud computing
>>> > also focuses on allowing computing to be delivered as a service.
>>> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> > _______________________________________________
>>> > gumstix-users mailing list
>>> > gumstix-users@lists.sourceforge.net
>>> > https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization & Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> gumstix-users mailing list
>>> gumstix-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>>
>>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> gumstix-users mailing list
> gumstix-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gumstix-users
>

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
gumstix-users mailing list
gumstix-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gumstix-users