Wireless connection freezes the computer

Hi,

Whenever I connect to my school networks, after a while my computer freezes, everything is locked and caps lock blinks.

There are two networks in my school. Both gives causes to crash. One is WEP + PEAP with Thawte Certificate. Other one is open network.

However it works perfectly fine at home where I have just WEP with no authentication.

Any helps?

I think it might be about something wrong with my wireless driver (my card is Intel 3945ABG)

I have been using OpenSuse for few months. I used to be a RedHat stream fan however OpenSuse changed it completely :slight_smile: I do not want to change my distribution and need help seriously.

-bilgehan

mrantims wrote:
> Hi,
>
> Whenever I connect to my school networks, after a while my computer
> freezes, everything is locked and caps lock blinks.
>
> There are two networks in my school. Both gives causes to crash. One is
> WEP + PEAP with Thawte Certificate. Other one is open network.
>
> However it works perfectly fine at home where I have just WEP with no
> authentication.
>
> Any helps?
>
> I think it might be about something wrong with my wireless driver (my
> card is Intel 3945ABG)
>
> I have been using OpenSuse for few months. I used to be a RedHat stream
> fan however OpenSuse changed it completely :slight_smile: I do not want to change my
> distribution and need help seriously.

Try installing the compat-wireless package for your kernel. To do
this, you will need to enable the repository at
http://download.opensuse.org/repositories/home:/Akoellh/openSUSE_11.1_Update/

This package will have the latest version of the 3945 driver.

Two little corrections.

a) compat-wireless was removed from my home-Repo, it is available via

Index of /repositories/home:/Akoellh:/compat-wireless_STABLE

or

Index of /repositories/driver:/wireless

respectively (both contain the same drivers).

b) The drivers are not the “bleeding edge” ones, they are based on 2.6.30 from

stable - Linux Wireless

and patched to the most recent version of 2.6.30 considering the wireless code in that package (they are 2.6.30.6 ATM, although the recent kernel of the 2.6.30 series is 2.6.30.7 as there were no changes in the respective files when going to 2.6.30.7).

If you want (need) completely bleeding edge drivers, then go for

Software.openSUSE.org

and search for “compat-wireless” there, there are in fact several other people offering compat-wireless packages, their state can be identified by the date in the filenames.

//Edit:

Just saw, that 2.6.30.8 was released a few days ago and there were two changes to the drivers/modules (cfg80211 and ath5k), so the package will soon bee also updated to 2.6.30.8.

Are you certain the issue is the network driver? Do you use any other software while at school?

If you think the problem is the driver you can see if the same issue occurs using ndiswrapper and windows driver. You might not be able to suspend/resume and there might be other issues with that approach but you should be able to pinpoint the driver as the cause.

Changes committed and packages building ATM.

If nothing goes wrong, they will be available in a few hours.

Wow, very fast respond.
I will try the compat-wireless first. I use exactly the same set of applications: banshee, firefox and pidgin both at home and at school.

@akoellh: impressive.

community working 7/24 on developing, releasing and helping. linux rocks!!! :slight_smile:

Akoellh wrote:
> Two little corrections.
>
> a) compat-wireless was removed from my home-Repo, it is available via
>
> ‘Index of /repositories/home:/Akoellh:/compat-wireless_STABLE’
> (http://tinyurl.com/yevc4s6)
>
> or
>
> ‘Index of /repositories/driver:/wireless’
> (http://download.opensuse.org/repositories/driver:/wireless/)
>
> respectively (both contain the same drivers).
>
> b) The drivers are not the “bleeding edge” ones, they are based on
> 2.6.30 from
>
> ‘stable - Linux Wireless’
> (http://www.linuxwireless.org/en/users/Download/stable/)
>
> and patched to the most recent version of 2.6.30 considering the
> wireless code in that package (they are 2.6.30.6 ATM, although the
> recent kernel of the 2.6.30 series is 2.6.30.7 as there were no changes
> in the respective files when going to 2.6.30.7).
>
> If you want (need) completely bleeding edge drivers, then go for
>
> ‘Software.openSUSE.org’ (http://software.opensuse.org/search)

I assume that there is a good reason for not using the bleeding-edge
drivers. For the Broadcom 4315 devices, one needs them.

The package has some other drivers added, which I could not get to build with the bleeding edge drivers, one of them is ar9070 in a version shortly before it was officially included into compat-wireless.

The reason for including that older version is simply, that this one could be built against 2.6.27 (openSUSE 11.1), the code included in compat-wireless does not build with kernel < 2.6.29, so I would have to exclude that driver in a bleeding edge package.

The package itself has become quite a “monster” over time and switching to code from >= 2.6.31 will be a lot of work in reviewing/adapting patches, so that package won’t be updated to code from >= 2.6.31, but if I find the time I might be offering another “branch” with more recent code.

As several other repos offer bleeding edge drivers in their compat-wireless packages, this “branch” is on my “TODO”-list, but it’s not among the most urgent ones.

On 10/01/2009 02:26 PM, Akoellh wrote:
>
> lwfinger;2046464 Wrote:
>>
>> I assume that there is a good reason for not using the bleeding-edge
>> drivers. For the Broadcom 4315 devices, one needs them.
>
> The package has some other drivers added, which I could not get to
> build with the bleeding edge drivers, one of them is ar9070 in a version
> shortly before it was officially included into compat-wireless.
>
> The reason for including that older version is simply, that this one
> could be built against 2.6.27 (openSUSE 11.1), the code included in
> compat-wireless does not build with kernel < 2.6.29, so I would have to
> exclude that driver in a bleeding edge package.
>
> The package itself has become quite a “monster” over time and switching
> to code from >= 2.6.31 will be a lot of work in reviewing/adapting
> patches, so that package won’t be udated to code from >= 2.6.31, but if
> I find the time I might be offering another “branch” with more recent
> code.

I agree that it is a monster; however, I built it against 2.6.31-10
from 11.2 M8 this morning so that my Broadcom 4315 would work. All the
drivers built OK. I have only used b43 so far.

I will boot 2.6.27 in 11.1 and see what needs to be done to get it to
build. According to the wiki, it should just work. I’ll send you any
patches that might be needed.

Well, although I had something else in mind when speaking of a “monster” (actually I meant my set of patches which have gone into the RPM file to add extra drivers, device IDs and change configs to include those extra drivers, etc …), recent version of bleeding edge also (just) turned out to be a beast.

Tried with several snapshots (from 2009-09-19 to 2009-09-030) and all fail very early here against 2.6.27.29 on 11.1:

make
./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
make -C /lib/modules/2.6.27.29-0.1-default/build M=/tmp/compat-wireless-2009-09-19 modules
make[1]: Entering directory `/usr/src/linux-2.6.27.29-0.1-obj/x86_64/default'
make -C ../../../linux-2.6.27.29-0.1 O=/usr/src/linux-2.6.27.29-0.1-obj/x86_64/default/. modules
  LD      /tmp/compat-wireless-2009-09-19/drivers/misc/eeprom/built-in.o
  CC [M]  /tmp/compat-wireless-2009-09-19/drivers/misc/eeprom/eeprom_93cx6.o
In file included from /tmp/compat-wireless-2009-09-19/include/net/compat.h:19,
                 from &lt;command-line&gt;:0:
/tmp/compat-wireless-2009-09-19/include/net/compat-2.6.28.h:152: error: redefinition of ‘struct tracepoint’
In file included from /tmp/compat-wireless-2009-09-19/include/net/compat.h:19,
                 from &lt;command-line&gt;:0:
/tmp/compat-wireless-2009-09-19/include/net/compat-2.6.28.h:182:1: warning: "DEFINE_TRACE" redefined
In file included from /usr/src/linux-2.6.27.29-0.1/include/linux/module.h:19,
                 from /usr/src/linux-2.6.27.29-0.1/include/linux/textsearch.h:7,
                 from /usr/src/linux-2.6.27.29-0.1/include/linux/skbuff.h:26,
                 from /tmp/compat-wireless-2009-09-19/include/net/compat-2.6.28.h:10,
                 from /tmp/compat-wireless-2009-09-19/include/net/compat.h:19,
                 from &lt;command-line&gt;:0:
/usr/src/linux-2.6.27.29-0.1/include/linux/tracepoint.h:86:1: warning: this is the location of the previous definition
/tmp/compat-wireless-2009-09-19/include/net/compat-2.6.28.h:186: error: redefinition of ‘tracepoint_update_probe_range’

What looks a little odd to me is the reference to “compat-2.6.28.h” on a system running a 2.6.27.

OK, fixing those errors was easy, still I am not sure if my “solution” (just to make things clear, I am far from being a programmer and even further from being a kernel hacker, I’m just doing the dull packaging stuff) is appropriate.

As those errors are all related to redefinitions, I commented them in the sources:

 diff -u include/net/compat-2.6.28.h.orig include/net/compat
-2.6.28.h
--- include/net/compat-2.6.28.h.orig    2009-10-01 22:07:45.445106424 +0200
+++ include/net/compat-2.6.28.h 2009-10-01 22:09:16.445087637 +0200
@@ -149,12 +149,12 @@
 struct module;
 struct tracepoint;
 
-struct tracepoint {
-       const char *name;               /* Tracepoint name */
-       int state;                      /* State. */
-       void **funcs;
-} __attribute__((aligned(32)));                /*
-                                        * Aligned on 32 bytes because it is
+//struct tracepoint {
+//     const char *name;               /* Tracepoint name */
+//     int state;                      /* State. */
+//     void **funcs;
+//} __attribute__((aligned(32)));              /*
+/*                                      * Aligned on 32 bytes because it is
                                         * globally visible and gcc happily
                                         * align these on the structure size.
                                         * Keep in sync with vmlinux.lds.h.
@@ -179,13 +179,13 @@
                return -ENOSYS;                                         \
        }
 
-#define DEFINE_TRACE(name)
+//#define DEFINE_TRACE(name)
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)
 
-static inline void tracepoint_update_probe_range(struct tracepoint *begin,
+/*static inline void tracepoint_update_probe_range(struct tracepoint *begin,
        struct tracepoint *end)
-{ }
+{ }*/
 
 #endif

and the build went on rather smoothly (a few warnings but they looked harmless to me “defined but not used” and “unused variable” should not be a problem)

If this solution is appropriate, I can have a look into building an RPM from that.

On 10/01/2009 03:26 PM, Akoellh wrote:
>
> OK, fixing those errors was easy, still I am not sure if my “solution”
> (just to make things clear, I am far from being a programmer and even
> further from being a kernel hacker, I’m just doing the dull packaging
> stuff) is appropriate.
>
> As those errors are all related to redefinitions, I commented them in
> the sources:
>
>
> Code:
> --------------------
> diff -u include/net/compat-2.6.28.h.orig include/net/compat
> -2.6.28.h
> — include/net/compat-2.6.28.h.orig 2009-10-01 22:07:45.445106424 +0200
> +++ include/net/compat-2.6.28.h 2009-10-01 22:09:16.445087637 +0200
> @@ -149,12 +149,12 @@
> struct module;
> struct tracepoint;
>
> -struct tracepoint {
> - const char name; / Tracepoint name /
> - int state; /
State. */
> - void *funcs;
> -} attribute((aligned(32))); /

> - * Aligned on 32 bytes because it is
> +//struct tracepoint {
> +// const char name; / Tracepoint name /
> +// int state; /
State. */
> +// void funcs;
> +//} attribute((aligned(32))); /

> +/
* Aligned on 32 bytes because it is
> * globally visible and gcc happily
> * align these on the structure size.
> * Keep in sync with vmlinux.lds.h.
> @@ -179,13 +179,13 @@
> return -ENOSYS;
> }
>
> -#define DEFINE_TRACE(name)
> +//#define DEFINE_TRACE(name)
> #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
> #define EXPORT_TRACEPOINT_SYMBOL(name)
>
> -static inline void tracepoint_update_probe_range(struct tracepoint *begin,
> +/*static inline void tracepoint_update_probe_range(struct tracepoint *begin,
> struct tracepoint end)
> -{ }
> +{ }
/
>
> #endif
> --------------------
> and the build went on rather smoothly (a few warnings but they looked
> harmless to me “defined but not used” and “unused variable” should not
> be a problem)
>
> If this solution is appropriate, I can have a look into building an RPM
> from that.

I’ll look at it now.

Some more “live debugging” wanted?

:slight_smile:

Got another glitch, loading the modules fails as cfg80211 can not be loaded (“invalid module format”.

dmesg told me

 cfg80211: exports duplicate symbol round_jiffies_up (owned by kernel)

so my next “radical” fix was to deny exporting that symbol:

diff -u net/wireless/compat-2.6.28.c.orig net/wireless/compat-2.6.28.c
--- net/wireless/compat-2.6.28.c.orig   2009-10-01 22:32:44.670334510 +0200
+++ net/wireless/compat-2.6.28.c        2009-10-01 22:33:18.741733460 +0200
@@ -273,6 +273,6 @@
 {
        return round_jiffies_common(j, raw_smp_processor_id(), true);
 }
-EXPORT_SYMBOL_GPL(round_jiffies_up);
+//EXPORT_SYMBOL_GPL(round_jiffies_up);
 
 #endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) */

After that I was able to install and load the modules, in fact I am writing this post with those new drivers loaded.

Akoellh wrote:

> After that I was able to install and load the modules, in fact I am
> writing this post with those new drivers loaded.

It is working here too, including the Broadcom 4315.

The set of patches that implement the needed changes are as follows:

==================================================================

When building the bleeding-edge compat-wireless for kernel 2.6.27,
several compilation errors were detected.

Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>

Luis,

I checked these patches on 2.6.27 and 2.6.31, but not for the intermediate
releases.

Larry

Index: compat-wireless-2009-09-05/include/net/compat-2.6.28.h

— compat-wireless-2009-09-05.orig/include/net/compat-2.6.28.h
+++ compat-wireless-2009-09-05/include/net/compat-2.6.28.h
@@ -149,6 +149,7 @@ static inline void skb_queue_splice_tail
struct module;
struct tracepoint;

+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
struct tracepoint {
const char name; / Tracepoint name /
int state; /
State. */
@@ -159,6 +160,7 @@ struct tracepoint {

  • align these on the structure size.
  • Keep in sync with vmlinux.lds.h.
    */
    +#endif

#ifndef DECLARE_TRACE

@@ -179,13 +181,17 @@ struct tracepoint {
return -ENOSYS;
}

+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
#define DEFINE_TRACE(name)
+#endif
#define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
#define EXPORT_TRACEPOINT_SYMBOL(name)

+#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,28))
static inline void tracepoint_update_probe_range(struct tracepoint
*begin,
struct tracepoint *end)
{ }
+#endif

#endif

Index: compat-wireless-2009-09-05/net/wireless/compat-2.6.28.c

— compat-wireless-2009-09-05.orig/net/wireless/compat-2.6.28.c
+++ compat-wireless-2009-09-05/net/wireless/compat-2.6.28.c
@@ -260,6 +260,7 @@ static unsigned long round_jiffies_commo
return j;
}

+#if 0
/**

  • round_jiffies_up - function to round jiffies up to a full second
  • @j: the time in (absolute) jiffies that should be rounded
    @@ -274,5 +275,6 @@ unsigned long round_jiffies_up(unsigned
    return round_jiffies_common(j, raw_smp_processor_id(), true);
    }
    EXPORT_SYMBOL_GPL(round_jiffies_up);
    +#endif

#endif /* LINUX_VERSION_CODE < KERNEL_VERSION(2,6,28) */
Index: compat-wireless-2009-09-05/net/wireless/scan.c

— compat-wireless-2009-09-05.orig/net/wireless/scan.c
+++ compat-wireless-2009-09-05/net/wireless/scan.c
@@ -499,8 +499,10 @@ cfg80211_inform_bss(struct wiphy *wiphy,

kref_init(&res->ref);

+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
/* cfg80211_bss_update() eats up res - we ensure we free it there */
kmemleak_ignore(res);
+#endif

res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
if (!res)

These patches have been sent to the maintainer of compat-wireless.

Larry

OK, you persuaded me to start working on RPM packages for that.

I will apply your patches instead of my radical commenting “solution”.

BTW:

I have a IPW 5300AGN here, the driver works but not very well, at least with the ifup method (didn’t try NWM yet), it seems that wpa_supplicant does not start automatically, I need to invoke it manually (wpa_supplicant -iwlan …) and also the output if iwconfig looks really strange, some lines are missing (Power management, Link quality, Rx/Tx), but I suspect this to be a iwlwifi specific behavior as I am pretty sure you would have noticed that too, if it would appear with b43 also.

Give me a few hours and the packages will be up, I consider in creating a new project for that, maybe home:Akoellh:/compat-wireless_bleeding_edge or how about home:Akoellh:/compat-wireless_bleeding_nose?

:slight_smile:

OK, here we go:

Index of /repositories/home:/Akoellh:/compat-wireless_bleeding-edge

BTW:

--- compat-wireless-2009-09-05.orig/net/wireless/scan.c
+++ compat-wireless-2009-09-05/net/wireless/scan.c
@@ -499,8 +499,10 @@ cfg80211_inform_bss(struct wiphy *wiphy,

kref_init(&res->ref);

+#if (LINUX_VERSION_CODE > KERNEL_VERSION(2,6,30))
/* cfg80211_bss_update() eats up res - we ensure we free it there */
kmemleak_ignore(res);
+#endif

res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
if (!res)

This patch can not be applied to the latest snapshot, the code has changed in that part of scan.c:

        res->pub.len_information_elements = ielen;

        kref_init(&res->ref);

        res = cfg80211_bss_update(wiphy_to_dev(wiphy), res, 0);
        if (!res)
                return NULL;

        if (res->pub.capability & WLAN_CAPABILITY_ESS)
                regulatory_hint_found_beacon(wiphy, channel, gfp);

        /* cfg80211_bss_update gives us a referenced result */
        return &res->pub;

Akoellh wrote:
> OK, you persuaded me to start working on RPM packages for that.
>
> I will apply your patches instead of my radical commenting “solution”.
>
> BTW:
>
> I have a IPW 5300AGN here, the driver works but not very well, at least
> with the ifup method (didn’t try NWM yet), it seems that wpa_supplicant
> does not start automatically, I need to invoke it manually
> (wpa_supplicant -iwlan …) and also the output if iwconfig looks
> really strange, some lines are missing (Power management, Link quality,
> Rx/Tx), but I suspect this to be a iwlwifi specific behavior as I am
> pretty sure you would have noticed that too, if it would appear with b43
> also.

With b43, I get the following:

wlan0 IEEE 802.11bg ESSID:“lwfdjf_rad”
Mode:Managed Frequency:2.412 GHz Access Point:
00:14:BF:85:49:FA
Bit Rate=1 Mb/s Tx-Power=27 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Power Management:off
Link Quality=70/70 Signal level=-3 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0

There are some changes that are now being done that remove wext
(wireless extensions) in favor of iw. Perhaps the 5300 driver has been
converted more than b43.

If you use NM, then wpa_supplicant should be started automatically as
NM communicates with it through D Bus.

> Give me a few hours and the packages will be up, I consider in creating
> a new project for that, maybe
> home:Akoellh:/compat-wireless_bleeding_edge or how about
> home:Akoellh:/compat-wireless_bleeding_nose?

I like the latter. :wink:

Although access to the b-e (b-n) compat-wireless is not so important
for most wireless users in 11.2, the Broadcom 4315 users will still
need it. I would greatly appreciate having the package available
shortly after 11.2 is released. I’d do it myself, but I know nothing
of generating RPM’s, and too lazy/busy (take your pick) to learn.

Thanks, Larry

Hm,

the funny thing is, I get a “normal” output after being connected to the AP, if not connected, I get only the first few lines:


wlan0     IEEE 802.11abgn  ESSID:off/any  
          Mode:Managed  Access Point: Not-Associated   Tx-Power=14 dBm   
          Retry  long limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:off

Also interesting, directly after being associated to the AP the rate shown is only 1 Mb/s and will stay like that.

But after a few packages being sent/received (i.e. refreshing a site in my browser) the rate shown by iwconfig increases steadily (going up to 2Mb/s, 5.5 Mb/s …) until it reaches 54 Mb/s which is the maximum of my AP, while with the drivers from 2.6.30 I get the 54 Mb/s immediately.

Yes, that works fine, with NM wpa_supplicant appears directly after loading the module iwlagn, with ifup nothing happens although the STARTMODE is set to “ifplugd”.

With the older drivers (compat-wireless_STABLE from 2.6.30) wpa_supplicant appears also directly after loading the module (presumably due to the “ifplugd” setting).

I then tried with STARTMODE=‘auto’, but again no wpa_supplicant is started after activating the card with “ifup wlan0”.

Some of the packages are already up, only Factory will take a little longer.

Akoellh wrote:
> the funny thing is, I get a “normal” output after being connected to
> the AP, if not connected, I get only the first few lines:
>
>
> Code:
> --------------------
>
> wlan0 IEEE 802.11abgn ESSID:off/any
> Mode:Managed Access Point: Not-Associated Tx-Power=14 dBm
> Retry long limit:7 RTS thr:off Fragment thr:off
> Encryption key:off
> Power Management:off

That is to be expected. Until you are associated, many of the
parameters are not yet defined/available.

> Also interesting, directly after being associated to the AP the rate
> shown is only 1 Mb/s and will stay like that.
>
> But after a few packages being sent/received (i.e. refreshing a site in
> my browser) the rate shown by iwconfig increases steadily (going up to
> 2Mb/s, 5.5 Mb/s …) until it reaches 54 Mb/s which is the maximum of
> my AP, while with the drivers from 2.6.30 I get the 54 Mb/s
> immediately.

That is the behavior of the rate-setting mechanism. It always connects
at 1 Mb/s, which gives the best chance of success. It will then try a
higher rate and look at the success/fail probabilities. I didn’t think
there was a change in the algorithm between 2.6.30 and 2.6.32-rc1.
What does ‘dmesg | grep rate’ show with 2.6.30?

> With the older drivers (compat-wireless_STABLE from 2.6.30)
> wpa_supplicant appears also directly after loading the module
> (presumably due to the “ifplugd” setting).
>
> I then tried with STARTMODE=‘auto’, but again no wpa_supplicant is
> started after activating the card with “ifup wlan0”.

The wireless mailing list has had some traffic concerning
wpa_supplicant issues using the wext interface. I have not followed
them, but I suspect that is the source of the problem. It should be
resolved soon.

> Some of the packages are already up, only Factory will take a little
> longer.

Thanks.

OK, that explains this behavior.

dmesg |grep rate -i
phy0: Selected rate control algorithm 'iwl-agn-rs'

Note, that this is not a “pure” 2.6.30.X, but I except the relevant code is from 2.6.30.X (via compat-wireless).

Well, I follow the wireless mailinglist on a very unregular basis and I think I read something about that, too.

Nevertheless, this does also occur when using “nl80211” instead of “wext”, my system is 11.1 but most of the wireless stuff is “tuned” a little (mostly from my own repos), so I have wpa_supplicant >= 0.6.9 (I do some experiments with latest GIT stuff of wpa_supplicant,too.
If you want to version it, it would be “0.7.0pre”) so I can use and switch between different driver extensions in wpa_supplicant also for testing purposes.

The main reason for that is (or was, at this feature will be available in 11.2) this here:

https://bugzilla.novell.com/show_bug.cgi?id=477833

Short update on the “bleeding edge” packages:

The latest version (from 2009-04-10) now contains your patches and builds fine against 11.1, with 11.2 there is a little glitch, which was rather easy to resolve.

Again, I did it in the “brutal way”, because I have not tested yet, if it is related to the (chrooted) build process when using OBS.

When building against factory (with 2.6.31) one file (compat-2.6.32.c) is not compiled which is needed and mac80211 can not be loaded due to missing symbols.

From config.mk


ifneq ($(wildcard $(KLIB_BUILD)/Makefile),)
COMPAT_LATEST_VERSION = 32
KERNEL_SUBLEVEL := $(shell $(MAKE) -C $(KLIB_BUILD) kernelversion | sed -n 's/^2\.6\.\([0-9]\+\).*/\1/p'
)
COMPAT_VERSIONS := $(shell I=$(COMPAT_LATEST_VERSION); while  "$$I" -gt $(KERNEL_SUBLEVEL) ]; do echo $
$I; I=$$(($$I - 1)); done)
$(foreach ver,$(COMPAT_VERSIONS),$(eval CONFIG_COMPAT_WIRELESS_$(ver)=y))

and net/wireless/Makefile


ccflags-y += -D__CHECK_ENDIAN__
# Compat-wireless kernel compatibility code
cfg80211-$(CONFIG_COMPAT_WIRELESS_22) += compat-2.6.22.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_23) += compat-2.6.23.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_24) += compat-2.6.24.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_25) += compat-2.6.25.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_26) += compat-2.6.26.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_27) += compat-2.6.27.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_28) += compat-2.6.28.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_29) += compat-2.6.29.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_30) += compat-2.6.30.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_31) += compat-2.6.31.o
cfg80211-$(CONFIG_COMPAT_WIRELESS_32) += compat-2.6.32.o

I understand, that only those objects for each newer kernelversion than the running one will be compiled (at least that would make sense to me) and on openSUSE 11.1 with 2.6.27.X you see how all of them are built from compat-2.6.28.o up to compat-2.6.32.o.

However on 11.2/Factory with 2.6.31 the compat-2.6.32.o is not built and consequently you get missing symbols.

My sledgehammer fix for the RPMs was

--- net/wireless/Makefile.orig  2009-10-03 18:30:30.000000000 +0200
+++ net/wireless/Makefile       2009-10-03 18:30:50.000000000 +0200
@@ -21,5 +21,5 @@
 cfg80211-$(CONFIG_COMPAT_WIRELESS_29) += compat-2.6.29.o
 cfg80211-$(CONFIG_COMPAT_WIRELESS_30) += compat-2.6.30.o
 cfg80211-$(CONFIG_COMPAT_WIRELESS_31) += compat-2.6.31.o
-cfg80211-$(CONFIG_COMPAT_WIRELESS_32) += compat-2.6.32.o
+cfg80211-y += compat-2.6.32.o

to hardcode this combined with

%if 0%{?suse_version} > 1110
%patch0 -p0
%endif

this entry in the spec file (so the patch would only be applied for 11.2).

I still have to test, if this is also needed if you rebuild the src.rpm on a running 11.2 (then it is a OBS-specific problem) or when compiling the modules outside rpmbuild (then it will be an openSUSE/rpmbuild specific issue).

If this happens in any case, then it could be an issue of compat-wireless itself.