HEP 13: Wi-Fi Access and Records

[mhalikosen]

👉	HEP 13: Wi-Fi Access and Records
Authors	@mhalikosen
Status	Active
Related PRs	#48
Related HEPs	HEP 2

Introduction

HEP 2 left two questions hanging, and @mrabdullahsahin asked both of them in its PR: do we know who's connecting, and are we keeping the records the law expects from us? @safaorhan said he hadn't set up anything like this before and asked whether anyone had.

I have, so this is my answer. It covers how we run the Wi-Fi, what you'll actually go through when you connect, what we have to keep on file, and what it costs.

It also proposes a simpler network layout than HEP 2 does, so please read the next section before the rest.

How This Changes HEP 2

HEP 2 proposes three wireless networks: infrastructure, members, guests. This one proposes two.

Network	Visible	Who	Purpose
KonyaHackerSpace	Yes	People	Laptops, phones, tablets
KonyaHackerSpaceInfra	Hidden	Nobody, directly	Sensors, cameras, printers, anything that runs the space

The member and guest split goes away, and so does the guest network itself. One Wi-Fi for people, only members on it, everyone identified the same way. More on that below.

Why:

1. A guest network wouldn't be any cheaper to run. The law wants us to know who's on the connection, and that applies to a guest network as much as a member one. So a second network doesn't save us the identification work, it duplicates it.
2. Two passwords is two passwords to leak. A member password that's been circulating for a year isn't a boundary any more, it's a rumour.
3. It's less to build and less to explain.

If both HEPs pass, HEP 2's table should be updated to match. That's @safaorhan's call as its author, and I'd rather we settle it than let the two documents quietly disagree.

Who Can Connect, and How We Know Who They Are

You join the Wi-Fi with the shared password, then log in on a page using an account we've given you beforehand. That account is what lets us answer the law's question about who was online.

No SMS anywhere in this. Nothing to integrate, no per-message bill, and no phone numbers sitting in a database for two years. Your identity gets checked once, by the association, when your account is created. A membership process is a better check than a code sent to a number nobody verified.

So there are two locks. The Wi-Fi password controls who can reach our network. The account records who it was.

What it costs you

You'll log in roughly once a day. Sessions last 24 hours, so you're not typing a password every time you open your laptop, but you are typing it most mornings. There's no "remember this device" and I couldn't find a good way to build one. Captive portal pages open in a sandboxed mini browser on iOS and Android that discards cookies when it closes, and the only other thing a router can key on is the MAC address, which anyone in radio range can copy off the air. Session length is the one knob we have, and we can turn it up if a day turns out to be too short.

Only members get on. No guest accounts, and no way to issue one. Someone who drops in for a workshop uses their own mobile data.

That was argued in HEP 2's PR and I'm siding with one half of it. @theilgaz asked whether we need a guest network at all now that everyone carries cellular data; @safaorhan replied that Vodafone coverage inside the space is bad. His objection still stands and this HEP doesn't answer it. What we get instead is no anonymous traffic to account for and nothing to hand out at the door. If it turns out people genuinely can't get a signal in the space, that's when to reopen this.

Why we're not doing enterprise Wi-Fi

There's a nicer version of all this. Enterprise Wi-Fi, meaning WPA2/WPA3-Enterprise with 802.1X, hands every member their own credentials at the Wi-Fi layer instead of on a web page. Your device stores them, so you connect once and never think about it again, and cutting off one person doesn't disturb anyone else. The access point in the shopping list supports it. I spent a while on this one before dropping it, so here's the reasoning, to save the next person the trip.

The setup cost lands on every device and never goes away. Enterprise Wi-Fi needs a server certificate, and each client has to be told which certificate to trust. Two ways to do that, neither free:

• Run our own certificate authority. Strongest option, but its public half has to go onto every device. Roughly thirty seconds on an iPhone or Mac if we prepare a configuration profile, one to two minutes on Android, two to four on Windows, and Windows is where people get it wrong.
• Buy or fetch a public certificate, from Let's Encrypt or similar. Nothing to install, but that root is already trusted on every device on earth, so an attacker who gets their own certificate can impersonate our server unless each client is separately told to check our server's name. It trades a file for a text field. It also adds a renewal chain, and if that ever fails quietly, nobody can get on the Wi-Fi at all.

Then, on top of the per-device work:

• It's per device, not per person. A laptop, a phone and a tablet means three setups for one member.
• Android won't store a Wi-Fi certificate unless the phone has a lock screen PIN. So joining our network can mean changing your phone's security settings first.
• Recent Android versions dropped the "don't validate" escape hatch. Good for security, but a device that was set up slightly wrong now just fails, with nothing the user can click to get past it. That support call comes to us.
• We'd have to write and maintain onboarding material for each platform: an Apple configuration profile, a Windows script, an Android walkthrough with screenshots.
• We'd be running a second authentication system and our own certificate authority next to the portal we need anyway.

For a company with a fixed headcount and managed laptops, that's a reasonable trade. For a space where the faces change every week and everybody owns their own hardware, it's a tax on showing up. I'd rather people typed a password once a day than sat through a five minute conversation about certificates before they could check their mail.

The infrastructure network

KonyaHackerSpaceInfra is hidden, has its own password, and sits on its own segment. No portal in front of it, because a camera can't log in to a web page.

The alternative was leaving those devices on the main network and controlling them with a MAC whitelist, which we rejected. MAC addresses travel through the air unencrypted, so anyone nearby can read a permitted one and clone it in seconds, and a whitelisted device on the same SSID is sharing everybody's Wi-Fi password regardless. The list would be an inventory, not a wall. With a separate hidden network, a fully compromised laptop never learns the infrastructure password and can't reach those devices at the network level either. The access point does this for free.

What the Law Actually Asks of Us

There's a name in Turkish law for what we're doing when we let people use our connection: toplu kullanım sağlayıcı. The rules are in article 7 of Law 5651 and a 2017 regulation under it, and they apply to us even as a non-profit giving Wi-Fi away.

Three duties:

1. Run a content filter. Our ISP already does this on their side, so it's handled.
2. Keep access records for two years. Not names, not browsing history. The regulation asks for which internal address a device had, when it started and stopped, its MAC address, and which addresses it talked to.
3. Be able to say who was using the connection. This one is written for places open to the public, and we're doing it regardless. The wording is "SMS and similar methods". Accounts issued after we've confirmed someone is a member qualify, and they're a better check than a code texted to an unverified number.

Two things people always ask about.

We're not logging what anyone reads or types. It's all encrypted in transit; we couldn't read it if we tried. What ends up on disk is closer to a phone bill: who, when, which server, never the contents.

The timestamp thing. Plenty of Turkish vendors will tell you 5651 requires your log files to be sealed with an accredited timestamp from an authority like TÜBİTAK KamuSM, and they'll sell you the subscription. I went and read the law. The word "timestamp" isn't in it. Hosting providers and ISPs are told to ensure the accuracy, integrity and confidentiality of their records, and no method is prescribed. The regulation adds one line on top for commercial providers, meaning internet cafes: they also have to record a daily value confirming that accuracy and integrity. That's a hash, not a timestamp, and it doesn't reach associations.

So nobody is owed a subscription here. We'll still hash and sign the archives nightly, since it's free and it's what makes tampering visible.

What We're Building

A small computer sits between our internet line and the Wi-Fi. It hands out addresses, authenticates people and writes the records. A managed switch keeps the two networks apart. One ceiling access point broadcasts both.

Three boxes. No rack, no fans, no server room.

internet --- switch --- small computer (router + auth + records)
               |
               +------ ceiling access point ---> KonyaHackerSpace       (people)
               |                            \--> KonyaHackerSpaceInfra  (hidden)
               |
               +------ wired ports (infrastructure devices only)

Before We Buy: Check Your Drawer

I'd rather not spend the hackerspace's money on this if we don't have to.

Most of the list below is the sort of hardware people like us end up owning two of. If any of it is sitting unused at home or at the office and you'd be happy for it to live at the space, say so in the comments. A donated box beats a bought one every way I can think of: it arrives sooner, it's free, and the thing gets used instead of aging in a drawer.

What would help:

• Any small computer that can run Linux around the clock. We're planning on a Raspberry Pi 5, but nothing here is Pi-specific. A retired mini PC, a thin client, an old NUC, all fine and in some ways better. One ethernet port minimum. It runs 24/7, so quiet and low power matter more than speed.
• Anything that gives it a real SSD. On a Pi that's an NVMe adapter board plus a drive; on a mini PC the drive is usually already in there. The records are small, so 128 GB is plenty. The only hard requirement is that it isn't an SD card, which would wear out.
• A power supply that can actually feed it. On a Pi 5 with a drive attached that means the official 27 W USB-C one specifically. Phone chargers cause strange problems that take a day to diagnose.
• A managed switch, with the caveat below.
• A ceiling or wall access point that can put separate networks on separate SSIDs and tag each one onto its own VLAN.

Two ethernet ports is worth extra to us. With two, one port faces the internet and the other carries both Wi-Fi networks to the access point, which leaves the switch with almost nothing to do. We'd still want one eventually, as soon as we need wired ports for infrastructure gear, but a two-port donation would let us start without buying it. So a two-port mini PC in your drawer is worth roughly the computer plus the switch.

A note on switches, so nobody's disappointed. Not every switch works here. The one thing we can't compromise on is that it has to keep its own admin page on a different network from everyone else. Plenty of cheap "smart" switches can't, and on those anyone on the Wi-Fi can reach the switch's admin page, which is exactly the attack HEP 2 is trying to prevent. A switch that fails that test isn't a saving.

Not sure whether what you have qualifies? Drop the model name in a comment and I'll look it up. Either we save a purchase or we find out early that we still need to make one.

Same goes for anything that isn't on the list.

Bill of Materials

Prices are what I could find on 2 September 2026 and will drift. Accessories are priced at SAMM Market where they stock them. The "Have one?" column is for us to fill in as people speak up.

#	Name	Price	Link	Have one?
1	Raspberry Pi 5, 4 GB, or any equivalent mini PC	5500₺	Robolink	?
1	Raspberry Pi M.2 HAT	730₺	SAMM	?
1	NVMe SSD 256 GB	1540₺	SAMM	?
1	Official 27W USB-C power supply	927₺	SAMM	?
1	Official Active Cooler	304₺	SAMM	?
1	TP-Link TL-SG2008P, hardware V3.2x or newer	1717₺	Akakçe	?
1	TP-Link EAP650 ceiling AP	5147₺	Akakçe	?
-	Total	15865₺	-	-

SAMM stocks the Pi board too, but noticeably above what other Turkish sellers want for it, so the board is priced elsewhere and the accessories at SAMM.

Nothing here has a running cost. No SMS bill, no subscription, no licence.

Pledging

This HEP accepts pledges. If you want it to happen, pledge in the PR comments and I'll add you to the table. Donated hardware counts as a pledge and goes in the table too, at whatever it saves us.

Donor	Amount
Collected Total	0₺
Required Total	15865₺

---

That's the part I think everyone should read. What follows is for anyone who wants the reasoning and the settings.

---

Technical Details

Network layout

The small computer routes between VLANs. With one ethernet port it does that over a single trunk and the switch carries the tagged networks; with two ports the WAN gets its own interface.

VLAN	Purpose
10	WAN, a single port facing the ISP router
20	KonyaHackerSpace, the people network
30	Management: the router, the AP's admin page, the switch's admin page
40	KonyaHackerSpaceInfra and the wired ports

Per HEP 2, no wired ports for people. The wired ports carry infrastructure devices only.

Routing everything over one port halves the theoretical ceiling to about 500 Mbps. Our uplink is nowhere near that, so it costs us nothing and saves a cable. If the line ever gets upgraded past it, or we end up with a two-port machine, the WAN moves to its own interface and nothing else changes.

Why not pfSense

Fair question, and it came up in HEP 2's comments. Two reasons.

They don't run on the hardware we want. OPNsense is FreeBSD on x86 only and pfSense's ARM support doesn't cover a Raspberry Pi, so using either means buying a small x86 box. That costs more, draws more power around the clock, and is far harder for a member to pull out of a drawer.

The other reason is that a firewall appliance doesn't solve the part that's actually hard. What's hard here is authenticating our own members and producing a log format that lines up with the regulation. We'd be writing that ourselves whatever we ran underneath.

So: Ubuntu Server 26.04 LTS. Official Raspberry Pi image, five years of support, and it runs on any x86 box somebody donates.

The switch, if we buy the recommended model

This section assumes we buy the TL-SG2008P rather than being handed something suitable. If a donated switch turns up, the reasoning carries over but the model numbers don't.

The requirement is that the admin interface can be moved off the network people are on. The cheap and popular TL-SG108E can't do that: VLAN 1 can't be removed, every port belongs to it, and the admin page lives there. The TL-SG2008P can, through an interface under L3 Features.

Get hardware version V3.2x or newer, and check the Ver: sticker on the box before you pay. Version 1 is end of life. Version 2's last firmware is from August 2021, so it never got the fix for a January 2026 bug in the web interface that an unauthenticated attacker on the same network can trigger (CVE-2026-1668, CVSS 7.7). Turkish stock is old often enough that it's worth asking the seller.

Day one, all five:

1. Update the firmware to 3.20.17 or 3.30.1 or newer.
2. Leave it standalone. Don't connect it to TP-Link's cloud.
3. Move the admin interface to VLAN 30 and restrict it with an ACL.
4. Turn off telnet.
5. Turn off the HTTP and HTTPS admin servers and manage it over SSH. Every published vulnerability on this switch family so far has been in the web interface, so turning it off removes the whole category. Enable SSH and actually log in with it before you turn the web interface off, or the only way back in is a factory reset.

I'm not claiming this switch is secure in any absolute sense. Nothing at this price is. Cisco's equivalent had a worse bug, unauthenticated remote root at CVSS 9.8, and Zyxel's shipped with hardcoded keys. What makes a device acceptable is whether it's still getting patches, whether the vendor publishes advisories, and whether we can keep its admin interface away from users. This one manages all three at about a sixth of what the alternatives cost.

The access point

EAP650. What we need is modest: two SSIDs, each on its own VLAN, standalone with no Omada controller. It does that and handles up to 16 SSIDs, so we're nowhere near a limit.

Choosing it over the cheaper EAP610 is about capacity, not features. AX3000 Wi-Fi 6, rated for 250 or more clients at once and roughly 140 m² of coverage, which handles a full room on event nights and pushes back the day we need a second unit. If the budget gets tight, the EAP610 does the same job for about 1350₺ less and fewer simultaneous users.

It also handles WPA2 and WPA3-Enterprise with 802.1X, which we've decided against for the reasons above. Good to know the door stays open if we change our minds.

A power adapter comes in the box, so PoE is optional and we can decide once we see whether there's a socket near the mounting point.

The software

Ubuntu Server 26.04 LTS on the small computer, and on top of it:

• Addresses and names: dnsmasq, one pool per network.
• Firewall and address translation: nftables.
• Accounts: PostgreSQL, holding members and sessions. Keeping this in a real database rather than a config file is what lets us later check people against an internal membership API instead of a local table, without touching anything else.
• The portal: openNDS, packaged in Ubuntu's repositories. It deals with the fiddly parts: how iOS, Android and Windows each detect a captive portal, session lifetimes, and re-authorising clients after a restart. We write the login page and nothing else.

What we log, and how the archive works

Connection records come from ulogd2 reading the kernel's connection tracking, which produces the exact fields the regulation names, translated source port included. Address handouts come from the DHCP server. Session start and end come from openNDS, which runs a local hook on both events that can write straight into PostgreSQL.

Every night the day's file gets compressed, hashed, chained to the previous day's hash, and signed. The chain is what does the work: a lone daily signature vanishes along with the file it signs, so on its own it can't prove a day went missing. Two years of this is about 18 GB, which fits on the smallest drive worth buying.

What's missing

• No off-site copy of the archive. Two years of records the law requires will sit on a single drive. If it dies, they're gone. The nightly archive is around 25 MB, so copying it somewhere is cheap and we should, but it's out of scope here.
• No UPS, and no backup battery for the clock. After a power cut the box comes up with the wrong time. We deal with that by holding the logger until the clock has synced, so we lose a few minutes of records instead of writing a few minutes of wrong ones.
• A KVKK notice has to exist before this goes live, covering what we store, why, and for how long. Someone has to write that; it isn't a setting.