
32C3 – Chaos Communication Congress – Streams Online - axx
http://streaming.media.ccc.de/32c3/
======
palcu
I'm always mindblowned by the sheer number of networking equipment deployed
and maintained during the conference. They now have[0] 5000 WiFi clients
connected, downloading with 2.70 Gbps and uploading with 8.93 Gbps. It's like,
once a year, a big part of the internet traffic is routed through Hamburg.

[0]: [http://dashboard.congress.ccc.de/](http://dashboard.congress.ccc.de/)

~~~
wslh
Someone in HN who can share some information about how to setup WiFi for high-
demand? In any place I go (e.g. airports, restaurants) the WiFi is terrible.

~~~
sathackr
I work for an ISP and have done wifi for events with over 10,000 attendants.
We have done this exclusively with Ubiquiti equipment. I have not used any of
the high-end gear that claims to be designed for this
(Aerohive/Ruckus/etc...). The bottom line is, ultimately, the wifi standard is
not designed for this type of deployment -- the standards do not support the
features that would be needed to get the best performance in this environment.
That being said, like with most things, it can often be made to work with a
reasonable level of service.

There are two bands that are available for use -- 2.4ghz and 5.8ghz. Most
newer devices support 5.8ghz -- there is more overall bandwidth available on
the 5.8ghz band, but we have had good success deploying only 2.4ghz for public
events. Deploying 802.11ac in the 5ghz band with beam steering is something
that we may investigate as more clients begin to support this band.

Two of the main issues is contention for air time (bandwidth) and channel
usage. Wifi is half duplex, and only one device within a cell can talk at the
same time on the same channel. If the access point(AP) is talking,
clients(cell phone/laptop/etc...) must listen. If a client is talking, the AP
and all other clients must listen. A protocol is implemented for this, CSMA/CA
[1]. Think about this for a second -- when someone is transmitting data,
nobody else can receive data. This is important (will explain later).

While(in the US) there are 11 available channels in the 2.4ghz band, there are
only 3 usable channels. The others overlap and will cause interference if used
in the same area. 1/6/11 are the non-overlapping channels. There is a limited
amount of bandwidth available in any given area on any given channel. 2.4ghz
tops out at about 130mb/s over-the-air (figure about 60% usable bandwidth as a
best-case scenario) so about 80mb/s. That's with a single client, clean
spectrum, and a single access point. If the signal is weak or if there is
interference, this number will be reduced.

Antennas and access points need to be placed and configured (transmit power)
in such a manner that you control the number of devices that are within range
of them such that their client densities don't get too high (you don't want
1000 people connecting to one access point, wifi's implentation of CSMA/CA
breaks down with these densities) but also the targeted clients have a good
signal. One thing you must consider that many people don't is, that while you
can control the area and transmit power of your access point, you cannot
control the client device talking to it. You must take this into consideration
also. That client 150ft away on the fringe of this cell is transmitting with
full power, likely interfering with another access point 250ft away that can't
even hear this AP's signal.

A single low signal client can turn your 80mb/s access point into a 2mb/s
access point. An access point talking to a client with a weak signal will
'downshift' and talk at a slower speed -- say 12mb/s instead of 54mb/s -- this
makes it easier for the client to receive the data being transmitted without
errors. But, this slower speed means more time must be spent transmitting the
data, and this is time that the AP can't talk to other clients, and other
clients can't talk to the AP. In this manner, a single weak signal device
streaming Youtube at 2mb/s can reduce your overall bandwidth on an access
point to 10mb/s or even worse. I aim for about 30 devices per access point,
with a maximum distance of about 100ft in outdoor environments and 50ft
indoors. In practice, this maintains a generally usable speed of about 5mb/s
(you'll want to deploy bandwidth management systems to enforce this). Your
overall usage will depend heavily on the type of event, but generally we see
about 10% of attendants using wifi -- so based on the rule above, about one
access point per 300 people.

If the layout of your event is such that this is difficult or impossible (such
as a large auditorium/stadium) you can co-locate multiple access points on
non-overlapping channels and handle about 1000 clients in a general area. But
care must be taken to control the signal propagation if you want to support
more clients in other areas as you will be using all 3 available channels thus
any other nearby access points(within range) will be cutting into your
available bandwidth.

This is complicated by the reluctance of most wifi devices (phones are the
worst because you generally can't configure this setting on the client) to let
go of a weak signal and grab a stronger one. A wifi device will generally hold
on to a signal long after it has become unusable. Many of the bigger
manufacturers have ways to mitigate it. With Ubiquiti, you MUST configure the
"minrssi" [2] feature and it is buried in a config file on the access point
controller. Most consumer grade access points do not support this feature at
all.

As I get more into trying to explain this I'm realizing all of the nuances and
gotchas that can really make this difficult for someone without experience to
engineer and implement. I'm not sure I can effectively convey them in an HN
reply but hopefully I've helped steer you in at least the right direction.
Sadly, most tech companies that would be contracted to do this type of work
are just as ill equipped to design and implement this.

[1]:
[https://en.wikipedia.org/wiki/Carrier_sense_multiple_access_...](https://en.wikipedia.org/wiki/Carrier_sense_multiple_access_with_collision_avoidance)

[2]: [https://help.ubnt.com/hc/en-us/articles/205146050-OD-
UniFi-H...](https://help.ubnt.com/hc/en-us/articles/205146050-OD-UniFi-How-
does-minimum-RSSI-work-)

~~~
JoeAltmaier
An ironic twist to this is, that those 'low-signal' clients that get
'downshifted' are often victims of noise. And much noise is periodic or
intermittent (think sparking from a microwave tube or a faulty car ignition).
Packets in the air are essentially getting hit by random darts. When the AP
'downshifts' to a lower rate, it makes the packets _bigger_ targets for the
darts. So the AP slows down some more. Often in a matter of a second it shifts
all the way down to the bottom rate. And now has a harder time getting
through.

It would be helpful if APs could distinguish between 'low signal' and 'high
error rate', and respond differently. It should actually speed up when the
periodic error rate is high, to make the packets smaller targets in the air.
Or make them shorter. Or even try to time transmissions to the fit between the
occurrences of noise.

~~~
sathackr
This is absolutely correct. I don't know the inner workings of the modulation
scheme selection but suspect that the downshift is solely based on the ratio
of received to unreceived acks from the client -- without knowing the reason
for the non-receipt. As far as I know, the wifi standard does not contain any
provision for the client device to report its received signal level to the AP.
The signal levels you typically see in the AP are the levels that the AP is
hearing the client at.

Some access points allow you to lock the modulation at a certain rate -- if
you know for a fact all of the clients will be able to receive the signal at
the required level for that modulation scheme, you can increase your overall
effective capacity. Unfortunately this is not usually the case. We almost
never get to control the client devices and positions, and without that
control, received signal levels can't be effectively predicted.

~~~
semi-extrinsic
With this type of stupidity, along with the string of failures when it comes
to Wifi security (WEP, WPS, the clusterfuck that is Probe Request frames,
etc.), shouldn't we stop listening to the IEEE and get someone who understands
hardware AND networks AND cryptography AND software to start writing the next
generation of standards?

~~~
sathackr
IEEE has gotten a bunch of things wrong, but they have gotten a bunch of
things right as well. How many other vendor-agnostic technologies are there
that work as well as Wifi? For the most part my wifi-enabled device will work
with any device made by any manufacturer, from the high end ones down to the
cheapest junk. That level of compatibility is rare in a standard in which
participation is entirely voluntary.

I think the IEEE struck a balance between simplicity and ease of
implementation and features. I don't think the goal was ever to design a
standard that could handle thousands of endpoints on commodity hardware.

For what it is, wifi works great. It falls apart when you try to make it do
what it wasn't designed to do. There have been missteps along the way, but
overall I think the good outweighs the bad.

Lets not throw the baby out with the bathwater.

~~~
semi-extrinsic
I dunno; between USB, HDMI, Bluetooth, CAN-bus, DisplayPort, PCI Express,
SATA, GSM/CDMA/HSPA/LTE, etc. etc. (none of which are IEEE organized) I don't
think Wifi is that unique. In particular the various cellular network
technologies face many of the same challenges as Wifi and have not had major
security fails (crypto implementation errors) like Wifi has had several times.

~~~
sathackr
You've brought up some great examples of successful standards. Each of them in
their current implementation work well for the task they were designed to do.

Many of them have not been without their failures. GSM had several long-
standing security issues, some of which went on uncorrected after disclosure
[1]. WEP was designed in the 90s and I believe there are a large number of
security/encryption methods designed in the 90s that have since been proven
flawed, either in design or implementation (RC4/MD5/SHA1 to name a few)
Bluetooth has gone a completely different direction than it's original design
and is also not without its failures. But the main difference is, each of the
standards you listed was designed for a specific task, and works well in doing
what it was designed to do. When you leave that area of designed function,
they start to break down.

In relation to the wireless technologies(GSM/HSPA/CDMA/LTE, et al...), their
design goal was indeed massive systems with 1000's of clients. They employ
various technologies that would generally be cost-prohibitive or otherwise
impractical (such as GPS synchronization) in the commodity consumer market. I
haven't seen the price tag for an LTE tower site, but I bet it is several
orders of magnitude larger than a $120 consumer router. Wifi was never
designed to do this.

I agree that wifi is not unique in its success, nor is it unique in its
failures. This extends to most entities in general. All have their failures
and successes, including IEEE.

On a side note, I have never been that concerned with wifi encryption. The
vast majority of wifi access is access to the internet. If you are not
securing your data before it leaves your control, the short hop over to the
access point is the least of your problems.

[1]:
[https://en.wikipedia.org/wiki/GSM#GSM_Security](https://en.wikipedia.org/wiki/GSM#GSM_Security)

------
zymhan
They did a presentation about Red Star OS [1] using Red Star OS. Brilliant.

EDIT:
[http://streaming.media.ccc.de/32c3/hall6](http://streaming.media.ccc.de/32c3/hall6)

[1]
[https://en.wikipedia.org/wiki/Red_Star_OS](https://en.wikipedia.org/wiki/Red_Star_OS)

~~~
Phil_Latio
You mean they do.
[http://cdn.c3voc.de/s4_native_sd.webm](http://cdn.c3voc.de/s4_native_sd.webm)

~~~
zymhan
Yes, thanks. I wasn't sure if I should link to the hall presentation since it
seems like the link won't point to this presentation for very long.

------
axx
As a side node, you can join the discussion on IRC (hackint):

#32c3-hall-1

#32c3-hall-2

#32c3-hall-G

#32c3-hall-6

#32c3-everywhere

\-
[http://32c3-wiki.top/congress/2015/wiki/Congress_Everywhere](http://32c3-wiki.top/congress/2015/wiki/Congress_Everywhere)

\- [https://hackint.eu/](https://hackint.eu/)

~~~
sawwit
Alternatively in the browser:

[https://webirc.hackint.org/#32c3](https://webirc.hackint.org/#32c3)

[https://webirc.hackint.org/#32c3-hall-1](https://webirc.hackint.org/#32c3-hall-1)

[https://webirc.hackint.org/#32c3-hall-2](https://webirc.hackint.org/#32c3-hall-2)

[https://webirc.hackint.org/#32c3-hall-G](https://webirc.hackint.org/#32c3-hall-G)

[https://webirc.hackint.org/#32c3-hall-6](https://webirc.hackint.org/#32c3-hall-6)

[https://webirc.hackint.org/#32c3-everywhere](https://webirc.hackint.org/#32c3-everywhere)

JSON of all streaming URLs:

[https://streaming.media.ccc.de/streams/v1.json](https://streaming.media.ccc.de/streams/v1.json)

------
lispm
[http://ccc.de/en/updates/2015/fatuma](http://ccc.de/en/updates/2015/fatuma)

Fatuma Musa Afrah gave the keynote speech at the annual hacker conference, the
32nd Chaos Communication Congress in Hamburg/Germany.

She is from Somalia and lives currently in Berlin/Germany as a
refugee/newcomer.

------
lumberjack
Where can I find a list of the scheduled talks? I found this link but I get a
503 and the cached version is not navigable.

[http://events.ccc.de/](http://events.ccc.de/)

EDIT:
[https://events.ccc.de/congress/2015/Fahrplan/](https://events.ccc.de/congress/2015/Fahrplan/)

This link works

------
ufo
Simon Menner's "What does Big Brother see, while he is watching?" talk is a
really interesting look at the Cold War. Does anyone know where the VODs will
be available so others can watch it later?

~~~
def-
[https://media.ccc.de/b/congress/2015](https://media.ccc.de/b/congress/2015)

[https://streaming.media.ccc.de/32c3/relive/](https://streaming.media.ccc.de/32c3/relive/)

------
yexponential
"Use a desktop player! Browsers and video doesn't go together well, even in
2015 and especially when it's live. So for your best viewing experience please
use a desktop player like VLC or mplayer."

Am I the only one to be bothered by this comment.

~~~
dijit
Why are you bothered by it. It's true. HTML5 live streaming is only reasonably
done by Apple and only works in Safari. I wouldn't push flash video streaming
if I were them either.

Which leaves streaming over http (not using the browser) or rtmp

~~~
rst
Firefox's built-in mp4 player is working for me well, for both live streams
and recordings (the "re-live" section of streaming, which has all the talks
that happened before folks in America woke up). So, they're at:

[http://streaming.media.ccc.de/32c3/relive/](http://streaming.media.ccc.de/32c3/relive/)

BTW, there's also a flash player for the "re-live" stuff, which isn't working
for me on Linux at all; if you're having trouble with it, try the mp4s. (Just
as well; I get to shove the flash-enabled browser profile back in its box.)

~~~
fivre
For me Firefox seems to be doing some weird thing with the live video where
you'll watch it and it will get stuck due to congestion or whatever, and then
refreshing the page appears to restart the video from the beginning until the
point where it broke. Very odd.

------
r3bl
Is there a place where recordings get saved once they're finished or will I
have to wait until the end of the conference? My internet connection is too
unstable to watch them live.

~~~
lorenzhs
Automatic stream dumps are here:
[https://streaming.media.ccc.de/32c3/relive/](https://streaming.media.ccc.de/32c3/relive/)
\-- note that they're completely automatic, no editing has been done. They
include the 15 minutes before and after the talk in case it starts early or
takes a bit longer.

The video operation centre will put finished releases up at
[https://media.ccc.de/b/congress/2015](https://media.ccc.de/b/congress/2015)
once they've finished processing. Those include translated audio (all talks
will be available in English _and_ German), subtitles, intros and some audio
processing.

~~~
r3bl
Thanks! Downloading three talks that I really want to hear right now. I'm
perfectly fine with watching them unedited.

------
danners
schedule:

[https://events.ccc.de/congress/2015/Fahrplan/schedule/0.html](https://events.ccc.de/congress/2015/Fahrplan/schedule/0.html)

~~~
nly
Mirror:
[http://fahrplan.top/congress/2015/Fahrplan/](http://fahrplan.top/congress/2015/Fahrplan/)

------
dimdimdim
45% Insecure WiFi traffic? at a Hacker Conference? :)

~~~
xorcist
Why? I long made a point of only running "insecure" network layers at home. I
sincerely believe in the stupid network, and that any security belongs above
the transport.

Using the term for wireless networks at home really drives the point home that
you're supposed to get your personal connection and buy your own access point,
so that IP addresses finally can represent identity. That is not a
coincidence.

~~~
dimdimdim
Keep in mind though, that once your Layer 2 is hijacked, a lot of attacks are
possible before upper layer security kicks in - things like browser
redirection and exploitation are very common these days

~~~
urda
Please take note of this folks. Simply trusting "transport security" isn't
enough. Please do not seriously run an open access point because you think
it's just as safe as the OP.

------
Too
The list of presentations is looong. Any recommendations?

------
rdl
Audio is fixed now.

