Pitch script – full deck (pitch-deck.html)

Spoken text for the full deck (cover + 20 slides), about 10 minutes including a 2-minute demo. Use it for a longer slot, a walkthrough with the Tesla engineers, or as the source for Q&A answers. [click] = press the clicker once (same slide, next step). → = next slide. Speak to the jury, not to the slides. Say numbers slowly.

Part 1 · The problem

1 · Cover

Shown before you start. When it is your turn: →

2 · A torque tool reports every screw · 0:00 (20 s)

This is a car on a Tesla line. Next to it, a torque tool. Every screw it tightens, it reports to the line control over Wi-Fi: screw one, 45 newton-metres, okay. Only when all screws are confirmed may the car move on. One car every minute.

→

3 · No Wi-Fi, no confirmation · 0:20 (15 s)

Now the tool loses its Wi-Fi. The screw is tight, but the line control never hears it. No confirmation, and the car may not move on. The line stops.

→

4 · €50,000 every minute · 0:35 (15 s)

The counter has been running since the line stopped. One car a minute, about fifty thousand euros a car. That's three million euros an hour. This is a scenario, but the order of magnitude is real.

→

5 · Nobody knows why · 0:50 (15 s)

And the line still stands. Is it the tool? The access point? The network behind it? The worker swaps the tool, IT looks at the access point, and everybody is guessing.

→

Part 2 · The idea

6 · Know when, and why · 1:05 (10 s)

So it's not enough to know that the connection is lost. We need to know why, within seconds, and send it to the one person who can fix it.

→

7 · A sensor listens · 1:15 (20 s)

Our idea: a sensor next to the line that listens to the Wi-Fi. It only reads the frame headers: who talks to whom, and when. No payload, no passwords. That is exactly the data Tesla gave us: eight sensors, thirty minutes, 1.1 million frames.

→

8 · A connection is five steps · 1:35 (30 s)

What does the sensor hear? A connection is not one thing. It is five steps: the device finds the network with a probe, it joins the access point with authentication and association, it logs in with 802.1X or a shared key, it agrees on keys in the 4-way handshake, and then it talks. For the tools that means a heartbeat every thirty seconds.

[click]

This tool, T-01, finds its network …

[click]

… and then nothing. It never reaches the line. The sensor sees which step never comes.

→

9 · The step tells the cause · 2:05 (35 s)

And that step already tells us a lot. From the line, it always looks the same: device offline. But:

[click]

Stops after step one: its access point is off, and it never tries another one.

[click]

Stops at log in: the login server does not answer. Sixty-three devices.

[click]

Gets in, and then thrown out on a timer: the controller kicks devices.

[click]

Talks, signs off, silence: the tool was switched off. Four causes, and four different people who have to act.

→

Part 3 · The challenge

10 · 30 access points, 99 devices · 2:40 (20 s)

And that was one tool. Tesla's capture has thirty access points, twenty-nine on the air, each with two networks: TESLA-TOOLS for the tools, TESLA-CORP for phones and laptops. Every card here is one access point with its five steps, from the real data. AP 0d is completely silent.

→

11 · Every device hears many access points · 3:00 (30 s)

It gets harder: every device hears many access points. It's a web, not a line.

[click]

But here is something we found in the data: every device stays on one access point. 87 of 87 connected devices, zero roams in thirty minutes.

[click]

So when one access point goes off, its devices stay offline, even though they can hear twenty-eight others. That's a configuration problem, not a radio problem.

→

12 · We merge the records of every sensor · 3:30 (30 s)

How do we still find the one broken connection? Every sensor listens on its own channel, and every sensor has its own clock. Up to 1.2 seconds apart, and drifting by up to 25 ppm.

[click]

So we align them. The access points stamp every beacon with their own timer, and all sensors hear those beacons. That gives us one clock for all eight.

[click]

Then we follow every device through its five steps. T-03 talks, then signs off. T-01 never joins. The office laptop stops at login. The missing step is the finding.

→

Part 4 · The solution

13 · Three questions decide the cause · 4:00 (60 s)

This is the slide the engineers score. Slow down.

This is the logic, and it is the same for every break. Three questions: which step never comes, how far does it spread, and who sent the last frame?

[click] (T-03)

T-03. The heartbeat stops. Only this one device; its access point and the neighbours keep working. And the last frame is the tool itself: a deauthentication with reason 3, "station is leaving". So it was switched off. The line lead swaps it.

[click] (T-01 + 11)

Twelve devices never start to join. They scan, and they get answers. But only devices whose own access point is silent are affected, and on this site no device ever tries a second one. Access point off, no fallback. That goes to the network team.

[click] (63 office devices)

Sixty-three office devices stop right after the identity request. 1,692 requests, zero successful logins in thirty minutes. And it happens on 26 access points, on all eight channels, at the same time. So it can't be a device, and it can't be a radio. It's the login server behind the access points.

[click] (18 devices, kicks)

And the one that looks scary: eighteen devices thrown out on a fixed timer, in address order. An attacker? We checked. All 1,477 of those frames continue the access point's own sequence counter, and they arrive with the access point's own signal strength. The access point sends them itself. That's a controller job. And that also means 802.11w would not help here.

So what we rule out, we rule out with the same logic: a radio fault can't hit eight channels in the same second, and a forger can't continue the AP's own frame counter.

→

14 · Sensors in, cause and owner out · 5:00 (25 s)

To sum it up: Gearbox takes the headers from all sensors. It fuses them onto one clock, follows every device through its steps, turns every missing step into a finding, groups the same break into one incident with its proof frames, and routes it: line lead, IT, or security. 1.1 million frames become eleven incidents. Two of them can stop the line. Let me show you.

→ (the live dashboard opens)

Part 5 · Demo

15 · Live demo on /final · 5:25 (2:00)

Click path. Do not read the screen, say what it means.

1. Status line (10 s)

   "Two problems can stop the line." Also active: three on the office network, one security incident. That's what a shift lead sees first.

2. "3 devices on TESLA-TOOLS cannot connect" in Most important warnings (30 s)

   What to do now: don't swap the device, it won't help, IT is informed. Then the technical recommendation for IT: switch the radio back on, remove the single-AP binding. Confidence high, with its reasons. And the evidence: sensor, frame number, time. Click Copy Wireshark filter One click, and anyone can check this in the original pcap.

3. "A device signed off and never came back" (T-03) (20 s)

   Here the answer is different: "You can fix this." The supervisor finds the tool, checks the battery, swaps it. Confidence medium, because only one sensor heard it, and we say so.

4. "18 devices kicked off Wi-Fi on a fixed timer" (25 s)

   What the sensors recorded: the timer, the address order, and the proof that the AP sends the frames itself. So IT gets: find the controller job.

5. Replay: in the dark bar at the top, press Play, choose 60× (25 s)

   The same thirty minutes, replayed. The incidents appear in the order they happened, and the channel strip shows which channels are affected at that moment.

6. Move the mouse off the page, then → (or Next › top right)

Part 6 · Priorities

16 · Not only tools are on the network · 7:25 (20 s)

What you saw are different error pictures, because the tools are not alone. In the capture: 27 torque tools, 37 phones and tablets, 35 laptops. Device type from the MAC vendor. They share the same air, and they fail for different reasons.

→

17 · Tools stop the line, they come first · 7:45 (20 s)

But a phone without Wi-Fi is annoying. A torque tool without Wi-Fi stops the line. So Gearbox doesn't sort by how many devices are affected. It sorts by line risk, and it says who acts: "You can fix this" for the line lead, "IT is informed" for everything else.

→

18 · 16 fault classes (optional) · 8:05 (15 s)

Skip if you are late.

And we don't only show what we found. We check sixteen fault classes. Seven found, nine checked and clean: no congestion, no roaming ping-pong, no evil twin, no deauth flood. That answers "can you detect everything?" and "false alarms?" in one view.

→

Part 7 · Reliability

19 · Every link has to hold · 8:20 (15 s)

One more thing. Gearbox itself has to be reliable. Sensor, records, software, server.

[click]

If one link breaks exactly when the Wi-Fi breaks, nobody fixes software in minutes. And the line costs fifty thousand euros a minute.

→

20 · What makes each link reliable · 8:35 (40 s)

So every link has a method. The sensor reads headers only, and it is checked itself: its clock against the beacons, its heartbeat. A silent sensor is a finding, not a blind spot. The records are small and can be re-read; at scale they go through a buffered log, keyed by device, so nothing is lost on a restart. The software proves every claim with a frame. We re-read all 77 evidence frames from the original captures, 77 of 77 match, and a second parser without tshark finds the same causes. The server runs one container image and keeps its results. And on scale: one core processes about 21,000 frames per second, measured. Tesla's sensors send 78 per second, a busy factory channel one to two thousand. More sensors means more partitions, not a new design.

→

21 · Close · 9:15 (15 s)

This is Gearbox: reliability back on the connection between the tools, the devices and the network that runs the line. Tools first, phones last. Thank you.

End at about 9:30.

Likely questions (short answers)

Numbers on one line

1,118,853 frames · 8 sensors / 8 channels · 30 APs planned, 29 on air · 99 device addresses (27 tools, 37 phones, 35 laptops) · 87 of 87 on one AP, 0 roams · clocks up to 1.2 s apart, 25 ppm drift · 11 incidents, 2 can stop the line · T-03 signed off 12:36:32, reason 3 · 12 devices never join · 63 devices, 26 APs, 1,692 identity requests, 0 logins · 18 kicked, 1,477 of 1,477 frames continue the AP's counter · 16 fault classes, 7 found · 77 of 77 evidence frames re-checked · ~21,000 frames/s per core (measured) · €50,000/min is a scenario.