Announcement

Collapse
No announcement yet.

Technology Tip - WiFi Direct Pairing (LONG)

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Technology Tip - WiFi Direct Pairing (LONG)

    Hi Folks

    I wanted to create a post with some information and tips about the Wi-Fi Direct Pairing process used by the FTC apps to establish a point-to-point wireless connection.

    Background:
    The FTC apps need to be "paired" together before you can control your robot via the driver station. They use a technology called Wi-Fi Direct to establish this unique and persistent connect. The Robot Controller (RC) acts as the "Group Owner" (sort of like a wireless access point) and the Driver Station (DS) acts as a client connected to the Wi-Fi Direct network established by the group owner. Wi-Fi Direct gives you Bluetooth-like connectivity using the Wi-Fi (802.11) technology.

    When you want to pair your DS to a RC, you should use the Pair with Robot Controller menu item of the FTC Driver Station App (accessed in the Settings menu from the main screen). When you launch the Pair with Robot Controller activity the DS does a quick Wi-Fi Direct scan to see what Wi-Fi Direct enabled devices are available. It actually will send probe requests on a few known channels (1, 6, and 11) and then listen for probe responses from other Wi-Fi Direct enabled devices. It uses this probe response information to generate a list of available devices that you can select from the Pair with Robot Controller activity.

    When you make your selection and exit back to the main activity of the FTC Driver Station app, the DS will attempt to establish a Wi-Fi Direct connection with the RC. If it is a new connection, a dialog box will appear on the RC's screen and the user has to manually accept the connection request in order to establish the Wi-Fi Direct connection between the two devices. Once the connection is made, it will be persistent. This means that the next time you turn on your FTC Driver STation app, the app will attempt to pair with the RC that it had previously established a connection. If that RC is up and its FTC Robot Controller app running, the two devices will establish the Wi-Fi Direct connection automatically (the user does not have to accept the connection request a second time).

    Here's an important tip - at some of the Pilot Test events last winter I noticed that some teams had been pairing their devices through the Wi-Fi Direct activity of the Android operating system. In general, I don't think you want to do this. Generally, you want to use the Pair With Robot Controller activity to pair your DS to an RC. You can use the Android's Wi-Fi Direct activity to do tasks like rename your device or if you want to forget previously remembered Wi-Fi Direct groups. HOwever, in general you should use the Pair with Robot Controller to pair your DS to an RC.

    Potential problems with Wi-Fi Direct Discovery Process

    The Wi-Fi Direct connections that are established by the FTC apps are fairly robust. They can tolerate a fair amount of activity and noise/interference on their operating channel and still work reliably. However, somewhat paradoxically, the Wi-Fi Direct Discovery Process can be sensitive to background noise and traffic on the Wi-Fi spectrum.

    If you are at an event and you notice that your Android devices have difficulties pairing (either they were pre-paired and can't establish a connection or you are trying to pair the DS to the RC but you don't see the RC listed in the available devices list) then it could be that the traffic and noise in the vicinity is hindering the Wi-Fi Direct discovery process. Here are some steps you can do to help successfully pair your devices:

    1. You can physically remove the two devices from the general crowd and attempt to pair the devices in isolation. Once the devices have been paired, they can stay connected in spite of background noise and interference . By removing the devices from the main group of devices the DS should be able to receive the probe responses from the target RC and be able to see and pair to the device properly.

    2. If you have a large group of teams that are all trying to pair their devices simultaneously, it might be easier to pair the devices in smaller groups. Have one small group (group "A" for example) turn on their devices first and pair, then after group "A" is done, have the next small group do this and so on until all groups are turned on.

    Again, once the devices are paired they should operate properly and be able to tolerate a fair amount of noise. However, the WiFi Direct discovery process can be sensitive to noise so pairing in isolation or pairing in batches might be options at very crowded venues.

    Malformed Probe Response Packets
    There is a bug in Android Kit Kat (and possibly in early versions of Lollipop - we think we've seen it during our testing with a Lollipop device or two) where an Android device that is doing a Wi-Fi Direct scan (to search for available devices in the area) will crash and reboot itself whenever it encounters a "malformed" packet. The bug was reported by a company called Core Security (http://www.coresecurity.com/advisori...denial-service) in early 2015. Google fixed the bug, but did not include a patch for Kit Kat. The ZTE Speed phone currently runs Kit Kat and is vulnerable to this issue.

    Philbot (thanks Phil!!!) was the first person in our community to encounter and report this bug (http://ftcforum.usfirst.org/showthre...hlight=newline) with the ZTE devices and we've seen this happen elsewhere. What Phil reported is that if a newline character is embedded in the Wi-Fi Direct name of a device, it can cause other Kit Kat Android devices to reboot whenever the device tries to do a Wi-Fi Direct scan. This is an Android issue, and will occur if you do a Wi-Fi Direct scan from the Android Wi-Fi Direct activity. It will also occur when the FTC Driver STation app tries to do a scan to see what Wi-Fi Direct devices are nearby.

    This is a very scary situation if you are unaware of the cause. What can happen is that all of the Android devices start mysteriously rebooting whenever you launch the FTC apps. What is happening is that the FTC Driver STation app will try to scan the network and see what available devices are nearby. It will encounter the malformed packet that has the newline character in its name and reboot because of the bug.

    We have seen this happen a few times - the virtual keyboard on the ZTE Speeds are very small and users inadvertently hit the RETURN key when they are typing in the device name for their phone.

    The way to address the problem is as follows,

    1. See if you can identify the device that has the newline character in its name. Note that the name might look like it has an underscore ("_") character in it which might actually be a newline character. If you find the offending device, rename it to remove the newline character.
    2. Pair your devices in isolation. Take your DS and RC phones to a place away from the crowd, pair them and then come back. ONce the devices have been paired they will not do a WiFi Direct scan (unless you power cycle the DS or swipe close the DS then relaunch it).
    3. Pair your devices in batches. Turn all devices off first, then pair them in small groups one group at a time.

    Again, once the devices are connected they should not need to do a WiFi direct scan and will not be vulnerable to this issue (unless you power cycle the DS or swipe close the DS app and then relaunch it).

    Mischief Makers Take Note!
    It is possible to artificially create malformed packets and inject them into the spectrum to target individual phones or all phones with this vulnerability. It is also possible to detect such the presence of such attacks. If you are thinking about creating malformed packets and injecting them to disrupt an event, or using some other DoS mechanism to disrupt an event you should reconsider. This is very un-GP behavior and you run the risk of getting caught. Any type of malicious attack is regarded as a very serious offense and it can result in instant disqualification from an event and possible additional consequences!

    House Cleaning
    If you look in the WiFi Direct activity (go to Settings on your Android device, launch the Wi-Fi activity, then usually there is a WiFi Direct sub menu) you see "Remembered Groups" in the activity. These remembered groups get created whenever you connect to another Wi-Fi Direct device. The FTC apps should be able to operate, even if it there are a large number of remembered groups in the list. However, sometimes you might want to clean up and remove unused/unneeded remembered groups.

    You simply long click/touch on a remembered group to bring up a dialog box ("Forget this group?"). Select OK to forget the group. Once you have cleaned up, you might need to shut down and then restart your Wi-Fi adapter (I usually just reboot the device).

    Trouble Pairing... Are devices connected to other WiFi networks?
    In our testing, we have occasionally seen the case where a DS has problems connecting to its RC or where it seems like it is connected (for instance the FTC Robot Controller app will look like it's connected to a driver station) but the DS is unable to connect properly to the RC. When we've seen this, we have noticed that sometimes the FTC Robot Controller is also connected to another Wi-fi network (for example to a Wireless access point to do wireless ADB for debugging).

    We recommend that for competitions, teams make sure that both Android devices (DS and RC) are not connected to any other Wi-Fi or Wi-Fi direct network, with the exception of the Wi-Fi Direct connection between the two devices. If you notice that there are some connection issues with your devices and if either or both of the devices are connected to other Wi-Fi networks, try disconnecting and forgetting the other networks and rebooting the devices to see if the connection problems get resolved.

    Don't Install FTC Driver Station Software on the same device as FTC Robot Controller Software
    One common problem that I have seen is when someone installs both the FTC Robot Controller app and the FTC Driver STation app on the same device. This is not recommended. The FTC Robot Controller wants to be a group owner, while the FTC Driver Station wants to be a client. If both apps are installed and were run at some point on the same device, it could cause conflicts with the Wi-Fi direct settings.

    I hope this info helps!

    Please let me know if you have questions and be sure to help your fellow member of the FIRST community if they encounter any WiFi Direct issues.

    Tom

  • #2
    I'm not really sure that I'm comfortable with heading to a competition with a known security bug, even if there are rules in place to attempt to prevent it, since I'm not able to do anything on my end to mitigate it, it is remotely performed, and it can affect a match greatly.

    Will FTAs restart matches in case of observed behavior like this, OR will possible amendments to Game Rules I be made to allow devices running custom firmware not vulnerable to this, even if just by swallowing the exception in a modified class/dex file associated with this bug, as would be potentially doable on a rooted Speed?
    FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
    Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

    Comment


    • #3
      Originally posted by hexafraction View Post
      I'm not really sure that I'm comfortable with heading to a competition with a known security bug, even if there are rules in place to attempt to prevent it, since I'm not able to do anything on my end to mitigate it, it is remotely performed, and it can affect a match greatly.

      Will FTAs restart matches in case of observed behavior like this, OR will possible amendments to Game Rules I be made to allow devices running custom firmware not vulnerable to this, even if just by swallowing the exception in a modified class/dex file associated with this bug, as would be potentially doable on a rooted Speed?
      Hi hexafraction,

      I appreciate your concern and sympathize with your feelings on the matter - the vulnerability does seem scary, but the ability for someone to affect a match with this vulnerability is small. This bug only affects when a device (Kit Kat) does a Wi-Fi Direct scan. this does not normally happen when the devices are already connected to each other. For instance, if you're phones are already connected and your just standing in the queue waiting to get onto the field, or if you are on the field competing in a match, this vulnerability cannot be used to interrupt or crash your phone.

      The vulnerability only affects the phone's ability to do a wifi scan. Once the devices are connected they are not affected by this issue. You can run your op modes and control your robot even if a malformed packet is in the immediate area.

      I don't think a match restart would be warranted by this issue. The phones should already be connect prior to the match starting.

      Also, unfortunately I don't think it's easy to fix the vulnerability on the ZTE speeds - the phones boot loaders are locked and I don't think it's possible to root these devices.

      The practical reality is that there will be vulnerabilities with any wireless system. Regardless of the system we adopt, there are usually several ways to disrupt that system.

      I am posting this information so that the community is aware of the issue if they encounter problems when they are trying to pair their devices.

      Tom

      Comment


      • #4
        Originally posted by Tom Eng View Post
        Hi hexafraction,

        I appreciate your concern and sympathize with your feelings on the matter - the vulnerability does seem scary, but the ability for someone to affect a match with this vulnerability is small. This bug only affects when a device (Kit Kat) does a Wi-Fi Direct scan. this does not normally happen when the devices are already connected to each other. For instance, if you're phones are already connected and your just standing in the queue waiting to get onto the field, or if you are on the field competing in a match, this vulnerability cannot be used to interrupt or crash your phone.

        The vulnerability only affects the phone's ability to do a wifi scan. Once the devices are connected they are not affected by this issue. You can run your op modes and control your robot even if a malformed packet is in the immediate area.

        I don't think a match restart would be warranted by this issue. The phones should already be connect prior to the match starting.

        Also, unfortunately I don't think it's easy to fix the vulnerability on the ZTE speeds - the phones boot loaders are locked and I don't think it's possible to root these devices.

        The practical reality is that there will be vulnerabilities with any wireless system. Regardless of the system we adopt, there are usually several ways to disrupt that system.

        I am posting this information so that the community is aware of the issue if they encounter problems when they are trying to pair their devices.

        Tom
        I understand more clearly now; I was under the impression that the packet would be parsed triggering the issue if received at any time. I do appreciate all the work that was put in to minimize this issue. At any rate if there is a large issue one can always remove themselves from the area to pair. Thanks!
        FTC6460 mentor (software+computer vision+electronics), FPGA enthusiast. In favor of allowing custom electronics on FTC bots.
        Co-founder of ##ftc live chat for FTC programming--currently you may need to join and wait some time for help--volunteer basis only.

        Comment


        • #5
          Thanks Tom for this complete breakdown.

          Knowing the "best practices" should help things run more smoothly.

          Phil.

          Comment


          • #6
            Teams should consider renaming their WiFi direct name something other than the default name. Imagine having to pair your androids at a tournament if every team were using the default WiFi name. You'd likely have problems finding your own android in the list of names. To ensure a unique name, we include our team number in the name as in "RO-3928" for the robot-side android and "DR-3928" for the driver android.

            Comment


            • #7
              Originally posted by emeflag View Post
              Teams should consider renaming their WiFi direct name something other than the default name.
              The game rules are very explicit about the naming and a check for this is included on the inspection checklist:

              <RS02> Each Team MUST “name” their Robot Controller with their official FTC Team number and –RC (e.g.
              “1234-RC”). Each Team MUST “name” their Driver Station with their official FTC Team number and –DS (e.g.
              1234-DS). Spare Android devices should be named with the Team number followed by a hyphen then a letter
              designation beginning with “B” (e.g. “1234-B-RC”, “1234-C-RC”).

              Comment


              • #8
                Originally posted by Tom Eng View Post
                Trouble Pairing... Are devices connected to other WiFi networks?
                In our testing, we have occasionally seen the case where a DS has problems connecting to its RC or where it seems like it is connected (for instance the FTC Robot Controller app will look like it's connected to a driver station) but the DS is unable to connect properly to the RC. When we've seen this, we have noticed that sometimes the FTC Robot Controller is also connected to another Wi-fi network (for example to a Wireless access point to do wireless ADB for debugging).

                We recommend that for competitions, teams make sure that both Android devices (DS and RC) are not connected to any other Wi-Fi or Wi-Fi direct network, with the exception of the Wi-Fi Direct connection between the two devices. If you notice that there are some connection issues with your devices and if either or both of the devices are connected to other Wi-Fi networks, try disconnecting and forgetting the other networks and rebooting the devices to see if the connection problems get resolved.
                First, I want to extend a thank-you for this write-up. It was very clear and insightful.

                I'd like, however, to observe that robot controllers will virtually 100% of the time have their USB ports connected to the power distribution module and so unavailable for connection to a PC. Thus, if one wants to debug them, one will be of necessity using Wifi debugging instead of USB debugging, and this requires a second Wifi network. This is true both for debugging during development in our various labs and debugging in the pits during competitions (I am aware there is a currently a rules issue regarding Wifi in the pits).

                To suggest that secondary Wifi networks be disabled is thus to effectively make the robots undebuggable, and this seems unreasonable. I'd like to therefore suggest that whateever bugs are causing issues with these configurations be given a boost in their priority for fixing.

                On a related note, I'll observe that the recent update is anecdotally worse regarding these issues than the August beta was. As the author of BotBug, I have been working a lot with wireless debugging this past month or so, as much or more than anyone has I'd hazard a guess, and I found the beta generally to be very, very good. I'd say I've perhaps seen more connection failures of the nature you describe above in the last two days on the new release as I did the entire past month and a half on the beta. So something seems to have changed to make this worse, if that helps you root out the cause of it.

                Thanks again for all the updates and information.

                Comment


                • #9
                  Originally posted by FTC0417 View Post
                  First, I want to extend a thank-you for this write-up. It was very clear and insightful.

                  I'd like, however, to observe that robot controllers will virtually 100% of the time have their USB ports connected to the power distribution module and so unavailable for connection to a PC. Thus, if one wants to debug them, one will be of necessity using Wifi debugging instead of USB debugging, and this requires a second Wifi network. This is true both for debugging during development in our various labs and debugging in the pits during competitions (I am aware there is a currently a rules issue regarding Wifi in the pits).

                  To suggest that secondary Wifi networks be disabled is thus to effectively make the robots undebuggable, and this seems unreasonable. I'd like to therefore suggest that whateever bugs are causing issues with these configurations be given a boost in their priority for fixing.

                  On a related note, I'll observe that the recent update is anecdotally worse regarding these issues than the August beta was. As the author of BotBug, I have been working a lot with wireless debugging this past month or so, as much or more than anyone has I'd hazard a guess, and I found the beta generally to be very, very good. I'd say I've perhaps seen more connection failures of the nature you describe above in the last two days on the new release as I did the entire past month and a half on the beta. So something seems to have changed to make this worse, if that helps you root out the cause of it.

                  Thanks again for all the updates and information.
                  I understand the desire to use wireless ADB to debug your code while the robot controller is attached to the robot. HOwever, if you are in a match (and not in the practice area), we recommend that you only have the phones connected to each other, and nothing else. The ping times for a device that is connected through wireless adb are higher than when the devices are only directly connected.

                  Also, please note that I believe the current robot rules (Game Manual part 1, Section 4.4) prevent teams from setting up their own access points so unless the event manager provides a wireless access point in the practice area I don't know if wireless ADB is an option at some events. For questions related to the robot rules, consult the appropriate subforum in the FTC game Q&A forum.

                  Tom

                  Comment


                  • #10
                    Originally posted by Tom Eng View Post
                    Also, please note that I believe the current robot rules (Game Manual part 1, Section 4.4) prevent teams from setting up their own access points so unless the event manager provides a wireless access point in the practice area I don't know if wireless ADB is an option at some events. For questions related to the robot rules, consult the appropriate subforum in the FTC game Q&A forum.
                    Tom
                    I would have to say that this rule is pretty explicit.

                    Game Manual 1 Section 4.4
                    Internet/Wireless Network Access: Teams may not setup a wireless computer network for any purpose (i.e.
                    Internet access, Team communication, Team computer to Robot, etc.).

                    This would appear to rule out any form of wireless debugging, even in the pits.
                    So, now we all need to find a method of anchoring down out phone USB cables so that they don't shake loose during matches, yet permit us to frequently disconnect them to enable us to do program updates and testing.
                    This is becoming quite the wiring challenge.

                    I'm starting to long for BlueTooth downloads. Is there a Bluetooth ADB interface, and would this also be prohibited.

                    I do think that it's ironic that we can't setup a computer to Phone connection for downloading, but many teams will have their Phone to Phone connections running most of the time (because they just don't turn them off).

                    Phil.

                    Comment


                    • #11
                      Originally posted by Philbot View Post
                      Originally posted by Tom Eng View Post
                      Also, please note that I believe the current robot rules (Game Manual part 1, Section 4.4) prevent teams from setting up their own access points so unless the event manager provides a wireless access point in the practice area I don't know if wireless ADB is an option at some events. For questions related to the robot rules, consult the appropriate subforum in the FTC game Q&A forum.
                      Tom
                      I would have to say that this rule is pretty explicit.

                      Game Manual 1 Section 4.4
                      Internet/Wireless Network Access: Teams may not setup a wireless computer network for any purpose (i.e.
                      Internet access, Team communication, Team computer to Robot, etc.).

                      This would appear to rule out any form of wireless debugging, even in the pits.
                      So, now we all need to find a method of anchoring down out phone USB cables so that they don't shake loose during matches, yet permit us to frequently disconnect them to enable us to do program updates and testing.
                      This is becoming quite the wiring challenge.

                      I'm starting to long for BlueTooth downloads. Is there a Bluetooth ADB interface, and would this also be prohibited.

                      I do think that it's ironic that we can't setup a computer to Phone connection for downloading, but many teams will have their Phone to Phone connections running most of the time (because they just don't turn them off).

                      Phil.
                      Windows 8+ supports WiFi Direct. You could connect a Windows 8+ system to the Robot Controller at the same time that the Driver Station is connected to the Robot Controller. Conceivably you could run wireless adb over WiFi Direct from Windows 8+ to the Robot Controller.

                      Comment


                      • #12
                        Originally posted by Alec View Post
                        Windows 8+ supports WiFi Direct. You could connect a Windows 8+ system to the Robot Controller at the same time that the Driver Station is connected to the Robot Controller. Conceivably you could run wireless adb over WiFi Direct from Windows 8+ to the Robot Controller.
                        Interesting... I'll have to try this.

                        Anyone "know" if this is also possible with Windows 10 (I'm thinking of upgrading).

                        Phil.

                        Comment


                        • #13
                          Originally posted by Philbot View Post
                          Originally posted by Alec
                          Windows 8+ supports WiFi Direct. You could connect a Windows 8+ system to the Robot Controller at the same time that the Driver Station is connected to the Robot Controller. Conceivably you could run wireless adb over WiFi Direct from Windows 8+ to the Robot Controller.
                          Interesting... I'll have to try this.

                          Anyone "know" if this is also possible with Windows 10 (I'm thinking of upgrading).

                          Phil.
                          I've explored trying to connect from the PC to the robot controller over Wifi Direct, both on Win10 and on Win8.1, without success. The PC can see the SSID of the robot controller "access point", but I just haven't figured out how to actually do the pairing (I hope I'm just "missing something" but can't tell). Figuring this out would indeed be very, very useful, as it would significantly simplify debugging as has been mentioned in this thread.

                          Comment


                          • #14
                            IMHO The wireless solution is a nice convenience for downloading to the device. However always depending on it for debugging may be overkill as most issues can be debugged easily with simple logging or telemetry.

                            Comment


                            • #15
                              Originally posted by dlevy View Post
                              IMHO The wireless solution is a nice convenience for downloading to the device. However always depending on it for debugging may be overkill as most issues can be debugged easily with simple logging or telemetry.
                              I rarely (if ever) do debugging over the ADB interface, however, during autonomous development, being able to download wirelessly is essential (rather than just a nice convenience).

                              It means the robot can remain on the field, while the programmers work at a table without needing to be tethered.
                              It means wear and tear on cables AND connectors is minimized.
                              It means the opportunities to snag a cable and destroy the phone is eliminated

                              And, given the issues we are currently having with the RobotController seeing the USB devices after there is any sort of USB interruption, each wired download cycle is going to escalate the aggravation factor.

                              Phil.

                              Comment

                              Working...
                              X