[PATCH 18/19] P2PS: add a wildcard with other advertised service info

[Stepanov, Max]

>From: Jouni Malinen [mailto:j at w1.fi]
>Sent: Thursday, June 18, 2015 20:02
>
>I pushed in number of fixes to this behavior and some cleanup as well.
>I think the current behavior matches the P2PS specification. Anyway,
>additional review of those changes is obviously welcome.
>

>P2PS: Fix P2P_FIND seek parameter parsing

Please see P2PS: Fix p2p_find last parameter handling


>P2PS: Fix Probe Response frame building in error cases

Please see P2PS: Fix attribute addition in p2p_buf_add_service_instance()
It fixes a small enumeration issue (with my credits to Ilan who noticed it)


>P2PS: Fix service hash matching for org.wi-fi.wfds
>P2PS: Fix org.wi-fi.wfds matching when building the response

IMHO, these two patches are tricky. I tend to think that the original implementation was correct.
In P2PS 1.1 spec section 3.4.1: 
"The ASP?at the?Service Advertiser shall respond positively if a Service Seeker sends the hash value for ?org.wi-fi.wfds? and has at least one?advertised?P2Ps?service."
Also P2PS test verifying discovery of multiple services using Prefix Search assumes that advertiser publishes ?org.wi-fi.wfds" with adv_id 0 together with ?test.abc.xyz?.
If to assume that ASP doesn't add ?org.wi-fi.wfds? explicitly, it looks like the right behavior is to reply with ?org.wi-fi.wfds? if at least one service advertisement is present.

What do you think?


>P2PS: Verify service name length in P2P_FIND command
>P2PS: Fix p2p_find handling to allow "wildcard" with other hash values
>P2PS: Do not ignore other hashes if org.wi-fi.wfds hash is included
>P2PS: Remove unnecessary service hash filtering from p2p_reply_probe()
>P2PS: Add more debug prints for service info building
>tests: Extend P2PS service seek test to cover multiple services
>tests: P2PS with large number of services in Probe Request/Response

The rest of the patches looks fine to me.

Thanks,
Max