Inspiration
We thought about MSU's wifi setup where you have to login each time, and thought "This sucks to sign into, what if it was a game?"
What it does
WiFight is a WiFi access point, but no ordinary access point. The login portal that auto pops up when you connect is Flappy Bird, and to get internet, you must beat the highest score, or if that's too much you can get 10 points for 10 minutes of 10mbps internet access. The WiFight dashboard shows all connected players, their states, scores, and a real-time synced feed of their game.
How we built it
We used a Raspberry Pi 4 and a Mediatek WiFi adapter, along with a GL.iNet travel router as the base hardware stack. A Python script orchestrates Linux's hostapd (access point), dnsmasq (DNS/DHCP), iptables (firewall/NAT), and tc (traffic control) to bring up a WiFi network with a captive portal. The portal itself is a Flask web server with Socket.IO for real-time communication.The game state syncs to the server at 30 ticks per second via WebSockets, with client-side prediction to keep gameplay smooth despite network latency. When a player earns their reward, we dynamically rewrite iptables rules to bypass the captive portal and redirect their DNS to real servers (Google's 8.8.8.8), giving them actual internet access. When time expires, we revoke those rules, deauthenticate them from the WiFi, and force them back into the game.
Challenges we ran into
Getting Linux to selectively enable/disable internet access without forcing manual reconnects was the biggest hurdle. Each OS (iOS, Android, Windows) checks different URLs for captive portal detection, so we had to implement handlers for all of them.
DNS was particularly tricky, dnsmasq intercepted queries before our iptables rules could redirect them. We had to understand the kernel's packet flow to make selective DNS bypass work. Debugging required tcpdump across multiple interfaces to trace where packets were being silently dropped. The RF environment at Spartahack was also brutal, hundreds of competing access points caused intermittent connection drops on our 2.4GHz signal.
Accomplishments that we're proud of
We were able to manipulate Linux's networking stack to gamify wifi logins. The precise combinations of tc and dnsmasq configs allowed us to allow, deny, and shape (control the speed of) internet traffic going through our access point in a very flexible way.
What we learned
Linux's networking stack is incredibly powerful but requires understanding the exact order of operations (iptables chains, routing decisions, local socket delivery vs forwarding) Captive portal detection varies wildly across operating systems and even OS versions Traffic control (tc) with HTB (Hierarchical Token Bucket) queuing is the right tool for per-client bandwidth shaping WebSockets are essential for real-time game state sync, but you need client-side prediction to mask latency
What's next for WiFight
Multi-game support: Like Jackbox party pack, choose a game and let the users fight it out.
5Ghz support: Run the AP on a different band so we don't have to deal with as much interference.
Difficulty scaling: Adjust game difficulty based on network congestion: more players means harder games
Mobile-optimized controls: Better touch controls for phone users in the captive portal
Log in or sign up for Devpost to join the conversation.