[PATCH 18/19] P2PS: add a wildcard with other advertised service info
Tue Jun 23 07:46:31 PDT 2015
>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.
More information about the Hostap