We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

prplMesh: open source Wi-Fi mesh

00:00

Formal Metadata

Title
prplMesh: open source Wi-Fi mesh
Subtitle
Solving home Wi-Fi
Title of Series
Number of Parts
542
Author
License
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
"Mesh" is the new hotness when it comes to Wi-Fi. Routers, extenders and wireless range extenders all propose to work together to optimize your Wi-Fi experience. This is where prplMesh comes in. prplMesh is an open source implementation of the Wi-Fi Easymesh standard. It helps organize your network by making onboarding easier, coordinate settings between devices and steer devices to the correct access point. In this presentation, I'll go over some of the challenges of coordinating Wi-Fi devices, and how we use (and develop) open source and open standards to make Wi-Fi better for everyone.
14
15
43
87
Thumbnail
26:29
146
Thumbnail
18:05
199
207
Thumbnail
22:17
264
278
Thumbnail
30:52
293
Thumbnail
15:53
341
Thumbnail
31:01
354
359
410
Polygon meshOpen sourceOpen sourcePolygon meshComputer animation
MetreSoftware developerSoftwareData managementLinear mapMaxima and minimaFirmwareRouter (computing)Internet forumCollaborationismInformation securityVideo gameSystem programmingCycle (graph theory)Endliche ModelltheorieTelecommunicationOpen sourceMechatronicsGame theoryCodeIntelPolygon meshStack (abstract data type)Functional (mathematics)ImplementationGame controllerMereologyPlastikkarteStandard deviationMultiplicationComputer networkMetric systemConfiguration spacePortable communications deviceFocus (optics)Software testingDevice driverOperator (mathematics)Independence (probability theory)Stress (mechanics)Wireless LANLevel (video gaming)Local GroupRouter (computing)SoftwareComputer hardwarePhysical systemGroup actionFunctional (mathematics)Computing platformDevice driverSoftware developerSoftware testingOperating systemVermaschtes NetzComputer networkIndependence (probability theory)Projective planeData managementFirmwareTelecommunicationPresentation of a groupPolygon meshIn-System-ProgrammierungImplementationStack (abstract data type)Point (geometry)Core dumpInternet service providerInformation securityCommunications protocolMobile appData storage deviceOpen sourceCollaborationismInternet forumLine (geometry)Game controllerExtension (kinesiology)CodeDifferent (Kate Ryan album)Configuration spaceStandard deviationService (economics)Cartesian coordinate systemMereologyMusical ensembleGoodness of fitMedical imagingBus (computing)Metric systemNumberTheoryComputer animation
Device driverOpen sourcePolygon meshOperator (mathematics)Wireless LANStress (mechanics)Independence (probability theory)Local GroupLevel (video gaming)Data managementComputer networkRouter (computing)Configuration spaceCommunications protocolMultiplicationAddress spaceSource codeSoftware developerMobile appDevice driverRemote procedure callPolygon meshMechanism designImplementationRouter (computing)Standard deviationSoftwareFunctional (mathematics)Different (Kate Ryan album)Communications protocolWhiteboardSmartphoneComputer configurationType theoryPoint (geometry)LengthConfiguration spaceLatent class modelAddress spaceInformationOnline helpMetric systemExtension (kinesiology)Open sourceGame controllerDoubling the cubeRight angleProjective planeIn-System-ProgrammierungData storage devicePresentation of a groupOperator (mathematics)Network topologyIndependence (probability theory)Set (mathematics)Direction (geometry)Source codeInternet service providerStress (mechanics)LaptopConnected spaceLevel (video gaming)Software testingInterface (computing)Physical systemTopological vector spaceWireless LANWorkstation <Musikinstrument>NumberMessage passingComputer animationDiagram
Open sourcePolygon meshVulnerability (computing)Frame problemSoftwarePatch (Unix)Degree (graph theory)Endliche ModelltheorieComputer hardwareConnected spaceLoginWireless LANSpeech synthesisMobile WebCausalityArithmetic meanData conversionMoment (mathematics)Standard deviationWeb pageMultiplication signDevice driverCommunications protocolCASE <Informatik>Element (mathematics)Operator (mathematics)Gateway (telecommunications)VirtualizationBitSystem callSelf-organizationMessage passingMathematicsMereologyView (database)Point (geometry)Electric power transmissionPressureMultiplicationDifferent (Kate Ryan album)Projective planeNetwork topologyIP addressVideoconferencingSingle-precision floating-point formatSet (mathematics)Computer virusInterface (computing)TrailTerm (mathematics)Computer animationDiagram
Computer networkOpen sourceIndependence (probability theory)Source codeMoment of inertiaFunction (mathematics)Computing platformComputer configurationComputer-generated imageryBuildingComputer hardwareSheaf (mathematics)Presentation of a groupComputer animationSource code
Program flowchart
Transcript: English(auto-generated)
OK. Yeah. Hello, everyone, and welcome to my presentation. I'm Freilich van Boogerth. I work for a company called Mind. And I'm here to present to you the PurpleMesh project, which is an open source Wi-Fi mesh solution.
So who am I? Like I said, I'm an embedded software developer, and I work for Mind. And since 2020, I've been a project manager for this PurpleMesh project at the Purple Foundation.
And yeah, feel free to email me if you want after presentation if you have any more questions afterwards. So what is the Purple Foundation? So the Purple Foundation is really a very big conglomeration of the industry,
telecoms industry. So if you look at the logos that I have there, there are a lot of ISPs in there, like AT&T, like Dodge Telecom, like Dish, like Verizon, Vodafone. So there's a lot of big ISPs in Purple Foundation,
and also some hardware manufacturers, so like ASCII, MediaTek, MaxDinier, Kaon. And so basically what we do is we sponsor the development of router firmware.
And so how this came about is essentially operators, they want to provide their users. So with operators, I mean, internet service providers, they want to provide their users with access points and routers, because not everyone can go out and buy them
and configure them themselves. But all of the software development is not really their core expertise. So traditionally, they've relied on stacks developed by hardware, the hardware partners. But they also, this is not their core expertise.
And so Purple Foundation was kind of created to collaborate on this with various partners. So the main projects that we're working on are Purple OS, which is a router firmware based on OpenWRT, Purple Mesh, which is a subject of this presentation,
and also noteworthy is Lifecycle Management, which is kind of an attempt to create an app store infrastructure, which is really cool, actually. And we are also heavily involved in talking about router security and router data models, so basically the API of a router.
So that's kind of the overview of the Purple Foundation. So Purple Mesh itself is an IEEE 1905 stack. So this is a layer 2.5 protocol. So it sits on top of Wi-Fi and Ethernet, but below IP.
And the stack itself is based on open source Intel codes. And so we are fully functional, easy mesh implementation with both agent and controller roles supported. And I will talk later about what that means. And we have extensive API standardization efforts
as well in collaboration with the Broadband Forum. So we don't just want to write an API. We want to really think about it. And so we are collaborating on that with other industry fora. And we also have a very heavy emphasis on testing.
So we have some Wi-Fi lines that we extensively test with. So I said Purple Mesh is an easy mesh implementation. So what do I mean by that? So this is the easy mesh protocol.
It's a Wi-Fi line standard, just as Wi-Fi 6 and Wi-Fi 7 are Wi-Fi line standards. And this is all meant to simplify your Wi-Fi management. So for Wi-Fi, often the problem that we have is you want to add an access point to your network.
So you want to add an access point to your network, but then you need to configure it. And that can be quite tedious. So the easy mesh protocol can do that for you.
So you just onboard new devices using WPS pairing, which is also extended by the easy mesh standards. And the device will automatically join your network and have all of your settings, including passphrases and the bands it needs to operate on, the SSIDs, any guest networks that you have configured, and so on.
And another thing that the easy mesh standard does is it shares the configuration. So if you want to change this configuration, if you want to add SSIDs, if you want to add guest networks or change any other part of your Wi-Fi configuration, you only need to do that in one place. And it's applied to all of your access points
in your entire network. And finally, also, it gathers a lot of metrics about your network, which can be used to optimize how devices connect to your network. So in the image there, you see various access points,
and you also see various network devices. And so what can often happen is that an access point that is used in your network simply gets overloaded because all of the devices try to connect to that access point, and your other access points don't see any use.
And especially if you have a precarious backhaul, that can lead to some performance problems. So applications that use this easy mesh standard, they can monitor this, they can see that there's a problem, and they can try to steer this device to use different access points, thus solving performance
problems in your network. So purple mesh is an easy mesh implementation. So basically, we implement all of the functionality that I've just described. It is portable to a number of different router operating
systems, all based on Linux. So OpenWRT, PurpleOS, and RDKB, in particular. It's also portable in theory to other Linux-based operating systems. The main dependency that we have is we rely on a software bus, like UBSR.
Our bus is typically used in these router operating systems. But we could also support something like Dbus for other platforms. The main problem that we encounter when trying to port purple mesh to new platforms is we need really good Wi-Fi drivers,
because something like mesh networking tests your Wi-Fi drivers like nothing else. And we find that most Wi-Fi drivers simply are not good enough to support all the functionality that we need. So that is one thing that we are also
active in within purple, is we try to spur innovation in the Wi-Fi drivers. So we collaborate, or we try to collaborate, with hardware vendors to make sure that their drivers are not just capable enough to support mesh, but that this is also done
in their open source drivers. So we do still support some proprietary drivers for some hardware, but this is very much transitional. And we hope to get various vendors to open source their wireless drivers
and make sure that all the functionality that we need is supported by those open drivers based on config 8.2.11 and all 8.2.11. And so why did we develop purple mesh?
So basically, like I mentioned, purple is a whole community of different service providers coming together to develop a single solution. So instead of everyone having to develop their own software,
it makes sense to collaborate. Also, by developing the software ourselves, the service providers, they get independence from system chip vendors. So what we've seen in the past and what we still sometimes see is that there are SOC vendors that try to force you
to use their own proprietary software and to depend on their proprietary interfaces. And that creates a vendor lock-in within the ecosystem. And that is something that we are very much aware of and are trying to combat as well.
And another good reason to develop purple mesh and, in fact, the original reason is as a stress test for the wireless drivers. Because, like I mentioned, Wi-Fi mesh,
it taxes your Wi-Fi drivers in ways that nothing else does. And that was kind of the original motivation of purple mesh was to act as a test for open source Wi-Fi drivers.
But it's kind of ballooned from there. And one other thing that we do is try to encourage the development of a common API for easy mesh implementations. This API is usable for remote management, for network diagnostics, and to enable others
to create router apps to configure Wi-Fi so they can plug into purple mesh and use it to smartly configure your own Wi-Fi. This also is enabled by the LCM project, which allows you to add apps to your router.
And some of those might use purple mesh to optimize your network or to show you more information about your network.
So let me check the time here. We do have time. So yeah, easy mesh itself, like I mentioned, it's based on IEEE 1905. This is a very extensible protocol on top of Ethernet
and Wi-Fi. So it uses a fixed multicast address. And the main feature of it is it works with TLV. So type length value doubles. And you can add as many of these as you like.
And the way easy mesh works is it defines a set of TLVs that have a specific use. So for instance, TLVs to configure access points or to report certain metrics or to discover devices
on the network, things like that. One thing that easy mesh does is it uses. So one thing that easy mesh can also be used for is discovery of devices on the network.
So all IEEE 1905 devices, they can report all of their neighboring devices in the network. And that helps you get a topology map of all of the devices that are present in your network. So it's easy to discover what's currently living in your network.
And so this is also, of course, a vital tool to allow you to optimize the network. And one other thing that we get is metrics, like I mentioned. So you can see how well the connection is between various devices that you
might have in your network, like your laptops and your smartphones and your smart TVs. How well is the connection to their access point? And is there any possibility that we can connect them to a different access point that has maybe a better connection? So this is also very useful.
And yeah, once we've determined that we would actually like a device to connect to a different access point, this is something that we can also do. So the easy mesh protocol includes messages to steer a device. And what we will do is the controller will tell the agents, try to tell a station connected
to you to disconnect. There's a number of mechanisms for that in the Wi-Fi standards, like 802.11k, 802.11v. They are not always supported by all devices. In particular, smartphones have a habit of ignoring them.
So what we can also then do as a final option is to just blacklist the device, not allow it to connect to an agent anymore. So it's forced to connect to a different wireless access point. Yeah, one other very crucial functionality is onboarding.
So if you add new agents, it's easy for them to find the controller, send them, and then on board through WPS or DPP, new standards from Wi-Fi Alliance.
In conclusion, Wi-Fi interferos, they are getting more complex. And that means they also need to get smarter. And that is really what we are doing
within the Purple Mesh project and Purple Ecosystem in general, is we are trying to make Wi-Fi smarter. And we can use your help with that. One thing that's also crucial to know
is that open source is also very useful to get vendor independence. So no more vendor lock-in. That is really a very big deal. And also, sometimes you can find open ecosystems out there,
even where you might not expect it. So all of the things that I've talked about is these router operating systems, this LCM App Store ecosystem, and Purple Mesh itself, it's all open source. But right now, it's still developed by the ISPs,
basically, and Purple Foundation itself. We don't get a lot of external contributions, but we welcome everyone who wants. So check us out when you can.
And related to that also, you can make good money developing open source code. So this is where I plug my own company, Mind. We are software consultants, especially focused on embedded software and open source.
And we are hiring. So I'll be around here outside of the hall after presentation. So hit me up if that sounds interesting to you. All right. Then, any questions?
So the operators and ISPs have previously gotten together and made something called HomeNet. And that went very much the same direction. And then they decided they didn't like it, because it supports you getting more than one internet provider
and using that at the same time, which this does not support. And this also doesn't support other things, for example, meshing well with Zigbee or home automation stuff. So I would ask you, have you actually evaluated whether this is a good standard to implement? Do you think this is a good standard to implement?
And if yes, why? Yeah, an interesting question. I am not familiar with this HomeNet you're talking about, although behind you, Walter definitely is. Maybe I can answer that, because I'm one of the operators. And I was in the home networking group as well. I rejected being the chair at some point in time.
HomeNet was very challenging in the sense that it decided to remove all existing protocols to communicate with the individual devices, such as, let's get rid of the HCP. Let's go do something else. So from a point of view of a realistic framework, a realistic path to get there, that was a problem.
There are some parts of HomeNet, such as HNCP, that have been reused by some proprietary vendors here and there. But it's all died. Now, when it comes to the lineage of EasyMesh, that's a whole different story. And why it's based on 1905, it was essentially a few companies that got together and said, what are we going to do? Are we going to do it at layer two?
Are we going to do it at layer three? And it's mostly based on internal pressures of, well, we have something that's 1905-based. It works together with our power line devices already. Let's use that as a basis. Wasn't too fond of it, but VHS versus a Betamax and V2000.
So to me, I still see value in HomeNet in trying to get some of the concepts in there. Now, the other problem with HomeNet, and I had the discussion with the chair at the time as well, is this mentality that there was that every access point had its own IP range,
rather than what the reality is in a wireless network in a home, which is that it's all a layer two. It's all one single layer two. If you do this steering that really explains where a device in milliseconds switches from one access point to another while consistently maintaining like a video call or something like that,
you're not going to get a different IP address. You're not going to restart your TCP connection or whatever. It doesn't make any sense. So doing this at layer two just makes a lot more sense and then the HomeNet concept of multiple segments and passing on from there.
So HomeNet does have the advantage that you don't need special hardware support in supporting the four frame 802.11 to get the data along. I do actually agree with most of your points, and I think that the best solution is somewhere in the middle between the two because this is so Wi-Fi centric that it can't really support things
that aren't Wi-Fi. But it is better for Wi-Fi itself, which I think is to a good degree your point, especially with the mobility. So the question is, is it possible to build both into one thing maybe? Let's continue this conversation.
Yes, so right. So that's the nice thing of being based on. So Wi-Fi alliance has focused purely on the wireless side. The rest of us are making sure that wired connections retain support, especially Ethernet. Now, the good thing about 1905 is that it is a protocol that supports also other,
not only Ethernet, but also other things. In 1905, that 1A added standard support for g.hn. So there is a modeling on top of MoCA, so you can have coax, a twisted pair, an in-home fiber, et cetera. Protocols are all supported. We just need to keep the Wi-Fi alliance almost from time
to time because their modeling using Wi-Fi alliance data elements of the network topology tends to ignore everything that's not wireless. But when it comes to supporting network ports on a particular switch, et cetera, that all comes natively in 1905. So that's fully supported by EasyMesh.
And we make sure that that is supported in PurpleMesh. Indeed, that is indeed very important. We try to go beyond Wi-Fi, as well as that. You mentioned that most hardware is not compatible, but can you give some examples, maybe, which hardware is?
Yeah. So what I think Qualcomm tends to be fairly good about their hardware drivers, you know, Broadcom is not as good.
So yeah, a message for anyone considering trying to make a new SoC, avoid Broadcom. A bit more detail, I did get Broadcom to agree to support this as well, and it is supported. There are some gaps in what the proprietary drivers support
at the moment, and will be supported in a later 2011. So Linux wireless does need to get upset. We've identified the gaps, and we hope to work with the host AP and the Linux wireless community to fix that. Now, me as an operator, I've given it a hard requirement to all our silicon vendors who want to do a gateway or an access point,
that they must comply with this. And we do have general support for it. It's just that every time there's a new standard coming out, such as Wi-Fi 7 now, that they first develop proprietary interfaces, and we need to keep them on the right track. That's a bit of the, that's the challenge, essentially. I did mention before that the Purple Foundation is also
involved in trying to set standards for Wi-Fi drivers and low-level API. That's my part, this low-level API, this definition of that. I'm the chair of that, to make sure that all the proprietary silicon uses standard Linux interfaces.
Some more questions? Someone over there. Hello. In terms of vulnerability management, is there a way for the agents to be updated from the central agent
or in some other way without losing connectivity, or would the need to patch something cause everything to drop? So if I understand correctly, the question is whether it's possible to steer a device without causing the connection to drop, right? Either steer it or, because you said
that it's highly demanding on the wireless driver to do that, so I'm guessing that in case you also need to patch something, you're risking the connection. So is there some handling internally to ensure that even during an update, it could be a running update, for example, one agent at a time or something like that. Is there some provision to make sure
that it's not going to cost connectivity if it does an update? Or is something that's still not being developed yet? I think if you reconfigure a network, like change SSIDs and so on, connection will drop. No? OK.
Yeah, my apologies. I'm not super into all of the technical details, but apparently there are ways to manage that so that your connections are not dropping. And I should also mention the virtual BSS project,
which we are also collaborating on with an organization called CableLabs. And there the goal is to have a single virtual AP per device, so basically an AP that follows your device around by means of speaking.
So it means that your phone, for instance, will always see the same AP, regardless of where you go. And this means that no connections ever need to get dropped when you move around. This is also a very interesting project that we are working on at the moment.
But in general, the answer to your question is no. The connection doesn't need to drop. Any more questions? So it is all very interesting. The question is, is there any off-the-shelf equipment which your marimortals may try that?
Yes, we have some reference hardware that you can just buy on Amazon or other places. So that's readily available that you can test for permission. So we have two reference devices, the GLINET B1300
and the Turis Omnia that are readily available. And we will be adding more in the future as well. And I guess it is mentioned somewhere, so I'm going to check. So if you go to our hit log page for PRPLmesh,
we have a lot of documentation on the wiki, including documentation about which hardware to get. So I think, you know, so yeah, actually, I had it there. So we have in the Getting Started guide,
we have a section here on device purchasing options. So as you can see, I would recommend the Turis Omnia and the GLINET. The NETGEAR-REX40 is no longer really supported because it lacks a crucial feature that's required for wireless back also.
I would not recommend that one. OK, thank you. My questions? I think we are good. There are no more questions for you. Thank you very much for the presentation.