WPA in ad-hoc mode with carl9170

WPA in ad-hoc mode with carl9170

[Ignacy Gawedzki]

Hi,

I've been trying to setup WPA using wpa_supplicant in an ad-hoc network,
specifically using AR9170 USB interfaces with the carl9170 driver and
firmware.

Although wpa_supplicant is supposed to be able to setup a single shared group
key for all communications, it appears at least the broadcast traffic is
neither enciphered at the sending end nor received at the receiving end
(tested with both TKIP and CCMP).

I was wondering whether this is supposed to work or it is just too soon.  If
there's anything that I could do to contribute, I'd be happy to help.

Thanks.

Ignacy

-- 
Sex on TV doesn't hurt....unless you fall off.

Re: WPA in ad-hoc mode with carl9170

[Brian Prodoehl]

On Fri, May 13, 2011 at 12:01 PM, Ignacy Gawedzki <i@lri.fr> wrote:
> Hi,
>
> I've been trying to setup WPA using wpa_supplicant in an ad-hoc network,
> specifically using AR9170 USB interfaces with the carl9170 driver and
> firmware.
>
> Although wpa_supplicant is supposed to be able to setup a single shared group
> key for all communications, it appears at least the broadcast traffic is
> neither enciphered at the sending end nor received at the receiving end
> (tested with both TKIP and CCMP).
>
> I was wondering whether this is supposed to work or it is just too soon.  If
> there's anything that I could do to contribute, I'd be happy to help.
>
> Thanks.
>
> Ignacy

Have you tested only with hw crypto?  Try passing the nohwcrypt param
to the module while loading.

-Brian

Re: WPA in ad-hoc mode with carl9170

[Ignacy Gawedzki]

On Fri, May 13, 2011 at 12:39:53PM -0400, thus spake Brian Prodoehl:
> Have you tested only with hw crypto?  Try passing the nohwcrypt param
> to the module while loading.

I just tried that and at first it seemed to make no difference.  But at some
point, one of the two nodes of my testbed started to send encrypted frames
(both broadcast and unicast) and the other node could receive them okay.

Unfortunately, I just can't make the other node work (the difference being it
is a x86_64 netbook vs. an i386 embedded atom industrial PC for the first
node).

Next week, I'll hopefully have more time to investigate and find a repeatable
procedure to make that work or break.  My preliminary tests show that setting
the nohwcrypt option makes no difference.

Thanks for the hint anyway.

Ignacy

-- 
A person is shit's way of making more shit.
		-- S. Barnett, anthropologist.

Re: WPA in ad-hoc mode with carl9170

[Christian Lamparter]

On Friday 13 May 2011 19:40:41 Ignacy Gawedzki wrote:
> On Fri, May 13, 2011 at 12:39:53PM -0400, thus spake Brian Prodoehl:
> > Have you tested only with hw crypto?  Try passing the nohwcrypt param
> > to the module while loading.
> 
> I just tried that and at first it seemed to make no difference.  But at some
> point, one of the two nodes of my testbed started to send encrypted frames
> (both broadcast and unicast) and the other node could receive them okay.
> 
> Unfortunately, I just can't make the other node work (the difference being it
> is a x86_64 netbook vs. an i386 embedded atom industrial PC for the first
> node).
> 
> My preliminary tests show that setting the nohwcrypt option makes no difference.
not too surprising, the driver does not set IEEE80211_HW_SUPPORTS_PER_STA_GTK.
Therefore the software crypto is always used in this case. 

Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key
cache controller to do the "key security settings" lookup with addr2 for all
bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the
per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into
the per-sta space [0-63?]] we should be able to enable PER_STA_GTK...
although the driver will be restricted to a single vif [I think].

> Next week, I'll hopefully have more time to investigate and find a repeatable
> procedure to make that work or break.
you should try your setup with mac80211_hwsim first [so we can rule out all
driver bugs].

Regards,
	Chr
 

Re: WPA in ad-hoc mode with carl9170

[Christian Lamparter]

On Friday 13 May 2011 22:31:47 Christian Lamparter wrote:
> On Friday 13 May 2011 19:40:41 Ignacy Gawedzki wrote:
> > On Fri, May 13, 2011 at 12:39:53PM -0400, thus spake Brian Prodoehl:
> > > Have you tested only with hw crypto?  Try passing the nohwcrypt param
> > > to the module while loading.
> > 
> > I just tried that and at first it seemed to make no difference.  But at some
> > point, one of the two nodes of my testbed started to send encrypted frames
> > (both broadcast and unicast) and the other node could receive them okay.
> > 
BTW: I hope your compat-wireless/wireless-testing.git is up to date. 
Nicolas Cavallari <Nicolas.Cavallari@lri.fr> has submitted a fix for
his ad-hoc setup recently, see: "carl9170: fix allmulticast mode".

Regards,
	Chr

Re: WPA in ad-hoc mode with carl9170

[Ignacy Gawedzki]

On Fri, May 13, 2011 at 11:30:28PM +0200, thus spake Christian Lamparter:
> BTW: I hope your compat-wireless/wireless-testing.git is up to date. 
> Nicolas Cavallari <Nicolas.Cavallari@lri.fr> has submitted a fix for
> his ad-hoc setup recently, see: "carl9170: fix allmulticast mode".

I'm using the compat-wireless tarballs as much up-to-date as possible.  Same
for carl9170 firmware.  As for Nicolas' patch, I got it even before he
submitted it for your attention. =)

-- 
To err is human, to purr feline.

Re: WPA in ad-hoc mode with carl9170

[Ignacy Gawedzki]

On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter:
> Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key
> cache controller to do the "key security settings" lookup with addr2 for all
> bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the
> per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into
> the per-sta space [0-63?]] we should be able to enable PER_STA_GTK...
> although the driver will be restricted to a single vif [I think].

If I understand correctly, by PER_STA_GTK you mean a different encryption key
for each one-hop neighbor.  It happens to be unnecessary in my case as one
"ad-hoc-global" encryption key would be enough.

> you should try your setup with mac80211_hwsim first [so we can rule out all
> driver bugs].

Good idea indeed.  I'll do that as soon as possible.

Thanks.

-- 
NO CARRIER

Re: WPA in ad-hoc mode with carl9170

[Christian Lamparter]

On Saturday 14 May 2011 00:21:41 Ignacy Gawedzki wrote:
> On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter:
> > Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key
> > cache controller to do the "key security settings" lookup with addr2 for all
> > bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the
> > per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into
> > the per-sta space [0-63?]] we should be able to enable PER_STA_GTK...
> > although the driver will be restricted to a single vif [I think].
> 
> If I understand correctly, by PER_STA_GTK you mean a different encryption key
> for each one-hop neighbor.  It happens to be unnecessary in my case as one
> "ad-hoc-global" encryption key would be enough.
yes, but AFAIK that's not how it works. There's no "global" encryption key see
802.11-2007 8.4.9 RSNA key management in an IBSS: 
"Each Authenticator generates its own GTK and uses either the 4-Way Handshake
or Group Key Handshake to transfer the GTK to other STAs with whom it has
completed a 4-Way Handshake."
 
Regards,
	Chr

Re: WPA in ad-hoc mode with carl9170

[Ignacy Gawedzki]

On Sat, May 14, 2011 at 01:13:09AM +0200, thus spake Christian Lamparter:
> On Saturday 14 May 2011 00:21:41 Ignacy Gawedzki wrote:
> > On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter:
> > > Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key
> > > cache controller to do the "key security settings" lookup with addr2 for all
> > > bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the
> > > per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into
> > > the per-sta space [0-63?]] we should be able to enable PER_STA_GTK...
> > > although the driver will be restricted to a single vif [I think].
> > 
> > If I understand correctly, by PER_STA_GTK you mean a different encryption key
> > for each one-hop neighbor.  It happens to be unnecessary in my case as one
> > "ad-hoc-global" encryption key would be enough.
> yes, but AFAIK that's not how it works. There's no "global" encryption key see
> 802.11-2007 8.4.9 RSNA key management in an IBSS: 
> "Each Authenticator generates its own GTK and uses either the 4-Way Handshake
> or Group Key Handshake to transfer the GTK to other STAs with whom it has
> completed a 4-Way Handshake."

Okay, I suppose I didn't understand correctly after all.  What you mean by
PER_STA_GTK is a different *decryption* key per station (one-hop neighbor),
right?  The encryption key is the GTK and any receiving station supposed to be
able to decrypt the frames must have gone through the 4-way handshake with the
sending station somehow.

In my case, it would be nice to be able to tell the driver to use the
encryption key for decryption as well and bypass the need to go through the
handshake.  But I assume this is not something worth implementing if it's not
there already and not specified by the standard anyway.

-- 
 "The whole problem with the world is that fools and fanatics are
   always so certain of themselves, and wiser people so full of doubts."
                                                 - Bertrand Russell

Re: WPA in ad-hoc mode with carl9170

[Christian Lamparter]

On Saturday 14 May 2011 11:41:02 Ignacy Gawedzki wrote:
> On Sat, May 14, 2011 at 01:13:09AM +0200, thus spake Christian Lamparter:
> > On Saturday 14 May 2011 00:21:41 Ignacy Gawedzki wrote:
> > > On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter:
> > > > Note: there's a special bit [RX_MAC_CONTROL - bit 6] which instructs the key
> > > > cache controller to do the "key security settings" lookup with addr2 for all
> > > > bc/mc frames. If we enable this bit and modify carl9170_op_set_key to set the
> > > > per station gtk correctly [i.e.: use sta->addr as MAC and put the keys into
> > > > the per-sta space [0-63?]] we should be able to enable PER_STA_GTK...
> > > > although the driver will be restricted to a single vif [I think].
> > > 
> > > If I understand correctly, by PER_STA_GTK you mean a different encryption key
> > > for each one-hop neighbor.  It happens to be unnecessary in my case as one
> > > "ad-hoc-global" encryption key would be enough.
> > yes, but AFAIK that's not how it works. There's no "global" encryption key see
> > 802.11-2007 8.4.9 RSNA key management in an IBSS: 
> > "Each Authenticator generates its own GTK and uses either the 4-Way Handshake
> > or Group Key Handshake to transfer the GTK to other STAs with whom it has
> > completed a 4-Way Handshake."
> 
> Okay, I suppose I didn't understand correctly after all.  What you mean by
> PER_STA_GTK is a different *decryption* key per station (one-hop neighbor),
> right?  The encryption key is the GTK and any receiving station supposed to be
> able to decrypt the frames must have gone through the 4-way handshake with the
> sending station somehow.
> 
> In my case, it would be nice to be able to tell the driver to use the
> encryption key for decryption as well and bypass the need to go through the
> handshake.  But I assume this is not something worth implementing if it's not
> there already and not specified by the standard anyway.
Oh, don't let the "RX_MAC_CONTROL" fool you, this is just Atheros' name
for the register. They really say "Setting this bit instructs the Key Cache controller
to send address2 of multicast/broadcast frames to be searched for user and
key security settings". If it would only affect decryption, the would have written
"*RxMac* Key Cache controller" instead... or Stephen, can you comment on this?
[We are talking about Address: 0x1c3c40 - Bit 6] 

Regards,
	Christian

Re: WPA in ad-hoc mode (was: ...with carl9170)

[Ignacy Gawedzki]

On Sat, May 14, 2011 at 12:21:41AM +0200, thus spake Ignacy Gawedzki:
> On Fri, May 13, 2011 at 10:31:47PM +0200, thus spake Christian Lamparter:
> > you should try your setup with mac80211_hwsim first [so we can rule out all
> > driver bugs].
> 
> Good idea indeed.  I'll do that as soon as possible.

Hi again,

I just tried the following:

  Compile and set up mac80211_hwsim from latest compat-wireless (which did not
  go without some hacking, see below).

  Run wpa_supplicant with the following configuration file on both interfaces:

    ap_scan=2
    network={
      ssid="Test1"
      mode=1
      proto=WPA
      key_mgmt=WPA-NONE
      pairwise=NONE
      group=CCMP
      psk="testtesttest"
    }

  Set addresses with /32 prefixes on both interfaces.

  Run ping using -I to bind to one interface and the address of the other as
  destination.

  Run wireshark on hwsim0 to look at what's going on.

I had to force the same BSSID on both interfaces as they tended to create
separate ones.  After that, it appears wpa_supplicant manages to set the keys
correctly:

  Associated to a new BSS: BSSID=00:00:00:00:00:01
  Select network based on association information
  Network configuration found for the current AP
  WPA: Using WPA IE from AssocReq to set cipher suites
  WPA: Selected cipher suites: group 16 pairwise 1 key_mgmt 16 proto 1
  WPA: clearing AP WPA IE
  WPA: clearing AP RSN IE
  WPA: using GTK CCMP
  WPA: using PTK NONE
  WPA: using KEY_MGMT WPA-NONE
  WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50
  f2 04 01 00 00 50 f2 00 01 00 00 50 f2 00
  EAPOL: External notification - EAP success=0
  EAPOL: External notification - EAP fail=0
  EAPOL: External notification - portControl=ForceAuthorized
  Associated with 00:00:00:00:00:01
  WPA: Association event - clear replay counter
  WPA: Clear old PTK
  EAPOL: External notification - portEnabled=0
  EAPOL: SUPP_PAE entering state DISCONNECTED
  EAPOL: Supplicant port status: Unauthorized
  EAPOL: SUPP_BE entering state INITIALIZE
  EAPOL: Supplicant port status: Unauthorized
  EAPOL: External notification - portValid=0
  EAPOL: Supplicant port status: Unauthorized
  EAPOL: External notification - portEnabled=1
  EAPOL: SUPP_PAE entering state S_FORCE_AUTH
  EAPOL: Supplicant port status: Authorized
  EAPOL: SUPP_BE entering state IDLE
  Cancelling authentication timeout
  State: ASSOCIATED -> COMPLETED
  CTRL-EVENT-CONNECTED - Connection to 00:00:00:00:00:01 completed (reauth)
  [id=0 id_str=]
  wpa_driver_wext_set_operstate: operstate 0->1 (UP)
  netlink: Operstate: linkmode=-1, operstate=6
  Cancelling scan request
  RTM_NEWLINK: operstate=1 ifi_flags=0x11003 ([UP][LOWER_UP])
  netlink: Operstate: linkmode=-1, operstate=6
  RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added
  RTM_NEWLINK: operstate=1 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
  RTM_NEWLINK, IFLA_IFNAME: Interface 'wlan0' added

Same thing on the other interface.

Running ping generates ARP requests, visible in cleartext on hwsim0, which I
suppose is unexpected.  Even if I populate the ARP table by hand (using ip
neigh), the echo requests are visible in cleartext on hwsim0.

By running tcpdump on both interfaces, I can tell that the frames are
discarded on the receiving end (both the broadcast ARP requests and the
unicast echo requests).

Am I doing something wrong or is there a real problem with WPA in ad-hoc mode
regardless of the driver?

As for the hacking I had to do to make mac80211_hwsim work, it is related to
the recent removal of dev_alloc_name() calls, among others in
net/mac80211/iface.c's ieee80211_if_add().  Any new interface ends up being
actually called wlan%d, which in the case of mac80211_hwsim, which creates
more than one interface, leads to clashes (only the first wlan%d is created
successfully).  I'm running kernel 2.6.38-9-generic from Ubuntu, which
obviously lacks what it takes to rename interfaces properly otherwise.

Regards,

Ignacy

-- 
Information wants to be beer, or something like that.