grsecurity forums

On an old laptop with an ipw2100 wireless adapter and grsec 3.14.24, rfkill shows

Code: Select all

0: phy0: Wireless LAN
   Soft blocked: no
   Hard blocked: yes


In the output from dmesg I see "eth%d: Radio is disabled by RF switch."

This device works with a vanilla kernel (3.16 as packaged by Debian). I do not have a working switch for the wireless adapter. There is a button but pressing it doesn't change the adapter's status.

According to lspci, the device in question is "02:06.0 Network controller: Intel Corporation PRO/Wireless LAN 2100 3B Mini PCI Adapter (rev 04)"

Any suggestions to get this working?

does a vanilla 3.14.x kernel work? if it does, can you post dmesg from both kernels?

Thanks for your attention. What I tried:

1. Removed the grsecurity patch (patch -R), then "make oldconfig". Installed the kernel and rebooted. rfkill was still 'hard blocked', therefore proving it's not grsecurity doing it. (I have no good reason for why I didn't I try this before.)
2. Installed debian's 3.14.x kernel from snapshots.debian.net. This worked.
3. Copied the config file from the working debian supplied 3.14 kernel to my grsecurity workspace, but I didn't apply the grsecurity patch. This worked too. A diff against the two config files didn't reveal anything obvious to me but I'll work on determining which configuration option disabled the wireless adapter with rfkill in the stock, vanilla kernel.
4. Applied the grsecurity patch. Re-enabled grsecurity. The kernel panicked with something like "grsec: halting the system due to suspicious kernel crash caused by root". I need to figure out how to get that text dumped to a log or the like so I don't have to resort to taking a picture of the screen.

My original problem hasn't a thing to do with grsecurity, but it did lead to grsecurity potentially finding a problem in the upstream kernel itself.

I can start another thread for the "grsec: halting the system" crash to make it easier to track.

I'll update this thread once I determine the cause of my original problem so people that come to this post (somehow) might learn how they can fix it.

for the kernel crash:

1. if it happens early enough and is not hw specific, you may be able to reproduce it in qemu, logging to a (virtual) serial consol is trivial then
2. try netconsole if you have another machine hanging around
3. if your machine has intel AMT, it provides serial-on-lan which should work too (still needs another machine)
4. screenshot can be useful too just make sure you have frame pointers and kallsyms enabled and use some high resolution frame buffer mode

shored wrote:
[...snipped...]

I'll update this thread once I determine the cause of my original problem so people that come to this post (somehow) might learn how they can fix it.

This was solved by enabling INPUT_WISTRON_BTNS under

Code: Select all

   Location:
     -> Device Drivers
       -> Input device support
         -> Generic input layer (needed for keyboard, mouse, ...) (INPUT [=y])
 (1)       -> Miscellaneous devices (INPUT_MISC [=y])

I n00bishly was not aware of this option.