 Hi everybody. So let me start by thanking you all for being here this late on day four to watch my talk and Let me just start by introducing myself and what I do So I've been an open WRT developer for more than 10 years now And I've been involved with the Linux wireless drivers pretty much almost as long and When I started thinking about what I'm going to talk about here at this Congress I I kind of look back to see what are the really important topics that kind of That I think about frequently in my work with with the project and one of the main issues That I come across frequently being a Linux wireless driver developer is What about freedom to extend those wireless drivers freedom to make changes to actually have decent drivers that are upstream and that are Not just usable for simple purposes of connecting to the existing network with your laptop But it can actually be used to build something more like the fry phone project building decentralized mesh networks like building your own access points and maintaining your own infrastructure and Software freedom in that regard and the freedom to program your own hardware are kind of a big deal so Let me first start by saying why it is such a big deal to have free drivers here in Many of the existing consumer access points as you've probably been aware during the last time There are so many security holes going on like if it's I've actually spent some time Looking at the GPL tar bowls of some of the routers that were exposed as being fundamentally insecure And I looked at where where these security holes are actually coming from or if it's something that people spent Months researching or if it's something that's really simple and what I found in many cases What was that it's something where somebody with a security background just spend a small bit of time Looking into these devices and these were the first holes that fell out So I guess you can you guys can expect for for lots of devices out there. There will be more security holes there will be more More remote exploits probably for for devices connected to the internet Simply because all of the code that runs on there is pretty horrible and to be able to change that you need to be able to Change the wireless drivers themselves as well because they're becoming a lot more complex And it's a lot harder to figure out what's going on and the more complex a piece of software is The usually the easier it is to find some bugs in there And that brings me to the second part stability Typically what you have in the normal consumer access point and with the drivers study that you get provided It's something that they tested in one particular scenario They may be test do do a test where they have some clients connected to it in an isolated environment And with a known configuration and if you deviate from that when building your own devices or making changes you can expect things to break horribly and and Just as well with these drivers you have a huge maintenance cost simply from the complexity of these source codes and free software goes a long way into Fixing these kinds of issues at the core by making sure that code is public code is Revealable for anybody who wants to see it and anybody can help make changes to make things more simple and more understandable And you can actually then go ahead and have Features implemented that are not deemed relevant by the vendors Like I pointed out to you earlier the fry from project in many places a big deal We've had some talks here about it as well and the ad hoc mode I think in many cases is simply not considered relevant by the chipset manufacturers at all yet It drives all these huge mesh networks. So if you don't have free drivers, how can you get that implemented? And so this is this is really what this talk is all about And to put it put it a bit more in perspective I like to present to you my like my journey through Linux wireless like how I started With very little freedom and what changed over time So when I began looking into my first wireless router there with WRT 54g We only had a binary only driver for Linux 2.4 Where we did some really horrible kernel hacks to be able to to push it forward and still make some kernel changes And it was really hard to keep like the full thing going and we couldn't make any changes to the wireless driver itself And it was only many years later partially replaced by an open-source driver based on reverse engineering But it never had the same degree of stability as this binary only module So as you can see not a lot of freedom going on there, but it was like the best thing we had at that point to build access points So what then came up came along a bit later in the game was the mad Wi-Fi driver Which is partially open has a binary only component that still runs in kernel context But at least it was free of any sort of kernel version dependencies and actually a large part of the driver Was open so we could do a lot more tests. We could play with the our talk mode We could play with rate control algorithms and all these things But of course still not fully free and there was still large parts that we simply could not touch properly Until it was later freed up by a proper upstream driver Of course, this also came years after After the original project that was still dependent on non-free binaries And it was basically a few years too late to be really relevant for a lot of research because by the time It became practically usable for many things the hardware was already pretty much outdated and But it it was still a useful prototype for developing Mac editor to 11 features so for the core wireless infrastructure of the Linux kernel and actually used it myself to develop The the basic form of the rate control algorithm that is still used by many drivers in the stack today But this was not really the most interesting part of my time in playing with Linux wireless Because what came afterwards was the f9k driver and now for the first time from from a ferrous Which made the most popular chipsets in the community. They actually developed the driver themselves and They published it and they upstream it upstreamed it themselves So this was really a big step forward and unlike the the earlier attempts at doing drivers with mad Wi-Fi This one was completely open and to the last bit So you could actually see how it tuned the radio parameters You could influence the code that messed with the tx power You could change the parts where it sets the frequency and you could play with lots of low-level radio parameters So this was really the dream driver for research projects for innovative things for building your own access point And for all that but even getting that usable was kind of a big deal because They the initial development was only prompted by customer demand from a laptop customer So they wanted to have Linux on their laptops where they were shipping with the Theros wireless cards And they wanted it to be usable on Linux itself So they forced Qualcomm a Theros or a Theros that was as it was only known back then To build this driver and actually push it upstream and this is one of the examples where actually Knowing about the values of free software doesn't give you much room in a chipset manufacturer Yes, we actually have to have the customer demand to be able to influence the decision making and of course since it was there And it was supporting chips that were not just used in laptops, but also similar chips That made it into access points There was a strong push from the community to open up even more code and documentation and kind of push the whole thing forward I myself Invested maybe more than three years of work into making this driver usable for production environments And it had the nice effect that actually at some point it was stable enough that Customers of a Theros that were doing embedded hardware actually started asking a Theros for commercial support on the S9k driver Instead of the reference driver that they just provided as an SDK And of course at that point in time They had never imagined that they would support S9k in such a configuration So they looked at who's doing all this work in the community and which was me for a large part And so they sent their own customers to me for support But now there were also quite a few issues with S9k a lot of work to really make it stable and usable came from the community because the vendor was unwilling Unwilling to invest any sort of significant resources comparable to their own internal development in making this driver better Additionally, there was there were many people involved in the company from the community They were actually pushing internally to be able to provide better open source support and have developers commit resources to that But this this progress was often very slow because of high turnover like at one point Yeah, the one engineering manager or project manager convinced that this whole open source thing was not going away And it was actually a useful thing and then he moved to another company and the next guy It was just as locked down as the other one was initially. So it's a repeated effort and It's it's really hard to kind of make this sustainable Whereas when customers demand a feature they usually jump immediately because they want to generate sales So these open source drivers really had Very limited resources like with f9k at some point It was two people working on it and then it just became one and then the one guy never really had much time So after some point there were not really that many contributions from a pheros or later QCA themselves it was basically maintained by the community and During the time where they actually try to figure out if they could commit more resources They also had some crazy ideas on how they could unify the f9k code base with the code base of their internal Driver and kind of sync it up both ways and have some ways of Maintaining control of a development direction of the open driver Which in some cases really goes against the Linux development model So kind of also made things harder because they were not really ready to commit to that Before they had they would figure out this whole unification thing which was impossible to figure out properly Now the biggest issue with us 9k is of course the 8 or 2.11 n chips that it supports They're going away and they have this new driver called as 10k for the 11 ac chips And it's actually named after as 9k with just a number increment because they wanted to really achieve the same sort of thing Of course, it didn't work out properly because of poor planning and other things and I'll get to that later But basically was horrible enough that I decided to stop working with QCA and figure out some alternatives so Media tech came along and they actually They're much smaller than Qualcomm, so you have less of this this bureaucratic BS going on and they actually Did found out that this open source thing is really nice for various reasons which I'll get to later And they decided they actually want a Mac 8 or 2.11 upstream Wi-Fi driver They just didn't know how to create such a thing So I offered them some help with in that regard and I started Writing a new driver for the chipsets from scratch which took me about a month of work But it was contract work paid paid for by them and in some ways It's it might be a suitable replacement if we can get enough hardware with this chipset going on For the things that were previously done with as 9k So one of the issues with that is there's like in as 10k There's a proprietary firmware that controls some things which is obviously it goes against the things that we want But the good thing about this chip is this firmware is very small and very simple So it only sets the channels and it only does some Calibrations which are the things that it might be interesting to some research projects But in many ways, it's not relevant to the day-to-day things that we want to do with this driver So the driver actually has the possibility to control the entire data path Which is what we need to build mesh networks to the rate control and software and all of these useful things So it's not as free as as 9k But it's it's usable and I hope someday to convince them to open source the firmware as well Which maybe will be possible because they've already figured out that open source is a good idea so Okay now to the point Now let's see what's wrong with as 10k and I thought a bit about like how to how to present this and In the end decided to show it with some pictures that I hope will match the intellectual level at which I assume the decision-making was going on So let's start with the first one which is kind of a big deal We have the stoner guy they create a successor to a popular free software driver But they put all the interesting parts in proprietary firmware. How nice So I was kind of deciding whether to use the stoner guy or the scumbag Steve here But then decided to go with Hanlon's razor which says never attribute to malice that which can adequately be explained by stupidity So to the next point they wanted to offload all the things that they could offload they finally had a microcontroller on there which was reasonably powerful and They were building a firmware with lots of fancy abstraction and they decided all we're going to do it like with the mobile chips We're just going to offload everything because they basically combined their mobile development unit with the network development unit So they would use the same approach for mobile and for the access point designs, which yeah It might save some resources, but of course There's lots of different requirements and like putting everything together is a bit hard and offloading all the things to proprietary firmware kind of Completely goes against what we as a community need or what people need to be able to build flexible devices So they decided they they offload scanning they offload lots of power safe handling They offload large parts of the data path. They do rate control entirely in firmware So we if the rate control is crappy and it actually is We cannot replace it. So that's kind of in the way of many useful things And that's also a big reason why I decided that I don't want to be involved with F10k any more than I have to So on to the next point which is kind of a funny one They actually put a lot of effort into designing fancy abstractions to keep the firmware compatible While their own internal engineers were basically treating the firmware as an extension to the driver so in the end they changed the Firmware a bi compatible layer pretty much with any version that they made and any branch that they made Defeating the whole purpose of the entire thing So if you actually look at the F10k driver, you have like five different Firmware interfaces and firmware APIs were depending on the version of the firmware and Sometimes just on the version not on the actual chipset You get a completely different API and it just handle has to handle all of those Because the Linux kernel is supposed to be compatible with firmware changes and everything So it's a big mess and I don't see anybody cleaning that up anytime soon. So Actually when I started looking into F10k before it became public I decided yes I could get involved in that mess if I wanted to but it would have been a multi month full-time job just to clean up that mess with Let's say slim chances of it actually succeeding in the long run due to the bureaucratic decisions at that level So I decided against it and decided well another manufacturer might just be more understanding when it comes to open source So to the last minor point with the driver They decided oh, well, we it's it's we don't just use plain 802 11 frames from the driver and then send those out It cannot be that simple. So they figured out a fancy mode which they called native Wi-Fi And I think this is actually a Microsoft term So they use the property of like the the Windows networking stack where it has some fake 802 11 headers That the drivers expected to put in there and they put that in silicon and they expect the Linux driver to like take the full 802.11 headers replace them with fake ones so the hardware can then replace those with the real ones while transmitting the packets So I spent a lot of time here talking about Qualcomm atheros So let's take a short look at what's up with the other vendors So you have Broadcom there they made actually made a soft Mac driver for some of the recent chipsets But they only made it for like one or two Generations of chipsets and not really for the 802.11 AC ones and they decided for the new stuff They're only going to support full Mac where it means that you don't even have the 802.11 data path in software You basically send in ethernet frames and you can configure some things But you have no freedom to actually have any sort of flexibility there And this is a trend that we're seeing with with other kinds of devices as well Like with with Marvell. They also have some full Mac devices though thankfully mostly limited to the mobile ones But they kind of follow the same trend as as 10k with the development of the the AP chip sets. They also Offload more and more things to proprietary firmware, which they also Frequently change they also have no real stability in the firmware interface and they kind of take away all the control But still have enough Boiler plate code in the kernel to be say to be saying we have a linux upstream driver But it's just unusable for for any purposes that go beyond the simple access point or simple client cases And you have really the same with Intel except that they're much more limited they have some AP support for a few chips But nobody uses it. So typically if you try it as a few people have done It doesn't work Because nobody ever uses that stuff or maybe some people use it in limited configuration to do Wi-Fi direct but for any real usage no not usable and With real tech you have something similar going on They keep cranking out new chipsets every now and then where they have different drivers all the time And they also put more and more stuff in firmware So it's it's all pretty much headed in the wrong direction and we have to focus on the few choices that we have Where we were kind of closest to where we need to be and I hope to be able to to build something like that based on media tech If they can manage to to properly stay on the market So in all of this discussion and dealing with chipset manufacturers There's lots of challenges which present a very small set of opportunities And I like to talk about what the the issues in working with the chipset manufacturers are so Educating them is kind of hard as I as I Pointed out earlier with Qualcomm a theorist They have lots of bureaucracy there and sometimes you have enough people to push internally for for putting open source On the agenda, but in the end most of the people there will not care And most of the people there will just go with the cheapest option where where they don't have any any sort of Cost that they cannot attribute to a particular business case or a particular like set of specific clients And they also expect their clients not to care about open source Which has the result of their clients actually not seeing anything usable based on proper open source So they don't know how to ask for it But if some customer has some people inside that are actually very smart about open source They can easily push for the chipset vendor to to make some changes to their roadmap But only if they're big enough in volume one of the really good examples here is is Google Chrome OS because they actually had people in there in the teams that dealt dealt with the chipset manufacturers that cared a lot about doing the right thing and Initially, I think they only demanded that all of the drivers that they get from chipset vendors are open source And then they found out that this is not enough because then they get tarbles of crappy vendor drivers That are still hard to integrate so they changed that over time to demand that the drivers need to be upstream So suddenly the chip vendor is forced to adhere to a quality standard controlled by the kernel community, which works much better So the big question here is can we engineer customer demand for free drivers? And I'd like to leave that for the discussion later because I think that's that's really the easy easiest possible way to make some changes to that ecosystem and one of some of the ways that we can do this that I found all that kind of work is Educating big customers with enough volume that open source is a nice way to kind of save on development costs because as as many many vendors that combine Silicon from different vendors they typically find out pretty quickly that all of the reference software for their hardware is only tested in very very limited Constellations and typically only with the default modes that the reference SDK is designed to use So if you if you deviate from that and if you kind of put it put a driver for from a different vendor in it in a Different the system with it with a system on chip from a different vendor Then you have all these kinds of mismatches through the hacks in the various trees Because vendors always assume that you're going to source everything from them and if you educate them that with with free drivers and Free kernel code and if it's all upstream then they don't actually have to worry about mixing those combinations anymore because typically kernel drivers are tested in lots of very diverse and very varying conditions with different platforms and typically a Driver for a system on chip is written in a way that it often does not depend on hardware support for that particular system on chip But it that it allows to be compiled with lots of different architectures for which it's it never will be useful Just to make sure that the code is written that is written is clean and portable and is supported in many different Configurations and with those kinds of quality standards You have a lot easier job of integrating all that in your own board if you're building a new system Then if you just get some random driver blob that was tested in one configuration But can be expected to to fail epically in various other configurations And I think a big deal in educating those customers is also to to provide good reference code and examples like actually had many years ago, I had a meeting at Broadcom and When I was still working for QCA and I sat down with some of the managers there and there was one guy responsible for the Embedded SDK part and he actually told me oh, yeah We are fully aware of open WRT because customers frequently ask us for features that they see there And then we have to go and build them ourselves And so this is something that that works You you show you show people what they can actually get with a decent platform with decent source code And then you tell them now go and demand this from you from your chipset vendor and depending on the size This can have a real impact There's actually a third way that has also turned out to to be very useful in some cases supporting GPL enforcement action because if you have a group of People enforcing the GPL against a particular router vendor or ODM and they've been caught repeatedly and They there's a lawsuit going on and they kind of see that they're on the losing end of this lawsuit It's nice to be able to tell them now if you were to use open source software You would have a lot less issue with the licenses You would just publish that and you would just have clean separation between the the open source code and the proprietary code It would all be much easier because in many cases It's actually not the ODM or the router manufacturer that's directly violating the GPL But they get reference code from the chip vendor which is really fishy with Licensing and you have that very frequently because the chip vendors are worried about the unique selling points and They so they they worry about marketing market differentiation and at some point they decide all building better hardware is hard Let's just differentiate by doing different quirky software and It's that I always see the analogy there that they're constantly fighting whether the wheel should have five or six corners and They still haven't figured that one out in the meanwhile We're building something that's supposed to have round corners, even though they aren't fully round yet But they they haven't figured out that this would be a nice idea yet Maybe we should tell them So then there's another key player that kind of spits in our soup here, which is the FCC It's it's always a bit of a love-hate relationship with the FCC because I think in some ways Sometimes they have demanded some good things like in the whole net neutrality debate They might actually be on the good side. I don't know. I haven't really followed much of that But here in the Wi-Fi space. They're really problematic because they noticed that some people put up some access points where That we're interfering with better rate weather radars and they looked at okay Where does this come from and then they see oh there's people there that are tinkering with their radios and Maybe they shouldn't do that. Maybe the tinkering is what's causing these issues So they basically treat user access to flexible radio devices as a bug that they can fix by policy And so they decided oh just going against the users is hard because there's so many of them We'll just make the hardware manufacturers are lackies and we just make them responsible for ensuring that the user has no control over his own device and This of course generated a strong backlash in the tech community from some key people that were responsible for a large part of the development of the internet actually and I guess they didn't quite expect that I think I think they thought that those this was just be would just be really Uncontroversial because they only want to make sure that the weather radars aren't messed with and they actually Made some revised rules based on the backlash But in some cases, they're really just as bad as the original ones like there was this this thing where they actually in the earlier version asked router manufacturers to Describe how they will prevent something like the free firmware DDWRT from being flashed onto the device and they had to show how they will prevent that and In the new rules they came along said oh well this was really not our intention to lock down the full devices and Our intention was only to make sure that they cannot touch the radio part But the kind of the concept that was pointed out to them repeatedly that they simply Refused to understand is that there's a big difference between the intention and the likely outcome And this is this is the part where they're still struggling to understand that concept Because they still maintain that oh well, they're only going to lock down radio parameters And they're not going to touch anything else But I've already heard from some silicon vendors that they already figured out that locking down only the radio is hard Locking down the entire platform is so much easier. So and so much cheaper. So let's just do that because nobody cares about that, right? Something that was pointed out to me in in an earlier talk at this Congress, which I found really interesting was there's a Interesting coincidence in timing between those rules and the appearance of a secondary user of the spectrum called LTE you which are it seems that they're attempting to do a land grab of like the the the unlicensed spectrum because Their license spectrum that they fully controls apparently not enough for them to guarantee the bandwidth that they want to have So they decided all let's just grab some of that Wi-Fi Nobody's using it, right? And so we really have to figure out how to deal with that. There's lots of people that are doing active campaigns You can find on the news sites That where people are complaining about the FCC, but one of the the main issue is there's many people Don't seem to get that it's just as important to fight against the part of locking down the radio parameters Then it is to fight against the lockdown of the full platform Because there's so much research going on so many interesting things like friends of mine are Developing a way to dynamically adapt the TX power of of the radio per station So if it figures out, oh, well this note is closer Then it can lower the TX power while getting the same throughput, which I think I think will do a lot of good things in for large high density networks and When having lots of access points and crowded spaces But the problem is the changes to the new chipsets are making it increasingly impossible to deploy something like this because all the access to the hardware level that we need to be able to build Something like that is going away based on some lame excuses And we have to figure out how to push this debate in the right direction Make it clear to people that just going for the convenient option is really not enough in this case And we also have similar problems in the EU actually the ETSI has decided to do something similar like that Which in some cases even goes beyond the scope of the FCC We I think we still have a bit more time to influence that one because it's it shows up as a EU directive and it still has to be implemented by the various countries international law and that gives us some leeway to to like in the individual countries Motivate some politicians to fight against those parts as well But I I can't give you many details about the inner workings of that one because I try to stay out of politics I just figured it was important to at least mention this because it's kind of becoming a big deal So what happens with all this hardware lockdown? That as I mentioned before the chipset manufacturers are already considering hardware lockdown to have an easier way to deal with the FCC rules And then there's the router manufacturers that are already already partially doing it In some cases maybe as an excuse to cut down on support costs by people that are reflashing The devices to custom operating systems in some cases. It's actually the excuse was we want to prevent Chinese clones I think this was the excuse that ubiquity networks uses whether they have some really popular outdoor equipment Which gets deployed in fry funk frequently and now with the new devices They actually locked down the bootloader and prevent flashing of custom firmware and they said oh, yeah This is about the Chinese clones and everything and It's in some cases I've seen the lockdown also be used as a very cheap excuse for market segmentation Because if you can in one market Cripple a few features and sell it as the basic version And then you have the same piece of hardware and you just put a different piece of software on it and a different key And it unlocks the full features You can have like different target groups and you can just enforce by some DRM schemes That people don't just change one for the other and what I'd really like to discuss with you guys What can we do about all of these things? I've put down a few few ideas like spread the word on on the FCC issues There's another point here, which I did mention before which is we can all analyze the security of the existing devices out There just to make the argument much more compelling that locking down these devices will actually prevent people from fixing the devices because they come shipped by the manufacturer buggy as hell and Making it very easy for attackers to get into your network and there has to be some way to have hardware that is actually fixable and if we just make sure That we we show that this is an industry-wide issue and that actually pretty much all of the standard routers out there are running Horrible software, which will have horrible security issues Then maybe we can show that this is this is kind of a big deal And one of the other things that I would appreciate some real help with is Writing free 802.11 drivers as I mentioned before the empty 76 driver with the experience that I've built over the time I built that thing basically in a month and now I'm adding support for a second chip set where I've put About five or six days worth of work in and it already does monitor mode and it sends some packets So I can do a bit of scanning and just like more people to get involved with that field So that we have the resources that when a chipset vendor comes along and says we want an open source driver But we need some help that we have a pool of people that can actually look at that code and Improve that code and write some free software drivers And it I can tell you from experience that it's a pretty exciting field to be in and it's a really really nice feeling When you brought up a large part of code For the first time and for the first time you see our now money to mode is working and I can actually send packets And I'm just making progress over time and it's I think it's a lot of fun And I hope that more people will figure out that it is a very interesting field in a very challenging field And one of the things that I just discussed with a with a friend of mine Some minutes before this talk was I think we should get together and create some some written material or some presentations specifically tailored at decision makers in big chipset vendors and big router vendors probably differentiated by target group where we figure out like what world are they living in like what are the concepts that they're used to thinking in and just Create something that is framed in a way that it will provide them with compelling arguments to do open source And I hope to get some some feedback from maybe from you guys or from people watching the streams later On how we can create something like that And this is really all that I have for now, and I hope you brought some really good questions Yeah, thanks a lot for your presentation that was really interesting Assume somebody is already a pretty decent C programmer So what's the best way to get your feet wet with Colonel driver developing especially in the realm that we were just talking about? I Mean how to get into that field how to figure it figure things out or I don't consider myself a good enough C program I to be quite honest and probably don't have the resources I just wanted to invite you to To give some practical advice how if somebody has the resources and some in the skill set You know the C is C skill set and some understanding of Linux programming or kernel programming What does he or she do to really start? Getting into that community. I think in some ways. It's actually pretty simple You just pick something where you find a device on the on the net That can do Wi-Fi and you figure out that Linux support for it is working to some degree But it's not fully working and then you just start playing with it You start experimenting if you can figure out what's actually going on if you can write your own debug code to figure out How the hardware works and you just start playing with it and see what happens? I think that's the best motivation to get into something like that to not have a specific plan Like I need to do this and these are the steps But actually play with something on still until you start to understand it more and just enjoy that process Hello, thanks for the great talk I have a question about firmwares. So from what I'm aware There are very few Wi-Fi chips with free firmware. Yes, and I think this is a probably not really Investigated security issue because especially if you have a PCI device then a bug in the firmware You can basically own the full device through a DMA attack. Yes And do you think there's what's kind of the status with firmware and do you think there's a potential to get more A chip that's with free firmware and yeah so far The fight is already to at least get some free drivers And I think free firmware it goes a few steps beyond that and I think it's a very important fight to have And I fully agree that it's a big deal with with regards to security They pointed out with the F10k firmware They have the approach of offloading everything and they they have some fancy bits in there That actually parsed TCP packets and do some funny things with those and they do some other protocol related things as well So I expect that there will be broken code there and there will be ways to exploit that and It's just not that the awareness of that It's just not very widespread yet because there haven't been many practical attacks on such firmware yet one question from the internet yes Which laptop manufacturer do require either us drivers? There aren't that many laptops anymore with Ethereus drivers. I think it was a for a for a short period of time There were a few laptop customers that that used it I Don't know if they actually shipped large quantity, but these days Qualcomm ethereus basically gave up on building cards for laptops on the left Are there any Wireless card chipsets that you would recommend in terms of firmer openness where the The firmer is open for those cards and this production grade. Let's say and Hacker both have to speak I know only of one such thing. It's an old ethereus 11 and usb device where During the the height of like the people lots of people working inside ethereus fighting for open source actually managed to convince Management to release the firmware for that one. There hasn't been that much Development afterwards mainly because the firm was only opened after the device was already long obsolete But it's if you look for devices supported by F9k HTC You will find an open driver and open firmware and you can you can compile everything there. Thank you Please Hi, thanks for all the work. You've put in over the time. I'm a very happy user of open WRT. So thanks a lot I dabbled in trying to do some work in free BST for some ethereus chips And that was a couple years ago when ethereus was willing to give out documentation Are there any vendors that are? Easy to deal with in getting documentation. I am not afraid of signing any NEA's or something like that, but like I Think many vendors are very reluctant to give some random guy Documentation on the hardware. Well with with media tech. I now have a working relationship So if you want to work in that field and on such drivers, I could probably introduce you and I For my own work I got the documentation under NDA and maybe I can convince them to hand it out to a few other developers as well to make progress there All right. Thanks. Yes How we can push manufacturers Where are you? From the IRC chef from the IRC. Okay. How you can push hardware manufacturers? Which one's the chipset or the routers? I think it was referred to slide 20 okay The the hardware manufacturers it depends on at which level like that the hardware manufacturers themselves If you can get the right contacts, you will find You sometimes you only have to connect their engineering departments with the people making the decisions because they will have learned about the frustrations of using crappy vendor SDKs and They will appreciate having something open But they just need to realize their power that I can actually ask the chipset manufacturers to provide something like that When it comes to chipset manufacturers, it depends if you're like the If you're talking to the market leader like Broadcom in many ways they simply don't care much about Doing something open because they already have a good position and they already know the value of their chips and their software and They they are likely not seeing anything wrong with what they're doing. So in some ways you probably have to go for the underdog and Help give present present them with some opportunities to sell more hardware like with some of the chipset vendors that I looked at I I guess they must have been losing customers with a crappy state that their software is in and They must at some point realize that better software can actually lead to getting more customers Yes It's very Good feeling that when I saw your Commit messages that the whole source code is occupied with your email ID in there so my question is I'm a Beginner, I mean I have good knowledge of CNC programming and I would like to contribute something I would like to know is there any webpage or the IRC channel where I can have a interaction with the people Who are contributing there? Which part Linux wireless or open WRT or which one yeah drivers I think there's not much Coordination going on among Linux driver developers. It's like people doing their own thing and then Discussing patches on the mailing list there is a Linux wireless summit frequently, but it's mostly interesting for people that already like regulars in in dealing with it with the drivers and I think I don't know if they have any sort of beginners workshops But I think you can you can easily get in touch with people if you just pick something That's there that you would like to play with and you just start making some patches fixing some bugs playing with a device or even asking for advice on On a technically detailed level I think if people notice that somebody is coming along and Caring about not just how can I do this but like what are the specifics of this and this in this part? They can probably find the motivation to help them along and to get them involved in discussions So I think there's lots of ways Simply by playing with something yourself that you can get into that field I have a question about something. I don't understand in this issue as your talk has the title freedom considered harmful What is it actually that they consider harmful? What is the vendor incentive not to publish this as open source instead of Locking it down. I understand of course the incentives for publishing it at all source, but why are what is the reason for them not to do it? some of the reasons are They're always afraid of losing control In many ways it in many ways they get the impression that if they publish something then other people will do different things with that and They have no control over what happens with a result and apparently on many levels that matters a big deal to people and Then there's also like big corporations like welcome They fully buy into this imaginary property kind of thing and especially that like the Qualcomm itself Their business is as far as I know patent licensing and anything that's even remotely involved with open source has to be a separate company just to to keep the lawyers happy and The lawyers themselves are also Establishing lots of paranoia about all the bad things that can happen if you publish open source software Like it might in the fringe on somebody's else's rights And if it's not published as open source it might still be there, but at least people won't see it and In some cases companies might also be be embarrassed to to show the quality of their software to the world Okay, thank you From the IRC. Yes How big should a customer be to make the vendors doing free software? I think in some cases it actually depends on having like at least a million chips per year or something a comparable volume So it typically has to be big to matter Small companies with 10,000 or 100,000 units are probably not big enough to convince a chipset vendor to change its ways Okay, I guess this was it. Thank you very much Another question We got another question from the IRC. Yes Why do the vendors need to be nice? They have no profits from using their hardware for researchers because they lose the possibility to sell them Research-grade hardware at much higher prices How how are you going to make them to be nice? Well The thing with with all kinds of research is a lot of the useful research that they benefit from if it's open source Comes from people that don't just go and buy expensive research equipment And many of the vendors are actually not in the business of selling expensive research equipment And that brings me to to another point Which which I heard actually from from a theorist back then when they were more open towards open software They actually said that Having lots of small companies that are able to build hardware That can support themselves simply by having open source software where they don't need to use the support channels of the vendor They they all combined might actually produce the volume of one big customer So it it's it is actually a way to increase sales and it is actually about many more things than just being nice there There's a lot of benefit to be had from that It just depends on more people making compelling compelling arguments in that space I think in many ways, it's if you look at it from the perspective of the people in those companies It is easy to find a kind of a frame or a mindset in which you can explain open source in a way That makes sense to them from from a financial point of view as well Okay. No, this was really the last question. So Thanks again, thanks for the work you do without you. Thank you all