Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/613 Thanks!
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 WTT developer
for more than 10 years now, and
I've been involved with 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, uh,
I kind of looked back to see what are the
really important topics that kind of,
uh, that I think about frequently
in my work with the project.
And one of the main issues that I
come across frequently, being a Linux
driver developer, is
what about freedom to extend
those wireless driver's 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 can
actually be used to build something more
like the free from 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 it's
I've actually spent some time looking
at the tar balls of some of the routers
that were exposed as being fundamentally
insecure.
And I looked at 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
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
lots of devices out there that will be
more security holes.
That will be more more
remote exploits probably for
for a device 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 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 one building
your own devices are making changes.
You can expect things to break horribly.
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
to fixing these kinds of issues at the
core by making sure that code is
public. Code is reviewable 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 it features implemented
that are not deemed relevant by the
vendors.
Like I pointed out to you earlier, that
the Triphone project in many places is 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'd like to
present to you 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 were 50 4G,
we only had a binary only driver for
Linux, two point four, 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
the whole 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 then came up, came along a bit
later in the game was the 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 ad hoc
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 was still a useful prototype for
developing Treleaven 11 features.
So for the core wireless infrastructure
of the Linux kernel and actually used
it myself to develop
the basic form of the ray 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 assigned driver
and now for the first time from
from Atheros, which made the most
popular chipsets in the community,
they actually developed the driver
themselves and they published
it and they upstream, upstream to
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 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 Atheros
wireless cards, and they wanted
it to be usable on Linux itself.
So they forced Qualcomm,
Atheros or Atheros.
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. You actually have to
have the customer demand to be able
to influence the decision making.
And of course, since it was there and
they 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 had the nice effect that actually
at some point it was stable enough
that customers of a
that were doing embedded hardware
actually started asking Atheros for
commercial support on the S9 K
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 ethnic in such a
configuration.
So they looked at who's doing all this
work in the community and which was,
uh, 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 S9, K..
A lot of work to really make it stable
and usable came from the community
because the vendor was unwilling or
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 that were actually pushing
internally to be able to provide
better open source support and have
developers commit resources to that.
But this progress was often very slow
because of high turnover.
Like at one point you had 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 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 asthma, I think
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 Atheros 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 ethnic code base
with the code base of their internal, uh,
driver and kind of sync
it up both ways and have some ways of
maintaining control over the 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.
And now the biggest issue with us, Kenya,
is, of course, the not 11
ships that it supports, they're going
away and they have this new
driver called as 10K for the 11
ships and is actually named after
S9 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. Now, 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 Mediatheque came along
and they actually
they're much smaller than Qualcomm.
So you have less of the bureaucratic
B.S. going on.
And they actually
found out that this opensource thing is
really nice for various reasons, which
I'll get you later.
And they decided they actually want a
macchiato. Treleaven upstream Wi-Fi
driver, they just didn't know how
to create such a thing.
So I offered them some help
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,
uh, it might be a suitable replacement
if we can get enough hardware with this
chipset going on, uh, for
things that were previously done with S9.
So one of the issues with that is
there's, uh, like in our 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
Disfarmer is very small and
very simple. So it only sets the channels
and it only does some calibrations,
which are the things that 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 do rate control and software
and all of these useful things.
So it's not as free as Alstyne, 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.
OK, now to the point.
Now, let's see what's wrong with
our 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 and 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,
oh, we're going to do it like with a
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 if
their 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 10K 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 abi compatible layer pretty
much with any version that they made
on any branch that they made, defeating
the whole purpose of the entire thing.
So if you actually look at the 10K
driver, you have like five different
firmware interfaces and firmware APIs
where depending on the version of the
Fermor and sometimes just on the version,
not on the actual chipset, you
get a completely different API and
it just 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 any time soon.
So actually,
when I started looking into our 10K
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,
uh, 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
while 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 plane eight or two, 11
frames from the driver and then send
those out. That 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 eight
or two, 11 headers that the driver is
expected to put in there.
And they put that in silicon
and they expect the Linux driver to
like take the full to the 11
headers, replace them with fake ones
so the hardware can then replace those
with the real ones while transmitting the
packets.
So I spend 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 softmax
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
11 AC ones.
And they decided for the new stuff,
they're only going to support Fulbeck,
which means that you don't even have the
2011 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 Fulbeck devices,
though thankfully mostly limited to the
mobile ones.
But they kind of follow the same
trend as I think with
the development of the the app chipsets.
They also offload more
and more things to proprietary firmware,
which they also frequently
change.
They also have no real stability in the
interface and they kind of take
away all the control but still have
enough boilerplate
code in the kernel to say to 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 basis.
And you have really the same with Intel,
except that they're much more limited.
They have some HP 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 use.
Uh, 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 mediatheque
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'd like to talk about what 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
Atheros, they have lots of bureaucracy
there and sometimes you have enough
people to push internally for
for putting opensource on the agenda.
But in the end, most of the people there
will 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
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 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 tarballs 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 that's really the easy, easiest
possible way to make some changes to that
ecosystem.
And 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 the
hardware is only tested in very,
very limited Constellation's 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 from a different vendor
in a different system or with
a system on chip from a different vendor,
then you have all these kinds of
mismatches to 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 Koln 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 that it allows
to be compiled with lots of different
architectures for which it
never will be useful, just
to make sure that the code is written
that is written as 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
than if you just get some
random driver blood 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
I 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 for the embedded SDK part.
And he actually told me, oh, yeah, we are
fully aware of Open 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,
uh, works, 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 the from your
chipset vendor.
And depending on the size, this can have
a real impact.
And 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 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.
It would just publish that and you would
just have clean separation between the
the open source code and the proprietary
code. And it would all be much easier
because in many cases it's actually not
the GM 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 then
worry about marketing market
differentiation.
And at some point they decide, oh,
building better hardware is hard, let's
just differentiate by doing
different quirky software.
And 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
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, uh, kind of spits in
our soup here, which is the FCC,
um, 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, uh, in
the whole net neutrality debate, they
might actually be on the good side.
I don't know. I've never really followed
much of that. But here in the Wi-Fi
space, the really problematic, because
they noticed that some people
put up some access points where,
uh, that were interfering with vital
trade weather radars and they looked
at, OK, where does this come from?
And then they see, oh, there's people
there that are tinkering with their
radios and, uh,
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 lackeys 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 this was just B would just be
really uncontroversial because they
only want to make sure that the weather
radars aren't messed with.
Um, 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 just this thing where they
actually, uh, in the earlier
version, as droughty manufacturers
to to describe how they will
prevent something like the
free foam party from being flashed
onto the device.
And they had to show how they will
prevent that.
And in the new rules, they
came along and 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 refuse 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 are 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.
And.
Something that was pointed out to me
in an earlier talk at this Congress,
which I found really interesting, was
there's an 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, uh,
the the unlicensed spectrum
because they're licensed spectrum
that they fully control is apparently not
enough for them to guarantee the
bandwidth that they want to have.
So they decided, oh, that's just, uh,
grab some of that Wi-Fi.
Uh, nobody's using it.
Right.
And so we really have to figure out
how to deal with that.
There's a lot 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 than 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 power of of the
radio station.
So if it figures out how well this note
is closer, then it can lower
the tax 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 in
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,
which I think we still have
a bit more time to influence
that one, because it's, uh,
it shows up as the 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,
uh, motivate some politicians
to fight against those parts as well.
But I I can 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, 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 partially doing it,
in some cases maybe as an excuse
to cut down on support costs by
people that are flashing 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 users, whether they have
some really popular outdoor equipment
which gets deployed and triphone
frequently.
And now with the new devices, they
actually lock down the bootloader and
prevent flashing of of custom firmware.
And they said, oh, yeah, this is about
the Chinese phones 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,
the different key, and it unlocks the
full features.
And 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 is what can we do about
all of these things?
I've put down a few few ideas,
like spread the word on the FCC issues.
There's another point here which I didn't
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 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 eight to 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
chipset 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.
I 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 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 are
now manito 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 and a very challenging field.
And one of the things that I just
discussed with with a friend of mine
some minutes before this talk was
I think we should get together
and create some some, uh, 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 and and just,
uh, 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.
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 Triva
developing, especially in the realm that
we are just talking about?
You mean how do you get into that field,
how to figure it, figure things out or.
I don't consider myself a good enough
C programmer to be quite honest and
probably don't have the resources.
I just wanted to invite you to
to give some practical advice.
If somebody has the resources
and some of the skill set C
C skill set and some understanding
of Linux programing or kernel programing,
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 still until you start to
understand it more and just enjoy that
process.
Um, hello. Uh, thanks for the great talk.
Um, I have a question about far.
So from what I'm aware, there are
very few Wi-Fi chips with free
from firmware. Yes.
And, um, I think this is probably
not really investigated security issue,
because especially if you have a PCI
device, then back in the firmware,
you can basically own the full
device through the tech.
Yeah. And do you think there
was kind of the status was firmer
and do you think there's a potential to
get more chipsets with free
firmware?
And yeah, so far,
um, the fight is already to
at least get some free drivers and
I think free firmware, that goes a few
steps beyond that.
And I think it's a very important
fight to have.
Um, and I fully agree that it's
a big deal with with regards to
security.
As I pointed out, with the 10K firmware,
they have the approach of offloading
everything and they they have
some fancy bits in there that actually
pass 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, uh, it's just not
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 is
which laptop manufacturer to require
Atheros drivers?
Um, there aren't that
many laptops anymore with,
uh, various drivers.
I think it was a four for
a short period of time.
There were a few laptop customers, uh,
that that used it,
um, that I don't know
if they actually shipped large
quantities. But these days, Qualcomm
Atheros basically gave up on
building parts for laptops.
On the left, are there
any wireless card
chipsets that you would recommend in
terms of Fermor openness
where the the
firmware is open for those
cards and there's production,
let's say, and hackable, so
to speak?
I know only of one
such thing. It's an old, uh,
Ferro's 11 new whispy device
where, uh, during
the height of the people,
lots of people working inside Atheros,
fighting for open source, they actually
managed to convince, uh, 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 if you look for devices supported
by F nine K HTC.
Um, you will find, uh,
an open driver and the open firmware
and you can you can compile
everything there.
Thank you.
Hi, thanks for all the work you've put
in over the time.
I'm very happy users of Open WRP,
so thanks a lot.
Appreciated. I dabbled
in trying to do some work
and previously for some Atheros
chips, and that was a couple of years
ago when Atheros was willing to give out
documentation.
Are there any vendors that
are easy to deal with
in getting documentation?
I'm not afraid of signing any MBAs
or something like that. But like
I think many vendors are very reluctant
to give some random guy documentation
on the hardware.
Well, with, uh, with mediatheque, 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, uh,
I get 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.
That's
how we can push manufactures,
um, where are you from
the assistance from the I.R.S., OK,
how you can push hardware manufacturers,
um, which ones?
The chipset or the routers?
Oh, I, I think it
refer to slide 20.
OK, um,
the, the hardware manufacturers.
It depends on at which level like that.
The hardware manufacturers themselves.
Uh, if you can get the right contacts
you will find uh 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, uh, crappy vendor sticks.
Um, and they will appreciate
having something open, but they just need
to realize the power that I can actually
ask the chipset manufacturer to provide
something like that.
When it comes to chipset manufacturers,
it depends if you're
like the the if you're talking
to the market leader like Broadcom,
in many ways they
simply don't care much about,
uh, doing something open because they
already have a good position and they
already know the value of of, uh, of
their chips and their software.
And, uh, 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, uh, help give
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
softwares and and, uh, they must at some
point realize that better software
can actually lead to getting more
customers.
Uh, um, it's, uh,
very, uh, uh, good feeling
that when I saw your, uh, comic
messages that the whole source
code is occupied with your humanity.
And, uh, so, um, my
question is, uh, I'm, uh,
a beginner.
I mean, I have a good knowledge of Sinisi
programing, and I would like to
contribute something.
I would like to know, is there any Web
page or the IAC Journal
where I can have, uh, interaction
with the people who are contributing
their, um, which part,
Linux Wireless or OpenTable.
Your or which.
Which one. Yeah. Uh, drivers.
Um, I think there's not much, uh,
coordination going on among Linux,
uh, driver developers.
It's like people doing their own thing
and then, uh, discussing patches on
the mailing list.
Uh, there is a Linux, uh,
wireless summit frequently, but it's
mostly, uh, interesting for people
that already like it, regulars
in and dealing with it with, uh,
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, uh,
on on a technical detailed
level. I think if people notice
that somebody is coming along and, uh,
caring about not just how can I do
this, but like, what are the specifics
of this and this and this part?
Um, 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, uh,
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 Unfreedom considered
harmful.
Um, 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 is open
source. But why?
What is the reason for them not to do it?
Uh, some of the reasons are
they are always afraid of losing control.
Um, in many ways in
maybe 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 the result. And apparently on many
levels, that matter is a big deal to
people.
And then there's also like big
corporations like Qualcomm, 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, uh, 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
infringe on somebody else's rights.
And if it's not published, that's
open source. It might still be there, but
at least people won't see it.
Uh, and in some cases,
companies might also be be embarrassed
to to show the quality of their software
to the world.
OK, thank you.
From the IOC, yes.
How big should the customer be to
make the venues doing free software?
I think in some cases it actually depends
on having like at least a
million chips per year or something
or comparable volume.
So it typically has to be big to matter
of small companies with ten thousand
one hundred thousand units are probably
not big enough to convince a chipset
vendor to change its ways.
OK, I guess this was it.
Thank you very much.
Sorry, I'm sorry.
So another
question, OK, the RNC, we
got another question from the IOC.
Yes.
OK, why do the winners need to be
nice? They have no profits
from using their have 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 another point
which which I heard actually
from from Atheros 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, 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.
OK, no, this was
really the last question, so
thanks again for the work you do without
you. Thank you all.