Steve,
Would you be so kind as to provide a binary image of your kernel? We'd love to test it out.

We can confirm that the latest "sakoman" build (overo / console / current) with kernel 3.0.0 has exact same problem.

Good news is we have no problems getting wifi online, so that's good.

I'm wondering if the "Reason 4" may be a unique problem to our external wifi chip. Meaning the onboard overo, since it does not give a reason, may be having a different issue. We're back to pinging every 30 seconds and will see if this craps out by morning.

Sincerely,
Blaine



On Wed, Feb 29, 2012 at 4:43 PM, Steve Sakoman <sakoman@gmail.com> wrote:
FWIW, the kernel build I have been testing has CONFIG_CFG80211_INTERNAL_REGDB=y

So perhaps that might explain why I don't see this . . .

Steve

On Wed, Feb 29, 2012 at 1:20 PM, Blaine Booher <bgbooher@gmail.com> wrote:
> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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