Help with wireless disassociation
Phil Black
Phil.Black
Wed Jun 17 08:23:48 PDT 2009
OK, the next question would be how to get this done... I don't think
driver supports it, and it didn't look like the kernel had generic
support for this either (or am I looking in the wrong spot). I saw some
code in hostap.c, but I thought the code in there was for creating an
AP, not for a STA connected to it.
I've dug around some more in the drivers for the card (ralink 2860,
using 'legacy' drivers), and found some code that looks like it
generates a nullfunc frame, but I don't see any way to just call this.
I searched around some in the wpa code and haven't found anything that
looks like what I want either. Given that this seems to be a fairly
wide spread occurrence, I'm surprised there isn't more support.
Just to make sure I've got my head wrapped around this correctly, the
current solution seems to be to add some functionality to the ralink
driver to send nullfunc frames.
In seems the 'proper' thing to do would be to set a timeout when the STA
associates, and reset it anytime data is sent over the link, to avoid
the extra data. If I understand the layers, this would need to get done
in the ralink driver. Or is there someplace in the generic kernel
levels that would be more appropriate?
Sorry, all of this (wireless, kernel drivers, etc) is relatively new to
me, and I just want to get my head wrapped around it before I start down
the wrong path.
Thanks for all the advice,
Phil
Date: Tue, 16 Jun 2009 23:59:21 +0300
From: "Chuck Tuffli" <Chuck.Tuffli at dspg.com>
Subject: RE: Help with wireless disassociation
To: <hostap at lists.shmoo.com>
Message-ID: <5EFF534737810441B0F97C2792E49C2D3B9CD0 at ILMAIL01.dspg.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com
> [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
...
> You could make the driver send out empty data nullfunc frames
> (assuming it supports sending arbitrary frames) if you want to
> minimize size of the transmitted frames. However, it is not sure
> whether the AP would count those as activity as far as the inactivity
> timeout is concerned.
I'll second Jouni's suggestion. We've had success sending Data Null
packets from within the device driver to keep APs from disconnecting.
---chuck
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
-----Original Message-----
From: hostap-bounces at lists.shmoo.com
[mailto:hostap-bounces at lists.shmoo.com] On Behalf Of
hostap-request at lists.shmoo.com
Sent: Tuesday, June 16, 2009 5:16 PM
To: hostap at lists.shmoo.com
Subject: HostAP Digest, Vol 74, Issue 16
Send HostAP mailing list submissions to
hostap at lists.shmoo.com
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.shmoo.com/mailman/listinfo/hostap
or, via email, send a message with subject or body 'help' to
hostap-request at lists.shmoo.com
You can reach the person managing the list at
hostap-owner at lists.shmoo.com
When replying, please edit your Subject line so it is more specific
than "Re: Contents of HostAP digest..."
Today's Topics:
1. Re: wpa_supplicant-0.5.11 SEG FAULT for for
[WPA2-PSK-TKIP+CCMP-preauth] (Jouni Malinen)
2. Re: 802.1x, EAP-TLS -PEAP (Jouni Malinen)
3. Re: Help with wireless disassociation (Jouni Malinen)
4. Re: New wpa_supplicand dbus API proposal (Dan Williams)
5. Re: New wpa_supplicand dbus API proposal (Dan Williams)
6. RE: Help with wireless disassociation (Chuck Tuffli)
7. Re: New wpa_supplicand dbus API proposal (Marcel Holtmann)
----------------------------------------------------------------------
Message: 1
Date: Tue, 16 Jun 2009 20:49:15 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: wpa_supplicant-0.5.11 SEG FAULT for for
[WPA2-PSK-TKIP+CCMP-preauth]
To: hostap at lists.shmoo.com
Message-ID: <20090616174915.GA28024 at jm.kir.nu>
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 16, 2009 at 05:40:07PM +0530, Raghavendra wrote:
> I am using wpa_supplicant-0.5.11. I configured D-Link AP with WPA2-PSK
and Cipher Type as "Auto". Getting seg fault. Please see logs below.
> In scan result it displayed following info.
It looks like I'm unable to reproduce this. Would it be possible for you
to use gdb or valgrind to get a backtrace or at least the location of
the segmentation fault?
> # cat wpa_supplicant.conf.tmp
> ctrl_interface=/var/run/wpa_supplicant
> ap_scan=2
>
>
> network={
> ssid="default"
> proto=WPA RSN
> key_mgmt=WPA-PSK
> pairwise=TKIP CCMP
> group=TKIP CCMP
> psk="testtest"
> }
By the way, this is invalid configuration. With ap_scan=2, only one
option for proto/key_mgmt/pairwise/group is allowed. Not that this
should cause the crash (and it did not in my tests), but it may result
in unexpected results.
--
Jouni Malinen PGP id EFC895FA
------------------------------
Message: 2
Date: Tue, 16 Jun 2009 21:05:29 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: 802.1x, EAP-TLS -PEAP
To: hostap at lists.shmoo.com
Message-ID: <20090616180528.GA29289 at jm.kir.nu>
Content-Type: text/plain; charset=us-ascii
On Tue, Jun 16, 2009 at 01:45:49PM +0530, Harsha gowda wrote:
> I want to decrypt the TLS tunnel data,
> So far i have extracted client Key exchange message.
> Which has pre master Key,Decrypted with Root Private Key,
> Got 48 bytes of
> (MK)*Master_key*=PRF(Pre-Master-Key,"*master key*
> ",Client.random|Server.random).
>
> And derived 64 bytes
> (TK)*TunnelKey* (Master-Key,"*Client EAP encryption*
> ",Client.random|Server.random)
>
> Which is the key to encrypt/decrypt TLSV1 application data.
>
> Is tunnel Key is used to encrypt decrypt data.
The master key is used to derive a set of keys and related values
("key_block") and those keys/parameters are used to encrypt/decrypt TLS
records.
The key you call TK (the 64 octet long key is the TLS PRF output) could
be used, e.g., with WPA2-Enterprise as the PMK for 4-way handshake.
However, since you call this TK, I would assume you are looking into
PEAP cryptobinding case where this key is used to derive some additional
key for binding the tunneled methods together.
What are you trying to do? It would probably be easier to run through
another authentication and just look at the supplicant (or
authentication server) debug log to see what data was sent.. For
example, wpa_supplicant can show you that data in the debug log.
--
Jouni Malinen PGP id EFC895FA
------------------------------
Message: 3
Date: Tue, 16 Jun 2009 21:10:41 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: Help with wireless disassociation
To: hostap at lists.shmoo.com
Message-ID: <20090616181041.GB29289 at jm.kir.nu>
Content-Type: text/plain; charset=us-ascii
On Fri, Jun 12, 2009 at 04:22:07PM -0400, Phil Black wrote:
> I would like to avoid this behavior altogether. It seems like the
> simplest solution is to just put some traffic over the link as soon as
I
> have an IP address (via pinging the router or something), but this
seems
> a bit overkill. I've read a couple postings that seem to hint that
it's
> possible to just send some small/empty packages over the link to keep
> the connection alive at the PHY layer. Or is there some way to get
> wpa_supplicant to provide a keep alive?
You could make the driver send out empty data nullfunc frames (assuming
it supports sending arbitrary frames) if you want to minimize size of
the transmitted frames. However, it is not sure whether the AP would
count those as activity as far as the inactivity timeout is concerned.
--
Jouni Malinen PGP id EFC895FA
------------------------------
Message: 4
Date: Tue, 16 Jun 2009 16:06:14 -0400
From: Dan Williams <dcbw at redhat.com>
Subject: Re: New wpa_supplicand dbus API proposal
To: Marcel Holtmann <marcel at holtmann.org>
Cc: Jouni Malinen <j at w1.fi>, hostap at lists.shmoo.com
Message-ID: <1245182774.28992.22.camel at 130.81.190.10.in-addr.arpa>
Content-Type: text/plain
On Fri, 2009-06-12 at 01:31 +0200, Marcel Holtmann wrote:
> Hi Witold,
>
> > >> Here is second proposal of new DBus API build basing of our
earlier
> > >> e-mail correspondence, Marcel's remarks and arrangement I made
with Dan
> > >> on #wireless.
> > >> I will start to implement this in next week. Request for
comments.
> > >>
> > >> Service Name: fi.w1.wpa_supplicant1
> > >>
> > >> O: /fi/w1/wpa_supplicant1
> > >> I : fi.w1.wpa_supplicant1
> > >>
> > >> M: CreateInterface(args a{sv}) -> path o
> > >> args: Ifname -> s
> > >> Driver -> s
> > >> Bridge-ifname -> s
> > >> Level -> u
> > >> Timestamp -> b
> > >> Show_keys -> b
> > >>
> > Level should be DebugLevel - my mistake.
> > >
> > > can we add an Ifindex -> u here. So you can optionally give the
> > > interface index or the name. Could be useful in some cases where
> > > everything is based around the ifindex anyway.
> > >
> > OK. We would return InterfaceExists error if specified index is in
use.
> > Do we actually need that indexing? Couldn't we just use paths like
> > s/Interfaces/<ifname>/... instead of s/Interfaces/<ifindex>/...?
That
> > would make paths more telling, and we could kill interface indexing.
>
> I think it is a bad idea to make the object path in D-Bus meaningful.
I
> would advise against it.
Yeah, object paths are opaque and should not be depended on by
applications. They are like pointers, they mean nothing and are just a
bunch of numbers.
> > >> E: fi.w1.wpa_supplicant1.InterfaceExists
> > >> fi.w1.wpa_supplicant1.InterfaceUnknown
> > >> fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> M: RemoveInterface(path o)
> > >> E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > >> fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> M: GetInterface(ifname s) -> path o
> > >> E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > >> fi.w1.wpa_supplicant1.UnknownError
> > >>
> > >> P: Interfaces -> ao
> > >> EapMethods -> as
> > >>
> > >> S: InterfaceAdded -> path o
> > >> S: InterfaceRemoved -> path o
> > >> S: PropertiesChanged -> properties a{sv}
> > >>
> > >
> > > I still think using Device instead of Interface is better for the
sake
> > > of mind :)
> > >
> > Heh, actually I agree with Dan's explanation. I would rather
consider
> > Device as hardware device, and Interface as logical network
Interface.
> > Since there may be more than one interface on one device, and we are
> > actually interested in interfaces, *not* in devices here, I think
that
> > Interface describes matter better than Device.
>
> I agree with that, no questions asked. However using "Interface" as
> D-Bus interface name is nasty and makes you drive crazy.
Sort of, but that's the terminology we're stuck with :(
Dan
------------------------------
Message: 5
Date: Tue, 16 Jun 2009 16:19:24 -0400
From: Dan Williams <dcbw at redhat.com>
Subject: Re: New wpa_supplicand dbus API proposal
To: Marcel Holtmann <marcel at holtmann.org>
Cc: Jouni Malinen <j at w1.fi>, hostap at lists.shmoo.com
Message-ID: <1245183564.28992.36.camel at 130.81.190.10.in-addr.arpa>
Content-Type: text/plain
On Fri, 2009-06-12 at 00:08 +0200, Marcel Holtmann wrote:
> Hi Witold,
>
> > Here is second proposal of new DBus API build basing of our earlier
> > e-mail correspondence, Marcel's remarks and arrangement I made with
Dan
> > on #wireless.
> > I will start to implement this in next week. Request for comments.
> >
> > Service Name: fi.w1.wpa_supplicant1
> >
> > O: /fi/w1/wpa_supplicant1
> > I : fi.w1.wpa_supplicant1
> >
> > M: CreateInterface(args a{sv}) -> path o
> > args: Ifname -> s
> > Driver -> s
> > Bridge-ifname -> s
> > Level -> u
> > Timestamp -> b
> > Show_keys -> b
>
> can we add an Ifindex -> u here. So you can optionally give the
> interface index or the name. Could be useful in some cases where
> everything is based around the ifindex anyway.
That's reasonable; device names aren't stable but ifindexes are (while
the machine is up of course).
> > E: fi.w1.wpa_supplicant1.InterfaceExists
> > fi.w1.wpa_supplicant1.InterfaceUnknown
> > fi.w1.wpa_supplicant1.UnknownError
> >
> > M: RemoveInterface(path o)
> > E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > fi.w1.wpa_supplicant1.UnknownError
> >
> > M: GetInterface(ifname s) -> path o
> > E: fi.w1.wpa_supplicant1.InterfaceUnknown
> > fi.w1.wpa_supplicant1.UnknownError
> >
> > P: Interfaces -> ao
> > EapMethods -> as
> >
> > S: InterfaceAdded -> path o
> > S: InterfaceRemoved -> path o
> > S: PropertiesChanged -> properties a{sv}
>
> I still think using Device instead of Interface is better for the sake
> of mind :)
>
> > ****************************************
> >
> > O: /fi/w1.wpa_supplicant1/Interfaces/<interface_number>
> > I: fi.w1.wpa_supplicant1.Interface
> >
> > P: Capabilities (read-only) -> a{sv}
> > Pairwise -> as [ccmp, tkip, none]
> > Group -> as [ccmp, tkip, wep104, wep40]
> > Keymgmt -> as [wpa-psk, wpa-eap, ieee8021x, wpa-none,
> > wps, none]
> > Protocol -> as [rsn, wpa]
> > AuthAlg -> as [open, shared, leap]
> > Scan -> as [active, passive, ssid, bssid, ies,
channel]
> > P: State (read-only) -> s [disconnected, inactive, scanning,
> > authenticating, associating, associated, way_handshake,
group_handshake,
> > completed, unknown]
> > P: Scanning (read-only) -> b
> > P: ApScan (read/write) -> u [0, 1, 2]
> > P: Ifname (read-only) -> s
>
> Can we just add the Ifindex for completion here.
>
> > P: Driver (read-only) -> s
> > P: Bridge-ifname (read-only) -> s
> > P: Level (read/write) -> u
>
> What is Level. It is not intuitive.
>
> > P: Timestamp (read/write) -> b
> > P: Show_keys (read/write) -> b
> > P: Blobs (read-only) ->ao
> > P: Bsss (read-only) -> ao
> > P: Networks (read-only) -> ao
> >
> > M: Scan (args a{sv})
> > args: Type -> s [active, passive]
> > SSIDs -> aay array of (SSID)
> > IEs -> aay array of (IE)
> > Channels -> a(uu) array of (center freq in KHz, width)
> >
> > E: fi.w1.wpa_supplicant1.Interface.ScanDenied
> > fi.w1.wpa_supplicant1.Interface.ScanError
> > fi.w1.wpa_supplicant1.InvalidArgs
> >
> > M: Disconnect
> > E: fi.w1.wpa_supplicant1.Interface.NotConnected
> >
> > M: AddNetwork (args a{sv}) -> o
> > args: <dict of network properties, see
> > fi.w1.wpa_supplicant1.Interface.Network>
> >
> > M: RemoveNetwork (path o)
> > E: fi.w1.wpa_supplicant1.Interface.NetworkUnknown
> >
> > M: SelectNetwork (path o)
> > E: fi.w1.wpa_supplicant1.Interface.NetworkUnknown
> >
> > M: AddBlob (name s, data ay) -> o
> > E: fi.w1.wpa_supplicant1.Interface.BlobExists
> > E: fi.w1.wpa_supplicant1.UnknownError
> >
> > M: RemoveBlob (path o)
> > E: fi.w1.wpa_supplicant1.Interface.BlobUnknown
> >
> > S: PropertiesChanged -> properties a{sv}
> > S: ScanDone -> success b
> > S: StateChanged -> new_state s, old_state s
> > S: BssAdded -> path o
> > S: BssRemoved -> path o
> > S: BlobAdded -> path o
> > S: BlobRemoved -> path o
> >
> > There were missing these signals in original Dan's proposal:
> > S: NetworkAdded, -> path o
> > S: NetworkRemoved -> path o
> > S: NetworkSelected -> path o
> >
> > ****************************************
> >
> > O: /fi/w1.wpa_supplicant1/Interfaces/<interface_number>
> > I: fi.w1.wpa_supplicant1.Interface.WPS
> >
> > M: Start (args a{sv}) -> a{sv}
> > args: Role -> s [enrollee, registrar]
> > Type -> a [pin, pbc]
> > Bssid -> ay (optional)
> > Pin -> s (optional)
> > Returns:
> > Pin -> s (autogenerated PIN if not specified in
args)
> > P: Credentials (read-only) -> a{sv}
> > BSSID -> ay
> > SSID -> ay
> > AuthType -> as [open, shared, wpa-psk,
> > wpa-eap, wpa2-eap, wpa2-psk]
> > EncrType -> as [none, wep, tkip, aes]
> > Key -> ay byte-array of key data
> > KeyIndex -> u
> > P: ProcessCredentials (read/write) -> b (TRUE ==
> > wps_cred_processing=2, FALSE == wps_cred_processing=1)
> > S: PropertiesChanged -> a{sv}
> > S: Event -> name s, args a{sv}
> >
> > ****************************************
> >
> > O:
> >
/fi/w1.wpa_supplicant1/Interfaces/<interface_number>/Networks/<network_n
umber>
> > I: fi.w1.wpa_supplicant1.Interface.Network
> >
> > P: Enabled (read/write) -> b
> > P: <wpa_supplicant network block properties> (read/write) -> a{sv}
> > - Most properties can be set as strings, but can also be set
> > as a byte array if necessary (SSID, BSSID, PSK, etc).
Supplicant
> > can autoconvert like it does right now.
> >
> > S: PropertiesChanged -> a{sv}
>
> So what is the difference between Enabled and SelectNetwork() call.
This
> differentiation confused the hell out of me already with the current
> code. Why do we bother here at all.
>
> Lets just use SelectNetwork() to switch between networks and forget
> about Enabled stuff. If some network should not be in the list, then
> just lets use RemoveNetwork().
If we were to just use SelectNetwork(), how would we completely
disconnect the supplicant and tell it to stop doing anything? We could
make SelectNetwork with a blank object path do that for us.
BTW, enabled/disabled is what allows the supplicant to make the roaming
decisions for us, so while it doesn't get used by NM right *now*, maybe
we want to push that sort of thing to the supplicant in the future.
Currently NM only enables one network at a time.
Dan
> > ****************************************
> >
> > O:
/fi/w1.wpa_supplicant1/Interfaces/<interface_number>/Blobs/<blob_name>
> > I: fi.w1.wpa_supplicant1.Interface.Blob
> >
> > P: Name (read-only) -> s
> > P: Data (read-only) -> ay
> >
> > ****************************************
> >
> > O: /fi/w1.wpa_supplicant1/Interfaces/<interface_number>/BSSs/<BSSID>
> > I: fi.w1.wpa_supplicant1.Interface.BSS
> >
> > P: <BSS properties - identical to current BSSID properties>
(read-only)
> >
> > ****************************************
>
> Looks good after a really quick review.
>
> Regards
>
> Marcel
>
>
------------------------------
Message: 6
Date: Tue, 16 Jun 2009 23:59:21 +0300
From: "Chuck Tuffli" <Chuck.Tuffli at dspg.com>
Subject: RE: Help with wireless disassociation
To: <hostap at lists.shmoo.com>
Message-ID: <5EFF534737810441B0F97C2792E49C2D3B9CD0 at ILMAIL01.dspg.com>
Content-Type: text/plain; charset="us-ascii"
> -----Original Message-----
> From: hostap-bounces at lists.shmoo.com
> [mailto:hostap-bounces at lists.shmoo.com] On Behalf Of Jouni Malinen
...
> You could make the driver send out empty data nullfunc frames
> (assuming it supports sending arbitrary frames) if you want
> to minimize size of the transmitted frames. However, it is
> not sure whether the AP would count those as activity as far
> as the inactivity timeout is concerned.
I'll second Jouni's suggestion. We've had success sending Data Null
packets from within the device driver to keep APs from disconnecting.
---chuck
______________________________________________________________________
DSP Group, Inc. automatically scans all emails and attachments using
MessageLabs Email Security System.
_____________________________________________________________________
------------------------------
Message: 7
Date: Tue, 16 Jun 2009 23:16:04 +0200
From: Marcel Holtmann <marcel at holtmann.org>
Subject: Re: New wpa_supplicand dbus API proposal
To: Dan Williams <dcbw at redhat.com>
Cc: Jouni Malinen <j at w1.fi>, hostap at lists.shmoo.com
Message-ID: <1245186964.15367.30.camel at violet>
Content-Type: text/plain
Hi Dan,
> > > O:
> > >
/fi/w1.wpa_supplicant1/Interfaces/<interface_number>/Networks/<network_n
umber>
> > > I: fi.w1.wpa_supplicant1.Interface.Network
> > >
> > > P: Enabled (read/write) -> b
> > > P: <wpa_supplicant network block properties> (read/write) -> a{sv}
> > > - Most properties can be set as strings, but can also be set
> > > as a byte array if necessary (SSID, BSSID, PSK, etc).
Supplicant
> > > can autoconvert like it does right now.
> > >
> > > S: PropertiesChanged -> a{sv}
> >
> > So what is the difference between Enabled and SelectNetwork() call.
This
> > differentiation confused the hell out of me already with the current
> > code. Why do we bother here at all.
> >
> > Lets just use SelectNetwork() to switch between networks and forget
> > about Enabled stuff. If some network should not be in the list, then
> > just lets use RemoveNetwork().
>
> If we were to just use SelectNetwork(), how would we completely
> disconnect the supplicant and tell it to stop doing anything? We
could
> make SelectNetwork with a blank object path do that for us.
yeah and that is not gonna work out. D-Bus doesn't allow an empty object
path.
> BTW, enabled/disabled is what allows the supplicant to make the
roaming
> decisions for us, so while it doesn't get used by NM right *now*,
maybe
> we want to push that sort of thing to the supplicant in the future.
> Currently NM only enables one network at a time.
So personally I think every network we add is part of our roaming
agreement. If we don't want it anymore, we have to remove the network
again. That way we keep it simple.
Maybe we should not have a SelectNetwork at all. Just add/remove
networks and then have a global on/off switch on the Interface
interface.
Regards
Marcel
------------------------------
_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap
End of HostAP Digest, Vol 74, Issue 16
**************************************
More information about the Hostap
mailing list