how to configure WEP with shared password

Li Jin ljin
Thu Sep 26 16:02:06 PDT 2013


Hi Jouni,

Thanks for your reply! I am using nl80211 driver and from log I can see that in function wpa_driver_nl80211_set_ap, the following routine is being called. 
NLA_PUT_FLAG(msg, NL80211_ATTR_PRIVACY);

However when I checked the beacon frame from wireshark capture, the privacy bit (wlan_mgt.fixed.capabilities.privacy) is set to 0. Does that mean my wifi driver doesn't set the bit correctly?
The other setting from printf in function wpa_driver_nl80211_set_ap  are "params->auth_algs=2, params->key_mgmt_suites=2, params->pairwise_ciphers=2" and I assume they are okay?

Thanks
Li

-----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: Thursday, September 26, 2013 12:38 PM
To: hostap at lists.shmoo.com
Subject: HostAP Digest, Vol 125, Issue 31

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: how to configure WEP with shared password (Jouni Malinen)
   2. Re: wpa_supplicant segfault in large WLAN (Ben Greear)
   3. Re: wpa_supplicant segfault in large WLAN (Matt Causey)
   4. Re: wpa_supplicant segfault in large WLAN (Jouni Malinen)
   5. Re: wpa_supplicant segfault in large WLAN (Ben Greear)
   6. Re: wpa_supplicant segfault in large WLAN (Jouni Malinen)


----------------------------------------------------------------------

Message: 1
Date: Thu, 26 Sep 2013 22:05:06 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: how to configure WEP with shared password
To: hostap at lists.shmoo.com
Message-ID: <20130926190506.GB17041 at w1.fi>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 26, 2013 at 04:50:48PM +0000, Li Jin wrote:
> I tried the following configuration without HT capability specified. However the AP still shows up as OPEN. Anything else I might missed?
> 
> interface=wlan0
> ctrl_interface=/opt/wifi/hostapd
> ssid=Android
> channel=6
> auth_algs=2
> wep_default_key=0
> wep_key0=123456789a
> wep_key1="vwxyz"
> wep_key2=0102030405060708090a0b0c0d
> wep_key3=".2.4.6.8.0.23"
> bridge=br0

Are you sure the driver you are using supports Shared Key
authentication? This configuration works fine in my tests with the AP
coming up with Privacy=1 in Beacon/Probe Response frames and Shared Key
authentication with matching WEP key needed to complete authentication
exchange.

-- 
Jouni Malinen                                            PGP id EFC895FA


------------------------------

Message: 2
Date: Thu, 26 Sep 2013 12:06:09 -0700
From: Ben Greear <greearb at candelatech.com>
Subject: Re: wpa_supplicant segfault in large WLAN
To: Matt Causey <matt.causey at gmail.com>
Cc: "hostap at lists.shmoo.com" <hostap at lists.shmoo.com>
Message-ID: <524485A1.9000803 at candelatech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/26/2013 12:03 PM, Matt Causey wrote:
> Another detail that may or may not be of interest is that most of these access points are 4x4:3 APs - which may or may not affect what's in the IE on the beacons.

What chipset, if I may ask?  Might want to get some to play with :)


>     /**
>       * wpa_bss_get_vendor_ie - Fetch a vendor information element from a BSS entry
>       * @bss: BSS table entry
>       * @vendor_type: Vendor type (four octets starting the IE payload)
>       * Returns: Pointer to the information element (id field) or %NULL if not found
>       *
>       * This function returns the first matching information element in the BSS
>       * entry.
>       */
>     const u8 * wpa_bss_get_vendor_ie(const struct wpa_bss *bss, u32 vendor_type)
>     {
>          const u8 *end, *pos;
>
>          pos = (const u8 *) (bss + 1);
>          end = pos + bss->ie_len;
>
>          while (pos + 1 < end) {
>              if (pos + 2 + pos[1] > end)   <--------  **LINE 912**
>                  break;

Use gdb to print out *bss, pos, end.

Looks like something is probably walking off the end of the bss info
I'd guess.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



------------------------------

Message: 3
Date: Thu, 26 Sep 2013 15:15:47 -0400
From: Matt Causey <matt.causey at gmail.com>
Subject: Re: wpa_supplicant segfault in large WLAN
To: Ben Greear <greearb at candelatech.com>
Cc: "hostap at lists.shmoo.com" <hostap at lists.shmoo.com>
Message-ID:
	<CAGnc4p_RvQeYnBAh2XivR97rSAxFgBCD=7gjx=XCdSTprq8H6w at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

On Thu, Sep 26, 2013 at 3:06 PM, Ben Greear <greearb at candelatech.com> wrote:

> On 09/26/2013 12:03 PM, Matt Causey wrote:
>
>> Another detail that may or may not be of interest is that most of these
>> access points are 4x4:3 APs - which may or may not affect what's in the IE
>> on the beacons.
>>
>
> What chipset, if I may ask?  Might want to get some to play with :)


>
>
>      /**
>>       * wpa_bss_get_vendor_ie - Fetch a vendor information element from a
>> BSS entry
>>       * @bss: BSS table entry
>>       * @vendor_type: Vendor type (four octets starting the IE payload)
>>       * Returns: Pointer to the information element (id field) or %NULL
>> if not found
>>       *
>>       * This function returns the first matching information element in
>> the BSS
>>       * entry.
>>       */
>>     const u8 * wpa_bss_get_vendor_ie(const struct wpa_bss *bss, u32
>> vendor_type)
>>     {
>>          const u8 *end, *pos;
>>
>>          pos = (const u8 *) (bss + 1);
>>          end = pos + bss->ie_len;
>>
>>          while (pos + 1 < end) {
>>              if (pos + 2 + pos[1] > end)   <--------  **LINE 912**
>>                  break;
>>
>
> Use gdb to print out *bss, pos, end.
>
> Looks like something is probably walking off the end of the bss info
> I'd guess.
>
>
> Thanks for the hand-holding, Ben - this is a great learning experience for
me.  :-)  here's the data:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb73ae6c0 (LWP 5452)]
wpa_bss_get_vendor_ie (bss=0x8ada590, vendor_type=5304833) at bss.c:912
912    bss.c: No such file or directory.
    in bss.c
(gdb) bt
#0  wpa_bss_get_vendor_ie (bss=0x8ada590, vendor_type=5304833) at bss.c:912
#1  0x08086de9 in wpas_select_network_from_last_scan (wpa_s=0x8a87468) at
events.c:645
#2  0x08087e23 in _wpa_supplicant_event_scan_results (wpa_s=0x8a87468,
data=0xa) at events.c:1186
#3  0x08087ed3 in wpa_supplicant_event_scan_results (wpa_s=0x8ae7000,
data=0x0) at events.c:1269
#4  0x0808893d in wpa_supplicant_event (ctx=0x8a87468,
event=EVENT_SCAN_RESULTS, data=0xbfce7d48) at events.c:2438
#5  0x08099371 in send_scan_event (drv=0x8a87fb8, aborted=145535476,
tb=0xbfce8660) at ../src/drivers/driver_nl80211.c:1679
#6  0x08099d4b in do_process_drv_event (bss=0x8a880ac, cmd=34,
tb=0xbfce8660) at ../src/drivers/driver_nl80211.c:2201
#7  0x0809a4fc in process_global_event (msg=0x8a8b4c8, arg=0x8a87f00) at
../src/drivers/driver_nl80211.c:2346
#8  0xb76fe47c in nl_cb_call () from /usr/local/lib/libnl.so.1
#9  0xb76feb7a in nl_recvmsgs () from /usr/local/lib/libnl.so.1
#10 0x08055173 in eloop_sock_table_dispatch (table=0x80b8bc8,
fds=0x8a932e0) at ../src/utils/eloop.c:393
#11 0x08055a08 in eloop_run () at ../src/utils/eloop.c:769
#12 0x0808163e in wpa_supplicant_run (global=0x8a87388) at
wpa_supplicant.c:3322
#13 0x0808cc94 in main (argc=Cannot access memory at address 0x8ae6fff
) at main.c:297
(gdb) print bss
$1 = (const struct wpa_bss *) 0x8ada590
(gdb) print pos
$2 = (const u8 *) 0x8ae6fff ""
(gdb) print end
$3 = (const u8 *) 0x8b38315 <Address 0x8b38315 out of bounds>
(gdb)

--
Matt



>
>
>
> --
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.shmoo.com/pipermail/hostap/attachments/20130926/e7b56b38/attachment-0001.htm>

------------------------------

Message: 4
Date: Thu, 26 Sep 2013 22:19:02 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: wpa_supplicant segfault in large WLAN
To: Matt Causey <matt.causey at gmail.com>
Cc: Ben Greear <greearb at candelatech.com>,	"hostap at lists.shmoo.com"
	<hostap at lists.shmoo.com>
Message-ID: <20130926191902.GA17847 at w1.fi>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 26, 2013 at 02:45:55PM -0400, Matt Causey wrote:
> >> sudo gdb wpa_supplicant
> >> Program received signal SIGSEGV, Segmentation fault.
> >> [Switching to Thread 0xb73dc6c0 (LWP 16180)]
> >> wpa_bss_get_vendor_ie (bss=0x87c0a40, vendor_type=5304833) at bss.c:912

> Referencing wpa_supplicant-2.0, which we're using unmodified, here's the
> function:

> const u8 * wpa_bss_get_vendor_ie(const struct wpa_bss *bss, u32 vendor_type)
> {
>     const u8 *end, *pos;
> 
>     pos = (const u8 *) (bss + 1);
>     end = pos + bss->ie_len;
> 
>     while (pos + 1 < end) {
>         if (pos + 2 + pos[1] > end)   <--------  **LINE 912**
>             break;

Interesting.. I cannot find an issue here, so I'd assume the BSS entry
got somehow corrupted and this just happens to be the first place where
that corruption trigger a clearly visible error.

Would you be able to run wpa_supplicant under valgrind (sudo valgrind
./wpa_supplicant ...)? It could make it easier to find where the
corruption really happens for the first time.

It could also be useful to print bss->ie_len in that
wpa_bss_get_vendor_ie() function.

Alternatively or in addition to that, I'd be interested in seeing a full
wpa_supplicant debug log from start to the segfault point with as much
verbosity as possible (i.e., -ddd on command line). This will be large,
but it will include all the IE buffers from scan results, so it should
give pretty clear sign if something is really going wrong in parsing the
information. If you can send this, feel free to just email it directly
to me (compressed version preferred taken into account how large this
is likely to be) since the mailing list is not going to accept that long
a file.

-- 
Jouni Malinen                                            PGP id EFC895FA


------------------------------

Message: 5
Date: Thu, 26 Sep 2013 12:28:26 -0700
From: Ben Greear <greearb at candelatech.com>
Subject: Re: wpa_supplicant segfault in large WLAN
To: Matt Causey <matt.causey at gmail.com>
Cc: "hostap at lists.shmoo.com" <hostap at lists.shmoo.com>
Message-ID: <52448ADA.6020002 at candelatech.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 09/26/2013 12:15 PM, Matt Causey wrote:

> (gdb) print bss
> $1 = (const struct wpa_bss *) 0x8ada590

Try this:

print *bss

The * is important, should print out the bss struct members' values.

> (gdb) print pos
> $2 = (const u8 *) 0x8ae6fff ""
> (gdb) print end
> $3 = (const u8 *) 0x8b38315 <Address 0x8b38315 out of bounds>

As Jouni said, it does look corrupted...end seems way too much bigger
than pos.

You can also try moving to a different stack frame, finding the pertinent
source code, and printing out interesting variables.

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



------------------------------

Message: 6
Date: Thu, 26 Sep 2013 22:37:51 +0300
From: Jouni Malinen <j at w1.fi>
Subject: Re: wpa_supplicant segfault in large WLAN
To: Matt Causey <matt.causey at gmail.com>
Cc: Ben Greear <greearb at candelatech.com>,	"hostap at lists.shmoo.com"
	<hostap at lists.shmoo.com>
Message-ID: <20130926193751.GA18487 at w1.fi>
Content-Type: text/plain; charset=us-ascii

On Thu, Sep 26, 2013 at 03:15:47PM -0400, Matt Causey wrote:
> (gdb) print bss
> $1 = (const struct wpa_bss *) 0x8ada590
> (gdb) print pos
> $2 = (const u8 *) 0x8ae6fff ""
> (gdb) print end
> $3 = (const u8 *) 0x8b38315 <Address 0x8b38315 out of bounds>

Lovely. This was indeed corruption somewhere else like I assumed.
bss->ie_len is something in the neighborhood of 375 kB. Things crashed
when reading about 50 kB into it.. ;-)  So yes, obviously that ie_len is
not correct. The difficult part is in figuring out when it become
incorrect, though. valgrind could help, but not necessarily.

-- 
Jouni Malinen                                            PGP id EFC895FA


------------------------------

_______________________________________________
HostAP mailing list
HostAP at lists.shmoo.com
http://lists.shmoo.com/mailman/listinfo/hostap


End of HostAP Digest, Vol 125, Issue 31
***************************************





More information about the Hostap mailing list