Suzanne Taylor is a Public Policy & Internet Governance Consultant. In her work with the RIPE NCC, she has engaged with a broad range of Internet stakeholders including the RIPE NCC membership, governments, law enforcement and intergovernmental organisations. From 2012 to 2016, she worked in communications at the RIPE NCC … More
We're thinking about implementing WiFi measurements in RIPE Atlas, and we want to know what you think. There are several different ways we could do this - find out more below and then take our poll to make your voice heard!
We're always thinking about ways to improve the RIPE Atlas network and make this service as useful as possible for as many people as possible. As we're approaching 10,000 connected probes, we thought it was a good time to take stock and think about what our next steps might be in order to continue serving the wider Internet community.
Using RIPE Atlas probes to conduct WiFi measurements is something we've been discussing with the RIPE Atlas community for
some time already
. The hardware used as the basis for the current (third) version of probes (called v3 probes) are wireless routers, but in configuring the probes for use in RIPE Atlas, we decided not to provide software to support WiFi because we wanted to keep the host's traffic separate from the probe in order to ensure the host's privacy. Recently, however, some users have asked about the possibility of allowing these measurements because they're interested in monitoring wireless networks, and believe this use case could help us expand the reach of the RIPE Atlas network.
What do we mean by WiFi measurements?
Before outlining the reasons that it might be beneficial to allow the probes to do WiFi measurements, it's important to understand exactly what we mean when we talk about this. What we do NOT mean is that the probes would connect to the RIPE Atlas infrastructure over a wireless Internet connection. Instead, they would behave just as regular probes do now, being physically connected to a network, connecting via Ethernet to the RIPE Atlas infrastructure and receiving firmware updates, etc. this way. They would conduct all of the same built-in measurements that the regular probes do now. Conducting WiFi measurements would simply mean connecting to a specific WiFi network (with optional authentication), performing measurements over this new connection, then closing down the WiFi connection. These WiFi measurements would be user-defined measurements about the availability of a nearby wireless network specifically chosen as a target by the user setting up the measurement ahead of time - the probes would not scan for nearby wireless networks themselves.
Use cases and benefits
The idea to do WiFi measurements was first proposed by
GÉANT
, the
European data network for the research and education community
. They are interested in using RIPE Atlas probes to measure the availability of
eduroam,
their world-wide wireless network developed for the international research and education community, which is used by many universities around the world.
Of course, anyone interested in testing a particular wireless network's connectivity and availability - whether they run the network themselves or they're an interested customer - could perform their own WiFi measurements to monitor their own network or troubleshoot issues using RIPE Atlas probes around the globe. How many probes would be available for these sorts of measurements would depend on the way that we implement this feature.
This feature could attract new probe hosts interested in deploying probes throughout their networks, and could help expand the RIPE Atlas network, to the benefit of all RIPE Atlas users.
Candidate hardware for the next generation (v4) RIPE Atlas probe
Different implementation scenarios
There are a few different ways we could implement this. The major differences between them have to do with whether we implement WiFi measurements for the current v3 probes or we need to switch to a new generation of probes for this, and whether this is an opt-in feature for probe hosts. (Note that v1 and v2 probes are not capable of supporting WiFi measurements). Here are the main possible scenarios, with the advantages and disadvantages for each from our perspective:
1. Make WiFi measurements available for all existing and future v3 probes (and continue to use only v3 probes).
Advantages: This approach is the simplest for us from a technical and administrative point of view, because it would simply involve turning on the wireless capability fo all v3 probes, and would avoid having to keep track of different kinds of probes (i.e. those that support WiFi measurements and those that don't).
Disadvantages: Some RIPE Atlas users could feel this is a violation of the original terms they agreed to when volunteering to host a probe and might decide to unplug their probes from the network.
2. Make WiFi measurements available as an opt-in feature for all existing and future v3 probes
(and continue to use only v3 probes).
Advantages: This would allow for the largest number of probes being available for WiFi measurements, making the RIPE Atlas network the most useful for those interested in these types of measurements. Users would be able to opt-in to supporting WiFi measurements only if they choose to do so. From an administrative and technical standpoint, this feature could be implemented with probe tagging, which means a relatively small amount of development work from our end.
Disadvantages: Some current probe hosts might not trust us to ensure their choice about whether to enable WiFi measurements is carried out, or be upset that we changed the way the v3 probes are being used (even if only by some hosts) and could decide to unplug their probes from the network.
3. Keep v3 probes as they are and make WiFi measurements available only for the next generation of probes (v4 probes).
Advantages: Users will have full control over whether their probe is capable of performing WiFi measurements.
Disadvantages: From a technical point of view, this option would require significant resources in order to configure a new version of the hardware to support the measurements. Administratively, this is the most complicated option because it would involve keeping track of two types of probes (v3 and v4 probes), with all the associated logistical challenges.
4. Stop distributing v3 probes and make WiFi measurements available by default (but with an opt-out option) for the next generation of probes (v4 probes).
Advantages: This would encourage users to allow WiFi measurements, making this feature more useful for those interested in these measurements. Users could still decide to opt out of supporting WiFi measurements.
Disadvantages: Administratively, this would require development on our end in order to switch to the v4 probes and keep track of two types of v4 probes (those that have opted out and those that haven't).
Take the poll - tell us what you want!
As you can see, there's no clear-cut "winner" - at least not from our perspective - which is why we need your input. What do you think? Which scenario would you prefer? Let us know by answering our poll and we'll take the votes into account as we move forward in coming up with the best solution possible, both from a technical standpoint and in meeting the needs of our community. (Please note that the poll is closed now.)
Suzanne Taylor is a Public Policy & Internet Governance Consultant. In her work with the RIPE NCC, she has engaged with a broad range of Internet stakeholders including the RIPE NCC membership, governments, law enforcement and intergovernmental organisations. From 2012 to 2016, she worked in communications at the RIPE NCC … More
Suzanne Taylor is a Public Policy & Internet Governance Consultant. In her work with the RIPE NCC, she has engaged with a broad range of Internet stakeholders including the RIPE NCC membership, governments, law enforcement and intergovernmental organisations. From 2012 to 2016, she worked in communications at the RIPE NCC … More
Suzanne Taylor is a Public Policy & Internet Governance Consultant. In her work with the RIPE NCC, she has engaged with a broad range of Internet stakeholders including the RIPE NCC membership, governments, law enforcement and intergovernmental organisations. From 2012 to 2016, she worked in communications at the RIPE NCC … More
Suzanne Taylor is a Public Policy & Internet Governance Consultant. In her work with the RIPE NCC, she has engaged with a broad range of Internet stakeholders including the RIPE NCC membership, governments, law enforcement and intergovernmental organisations. From 2012 to 2016, she worked in communications at the RIPE NCC and has previously worked as a journalist and in media relations and science communications.
Comments 15
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Alexander
•
I would personally be happy with the first option (adding to all V3) however I recognise that when people signed up they knew the probe had no wireless enabled and this is a potentially substantial change to the system. Also I am somewhat concerned about the quality of the measurements that would be received. The nodes are installed in close proximity (usually) to a wired ethernet network and power, in many situations I have seen them connected directly to the router by both USB for power and the ethernet cable that comes along with them resulting in a very close proximity between the probe and the router (in many cases a wifi source) which is likely to leave the probe in a massive bubble of signal giving bad data for this testing.
Daniel Karrenberg
•
I really see two orthogonal questions here:
1) Do we want opt-out or opt-in for Wifi measurements on hardware that is capable to do them?
2) Do we want to retroactively make V3 probes capable for Wifi measurements?
Given the trust that we need from probe hosts who let us connect to their networks the only answer to the first question can be "opt-in". Given that the proposed measurements require a specific SSID to be configured this ssems rather logical too: those interested in montoring a specific SSID, like eduroam, will place probes where eduroam coverage exists for this purpose and convince existing hosts within eduroam coverage to opt-in.
Given that the only sensible answer to question 1 is 'opt-in', the answer to question 2 becomes easier. Currently hosts already trust us that we do no enable the Wifi in the V3 probes. I agree that some could re-evaluate their trust if we added the capability to switch it on for those that opt-in. Maybe it is worthwhile to consider using different firmware images in order to make it appear less likely that Wifi gets enabled by accident? In any case I personally answer the second question with "Yes, let us use this capability of the V3 hardware for those that opt-in."
In any case we need to communicate very clearly, and even more explicitly than in this article, that under no circumstances shall we provide a capability to just 'snoop around' on Wifi. RIPE Atlas will only measure Wifi networks that are explicitly configured. Maybe it would help if the "opt-in" configuration would include an option for the host to limit the SSIDs that can be measured?
Daniel Karrenberg
•
Thank you for providing poll results to those that take part in the poll. It would be useful to know the exact numbers in addition to the percentages or at least the total number of respondents.
Hide replies
Mirjam Kühne
•
Hi Daniel, we chose to display the chart rather than numbers. We will make the results including the numbers available when we have more votes. We've noticed that many people are already taking the poll - that's great :-)
Adam Konrad
•
I don't understand why would you want to measure WiFi this way. What exactly are you looking to measure when the probe is already connected to the same network? Isn't the probe also located in direct proximity of the AP in most cases? I just don't see the value of such feature. Did you also fully consider all the security issues letting a 3rd party request a WiFi connection from the probe host network? If you'd let only the probe owner setup such measurement, then I don't have a problem with it.
Hide replies
Robert Kisteleki
•
Measuring public wifi availability is the key use case -- the example mentioned in the article is Eduroam, but it could be any other network. In these cases first you want a working connection (existing wired) and then you want to see if the wireless is indeed available and working.
In Eduroam's case, this is a non-trivial question. The SSID may be there, but the (federated) authentication may fail in all or some cases. Once that works, can you actually send and receive packets properly? That's where the steps of associate/authenticate/measure help.
Tony McGregor
•
++eduroam measurements
Yang Yu
•
Personally I see limited user cases for wifi measurements. In the proposed user case, POE support might be needed. And to monitor the health of a wifi network, I am not sure if ping/traceroute/DNS/SSL is even close to sufficient. All these can be done from the switch (wired). There are alternative solutions for wifi health monitoring better suited for this use case.
I am not exactly sure who decides which SSID to connect. This article makes it sound like I could create a measurement for CableWiFi and any wifi-enabled probe can be selected to perform measurements if they have the SSID in range (constant scanning is involved). Sounds really cool. And definitely opt-in, it's simply too invasive to turn on wifi on all probes without permission. Better yet, load a different firmware when users opt in for wifi measurements (give the peace of mind for those that do not want wifi, they can have the non wifi-enabled firmware). If the current platform can measure RSSI, SNR, noise (relative values over time, not trying to compare values from one probe to another), imo it's fine to keep this platform.
If only the probe hosts can configure which SSID to connect, then that would be too much configuration for probe hosts (no point for opt-out model, if its not going to get configured, then why have it enabled at all). Very limited use cases as I can see.
Features needed:
wpa2-enterprise support
scheduling: (not) run measurements during certain hours
BSSID priority, blacklist/whitelist: very helpful when multiple APs with the same SSID are in range
Hide replies
Robert Kisteleki
•
See above for a known and expected use case.
The separate firmware is actually better solved by a different device; that way you're sure if your device can do this or not. The other realistic alternative is the opt-in tagging of the probe.
Ramon Bayán
•
I agree with your answer Robert.
I deploy first 802.1x for all staff working at the University on 2002 using EAP-TTLS solution using Oddisey client/Radius Steel-Belted Radius V4.0 /Enterasys APs and during the 2004 I decide to deploy a small networks of probes based on a modified firmware of WRT54G just to test and be sure that the wi-fi authenticated netwok was working fine as you mention, and to ping point the source of a problem, the client or the authenticated network, basically the radius and LDAP.
So I find this a nice idea and I agree with the thoughts of Daniel and you about opt-in tagging of the probe.
The test probe must be placed as someone mentioned in the correct place with a good Eduroam coverage.
I also agree with this Features needed:
wpa2-enterprise support
BSSID priority, blacklist/whitelist: very helpful when multiple APs with the same SSID are in range
Jan Ferré
•
While I have no problem about probes doing wifi measurements too, I do recognise the problems especially the commercial vendors might have. People could use the probes to determine if sales-claims was correct ("our coverage is xx%").
The answer, however is not to avoid current probes doing wifi analysis, but to make sure only mandated wifi networks can be chosen for test.
The problem about the validity of wifi-analyses using current probe (especially current probe installation) can be solved only by opt-in as care should be taken to install the probes in a user-like environment.
Leo Vegoda
•
I like the idea of WiFi measurements. There are many non-WiFi devices that interfere with the spectrum available to wireless networks, such as baby monitors. Also, some neighbourhoods has such a high density of wireless networks that the quality of the connection is impacted and throughput is very low. The ability to connect to both the wireless and wired networks for a single Internet connection would be helpful in gaining a statistically meaningful set of measurements that could help drive improvements in people's actual experience of the Internet when using a WiFi only device.
Marc Werner
•
Could you use the existing hardware switch on the v3 probe to allow the host to turn on/off this feature? Maybe this would give more confidence to "the sceptics".
Håvard Eidnes
•
I'm fine with opt-in for existing v3 probes.
However, I'm considering deployment of a probe (which sits here at my desk at the moment) in an area which has declared radio silence for WiFi and cell phones, and I need to be certain that my v3 probe suddenly doesn't turn on its WiFi radio, either with current or future software.
Comments 15
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Alexander •
I would personally be happy with the first option (adding to all V3) however I recognise that when people signed up they knew the probe had no wireless enabled and this is a potentially substantial change to the system. Also I am somewhat concerned about the quality of the measurements that would be received. The nodes are installed in close proximity (usually) to a wired ethernet network and power, in many situations I have seen them connected directly to the router by both USB for power and the ethernet cable that comes along with them resulting in a very close proximity between the probe and the router (in many cases a wifi source) which is likely to leave the probe in a massive bubble of signal giving bad data for this testing.
Daniel Karrenberg •
I really see two orthogonal questions here: 1) Do we want opt-out or opt-in for Wifi measurements on hardware that is capable to do them? 2) Do we want to retroactively make V3 probes capable for Wifi measurements? Given the trust that we need from probe hosts who let us connect to their networks the only answer to the first question can be "opt-in". Given that the proposed measurements require a specific SSID to be configured this ssems rather logical too: those interested in montoring a specific SSID, like eduroam, will place probes where eduroam coverage exists for this purpose and convince existing hosts within eduroam coverage to opt-in. Given that the only sensible answer to question 1 is 'opt-in', the answer to question 2 becomes easier. Currently hosts already trust us that we do no enable the Wifi in the V3 probes. I agree that some could re-evaluate their trust if we added the capability to switch it on for those that opt-in. Maybe it is worthwhile to consider using different firmware images in order to make it appear less likely that Wifi gets enabled by accident? In any case I personally answer the second question with "Yes, let us use this capability of the V3 hardware for those that opt-in." In any case we need to communicate very clearly, and even more explicitly than in this article, that under no circumstances shall we provide a capability to just 'snoop around' on Wifi. RIPE Atlas will only measure Wifi networks that are explicitly configured. Maybe it would help if the "opt-in" configuration would include an option for the host to limit the SSIDs that can be measured?
Daniel Karrenberg •
Thank you for providing poll results to those that take part in the poll. It would be useful to know the exact numbers in addition to the percentages or at least the total number of respondents.
Hide replies
Mirjam Kühne •
Hi Daniel, we chose to display the chart rather than numbers. We will make the results including the numbers available when we have more votes. We've noticed that many people are already taking the poll - that's great :-)
Adam Konrad •
I don't understand why would you want to measure WiFi this way. What exactly are you looking to measure when the probe is already connected to the same network? Isn't the probe also located in direct proximity of the AP in most cases? I just don't see the value of such feature. Did you also fully consider all the security issues letting a 3rd party request a WiFi connection from the probe host network? If you'd let only the probe owner setup such measurement, then I don't have a problem with it.
Hide replies
Robert Kisteleki •
Measuring public wifi availability is the key use case -- the example mentioned in the article is Eduroam, but it could be any other network. In these cases first you want a working connection (existing wired) and then you want to see if the wireless is indeed available and working. In Eduroam's case, this is a non-trivial question. The SSID may be there, but the (federated) authentication may fail in all or some cases. Once that works, can you actually send and receive packets properly? That's where the steps of associate/authenticate/measure help.
Tony McGregor •
++eduroam measurements
Yang Yu •
Personally I see limited user cases for wifi measurements. In the proposed user case, POE support might be needed. And to monitor the health of a wifi network, I am not sure if ping/traceroute/DNS/SSL is even close to sufficient. All these can be done from the switch (wired). There are alternative solutions for wifi health monitoring better suited for this use case. I am not exactly sure who decides which SSID to connect. This article makes it sound like I could create a measurement for CableWiFi and any wifi-enabled probe can be selected to perform measurements if they have the SSID in range (constant scanning is involved). Sounds really cool. And definitely opt-in, it's simply too invasive to turn on wifi on all probes without permission. Better yet, load a different firmware when users opt in for wifi measurements (give the peace of mind for those that do not want wifi, they can have the non wifi-enabled firmware). If the current platform can measure RSSI, SNR, noise (relative values over time, not trying to compare values from one probe to another), imo it's fine to keep this platform. If only the probe hosts can configure which SSID to connect, then that would be too much configuration for probe hosts (no point for opt-out model, if its not going to get configured, then why have it enabled at all). Very limited use cases as I can see. Features needed: wpa2-enterprise support scheduling: (not) run measurements during certain hours BSSID priority, blacklist/whitelist: very helpful when multiple APs with the same SSID are in range
Hide replies
Robert Kisteleki •
See above for a known and expected use case. The separate firmware is actually better solved by a different device; that way you're sure if your device can do this or not. The other realistic alternative is the opt-in tagging of the probe.
Ramon Bayán •
I agree with your answer Robert. I deploy first 802.1x for all staff working at the University on 2002 using EAP-TTLS solution using Oddisey client/Radius Steel-Belted Radius V4.0 /Enterasys APs and during the 2004 I decide to deploy a small networks of probes based on a modified firmware of WRT54G just to test and be sure that the wi-fi authenticated netwok was working fine as you mention, and to ping point the source of a problem, the client or the authenticated network, basically the radius and LDAP. So I find this a nice idea and I agree with the thoughts of Daniel and you about opt-in tagging of the probe. The test probe must be placed as someone mentioned in the correct place with a good Eduroam coverage. I also agree with this Features needed: wpa2-enterprise support BSSID priority, blacklist/whitelist: very helpful when multiple APs with the same SSID are in range
Jan Ferré •
While I have no problem about probes doing wifi measurements too, I do recognise the problems especially the commercial vendors might have. People could use the probes to determine if sales-claims was correct ("our coverage is xx%"). The answer, however is not to avoid current probes doing wifi analysis, but to make sure only mandated wifi networks can be chosen for test. The problem about the validity of wifi-analyses using current probe (especially current probe installation) can be solved only by opt-in as care should be taken to install the probes in a user-like environment.
Leo Vegoda •
I like the idea of WiFi measurements. There are many non-WiFi devices that interfere with the spectrum available to wireless networks, such as baby monitors. Also, some neighbourhoods has such a high density of wireless networks that the quality of the connection is impacted and throughput is very low. The ability to connect to both the wireless and wired networks for a single Internet connection would be helpful in gaining a statistically meaningful set of measurements that could help drive improvements in people's actual experience of the Internet when using a WiFi only device.
Marc Werner •
Could you use the existing hardware switch on the v3 probe to allow the host to turn on/off this feature? Maybe this would give more confidence to "the sceptics".
Håvard Eidnes •
I'm fine with opt-in for existing v3 probes. However, I'm considering deployment of a probe (which sits here at my desk at the moment) in an area which has declared radio silence for WiFi and cell phones, and I need to be certain that my v3 probe suddenly doesn't turn on its WiFi radio, either with current or future software.
Suzanne Taylor Muzzin •
Please see an update to our plans for implementing WiFi measurements here: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements-part-2