On Mon, Dec 19, 2011 at 1:03 PM, Marcel Holtmann <[email protected]> wrote: > Hi Flavio, > >> I've working in a project using using using wifi-direct (p2p), and I >> planning implementing it on connman, I saw that there is an item in the >> TODO about it. >> >> So, my plan is create a new technology wifi_p2p, the implementation and >> behaviour should be pretty similar to wifi technology. It will be >> necessary add support for p2p in the existent gsupplicant code. >> As the p2p, the idea is cover just a small set of functions for now, for >> connect we'll use just the push button control (PBC) method. The >> connection will be done without use the Group concept, I mean, both >> peers will use the command connect and one of them will be chosen the >> Group Owner, instead of one Peer create a Group and the other Peer join >> into this Group. The reason for this is that according with the wpa >> developers to use Group Add + Join is not the recommended way. > > so I am not sure that a new technology wifi_p2p is a good idea, but I > could be wrong here. It is just a feeling that this might not be the > best approach. However this should not stop you from trying. So go ahead > here and we see where it leads us. Just make sure that you send RFC > patches early. So you get more eyes on it. > > And for GSupplicant support for P2P, that sounds like a good idea > anyway. So I would start with that. Maybe at that point it also becomes > a lot clearer on how P2P fits into legacy WiFi networks in a clean way > without breaking everything else.
I'm no expert in P2P, but from a quick overview at how it works, trying to match it into existing wifi will be a PITA. First, security class is unimportant... or it's specified to be something fixed, don't remember, the point is that we can't choose it (or usually don't -- seems it's always WPS). Second, ssid is ignored, they hack random numbers to a common prefix, used to discover it. Then you'd need to hide this from user. Third, there are extra properties we can use, only available there. Similar to Bluetooth, there is a name (which we can use as the service name), manufacturer, model_name and a primary device type, with list of secondary types. Types are encoded with a leading and trailing known classes, these should be used to identify it (TV, Camera, Game...). We could have a Type=p2p and have P2P properties there, so GUI can show device icon or even filter itself (ie: I want to connect to a camera, hide everything else). Fourth, scan/list devices are different commands, also to get information. Then it would complicate current wifi. BTW, find a sample wpa_cli session to my TV: p2p_find # similar to scan OK p2p_peers # similar to scan_results 4e:e6:76:12:0e:73 p2p_peer 4e:e6:76:12:0e:73 age=202 listen_freq=2437 level=-79 wps_method=not-ready interface_addr=5e:e6:76:12:0e:73 member_in_go_dev=00:00:00:00:00:00 member_in_go_iface=5e:e6:76:12:0e:73 pri_dev_type=7-0050F204-1 device_name=BRAVIA KDL-40EX525 manufacturer=Sony Corporation model_name=Sony BRAVIA model_number=0 serial_number=0 config_methods=0x188 dev_capab=0x21 group_capab=0x3 go_neg_req_sent=0 go_state=unknown dialog_token=0 intended_addr=00:00:00:00:00:00 country=__ oper_freq=2437 req_config_methods=0x0 flags= status=0 wait_count=0 invitation_reqs=0 oper_ssid=DIRECT-GR-BRAVIA -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -------------------------------------- MSN: [email protected] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
