[patch] WPS: hostapd fails to proxy registrations with Intel ext. registrar

[Andriy Tkachuk]

Jouni,

I used here the Intel card and SW (driver & Intel PROSet application)
versions from WFA testbed...

Unfortunately I dropped logs already. I had to add my custom logs into
xml_get_first_item() routine in order to find the root cause. Anyway, I
have standard logs, which didn't help me enough though. After Enrollee
sent M1 to us and we forwarded it to Intel registrar, we got reply from
it, the parsing of which failed:

1269872027.309206: WPS UPnP: Got HTTP request type 4 from 192.168.1.111:60057
1269872027.309228: WPS UPnP: PutWLANResponse
1269872027.309259: WPS UPnP: POST failure ret=600

This failure, as appeared, happened on parsing the NewWLANEventMAC value
in web_process_put_wlan_response() here:

        val = xml_get_first_item(data, "NewWLANEventMAC");
        if (val == NULL || hwaddr_aton(val, macaddr)) {
                wpabuf_free(msg);
                os_free(val);
                return UPNP_ARG_VALUE_INVALID;
        }

Thank you,
    Andriy

On 2010-03-30 18:04, Jouni Malinen wrote:
> On Tue, Mar 30, 2010 at 05:08:37PM +0300, Andriy Tkachuk wrote:
>
>   
>> It appeared that clients can't enroll to the AP when hostapd works as
>> proxy and Intel is used as external wireless registrar. In particular
>> this affects the 4.2.3 test case from WFA WPS testplan. Debugging it
>> reveled that Intel sends the MAC address in non standard format (in
>> NewWLANEventMAC UPnP xml tag). The bytes in address are separated with
>> dots instead of colons, for example, like 00.aa.bb.cc.dd.ee (instead of
>> 00:aa:bb:cc:dd:ee, as it should be according to WFA WLANConfig 1_0
>> Template 1_01.pdf spec). The following patch, that makes hwaddr_aton()
>> routine more tolerant for address format, fixes the issue:
>>     
>
> I don't think this is a bug in hostapd or that this would "fix" the
> issue (the other end using incorrect format). It may be necessary to
> work around that issue, but in that case, I would prefer to not change
> hwaddr_aton() but instead, add another version of this in the WPS code
> with a clear comment on why it is there. I want to be able to build a
> version of hostapd that will strictly verify that WPS was implemented
> correctly by the other end and this type of change is just hiding the
> problems in a way that make it more difficult.
>
> Would you be able to send a debug log from hostapd showing this issue? I
> remember there being problems with some of the UPnP values having
> incorrect values (i.e., completely incorrect MAC address) in this area
> and I thought I added a workaround for it. Maybe that only avoids the
> issue where the address itself is incorrect, but still in correct
> format(?).
>
>