From: Steve S. <sa...@gm...> - 2012-02-29 21:43:43
|
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 <bgb...@gm...> 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 <bgb...@gm...> 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 <sa...@gm...> wrote: >>> >>> On Wed, Feb 29, 2012 at 8:16 AM, Blaine Booher <bgb...@gm...> >>> 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 <bgb...@gm...> >>> > 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 <sa...@gm...> >>> >> wrote: >>> >>> >>> >>> On Tue, Feb 28, 2012 at 8:18 PM, roystonvasey >>> >>> <mik...@ma...> >>> >>> 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 >>> >>> > gum...@li... >>> >>> > 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 >>> >>> gum...@li... >>> >>> 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 >>> > gum...@li... >>> > 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 >>> gum...@li... >>> 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 > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > |