Re: [PATCH RFC] cfg80211: add new command for reporting wiphy crashes

[Jouni Malinen]

On Fri, Sep 20, 2019 at 03:37:08PM +0200, Rafał Miłecki wrote:
> Hardware or firmware instability may result in unusable wiphy. In such
> cases usually a hardware reset is needed. To allow a full recovery
> kernel has to indicate problem to the user space.

Why? Shouldn't the driver be able to handle this on its own since all
the previous configuration was done through the driver anyway. As far as
I know, there are drivers that do indeed try to do this and handle it
successfully at least for station mode. AP mode may be more complex, but
for that one, I guess it would be fine to drop all associations (and
provide indication of that to user space) and just restart the BSS.

> This new nl80211 command lets user space known wiphy has crashed and has
> been just recovered. When applicable it should result in supplicant or
> authenticator reconfiguring all interfaces.

For me, that is not really "recovered" if some additional
reconfiguration steps are needed.. I'd like to get a more detailed view
on what exactly might need to be reconfigured and how would user space
know what exactly to do. Or would the plan here be that the driver would
not even indicate this crash if it is actually able to internally
recover fully from the firmware restart?

> I'd like to use this new cfg80211_crash_report() in brcmfmac after a
> successful recovery from a FullMAC firmware crash.
> 
> Later on I'd like to modify hostapd to reconfigure wiphy using a
> previously used setup.

So this implies that at least something would need to happen in AP mode.
Do you have a list of items that the driver cannot do on its own and why
it would be better to do them from user space?

> I'm OpenWrt developer & user and I got annoyed by my devices not auto
> recovering after various failures. There are things I cannot fix (hw
> failures or closed fw crashes) but I still expect my devices to get
> back to operational state as soon as possible on their own.

I fully agree with the auto recovery being important thing to cover for
this, but I'm not yet convinced that this needs user space action. Or if
it does, there would need to be more detailed way of indicating what
exactly is needed for user space to do. The proposed change here is just
saying "hey, I crashed and did something to get the hardware/firmware
responding again" which does not really tell much to user space other
than potentially requiring full disable + re-enable for the related
interfaces. And that is something that should not actually be done in
all cases of firmware crashes since there are drivers that handle
recovery in a manner that is in practice completely transparent to user
space.

-- 
Jouni MalinenPGP id EFC895FA

Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Tue, Aug 16, 2016 at 11:46:00AM +0200, Richard Cochran wrote:
> If I understand the test correctly, then the slightly different kernel
> timer behavior is ok, but the test isn't quite right.  Let explain
> what I mean.
> 
> First off, reading test_ap_wps.py, the point of the test is to see if
> ten simultaneous connections are possible.  I guess the server
> implements a hard coded limit on the number of clients.  (BTW where is
> the server loop?)

Yes, I think I wrote that test case to hit a specific code path in the
server side. The server implementation is here:
http://w1.fi/cgit/hostap/plain/src/wps/http_server.c

> You said that the server also sets 'backlog' to ten.  The backlog
> controls the size of the queue holding incoming connections that are
> in the SYN_RCVD or ESTABLISHED state but have not yet been
> accept(2)-ed by the server.  This is *not* the same as the number of
> possible simultaneous connections.

This is indeed what seems to be the key area that had a small change in
timing. After some more experimentation on various timing, it is
starting to look like the TCP initiator side retransmission timing is
now different after this kernel commit and that is hit for the case
where the server process does not have enough time to accept() the
incoming connections and listen() backlog ends up dropping it instead.

> On Sat, Aug 13, 2016 at 12:12:26PM +0300, Jouni Malinen wrote:
> > Yes, it looks like a TCP connect() timeout. I use a significantly
> > reduced timeout in the test scripts since they are run unattended and
> > are supposed to terminate in reasonable amount of time.. That said,
> 
> I did not find where the client sets the one second timeout.  Where
> does this happen?

There is a socket.setdefaulttimeout(1) call in wps_er_start().

> > If I increase that 20 to 50, I get more of such about 1.03 second
> > results at i=17, i=34, i=48..
> 
> Can you provide the timings when the test runs on the older kernel?

I had not realized this previously due to the test case passing, but the
same retransmit SYN case was happening with older kernels, it just was
done a tiny bit faster to escape that 1.0 second timeout limit.. That
about 1.03 sec value after this kernel commit is 1.0 sec before this
kernel commit. In other words, something in this specific kernel commit
seems to add about 0.03 sec delay to the TCP SYN retransmission. That
said, I realize that this is quite unlikely timeout to use for connect()
in real world and as such, it looks simply as a side effect of a test
case that was using way too close timing requirement in the first place.

> > Looking more at what exactly is happening at the TCP layer, this is
> > likely related to the server behavior since listen() backlog is set to
> > 10 and if there are 10 parallel connections, the last one if
> > immediately closed before reading anything.
> 
> To clarify, when the backlog is exceed, the new connection is not
> closed.  Instead, the SYN is simply ignored, and the client is expect
> to re-transmit the SYN in the normal TCP fashion.

That closing was referring to what the server code in http_server.c
does, i.e., it does call close() after accept()ing the 10th parallel
connection. I had not realized that this was actually hitting the
listen() backlog in this specific case around the 15th socket, but yes,
that does indeed explain the behavior shown in the sniffer capture.

I was also able to confirm that if I add a short wait in the test loop
between each connect() call, things work fine with this kernel commit
included, i.e., the "issue" was triggered only when this listen()
backlog case was hit.

> Here is what I suspect is happening.  By sending 20 SYN frames to a
> port with a backlog of 10, it saturates the queue.  One SYN is ignored
> by the kernel, and a race begins between the connect() timeout and the
> SYN re-transmission.  If the client's re-transmitted SYN and then the
> server's SYN,ACK returns before the connect timeout, then the call to
> connect() succeeds.  With the new timer wheel, the result of the race
> is different.

Yes, that does indeed look exactly what is happening.

> There a couple of ways to deal with this.  One is to increase the
> backlog on the server side.  Another is to increase the connect()
> timeout to a multiple of the re-transmission interval.

Taken into account this is a test case for testing a specific code path
in http_server.c that is very unlikely to be hit in real world and a way
too short timeout for connect(), it is clear to me that the proper fix
here is to fix the test case to use a longer connect() timeout
especially now that I saw the 1.0 sec time with older kernel as well.

-- 
Jouni MalinenPGP id EFC895FA

Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Tue, Aug 16, 2016 at 11:46:00AM +0200, Richard Cochran wrote:
> If I understand the test correctly, then the slightly different kernel
> timer behavior is ok, but the test isn't quite right.  Let explain
> what I mean.
> 
> First off, reading test_ap_wps.py, the point of the test is to see if
> ten simultaneous connections are possible.  I guess the server
> implements a hard coded limit on the number of clients.  (BTW where is
> the server loop?)

Yes, I think I wrote that test case to hit a specific code path in the
server side. The server implementation is here:
http://w1.fi/cgit/hostap/plain/src/wps/http_server.c

> You said that the server also sets 'backlog' to ten.  The backlog
> controls the size of the queue holding incoming connections that are
> in the SYN_RCVD or ESTABLISHED state but have not yet been
> accept(2)-ed by the server.  This is *not* the same as the number of
> possible simultaneous connections.

This is indeed what seems to be the key area that had a small change in
timing. After some more experimentation on various timing, it is
starting to look like the TCP initiator side retransmission timing is
now different after this kernel commit and that is hit for the case
where the server process does not have enough time to accept() the
incoming connections and listen() backlog ends up dropping it instead.

> On Sat, Aug 13, 2016 at 12:12:26PM +0300, Jouni Malinen wrote:
> > Yes, it looks like a TCP connect() timeout. I use a significantly
> > reduced timeout in the test scripts since they are run unattended and
> > are supposed to terminate in reasonable amount of time.. That said,
> 
> I did not find where the client sets the one second timeout.  Where
> does this happen?

There is a socket.setdefaulttimeout(1) call in wps_er_start().

> > If I increase that 20 to 50, I get more of such about 1.03 second
> > results at i=17, i=34, i=48..
> 
> Can you provide the timings when the test runs on the older kernel?

I had not realized this previously due to the test case passing, but the
same retransmit SYN case was happening with older kernels, it just was
done a tiny bit faster to escape that 1.0 second timeout limit.. That
about 1.03 sec value after this kernel commit is 1.0 sec before this
kernel commit. In other words, something in this specific kernel commit
seems to add about 0.03 sec delay to the TCP SYN retransmission. That
said, I realize that this is quite unlikely timeout to use for connect()
in real world and as such, it looks simply as a side effect of a test
case that was using way too close timing requirement in the first place.

> > Looking more at what exactly is happening at the TCP layer, this is
> > likely related to the server behavior since listen() backlog is set to
> > 10 and if there are 10 parallel connections, the last one if
> > immediately closed before reading anything.
> 
> To clarify, when the backlog is exceed, the new connection is not
> closed.  Instead, the SYN is simply ignored, and the client is expect
> to re-transmit the SYN in the normal TCP fashion.

That closing was referring to what the server code in http_server.c
does, i.e., it does call close() after accept()ing the 10th parallel
connection. I had not realized that this was actually hitting the
listen() backlog in this specific case around the 15th socket, but yes,
that does indeed explain the behavior shown in the sniffer capture.

I was also able to confirm that if I add a short wait in the test loop
between each connect() call, things work fine with this kernel commit
included, i.e., the "issue" was triggered only when this listen()
backlog case was hit.

> Here is what I suspect is happening.  By sending 20 SYN frames to a
> port with a backlog of 10, it saturates the queue.  One SYN is ignored
> by the kernel, and a race begins between the connect() timeout and the
> SYN re-transmission.  If the client's re-transmitted SYN and then the
> server's SYN,ACK returns before the connect timeout, then the call to
> connect() succeeds.  With the new timer wheel, the result of the race
> is different.

Yes, that does indeed look exactly what is happening.

> There a couple of ways to deal with this.  One is to increase the
> backlog on the server side.  Another is to increase the connect()
> timeout to a multiple of the re-transmission interval.

Taken into account this is a test case for testing a specific code path
in http_server.c that is very unlikely to be hit in real world and a way
too short timeout for connect(), it is clear to me that the proper fix
here is to fix the test case to use a longer connect() timeout
especially now that I saw the 1.0 sec time with older kernel as well.

-- 
Jouni MalinenPGP id EFC895FA

Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Thu, Aug 11, 2016 at 11:25 PM,  <rcoch...@linutronix.de> wrote:
> On Thu, Aug 11, 2016 at 06:21:26PM +0300, Jouni Malinen wrote:
>> The test code looked like this in python:
>>
>> addr = (url.hostname, url.port)
>> socks = {}
>> for i in range(20):
>> socks[i] = socket.socket(socket.AF_INET, socket.SOCK_STREAM,
>>  socket.IPPROTO_TCP)
>> socks[i].connect(addr)
>
> You getting a timeout on TCP connect()?  Isn't that timeout really
> long, like 75 seconds or something?

Yes, it looks like a TCP connect() timeout. I use a significantly
reduced timeout in the test scripts since they are run unattended and
are supposed to terminate in reasonable amount of time.. That said,
this specific test case should not really have used as short a timeout
as it did, i.e., just one second. Interestingly enough, increasing
that to just 1.1 seconds was enough to make the test case pass..
Looking at the time it takes to execute connect(), it is 1.02 - 1.08
seconds for the timing out (with timeout=1sec) case which is now at
i=14 while all the other 19 calls take 0.0 seconds..

If I increase that 20 to 50, I get more of such about 1.03 second
results at i=17, i=34, i=48..

Looking more at what exactly is happening at the TCP layer, this is
likely related to the server behavior since listen() backlog is set to
10 and if there are 10 parallel connections, the last one if
immediately closed before reading anything. Somehow this combination
with this kernel patch applied makes one of the connect() calls take
that surprisingly long 1.02 or so seconds.

Looking at a sniffer capture (*), the three-way TCP connection goes
through fine for the first 15 connect() calls, but the 15th one does
not get a response to SYN. This SYN is the frame 47 in the capture
file with srcport == 60802. There is no SYN,ACK for it. The about one
second unexpected time for connect() comes from this, i.e., the
connection is completed only after the client side does TCP
retransmission of the SYN (frame #77) a second later and the server
side replies with RST,ACK (frame #78).

  2   0.039135127.0.0.1 -> 127.0.0.1TCP 74 60772 > 49152 [SYN]
Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=4294937755 TSecr=0
WS=64
  3   0.039146127.0.0.1 -> 127.0.0.1TCP 74 49152 > 60772 [SYN,
ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1
TSval=4294937755 TSecr=4294937755 WS=64
  4   0.039156127.0.0.1 -> 127.0.0.1TCP 66 60772 > 49152 [ACK]
Seq=1 Ack=1 Win=43712 Len=0 TSval=4294937755 TSecr=4294937755
...
 47   0.042559127.0.0.1 -> 127.0.0.1TCP 74 60802 > 49152 [SYN]
Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=4294937756 TSecr=0
WS=64
 77   1.119943127.0.0.1 -> 127.0.0.1TCP 74 [TCP
Retransmission] 60802 > 49152 [SYN] Seq=0 Win=43690 Len=0 MSS=65495
SACK_PERM=1 TSval=4294937864 TSecr=0 WS=64
 78   1.119953127.0.0.1 -> 127.0.0.1TCP 54 49152 > 60802 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0

So it looks like the issue is in one of the SYN,ACK frames getting
completely lost..

(*) http://w1.fi/p/tcp-lo.pcap

> Can you provide a simple test case or explain in more detail how you
> run your test?  I would like to reproduce the issue it here.

I'm not sure how to make a simple test case for this taken into
account this seems to have some unknown timing dependencies.. A quick
loop of 20 TCP socket() + connect() calls with a server side that does
listen() with backlog 10 and non-blocking operations with 10th and
following incoming sockets getting close() immediately is what the
test case ends up doing, but whether a simple program doing that
without all of python and wpa_supplicant processing giving suitable
timing is unclear..

These files describe the test setup that I'm using to run this:
http://w1.fi/cgit/hostap/plain/tests/hwsim/README
http://w1.fi/cgit/hostap/plain/tests/hwsim/vm/README

with the actual test case being executed with
tests/hwsim/vm$ ./vm-run.sh ap_wps_er_http_proto

- Jouni

Re: [PREEMPT-RT] [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Thu, Aug 11, 2016 at 11:25 PM,   wrote:
> On Thu, Aug 11, 2016 at 06:21:26PM +0300, Jouni Malinen wrote:
>> The test code looked like this in python:
>>
>> addr = (url.hostname, url.port)
>> socks = {}
>> for i in range(20):
>> socks[i] = socket.socket(socket.AF_INET, socket.SOCK_STREAM,
>>  socket.IPPROTO_TCP)
>> socks[i].connect(addr)
>
> You getting a timeout on TCP connect()?  Isn't that timeout really
> long, like 75 seconds or something?

Yes, it looks like a TCP connect() timeout. I use a significantly
reduced timeout in the test scripts since they are run unattended and
are supposed to terminate in reasonable amount of time.. That said,
this specific test case should not really have used as short a timeout
as it did, i.e., just one second. Interestingly enough, increasing
that to just 1.1 seconds was enough to make the test case pass..
Looking at the time it takes to execute connect(), it is 1.02 - 1.08
seconds for the timing out (with timeout=1sec) case which is now at
i=14 while all the other 19 calls take 0.0 seconds..

If I increase that 20 to 50, I get more of such about 1.03 second
results at i=17, i=34, i=48..

Looking more at what exactly is happening at the TCP layer, this is
likely related to the server behavior since listen() backlog is set to
10 and if there are 10 parallel connections, the last one if
immediately closed before reading anything. Somehow this combination
with this kernel patch applied makes one of the connect() calls take
that surprisingly long 1.02 or so seconds.

Looking at a sniffer capture (*), the three-way TCP connection goes
through fine for the first 15 connect() calls, but the 15th one does
not get a response to SYN. This SYN is the frame 47 in the capture
file with srcport == 60802. There is no SYN,ACK for it. The about one
second unexpected time for connect() comes from this, i.e., the
connection is completed only after the client side does TCP
retransmission of the SYN (frame #77) a second later and the server
side replies with RST,ACK (frame #78).

  2   0.039135127.0.0.1 -> 127.0.0.1TCP 74 60772 > 49152 [SYN]
Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=4294937755 TSecr=0
WS=64
  3   0.039146127.0.0.1 -> 127.0.0.1TCP 74 49152 > 60772 [SYN,
ACK] Seq=0 Ack=1 Win=43690 Len=0 MSS=65495 SACK_PERM=1
TSval=4294937755 TSecr=4294937755 WS=64
  4   0.039156127.0.0.1 -> 127.0.0.1TCP 66 60772 > 49152 [ACK]
Seq=1 Ack=1 Win=43712 Len=0 TSval=4294937755 TSecr=4294937755
...
 47   0.042559127.0.0.1 -> 127.0.0.1TCP 74 60802 > 49152 [SYN]
Seq=0 Win=43690 Len=0 MSS=65495 SACK_PERM=1 TSval=4294937756 TSecr=0
WS=64
 77   1.119943127.0.0.1 -> 127.0.0.1TCP 74 [TCP
Retransmission] 60802 > 49152 [SYN] Seq=0 Win=43690 Len=0 MSS=65495
SACK_PERM=1 TSval=4294937864 TSecr=0 WS=64
 78   1.119953127.0.0.1 -> 127.0.0.1TCP 54 49152 > 60802 [RST,
ACK] Seq=1 Ack=1 Win=0 Len=0

So it looks like the issue is in one of the SYN,ACK frames getting
completely lost..

(*) http://w1.fi/p/tcp-lo.pcap

> Can you provide a simple test case or explain in more detail how you
> run your test?  I would like to reproduce the issue it here.

I'm not sure how to make a simple test case for this taken into
account this seems to have some unknown timing dependencies.. A quick
loop of 20 TCP socket() + connect() calls with a server side that does
listen() with backlog 10 and non-blocking operations with 10th and
following incoming sockets getting close() immediately is what the
test case ends up doing, but whether a simple program doing that
without all of python and wpa_supplicant processing giving suitable
timing is unclear..

These files describe the test setup that I'm using to run this:
http://w1.fi/cgit/hostap/plain/tests/hwsim/README
http://w1.fi/cgit/hostap/plain/tests/hwsim/vm/README

with the actual test case being executed with
tests/hwsim/vm$ ./vm-run.sh ap_wps_er_http_proto

- Jouni

Re: [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Mon, Jul 4, 2016 at 12:50 PM, Thomas Gleixner  wrote:
> The current timer wheel has some drawbacks:
...

It looks like this change (commit
500462a9de657f86edaa102f8ab6bff7f7e43fc2 in linux.git) breaks one of
the automated test cases I'm using to test hostapd and wpa_supplicant
with mac80211_hwsim from the kernel. I'm not sure what exactly causes
this (did not really expect git bisect to point to timers..), but this
seems to be very reproducible for me under kvm (though, this
apparently did not happen on another device, so I'm not completely
sure what it is needed to reproduce) with the ap_wps_er_http_proto
test cases failing to connect 20 TCP stream sockets to a server on the
localhost. The client side is a python test script and the server is
hostapd. The failure shows up with about the 13th of those socket
connects failing while all others (both before and after this failed
one) going through.

Would you happen to have any idea why this commit has such a
difference in behavior? I'm currently working around this in my test
script with the following change, but it might be worth while to
confirm whether there is something in the kernel change that resulted
in unexpected behavior.

http://w1.fi/cgit/hostap/commit/?id=2d6a526ac3885605f34df4037fc79ad330565b23

The test code looked like this in python:

addr = (url.hostname, url.port)
socks = {}
for i in range(20):
socks[i] = socket.socket(socket.AF_INET, socket.SOCK_STREAM,
 socket.IPPROTO_TCP)
socks[i].connect(addr)

With that connect() call being the failing (time out) operation and it
seemed to happen for i == 13 most of the time. This shows up only with
commit 500462a9de657f86edaa102f8ab6bff7f7e43fc2 included in the kernel
(i.e., test with commit b0d6e2dcb284f1f4dcb4b92760f49eeaf5fc0bc7 as
the kernel snapshot does not show this behavior). Changes in 500462a9
were not trivial to revert on top of the current master, so I have not
checked whether the current master branch would get rid of the failure
if only this one commit were reverted.

I can reproduce this easily, so if someone wants to get more details
of the issue, just let me know how to collect whatever would be
useful.

- Jouni

Re: [patch 4 14/22] timer: Switch to a non cascading wheel

[Jouni Malinen]

On Mon, Jul 4, 2016 at 12:50 PM, Thomas Gleixner  wrote:
> The current timer wheel has some drawbacks:
...

It looks like this change (commit
500462a9de657f86edaa102f8ab6bff7f7e43fc2 in linux.git) breaks one of
the automated test cases I'm using to test hostapd and wpa_supplicant
with mac80211_hwsim from the kernel. I'm not sure what exactly causes
this (did not really expect git bisect to point to timers..), but this
seems to be very reproducible for me under kvm (though, this
apparently did not happen on another device, so I'm not completely
sure what it is needed to reproduce) with the ap_wps_er_http_proto
test cases failing to connect 20 TCP stream sockets to a server on the
localhost. The client side is a python test script and the server is
hostapd. The failure shows up with about the 13th of those socket
connects failing while all others (both before and after this failed
one) going through.

Would you happen to have any idea why this commit has such a
difference in behavior? I'm currently working around this in my test
script with the following change, but it might be worth while to
confirm whether there is something in the kernel change that resulted
in unexpected behavior.

http://w1.fi/cgit/hostap/commit/?id=2d6a526ac3885605f34df4037fc79ad330565b23

The test code looked like this in python:

addr = (url.hostname, url.port)
socks = {}
for i in range(20):
socks[i] = socket.socket(socket.AF_INET, socket.SOCK_STREAM,
 socket.IPPROTO_TCP)
socks[i].connect(addr)

With that connect() call being the failing (time out) operation and it
seemed to happen for i == 13 most of the time. This shows up only with
commit 500462a9de657f86edaa102f8ab6bff7f7e43fc2 included in the kernel
(i.e., test with commit b0d6e2dcb284f1f4dcb4b92760f49eeaf5fc0bc7 as
the kernel snapshot does not show this behavior). Changes in 500462a9
were not trivial to revert on top of the current master, so I have not
checked whether the current master branch would get rid of the failure
if only this one commit were reverted.

I can reproduce this easily, so if someone wants to get more details
of the issue, just let me know how to collect whatever would be
useful.

- Jouni

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

[Jouni Malinen]

On Mon, Feb 29, 2016 at 05:30:20PM -0500, João Paulo Rechi Vita wrote:

> I agree there is a difference in the logic here, thanks for taking the
> time to point it out so clearly, and sorry for missing this. But AFAIU
> userspace should not call RFKILL_OP_CHANGE with ev.type ==
> RFKILL_TYPE_ALL, as RFKILL_OP_CHANGE is intended to be used to
> block/unblock one RFKill switch, and it is not possible to create a
> RFKill switch with type == RFKILL_TYPE_ALL (rfkill_alloc() would
> return NULL).

Interesting. Maybe Johannes can comment on that part since I think he
wrote the code that interacts with kernel for the rfkill test cases.

> I tried to look into the source code of the test suite you pointed,
> but couldn't easily figure out how it ends up with that combination.
> Could you please explain (or point me in the code) how is that a valid
> operation? If I'm not missing anything, we should probably return
> EINVAL in this case.

These specific failures were shown for the test cases in this file:
http://w1.fi/cgit/hostap/tree/tests/hwsim/test_rfkill.py

The interaction with kernel is done using this code:
http://w1.fi/cgit/hostap/tree/tests/hwsim/rfkill.py

It does indeed look like TYPE_ALL is used here (the block() and
unblock() implementations). If this is incorrect, we can certainly
change the script since I'd assume this is not used for anything else
than the hwsim test cases (or well who knows, it is available out there,
so if someone needs python code to do rfkill operations..).
 
-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

[Jouni Malinen]

On Mon, Feb 29, 2016 at 05:30:20PM -0500, João Paulo Rechi Vita wrote:

> I agree there is a difference in the logic here, thanks for taking the
> time to point it out so clearly, and sorry for missing this. But AFAIU
> userspace should not call RFKILL_OP_CHANGE with ev.type ==
> RFKILL_TYPE_ALL, as RFKILL_OP_CHANGE is intended to be used to
> block/unblock one RFKill switch, and it is not possible to create a
> RFKill switch with type == RFKILL_TYPE_ALL (rfkill_alloc() would
> return NULL).

Interesting. Maybe Johannes can comment on that part since I think he
wrote the code that interacts with kernel for the rfkill test cases.

> I tried to look into the source code of the test suite you pointed,
> but couldn't easily figure out how it ends up with that combination.
> Could you please explain (or point me in the code) how is that a valid
> operation? If I'm not missing anything, we should probably return
> EINVAL in this case.

These specific failures were shown for the test cases in this file:
http://w1.fi/cgit/hostap/tree/tests/hwsim/test_rfkill.py

The interaction with kernel is done using this code:
http://w1.fi/cgit/hostap/tree/tests/hwsim/rfkill.py

It does indeed look like TYPE_ALL is used here (the block() and
unblock() implementations). If this is incorrect, we can certainly
change the script since I'd assume this is not used for anything else
than the hwsim test cases (or well who knows, it is available out there,
so if someone needs python code to do rfkill operations..).
 
-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

[Jouni Malinen]

On Mon, Feb 22, 2016 at 11:36:39AM -0500, João Paulo Rechi Vita wrote:
> Using a switch to handle different ev.op values in rfkill_fop_write()
> makes the code easier to extend, as out-of-range values can always be
> handled by the default case.

This breaks rfkill.. There are automated test scripts for testing this
area (and most of Wi-Fi for that matter. It would be nice if these were
used for changes before they get contributed upstream..

http://buildbot.w1.fi/hwsim/

This specific commit broke all the rfkill_* test cases because of
following:

> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> @@ -1199,29 +1200,32 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
> - list_for_each_entry(rfkill, _list, node) {
> - if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
> - continue;
> -
> - if (rfkill->type != ev.type && ev.type != RFKILL_TYPE_ALL)
> - continue;

Note that RFKILL_TYPE_ALL here..

> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->type == ev.type ||
> + ev.type == RFKILL_TYPE_ALL)
> + rfkill_set_block(rfkill, ev.soft);

It was included for RFKILL_OP_CHANGE_ALL.

> + case RFKILL_OP_CHANGE:
> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->idx == ev.idx && rfkill->type == ev.type)
> + rfkill_set_block(rfkill, ev.soft);

but not for RFKILL_OP_CHANGE..

This needs following to work:


diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 59ff92d..c4bbd19 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1239,7 +1239,9 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
break;
case RFKILL_OP_CHANGE:
list_for_each_entry(rfkill, _list, node)
-   if (rfkill->idx == ev.idx && rfkill->type == ev.type)
+   if (rfkill->idx == ev.idx &&
+   (rfkill->type == ev.type ||
+ev.type == RFKILL_TYPE_ALL))
    rfkill_set_block(rfkill, ev.soft);
ret = 0;
break;
 
-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCHv2 08/10] rfkill: Use switch to demux userspace operations

[Jouni Malinen]

On Mon, Feb 22, 2016 at 11:36:39AM -0500, João Paulo Rechi Vita wrote:
> Using a switch to handle different ev.op values in rfkill_fop_write()
> makes the code easier to extend, as out-of-range values can always be
> handled by the default case.

This breaks rfkill.. There are automated test scripts for testing this
area (and most of Wi-Fi for that matter. It would be nice if these were
used for changes before they get contributed upstream..

http://buildbot.w1.fi/hwsim/

This specific commit broke all the rfkill_* test cases because of
following:

> diff --git a/net/rfkill/core.c b/net/rfkill/core.c
> @@ -1199,29 +1200,32 @@ static ssize_t rfkill_fop_write(struct file *file, 
> const char __user *buf,
> - list_for_each_entry(rfkill, _list, node) {
> - if (rfkill->idx != ev.idx && ev.op != RFKILL_OP_CHANGE_ALL)
> - continue;
> -
> - if (rfkill->type != ev.type && ev.type != RFKILL_TYPE_ALL)
> - continue;

Note that RFKILL_TYPE_ALL here..

> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->type == ev.type ||
> + ev.type == RFKILL_TYPE_ALL)
> + rfkill_set_block(rfkill, ev.soft);

It was included for RFKILL_OP_CHANGE_ALL.

> + case RFKILL_OP_CHANGE:
> + list_for_each_entry(rfkill, _list, node)
> + if (rfkill->idx == ev.idx && rfkill->type == ev.type)
> + rfkill_set_block(rfkill, ev.soft);

but not for RFKILL_OP_CHANGE..

This needs following to work:


diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index 59ff92d..c4bbd19 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1239,7 +1239,9 @@ static ssize_t rfkill_fop_write(struct file *file, const 
char __user *buf,
break;
case RFKILL_OP_CHANGE:
list_for_each_entry(rfkill, _list, node)
-   if (rfkill->idx == ev.idx && rfkill->type == ev.type)
+   if (rfkill->idx == ev.idx &&
+   (rfkill->type == ev.type ||
+ev.type == RFKILL_TYPE_ALL))
    rfkill_set_block(rfkill, ev.soft);
ret = 0;
break;
 
-- 
Jouni MalinenPGP id EFC895FA

Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason codes

[Jouni Malinen]

On Wed, Feb 05, 2014 at 07:44:48PM -0600, Calvin Owens wrote:
> Create a function to return a descriptive string for each reason code,
> and print that instead of the numeric value in the kernel log. These
> codes are easily found on popular search engines, but one is generally
> not able to access the internet when dealing with wireless connectivity
> issues.

I don't personally see need for this, but if others find it helpful, I'm
not that strongly against either (even though this would really belong
to user space), as long as it does not do this:

> + * ieee80211_get_reason_code_string - Get human readable reason code
> + *
> + * This function returns a string describing the @reason_code.
> + *
> + * @reason_code: Reason code we want a human readable string for
> + *
> + * Return: Human readable reason string, or "(INVALID)"

That "(INVALID)" is not helpful. It is just hiding the "unknown" value.
Printing out the actual reason code is much more valuable than making
this "human readable" in this way.

> +const char *ieee80211_get_reason_code_string(u16 reason_code)
> +{
> + if (reason_code <= 24)
> + return reason_code_strings[reason_code];
> + else if (reason_code >= 32 && reason_code <= 39)
> + return reason_code_strings[reason_code - 7];
> + else if (reason_code == 45)
> + return reason_code_strings[33];
> + else if (reason_code >= 52 && reason_code <= 66)
> + return reason_code_strings[reason_code - 18];
> + else
> + return "(INVALID)";
> +}

This is hiding a large number of recently added reason codes.. For most
of the "human readable" strings in the reason_code_strings array, I
would end up having to find the full explanation from the standard
anyway, so I would like to be able to find this easily (and seeing the
real value of the reason code field would be the easiest way).

> diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
> @@ -2231,8 +2231,8 @@ static void ieee80211_rx_mgmt_deauth(struct 
> ieee80211_sub_if_data *sdata,
> - sdata_info(sdata, "deauthenticated from %pM (Reason: %u)\n",
> -bssid, reason_code);
> + sdata_info(sdata, "deauthenticated from %pM (reason: %s)\n",
> +bssid, ieee80211_get_reason_code_string(reason_code));

Please don't do this unless ieee80211_get_reason_code_string() includes
the actual reason code number for every possible case, i.e., just leave
%u print of reason_code here even if the string is added.

-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ieee80211: Print human-readable disassoc/deauth reason codes

[Jouni Malinen]

On Wed, Feb 05, 2014 at 07:44:48PM -0600, Calvin Owens wrote:
 Create a function to return a descriptive string for each reason code,
 and print that instead of the numeric value in the kernel log. These
 codes are easily found on popular search engines, but one is generally
 not able to access the internet when dealing with wireless connectivity
 issues.

I don't personally see need for this, but if others find it helpful, I'm
not that strongly against either (even though this would really belong
to user space), as long as it does not do this:

 + * ieee80211_get_reason_code_string - Get human readable reason code
 + *
 + * This function returns a string describing the @reason_code.
 + *
 + * @reason_code: Reason code we want a human readable string for
 + *
 + * Return: Human readable reason string, or (INVALID)

That (INVALID) is not helpful. It is just hiding the unknown value.
Printing out the actual reason code is much more valuable than making
this human readable in this way.

 +const char *ieee80211_get_reason_code_string(u16 reason_code)
 +{
 + if (reason_code = 24)
 + return reason_code_strings[reason_code];
 + else if (reason_code = 32  reason_code = 39)
 + return reason_code_strings[reason_code - 7];
 + else if (reason_code == 45)
 + return reason_code_strings[33];
 + else if (reason_code = 52  reason_code = 66)
 + return reason_code_strings[reason_code - 18];
 + else
 + return (INVALID);
 +}

This is hiding a large number of recently added reason codes.. For most
of the human readable strings in the reason_code_strings array, I
would end up having to find the full explanation from the standard
anyway, so I would like to be able to find this easily (and seeing the
real value of the reason code field would be the easiest way).

 diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
 @@ -2231,8 +2231,8 @@ static void ieee80211_rx_mgmt_deauth(struct 
 ieee80211_sub_if_data *sdata,
 - sdata_info(sdata, deauthenticated from %pM (Reason: %u)\n,
 -bssid, reason_code);
 + sdata_info(sdata, deauthenticated from %pM (reason: %s)\n,
 +bssid, ieee80211_get_reason_code_string(reason_code));

Please don't do this unless ieee80211_get_reason_code_string() includes
the actual reason code number for every possible case, i.e., just leave
%u print of reason_code here even if the string is added.

-- 
Jouni MalinenPGP id EFC895FA
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: multiple xor_block() functions

[Jouni Malinen]

On Sat, Jun 02, 2007 at 08:57:46PM +0200, Adrian Bunk wrote:
> include/linux/raid/xor.h:extern void xor_block(unsigned int count, unsigned 
> int bytes, void **ptr);
> drivers/md/xor.c:xor_block(unsigned int count, unsigned int bytes, void **ptr)
> drivers/md/xor.c:EXPORT_SYMBOL(xor_block);
> 
> and
> 
> net/ieee80211/ieee80211_crypt_ccmp.c:static inline void xor_block(u8 * b, u8 
> * a, size_t len)
> 
> 
> At least one of them has to be renamed.

Why? Not that I would really mind renaming one of these, but I don't see
a good reason for it. ieee80211_crypt_ccmp.c should not include
linux/raid/xor.h and the xor_block() in CCMP code is a static inline
function that should not show up outside the scope of this file. Do we
have some magic that makes exported symbols pollute name space for
inlined helper functions?

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: multiple xor_block() functions

[Jouni Malinen]

On Sat, Jun 02, 2007 at 08:57:46PM +0200, Adrian Bunk wrote:
 include/linux/raid/xor.h:extern void xor_block(unsigned int count, unsigned 
 int bytes, void **ptr);
 drivers/md/xor.c:xor_block(unsigned int count, unsigned int bytes, void **ptr)
 drivers/md/xor.c:EXPORT_SYMBOL(xor_block);
 
 and
 
 net/ieee80211/ieee80211_crypt_ccmp.c:static inline void xor_block(u8 * b, u8 
 * a, size_t len)
 
 
 At least one of them has to be renamed.

Why? Not that I would really mind renaming one of these, but I don't see
a good reason for it. ieee80211_crypt_ccmp.c should not include
linux/raid/xor.h and the xor_block() in CCMP code is a static inline
function that should not show up outside the scope of this file. Do we
have some magic that makes exported symbols pollute name space for
inlined helper functions?

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] use list_for_each_entry() for iteration in hostap_ap.c

[Jouni Malinen]

On Sun, May 27, 2007 at 12:28:24PM +0200, Matthias Kaehlcke wrote:

> thanks for your comment, here's a patch that uses
> list_for_each_entry(), additionally to the initial patch it
> substitutes some list_for_each() loops by list_for_each_entry()

Thanks! I added this to my list of patches for the driver.

Could you please send a Signed-off-by line for this later version of the
patch? You did it for the first version, but just to be sure, it would
be prefered to see this explicitly for each version.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] use list_for_each_entry() for iteration in hostap_ap.c

[Jouni Malinen]

On Sun, May 27, 2007 at 12:28:24PM +0200, Matthias Kaehlcke wrote:

 thanks for your comment, here's a patch that uses
 list_for_each_entry(), additionally to the initial patch it
 substitutes some list_for_each() loops by list_for_each_entry()

Thanks! I added this to my list of patches for the driver.

Could you please send a Signed-off-by line for this later version of the
patch? You did it for the first version, but just to be sure, it would
be prefered to see this explicitly for each version.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 15/16] use-regular-eth-suffix.diff

[Jouni Malinen]

On Sun, Apr 01, 2007 at 08:18:12PM +0200, Jan Engelhardt wrote:

> Some radio adapter drivers wrongly(?) name their devices "wlan%d"
> instead of "eth%d" (if you ask me, it should be %u - but not today).

> Technically, they operate like Ethernet, and in fact, running
> `/sbin/ip a` shows "link/ether" instead of "link/ieee80211".

The address may look like wired Ethernet (both are based on IEEE 802
standards), but IEEE 802.11 does not behave like IEEE 802.3. For
example, one cannot send frames with a foreign source address in client
mode when using IEEE 802.11 which is clearly different from wired
Ethernet. IEEE 802.11 interfaces (in client mode) cannot be bridged at
layer 2 in the same way as wired Ethernet interfaces could.

> This patch renames them back, but I would appreciate some comment,
> explanation or at least link why they actually have wlan%d there.

Renames _back_? No it doesn't. Host AP driver has never used eth%d as
the interface name template

> Index: linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c
> -static char dev_template[16] = "wlan%d";
> +static char dev_template[16] = "eth%d";

NAK. Host AP driver has been using wlan%d for close to seven years and I
see no reason to change it now. This will just cause problems for users.
If someone wants to rename the interface to something else, they can do
it with number of different ways from user space. The kernel default
should not be changed at this point.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 15/16] use-regular-eth-suffix.diff

[Jouni Malinen]

On Sun, Apr 01, 2007 at 08:18:12PM +0200, Jan Engelhardt wrote:

 Some radio adapter drivers wrongly(?) name their devices wlan%d
 instead of eth%d (if you ask me, it should be %u - but not today).

 Technically, they operate like Ethernet, and in fact, running
 `/sbin/ip a` shows link/ether instead of link/ieee80211.

The address may look like wired Ethernet (both are based on IEEE 802
standards), but IEEE 802.11 does not behave like IEEE 802.3. For
example, one cannot send frames with a foreign source address in client
mode when using IEEE 802.11 which is clearly different from wired
Ethernet. IEEE 802.11 interfaces (in client mode) cannot be bridged at
layer 2 in the same way as wired Ethernet interfaces could.

 This patch renames them back, but I would appreciate some comment,
 explanation or at least link why they actually have wlan%d there.

Renames _back_? No it doesn't. Host AP driver has never used eth%d as
the interface name template

 Index: linux-2.6.21-rc5/drivers/net/wireless/hostap/hostap_hw.c
 -static char dev_template[16] = wlan%d;
 +static char dev_template[16] = eth%d;

NAK. Host AP driver has been using wlan%d for close to seven years and I
see no reason to change it now. This will just cause problems for users.
If someone wants to rename the interface to something else, they can do
it with number of different ways from user space. The kernel default
should not be changed at this point.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Tue, Jan 30, 2007 at 08:35:18PM -0600, Larry Finger wrote:

> If one does the equivalent of 'iwlist eth1 scan essid myssid', then a probe 
> response with
> NETWORK_EMPTY_ESSID set in the network flags will have 'myssid' returned in 
> the SSID field of the
> returned buffer. If the input command were 'iwlist eth1 scan', then an empty 
> SSID would be returned
> under the same circumstances. My code saves the SSID that is in the extra 
> argument of the
> SIOCSIWSCAN call, and uses that in the SIOCGIWSCAN call.

Well, yes, but SIOCSIWSCAN and SIOCGIWSCAN calls are not in any way
linked together.. You could have two user space programs asking for a
scan of different SSID at more or less the same time and then have them
read the results with SIOCGIWSCAN. At this point, the SSID from the last
SIOCSIWSCAN would be returned for all APs that are in the scan list
without an SSID. This may not be the correct SSID and can produce quite
confusing results. I don't see this as an improvement over just removing
the "" which will at least provide consistent results.

The proper fix for this is to use the information from the AP (Probe
Response frames) and create a local BSS list that has entries with SSID
updated from Probe Responses. If the underlying hardware/firmware does
not allow such handling, this kind of mapping of SSIDs from scan request
to scan results should probably in the hardware driver that would have
chance of mapping results from firmware to request for a given SSID. At
that point, it might be feasible to change the SSID in scan results, but
I see only problems for the case where this is done at higher layer.

> What is the method that should be used to associated with a given hidden AP?

The 802.11 stack should fill in the proper SSID data from Probe
Responses and maintain a local BSS list, i.e., the hidden APs would be
marked with proper SSID whenever Probe Responses are processed. See,
e.g., how driver/net/wireless/hostap/*.c use local->bss_list that will
be filled with information from both Beacon and Probe Response frames or
how wireless-dev.git net/d80211/ieee80211_sta.c handles updating of BSS
entry from both Beacon and Probe Response frames (i.e., do not allow
Beacon frames to replace data from Probe Response frames) in
ieee80211_rx_bss_info().

In other words, the hidden SSIDs are resolved in the BSS list based on
information from Probe Responses and user space programs will get proper
information in the scan results regardless of how the real SSID was
learned.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Tue, Jan 30, 2007 at 08:35:18PM -0600, Larry Finger wrote:

 If one does the equivalent of 'iwlist eth1 scan essid myssid', then a probe 
 response with
 NETWORK_EMPTY_ESSID set in the network flags will have 'myssid' returned in 
 the SSID field of the
 returned buffer. If the input command were 'iwlist eth1 scan', then an empty 
 SSID would be returned
 under the same circumstances. My code saves the SSID that is in the extra 
 argument of the
 SIOCSIWSCAN call, and uses that in the SIOCGIWSCAN call.

Well, yes, but SIOCSIWSCAN and SIOCGIWSCAN calls are not in any way
linked together.. You could have two user space programs asking for a
scan of different SSID at more or less the same time and then have them
read the results with SIOCGIWSCAN. At this point, the SSID from the last
SIOCSIWSCAN would be returned for all APs that are in the scan list
without an SSID. This may not be the correct SSID and can produce quite
confusing results. I don't see this as an improvement over just removing
the hidden which will at least provide consistent results.

The proper fix for this is to use the information from the AP (Probe
Response frames) and create a local BSS list that has entries with SSID
updated from Probe Responses. If the underlying hardware/firmware does
not allow such handling, this kind of mapping of SSIDs from scan request
to scan results should probably in the hardware driver that would have
chance of mapping results from firmware to request for a given SSID. At
that point, it might be feasible to change the SSID in scan results, but
I see only problems for the case where this is done at higher layer.

 What is the method that should be used to associated with a given hidden AP?

The 802.11 stack should fill in the proper SSID data from Probe
Responses and maintain a local BSS list, i.e., the hidden APs would be
marked with proper SSID whenever Probe Responses are processed. See,
e.g., how driver/net/wireless/hostap/*.c use local-bss_list that will
be filled with information from both Beacon and Probe Response frames or
how wireless-dev.git net/d80211/ieee80211_sta.c handles updating of BSS
entry from both Beacon and Probe Response frames (i.e., do not allow
Beacon frames to replace data from Probe Response frames) in
ieee80211_rx_bss_info().

In other words, the hidden SSIDs are resolved in the BSS list based on
information from Probe Responses and user space programs will get proper
information in the scan results regardless of how the real SSID was
learned.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Sun, Jan 28, 2007 at 04:18:01PM -0600, Larry Finger wrote:

> Is there something funny about Cisco APs with hidden SSID?

Yes, there is.. Or well, "hidden SSID" is funny concept in itself, but
anyway.. Some APs set the SSID IE to an array of 0x00 octets with the
length of the original SSID when "hiding" the SSID while others just use
0-length SSID.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote:

> Any AP with a hidden SSID will only respond to probe requests that specify 
> its SSID, and will ignore
> any other probes. In addition, the response will have an empty SSID field. 
> These responses are the
> only ones in which a substitution would occur. These are the same responses 
> where the current code
> sends back the "" pseudo-SSID. My change would put the correct one 
> there.

Is the SSID from the probe response really used here? Your patch did not
look like that.. The SSID from the last scan request command may not be
the one that triggered the last scan (e.g., one could request a new scan
without specifying an SSID).

> We aren't guessing. The response frame with the empty SSID field must have 
> come from the AP with the
> SSID we want. Filling in the expected value is just making it easier for the 
> user-space tools.

I don't see how the proposed patch would be using the correct SSID value
in all cases. Especially cases where there are multiple APs using hidden
SSIDs, but with different real SSID values and cases where multiple scan
requests are being processed would be likely to leave windows open for
reporting incorrect SSID.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Tue, Jan 30, 2007 at 01:08:29AM -0600, Larry Finger wrote:

 Any AP with a hidden SSID will only respond to probe requests that specify 
 its SSID, and will ignore
 any other probes. In addition, the response will have an empty SSID field. 
 These responses are the
 only ones in which a substitution would occur. These are the same responses 
 where the current code
 sends back the hidden pseudo-SSID. My change would put the correct one 
 there.

Is the SSID from the probe response really used here? Your patch did not
look like that.. The SSID from the last scan request command may not be
the one that triggered the last scan (e.g., one could request a new scan
without specifying an SSID).

 We aren't guessing. The response frame with the empty SSID field must have 
 come from the AP with the
 SSID we want. Filling in the expected value is just making it easier for the 
 user-space tools.

I don't see how the proposed patch would be using the correct SSID value
in all cases. Especially cases where there are multiple APs using hidden
SSIDs, but with different real SSID values and cases where multiple scan
requests are being processed would be likely to leave windows open for
reporting incorrect SSID.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Sun, Jan 28, 2007 at 04:18:01PM -0600, Larry Finger wrote:

 Is there something funny about Cisco APs with hidden SSID?

Yes, there is.. Or well, hidden SSID is funny concept in itself, but
anyway.. Some APs set the SSID IE to an array of 0x00 octets with the
length of the original SSID when hiding the SSID while others just use
0-length SSID.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote:

> When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
> which searches through the scan data looking for a particular ssid. Because
> ieee80211 has substituted a false ssid, namely "", wpa_supplicant
> cannot authenticate. This behavior is fixed by adding a new argument to
> ieee80211_translate_scan that contains the expected ssid.

Would this be replacing the SSID of all BSSes in scan results with the
SSID for which the latest per-SSID scan was issued? If yes, this does
not sound any better than the current behavior. The driver/802.11 code
should not replace the SSID value with anything else than the value
received from the AP.

In case of hidden SSIDs, the 802.11 implementation should maintain a
list of BSSes found during the scan(s) and update the SSID (in most
cases, by creating a new BSS entry) with the SSID from Probe Response
frames. In other words, if the scan is done for a specific SSID (Probe
Request includes that SSID), the AP that is using hidden SSIDs will
likely include the SSID in Probe Response and data from that Probe
Response can be used to fill in the missing pieces for the 
pair.

Generating false scan results by locally guessing what the SSID
could be is just plain wrong. The scan results need to be based on real
frames from the APs.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:

> Well, there's no way a userspace program could depend on all hidden SSID
> APs having the  tag, since if you stick in another,
> non-ieee80211-stack card it won't be like that.  So I don't think we
> should care about  in d80211, but I don't think we can remove it
> from ieee80211 either.

Use of '' is just not acceptable. IMHO, it should be removed
from everywhere, including net/ieee80211. The sooner this is done, the
better.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Mon, Jan 29, 2007 at 08:00:11AM -0500, Dan Williams wrote:

 Well, there's no way a userspace program could depend on all hidden SSID
 APs having the hidden tag, since if you stick in another,
 non-ieee80211-stack card it won't be like that.  So I don't think we
 should care about hidden in d80211, but I don't think we can remove it
 from ieee80211 either.

Use of 'hidden' is just not acceptable. IMHO, it should be removed
from everywhere, including net/ieee80211. The sooner this is done, the
better.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Hidden SSID's

[Jouni Malinen]

On Mon, Jan 29, 2007 at 10:52:20PM -0600, Larry Finger wrote:

 When an AP has a hidden SSID, ieee80211 fails, at least with wpa_supplicant,
 which searches through the scan data looking for a particular ssid. Because
 ieee80211 has substituted a false ssid, namely hidden, wpa_supplicant
 cannot authenticate. This behavior is fixed by adding a new argument to
 ieee80211_translate_scan that contains the expected ssid.

Would this be replacing the SSID of all BSSes in scan results with the
SSID for which the latest per-SSID scan was issued? If yes, this does
not sound any better than the current behavior. The driver/802.11 code
should not replace the SSID value with anything else than the value
received from the AP.

In case of hidden SSIDs, the 802.11 implementation should maintain a
list of BSSes found during the scan(s) and update the SSID (in most
cases, by creating a new BSS entry) with the SSID from Probe Response
frames. In other words, if the scan is done for a specific SSID (Probe
Request includes that SSID), the AP that is using hidden SSIDs will
likely include the SSID in Probe Response and data from that Probe
Response can be used to fill in the missing pieces for the BSSID,SSID
pair.

Generating false scan results by locally guessing what the SSID
could be is just plain wrong. The scan results need to be based on real
frames from the APs.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()

[Jouni Malinen]

On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:

> htonll() is nothing else than cpu_to_be64(), so we'd rather call the
> latter.

Actually, the htonll() implementation does not seem to be doing what
cpu_to_be64() is doing.. However, I would assume this is a bug in
htonll() and this change to use cpu_to_be64() is fixing that. Can this
bug cause any major problems in the current implementation?

> -u_int64_t htonll(u_int64_t in)
> -{
> - u_int64_t out;
> - int i;
> -
> - for (i = 0; i < sizeof(u_int64_t); i++)
> - ((u_int8_t *))[sizeof(u_int64_t)-1] = ((u_int8_t *))[i];

I would assume that the first index should have had '-i' added to it, if
the purpose is to swap byte order.. The code here is leaving some
arbitrary data in 7 bytes of the 64-bit variable and setting
(u8*)[7] = (u8*)[7] in somewhat inefficient way ;-). In addition,
this looks more like swap-8-bytes-unconditionally than doing this based
on host byte order..

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] [NETFILTER] remove bogus hand-coded htonll()

[Jouni Malinen]

On Sat, Sep 03, 2005 at 10:43:15AM +0200, Harald Welte wrote:

 htonll() is nothing else than cpu_to_be64(), so we'd rather call the
 latter.

Actually, the htonll() implementation does not seem to be doing what
cpu_to_be64() is doing.. However, I would assume this is a bug in
htonll() and this change to use cpu_to_be64() is fixing that. Can this
bug cause any major problems in the current implementation?

 -u_int64_t htonll(u_int64_t in)
 -{
 - u_int64_t out;
 - int i;
 -
 - for (i = 0; i  sizeof(u_int64_t); i++)
 - ((u_int8_t *)out)[sizeof(u_int64_t)-1] = ((u_int8_t *)in)[i];

I would assume that the first index should have had '-i' added to it, if
the purpose is to swap byte order.. The code here is leaving some
arbitrary data in 7 bytes of the 64-bit variable and setting
(u8*)out[7] = (u8*)in[7] in somewhat inefficient way ;-). In addition,
this looks more like swap-8-bytes-unconditionally than doing this based
on host byte order..

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] include/net/ieee80211.h must #include

[Jouni Malinen]

On Wed, Jul 27, 2005 at 09:51:00PM +0200, Adrian Bunk wrote:

> gcc found an (although perhaps harmless) bug:
> 
>   CC  net/ieee80211/ieee80211_crypt.o
> In file included from net/ieee80211/ieee80211_crypt.c:21:
> include/net/ieee80211.h:26:5: warning: "WIRELESS_EXT" is not defined

> +++ linux-2.6.13-rc3-mm1-full/include/net/ieee80211.h 2005-07-22 
> 18:38:10.0 +0200
> +#include 

>  #if WIRELESS_EXT < 17
>  #define IW_QUAL_QUAL_INVALID   0x10

Wouldn't the proper fix be to just remove this backwards compatibility
code since WIRELESS_EXT is actually 18 in this tree anyway.. Is there
valid need to keep this header file compatible with older kernel
versions?

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] new wireless stuffs

[Jouni Malinen]

On Sat, Jul 30, 2005 at 07:24:46PM -0400, Jeff Garzik wrote:

> One big thing I'm still hoping for is that someone will merge HostAP 
> (where ieee80211 code came from) with the ieee80211 generic code.  The 
> HostAP maintainer has been unwilling to do it, even though he has been 
> good about keeping HostAP updated, so hopefully a volunteer will step up.

I would say this has been more due to lack of time than unwillingness on
my part. Finally, I got git set up yesterday and got back to working
with the wireless-2.6/netdev-2.6 code and I'm planning on working with
the Host AP and ieee80211 code merge. I would expect the client side
functionality to be relatively easy merge, but the AP side functionality
may require considerable amount of work due to the current ieee80211
code being more focused on the client side.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [git patches] new wireless stuffs

[Jouni Malinen]

On Sat, Jul 30, 2005 at 07:24:46PM -0400, Jeff Garzik wrote:

 One big thing I'm still hoping for is that someone will merge HostAP 
 (where ieee80211 code came from) with the ieee80211 generic code.  The 
 HostAP maintainer has been unwilling to do it, even though he has been 
 good about keeping HostAP updated, so hopefully a volunteer will step up.

I would say this has been more due to lack of time than unwillingness on
my part. Finally, I got git set up yesterday and got back to working
with the wireless-2.6/netdev-2.6 code and I'm planning on working with
the Host AP and ieee80211 code merge. I would expect the client side
functionality to be relatively easy merge, but the AP side functionality
may require considerable amount of work due to the current ieee80211
code being more focused on the client side.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [-mm patch] include/net/ieee80211.h must #include linux/wireless.h

[Jouni Malinen]

On Wed, Jul 27, 2005 at 09:51:00PM +0200, Adrian Bunk wrote:

 gcc found an (although perhaps harmless) bug:
 
   CC  net/ieee80211/ieee80211_crypt.o
 In file included from net/ieee80211/ieee80211_crypt.c:21:
 include/net/ieee80211.h:26:5: warning: WIRELESS_EXT is not defined

 +++ linux-2.6.13-rc3-mm1-full/include/net/ieee80211.h 2005-07-22 
 18:38:10.0 +0200
 +#include linux/wireless.h

  #if WIRELESS_EXT  17
  #define IW_QUAL_QUAL_INVALID   0x10

Wouldn't the proper fix be to just remove this backwards compatibility
code since WIRELESS_EXT is actually 18 in this tree anyway.. Is there
valid need to keep this header file compatible with older kernel
versions?

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc2-mm3: hostap: do not #include .c files

[Jouni Malinen]

On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:

> drivers/net/wireless/hostap/hostap.c:#include "hostap_crypt.c"

> Please do not #include .c files.

A tested patch would be appreciated.. ;-)

> A proper separation in a .c file and a header file is the better 
> solution.

Agreed and this is on my to-do list, but not very high on it. Some of
these would be relatively easy to fix, but the hardware specific ones
(different register offsets for PC Card/PLX/PCI) would require quite a
bit of changes to get rid of this.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc2-mm3: hostap: do not #include .c files

[Jouni Malinen]

On Tue, Apr 19, 2005 at 04:03:12AM +0200, Adrian Bunk wrote:

 drivers/net/wireless/hostap/hostap.c:#include hostap_crypt.c

 Please do not #include .c files.

A tested patch would be appreciated.. ;-)

 A proper separation in a .c file and a header file is the better 
 solution.

Agreed and this is on my to-do list, but not very high on it. Some of
these would be relatively easy to fix, but the hardware specific ones
(different register offsets for PC Card/PLX/PCI) would require quite a
bit of changes to get rid of this.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.x wireless update and status

[Jouni Malinen]

On Tue, Mar 22, 2005 at 08:46:17PM -0500, Jeff Garzik wrote:

> Just updated the wireless-2.6 queue to include a HostAP update, and to 
> add Wireless Extensions 18 (WPA).  See attached for BK info, patch info, 
> and changelog.

Thanks!

> Moving forward, the next "todo" for kernel wireless hackers is to get 
> ieee80211 common code lib into shape, namely:
> * Merge Intel ipw drivers, which use ieee80211
> * Update HostAP to use ieee80211
> * Merge/convert other drivers to use ieee80211?

I'll be working on HostAP driver next; and ieee80211 code of course at
the same time, since it is likely to need some changes for this. As far
as other drivers are concerned, I'd like to see Atheros cards working
with the generic ieee80211 code. They would be a good test target since
they are an example of design where very large part of functionality is
in the driver/network stack (no firmware used). This would be a good
test to verify that the 802.11 code is generic enough for such a design.

> There is one minor point of contention so far.  Jouni stated he prefers 
> that HostAP go upstream before it gets updated to use ieee80211.  I 
> respectfully disagree, and prefer that HostAP is updated -first- to use 
> the ieee80211 lib, before going upstream.

I think we can resolve this quite easily. The main reason for the other
order was in trying to save my time by not having to work in more than
one active development tree at the same time. This is kind of required
since designing and maintaining an IEEE 802.11 stack would really be a
full-time job and unfortunately, I have not yet managed to reach this
goal in a way that would allow me to use all my time on open source
development.

BK did not really work that well for me, but it looks like I'm having
better luck with quilt as far as the amount of time needed for
organizing changes to wireless-2.6 is concerned. In addition, the total
number of changes to the driver code has been quite small lately, so I'm
beginning to be more open to moving all future development into
wireless-2.6 tree and just keeping my current CVS repository as a
backwards compatible (2.2/2.4/2.6 kernels), stable version that wouldn't
get any more new features. This would allow the order that you prefer.
In addition, if someone really wants to get the new features I may be
adding, these should be available through wireless-2.6 tree (and -mm for
that matter).

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc1-mm1: hostap stack usage

[Jouni Malinen]

(netdev added to cc:)

On Tue, Mar 22, 2005 at 05:33:40PM +0100, Adrian Bunk wrote:

> The stack usage in some files under drivers/net/wireless/hostap/ is
> too high.

Thanks; I'll fix these and submit a patch (or two) after some testing.

> drivers/net/wireless/hostap/hostap_ioctl.c:
> 
> prism2_ioctl_giwaplist:
> struct sockaddr addr[IW_MAX_AP];
> struct iw_quality qual[IW_MAX_AP];
> 
> 64 * (16 + 4) Bytes = 1280 Bytes

OK.

> prism2_ioctl_ethtool:
> struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
> 
> 196 Bytes

This seems to be somewhat obsolete now since most drivers have moved to
use get_drvinfo of ethtool_ops; I'll do the same.

> __prism2_translate_scan:
> char buf[MAX_WPA_IE_LEN * 2 + 30];
> 
> (64 * 2) + 30 Bytes = 158 Bytes

OK.

> drivers/net/wireless/hostap/hostap_cs.c:
> 
> prism2_config:
> cisparse_t parse;
> u_char buf[64];
> config_info_t conf;
> 
> The main offender seems to be "parse" (but I'm too lame counting how 
> many bytes it's exactly) resulting in nearly 1 kB stack usage.

This is actually very common for PC Card drivers in the current kernel
tree.. I'll change Host AP to kmalloc this, but someone might consider
going through all *_cs.c drivers..

> drivers/net/wireless/hostap/hostap_plx.c:
> 
> prism2_plx_check_cis:
> #define CIS_MAX_LEN 256
> u8 cis[CIS_MAX_LEN];

OK.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.12-rc1-mm1: hostap stack usage

[Jouni Malinen]

(netdev added to cc:)

On Tue, Mar 22, 2005 at 05:33:40PM +0100, Adrian Bunk wrote:

 The stack usage in some files under drivers/net/wireless/hostap/ is
 too high.

Thanks; I'll fix these and submit a patch (or two) after some testing.

 drivers/net/wireless/hostap/hostap_ioctl.c:
 
 prism2_ioctl_giwaplist:
 struct sockaddr addr[IW_MAX_AP];
 struct iw_quality qual[IW_MAX_AP];
 
 64 * (16 + 4) Bytes = 1280 Bytes

OK.

 prism2_ioctl_ethtool:
 struct ethtool_drvinfo info = { ETHTOOL_GDRVINFO };
 
 196 Bytes

This seems to be somewhat obsolete now since most drivers have moved to
use get_drvinfo of ethtool_ops; I'll do the same.

 __prism2_translate_scan:
 char buf[MAX_WPA_IE_LEN * 2 + 30];
 
 (64 * 2) + 30 Bytes = 158 Bytes

OK.

 drivers/net/wireless/hostap/hostap_cs.c:
 
 prism2_config:
 cisparse_t parse;
 u_char buf[64];
 config_info_t conf;
 
 The main offender seems to be parse (but I'm too lame counting how 
 many bytes it's exactly) resulting in nearly 1 kB stack usage.

This is actually very common for PC Card drivers in the current kernel
tree.. I'll change Host AP to kmalloc this, but someone might consider
going through all *_cs.c drivers..

 drivers/net/wireless/hostap/hostap_plx.c:
 
 prism2_plx_check_cis:
 #define CIS_MAX_LEN 256
 u8 cis[CIS_MAX_LEN];

OK.

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: 2.6.x wireless update and status

[Jouni Malinen]

On Tue, Mar 22, 2005 at 08:46:17PM -0500, Jeff Garzik wrote:

 Just updated the wireless-2.6 queue to include a HostAP update, and to 
 add Wireless Extensions 18 (WPA).  See attached for BK info, patch info, 
 and changelog.

Thanks!

 Moving forward, the next todo for kernel wireless hackers is to get 
 ieee80211 common code lib into shape, namely:
 * Merge Intel ipw drivers, which use ieee80211
 * Update HostAP to use ieee80211
 * Merge/convert other drivers to use ieee80211?

I'll be working on HostAP driver next; and ieee80211 code of course at
the same time, since it is likely to need some changes for this. As far
as other drivers are concerned, I'd like to see Atheros cards working
with the generic ieee80211 code. They would be a good test target since
they are an example of design where very large part of functionality is
in the driver/network stack (no firmware used). This would be a good
test to verify that the 802.11 code is generic enough for such a design.

 There is one minor point of contention so far.  Jouni stated he prefers 
 that HostAP go upstream before it gets updated to use ieee80211.  I 
 respectfully disagree, and prefer that HostAP is updated -first- to use 
 the ieee80211 lib, before going upstream.

I think we can resolve this quite easily. The main reason for the other
order was in trying to save my time by not having to work in more than
one active development tree at the same time. This is kind of required
since designing and maintaining an IEEE 802.11 stack would really be a
full-time job and unfortunately, I have not yet managed to reach this
goal in a way that would allow me to use all my time on open source
development.

BK did not really work that well for me, but it looks like I'm having
better luck with quilt as far as the amount of time needed for
organizing changes to wireless-2.6 is concerned. In addition, the total
number of changes to the driver code has been quite small lately, so I'm
beginning to be more open to moving all future development into
wireless-2.6 tree and just keeping my current CVS repository as a
backwards compatible (2.2/2.4/2.6 kernels), stable version that wouldn't
get any more new features. This would allow the order that you prefer.
In addition, if someone really wants to get the new features I may be
adding, these should be available through wireless-2.6 tree (and -mm for
that matter).

-- 
Jouni MalinenPGP id EFC895FA
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/