[PATCH 18/19] P2PS: add a wildcard with other advertised service info
Max.Stepanov at intel.com
Tue Jun 23 10:46:31 EDT 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