lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 12 Jul 2008 21:20:07 -0300
From:	Rogério Brito <rbrito@....usp.br>
To:	Ivo van Doorn <ivdoorn@...il.com>
Cc:	"John W. Linville" <linville@...driver.com>,
	linux-kernel@...r.kernel.org, rt2400-devel@...ts.sourceforge.net,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	rbrito@....usp.br
Subject: Re: [2.6.26-rc4] Problems with rt2x00 USB interface on powerpc
	(fwd)

Hi, Ivo, John, Linus and all the people at the mailing lists.

It seems that I'm flooded with bad luck. :-( I tried the modifications
in the script attached (progressively uncommenting the commands, as you
asked me), but it seems that I had the bad luck that nothing worked with
kernel 2.6.26-rc5. I also tried with kernel 2.6.26-rc9, but again,
nothing worked [*].

The only thing that gave a signal of life was when I imitated what you
did and set the led register to the value that was present on the
2.6.25.x kernel. Then, a "iwconfig wlan0 ap any" gave me blinks on the
"Act" led each time that I issued the command.

Attached also is the "meat" of the dmesg of my system. You may notice
that after some time, I tried simply "ifdown wlan0" and "ifup wlan0" in
my Debian system. These commands are responsible, as you should guess,
for bringing an interface down and up.

I have not checked closely, but it seems that the modifications to the
registers are lost when you bring the interface down---is that right?
>From the dmesg logs, this seems to be the case.

On Jul 08 2008, Ivo van Doorn wrote:
> Hi,
> 
> Could you try some of the following tests to control the registers:
> I have grouped each test together, please don't do them all in one single shot,
> since that will not help narrowing down the exact register which
> breaks everything.

Again, I didn't do everything in one single shot. I tested your
directions one at a time (first the 1st one, then, the 1st set and the
2nd set, then the 1st, 2nd, and 3rd set etc).

> > > 11 :0x0005                                                    | 11 :0x000a	MAC_CSR11: SIFS.
> > > 12 :0x016c                                                    | 12 :0x013a	MAC_CSR12: EIFS.
> 
> echo 11 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_offset
> echo 5 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_value
> echo 12 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_offset
> echo 364 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_value
> 
> ---
> 
> > > 33 :0xb11a                                                    | 33 :0xb162	TXRX_CSR1: TX configuration.
> 
> echo 33 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_offset
> echo 45338 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_value
> 
> ---
> 
> > > 42 :0x000e                                                    | 42 :0x000a	TXRX_CSR10: Auto responder control.
> > > 43 :0x015f                                                    | 43 :0x0000	TXRX_CSR11: Auto responder basic rate.
> 
> echo 42 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_offset
> echo 14 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_value
> echo 43 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_offset
> echo 351 > /<debugfsroot>/<mac80211>/rt2500usb/register/csr_value
> 
> ---
> 
> > > 2 :0x1e                                                       | 2 :0x06	R2: TX antenna control
> 
> echo 2 > /<debugfsroot>/<mac80211>/rt2500usb/register/bbp_offset
> echo 30 > /<debugfsroot>/<mac80211>/rt2500usb/register/bbp_value

I attach to this message the commands that I used. As you can see, I
tried some which seemed to me (as a layman) that would make some
difference, but they did nothing. :-( My commands were based on some of
the differences that you narrowed down in the last message.


Thank you very much, Rogério Brito.

[*] Actually, I got it once to work/authenticate with kernel 2.6.26-rc9,
but I couldn't reproduce the steps to that. I tried loading all the
registers this time with the script that I attach here, and I was so sad
that it didn't work a second time (and a third, etc) that I was running
a script that did:

"ifconfig wlan0 up; iwconfig wlan0 key s:xxx; iwconfig wlan0 essid
default" && iwconfig wlan0

Not even once it showed that it was associated with the ap, but once in
a while (not every time) that I run the line above the "act" led blinked
and the messages generated on the dmesg were slightly different from one
time to another (compressed, the log is quite small).
-- 
Rogério Brito : rbrito@...ckenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

View attachment "rtusb2500-try04.txt" of type "text/plain" (1274 bytes)

View attachment "dmesg-with-2.6.25.txt" of type "text/plain" (1626 bytes)

Download attachment "dmesg-2.6.26-rc9.txt.gz" of type "application/octet-stream" (1037 bytes)

Powered by blists - more mailing lists