So I'm trying to get my thinkpad to work with this pcmcia card.

I installed suse 9.1 -- it recognized the card during installation--
and I unpacked the utilities so I could use LEAP authentication.

Everything worked, though I had to be root to run leap authentication.
And when I switched to the root id in an xterm, I was unable to start
and x-windows programs-- the x-server would refuse the connection.

This was a minor annoyance untill I needed to log into a remote computer
from my laptop and could't run any x-programs on the remote machine.

I played around with the x-server settings, then gave up and tried mandrake 10.1.

Well, my wireless card wasn't recognized and I couldn't get the airo_cs driver to get loaded by the 2.6 kernel.

So I switched back to suse 9.1, only now my wireless card refuses to authenticate. User ID/password still work in windows.

Can anyone tell me what I've done wrong here?

ifconfig shows eth0, lo, and wifi0 network interfaces are configured, but for every tc packet, there's an error.

ok so this is wierd:

I was able to authenticate by running acu from the user mode
using kdesu, and then running leapscript from a user window.

but when I try to login using leap as root -- which is the only way I could get it to work before, I get a login failed message.

so before, I could only use the utilities as root, but now, I can only get them to work as a user.

?

the problem with root not being able to open an x-window and not being able to run x-wondows programs on a remote computer persists, though.

Anyone?

Could be a combination of things... You will likely need to do a "xhost +localhost" to allow root to open an xwindow. However, I'm not sure about not being able to run xwindows from a remote computer.. that may be a different problem.

I had a similar problem with SuSE 9.1 as well but it was opening a xwindow from a remote server via ssh on the local display. This worked initially for me but then stopped working. It turns out one of the SuSE security patches changed the /etc/ssh/ssh_config file. Try changing "ForwardX11 no" to "ForwardX11 yes" then restarting the sshd.

that worked!

now back to my wireless card, the last time I rebooted
(remember I'm on a notebook so I do that often)
I again had to run the acu utilities as root to get my
wireless card to associate.

Did I set something up wrong?

Is some setting or group permission changing on me?

Why this strange behavior?

The new linux 2.6 kernel is, I'll admit, something of a mystery to me.
What governs what hardware a user can directly control?

I'm not sure that I understand the question...

Is the question why do you need to be root in order to start acu so that you can associate to the Access Point? This is typical. I'm not sure I can provide a definitive answer for why that is ... my guess would be that configuration files in the /etc dir may be modified or updated with access point information ((ie) ethX.cfg). Regular users do not have write permission to the /etc filesystem thus you need to be root.

If I recall correctly you could add "bcard" to the initialization scripts and perform the association (and leap login ?) automagically at boot. Then you don't need to use root at all. But don't quote me on that since it has been a while ...

I have not had any luck with acu and SuSE 9.1 2.6 series kernel myself. Each time I try to start acu I get an error message that the radio is not found even though the card is functional. The truth is I have no idea what the problem is with my machine.

If your only problem is being root to associate then consider yourself lucky :-)

if you get the message no radio found-- try running the acu utility as a different
user. Sometimes I need to be root to access it, and sometimes I need to be a user.

perhaps the bcard script modifies the owner of some file?

the last time I booted my laptop, I got the utilities running in kde by running
"kdesu /opt/cisco/bin/acu" but suthenticating with leapscript gave me
"login incorrect" even as root.

There is something funny that's going on. I don't think the kernel is at fault, since
the card gets turned on reliably when I boot. But I seem to have some kind of funny
ping pong effect where every time I log on I can authenticate, but I have to do it in
a different way.