"Calling CRDA to update world regulatory domain"

Completely Clueless · 11-25-2013, 12:44 PM

For some 7 months now I've had a Raspberry Pi running Raspbian acting as an embedded controller for a time release lock. The system is contained on a 4Gb SD card which has the little tab in the 'locked' position so it can't get written to or corrupted (in theory at any rate). Everything was running sweet as a nut until about a week ago when I couldn't get the lock to open.
This system relies on getting the time/date from the network via a wi-fi connection, but on examination of the problem, it seems some sort of subroutine has unaccountably started interfering with the bash script I wrote to perform the timing function and is constantly interrupting it. Here's an example of what I'm seeing on a screen when this happens:

Code:

[ 338.519037] cfg80211: Calling CRDA to update world regulatory domain
[ 338.523266] cfg80211: World regulatory domain updated:
[ 338.523269] cfg80211: (start_freq - end_freq @ bandwidth),
(max_antenna_gain, max_eirp)
[ 338.523272] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523276] cfg80211: (2457000 KHz - 2482000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523279] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300
mBi, 2000 mBm)
[ 338.523281] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 338.523284] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300
mBi, 2000 mBm)
[ 340.948738] wlan1: authenticate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.950479] wlan1: authenticated
[ 340.950707] wlan1: associate with 00:1d:a2:d8:7e:70 (try 1)
[ 340.953611] wlan1: RX ReassocResp from 00:1d:a2:d8:7e:70 (capab=0x401
status=0 aidy)
[ 340.953614] wlan1: associated
[ 458.646604] wlan1: deauthenticated from 00:1d:a2:d8:7e:70 (Reason: 2)

...and so on. It actually goes on for page after page.

So anyway, I re-imaged the SD card from a backup and the same problem is happening, so it's obviously something extraneous that's changed rather than any corruption or virus on the card.
Anyone know what this problem is caused by and how I can get rid of it?
TIA,
CC

unSpawn · 11-25-2013, 01:24 PM

Quote:

Originally Posted by Completely Clueless

Anyone know what this problem is caused by and how I can get rid of it?

It's not a problem but messages of the informational level. AFAIK the cfg80211 doesn't have any modprobe switches to quieten it down so you'll have to bit bucket them via a Rsyslogd or Syslog-NG filter. Else maybe you shouldn't use a script but NTP instead or refine it.

Completely Clueless · 11-25-2013, 04:07 PM

I don't know how you can say "it's not a problem" when it is continually interfering with the running of this script right from the moment the thing boots up! How did it get there in the first place? For 7 months the thing was running like a Swiss watch, then all of a sudden out of nowhere these infernal interruptions crop up which render the whole system useless.

rokytnji · 11-25-2013, 04:15 PM

I get this as the last message at shutdown. I don't run your script so maybe that was why
you are having a problem. I pulled this out of /var/log/kernel.log

Code:

Oct 22 08:45:26 biker kernel: [47645.439193] wlan1: deauthenticating from d8:6c:e9:5f:07:44 by local choice (reason=3)
Oct 22 08:45:26 biker kernel: [47645.502905] cfg80211: Calling CRDA to update world regulatory domain
Oct 22 11:52:47 biker kernel: imklog 5.8.11, log source = /proc/kmsg started.
Oct 22 11:52:47 biker kernel: [    0.000000] Initializing cgroup subsys cpuset
Oct 22 11:52:47 biker kernel: [    0.000000] Initializing cgroup subsys cpu
Oct 22 11:52:47 biker kernel: [    0.000000] Linux version 3.7.10-antix.3-486-smp (unknown) (root@antiX1) (gcc version 4.7.3 (Debian 4.7.3-4) ) #1 SMP Sat Jun 1 13:59:18 EEST 2013
Oct 22 11:52:47 biker kernel: [    0.000000] Atom PSE erratum detected, BIOS microcode update recommended
Oct 22 11:52:47 biker kernel: [    0.000000] Disabled fast string operations

I THINK that is why Unspawn means it is no problem. I get the CDRA message on all my AntiX
laptops and Desktop computers. It is the last message before shutdown.

unSpawn · 11-25-2013, 04:40 PM

...additionally

Quote:

Originally Posted by Completely Clueless

(..) it is continually interfering with the running of this script

what script exactly? Who created it? What does it do? Or else what's the contents (as in 'grep -v ^# script|grep .;').

Completely Clueless · 11-25-2013, 04:56 PM

Quote:

Originally Posted by unSpawn

...additionally

what script exactly? Who created it? What does it do? Or else what's the contents (as in 'grep -v ^# script|grep .;').

This one:

Code:

#!/bin/bash        
clear
# remember to create execute permissions for user before running
echo Starting Timelock script...
sleep 5
echo Initialising GPIO pins 2 and 3 to near zero volts...
sleep 3

sudo /home/pi/wiringPi/gpio/gpio -g mode 3 out
sudo /home/pi/wiringPi/gpio/gpio -g write 3 0
sudo /home/pi/wiringPi/gpio/gpio -g mode 2 out
sudo /home/pi/wiringPi/gpio/gpio -g write 2 0

echo Giving connection extra time to stabilise...
sleep 30

x=`date +%u`   # assigns a single integer representing the day of the week to x
y=`date`

if(( $x == 2 || $x == 5 ));    # Monday is 1, Tuesday is 2 and so on...Friday is 5
   then
   echo 'Today is '$y
   echo Access granted. sending enable signal to lock mechanism.
   sudo /home/pi/wiringPi/gpio/gpio -g write 3 1 # set pin 3 of the pi to high if it's correct day
   sleep 30
   sudo poweroff
   else
   echo 'It is NOT Friday today! Today is '$y  'so sorry, no access possible. Will now close down...'
   sudo /home/pi/wiringPi/gpio/gpio -g write 2 1 # turn on the red led
   sleep 10    
   sudo poweroff
fi

I wrote it. It enables an electronic lock to be opened on Tuesdays and Fridays only (as is evident from the comments).

Completely Clueless · 11-25-2013, 05:03 PM

Quote:

Originally Posted by rokytnji

I get this as the last message at shutdown. I don't run your script so maybe that was why
you are having a problem. I pulled this out of /var/log/kernel.log
[snip]

I THINK that is why Unspawn means it is no problem. I get the CDRA message on all my AntiX
laptops and Desktop computers. It is the last message before shutdown.

Interesting. If it did this on mine only at shutdown it wouldn't be a problem. Perhaps if I moved the instruction calling the script to a different file it might fix the problem. Maybe I'm calling it too soon before the system has settled down. Anyway as I say, it never used to matter, though. :-/

unSpawn · 11-25-2013, 05:51 PM

So the script itself isn't the problem (can't see how, looks clean) but apparently how and when you call it. Elaborate?

Completely Clueless · 11-25-2013, 06:00 PM

Quote:

Originally Posted by unSpawn

So the script itself isn't the problem (can't see how, looks clean) but apparently how and when you call it. Elaborate?

I was just trying to find the file and folder from which it is called but it's taking longer than I thought. If I don't post the answer again within 10 mins, it'll have to be tomorrow as it's late here already...

Completely Clueless · 11-25-2013, 06:12 PM

Right, found it. The script is called by a line in the file /etc/rc.local but there is also an rc.local file in /etc/init.d so perhaps I should transfer the call over to the other one (although I can't see it making much difference).
Right, got brain-ache now so off to bed!

rokytnji · 11-25-2013, 07:12 PM

In the House now on my

Code:

$ inxi -Fxz
System:    Host: biker Kernel: 3.12.1-antix.1-amd64-smp x86_64 (64 bit, gcc: 4.8.2) 
           Desktop: Fluxbox 1.3.5 Distro: antiX-13-rc1_x64-full Luddite 3 May 2013
Machine:   System: LENOVO product: 6075BHU version: ThinkCentre M57
           Mobo: LENOVO model: LENOVO Bios: LENOVO version: 2RKT41AUS date: 03/20/2008
CPU:       Dual core Intel Pentium Dual CPU E2160 (-MCP-) cache: 1024 KB flags: (lm nx sse sse2 sse3 ssse3) bmips: 7182.74 
           Clock Speeds: 1: 1200.00 MHz 2: 1800.00 MHz
Graphics:  Card: Intel 82Q35 Express Integrated Graphics Controller bus-ID: 00:02.0 
           X.Org: 1.14.3 drivers: intel (unloaded: fbdev,vesa) Resolution: 1600x900@60.0hz 
           GLX Renderer: Mesa DRI Intel Q35 GLX Version: 2.1 Mesa 9.2.2 Direct Rendering: Yes
Audio:     Card: Intel 82801I (ICH9 Family) HD Audio Controller driver: snd_hda_intel bus-ID: 00:1b.0 
           Sound: Advanced Linux Sound Architecture ver: k3.12.1-antix.1-amd64-smp
Network:   Card-1: Ralink RT2561/RT61 802.11g PCI driver: rt61pci ver: 2.3.0 bus-ID: 11:0c.0
           IF: wlan0 state: up mac: <filter>
           Card-2: Intel 82566DM-2 Gigabit Network Connection driver: e1000e ver: 2.3.2-k port: 1820 bus-ID: 00:19.0
           IF: eth0 state: down mac: <filter>
Drives:    HDD Total Size: 80.0GB (25.7% used) 1: id: /dev/sda model: ST380815AS size: 80.0GB 
Partition: ID: / size: 41G used: 20G (50%) fs: ext4 ID: swap-1 size: 3.27GB used: 0.00GB (0%) fs: swap 
Sensors:   System Temperatures: cpu: 44.0C mobo: N/A 
           Fan Speeds (in rpm): cpu: N/A 
Info:      Processes: 119 Uptime: 2 days Memory: 565.9/1980.8MB Runlevel: 5 Gcc sys: 4.8.2 
           Client: Shell (bash 4.2.45) inxi: 1.9.16

I checked AGAIN so you will see CDRA is a normal thing

Code:

Nov 24 06:25:33 biker kernel: [72907.300033] ieee80211 phy0: wlan0: No probe response from AP d8:6c:e9:5f:07:44 after 500ms, disconnecting.
Nov 24 06:25:33 biker kernel: [72907.308469] ieee80211 phy0: rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the non-full queue 0
Nov 24 06:25:33 biker kernel: [72907.308469] Please file bug report to http://rt2x00.serialmonkey.com
Nov 24 06:25:33 biker kernel: [72907.312134] cfg80211: Calling CRDA to update world regulatory domain

You'll see in my inxi report I am running a 3.12.1 64bit kernel and above was also pulled from /var/log/kern.log.
My other post was from my 32bit i486 3.12.1 kernel on my Atom Netbook running the same distro but in 32bit.

Completely Clueless · 11-26-2013, 03:29 AM

OK, accepting what you say that it's "normal" behaviour, that still leaves me with a system that this "normal, not-a-problem" thing has rendered inoperative.
My original questions remain unanswered, however. What is this thing, how come it suddenly began interfering with my script after 7 months of trouble-free operation and how do I get rid of it - or at least work around it?

rokytnji · 11-26-2013, 08:13 AM

Gee, I don't know. Might help. might not.

http://wireless.kernel.org/en/developers/Regulatory

Completely Clueless · 11-26-2013, 10:52 AM

Quote:

Originally Posted by rokytnji

Gee, I don't know. Might help. might not.

http://wireless.kernel.org/en/developers/Regulatory

Thanks, I shall take a look later (after a few triple expressos to improve my concentration).

Anyway, searches of the web have revealed that many other users have experienced similar problems with this particular interference, though nowhere have I read anything which explains what precisely it is, where it came from, or how it mysteriously appears (in my case on an SD card which is mounted read-only in /etc/fstab AND has the 'lock' tab in the locked position to prevent alteration/corruption by anyone other than myself (since I alone have physical access).
Perhaps I should have posted this query in the 'security' forum?

unSpawn · 11-26-2013, 04:13 PM

Quote:

Originally Posted by Completely Clueless

Anyway, searches of the web have revealed that many other users have experienced similar problems with this particular interference, though

Could it be what you are seeing in the logs actually is a side effect of Something Completely Different? Like the device constantly trying to re-establish a connection with the AP? does your AP send a country code? As in 'iw set reg ES'?

Quote:

Originally Posted by Completely Clueless

nowhere have I read anything which explains what precisely it is, where it came from, or how it mysteriously appears

That's where the link rokytnji posted comes in.

Quote:

Originally Posted by Completely Clueless

Perhaps I should have posted this query in the 'security' forum?

No, this isn't a Linux security question.