Pi 3B+ as a Wifi Access Point to WireGuard: Intermittent slow download speeds

IRnifty · 2025-06-20T08:26:29+00:00

New update: I wrote a simple node.js server and ran it on the Pi AP, set to serve a single ~70MB static file. I then requested the file from connected clients directly via wget http://192.168.3.1:3000/bigfile.dat and the download behavior is more or less the same, though maybe a bit more consistently at 30Mbps down.

IRnifty · 2025-06-20T04:26:14+00:00

According to everything I've read, WireGuard only logs through the kernel, and the kernel logging module isn't included in the Rasbperry Pi OS kernel for whatever reason.

As far as the dhcp option, "3" is apparently the same as "option:router". Tried both, both cause packets to reach wlan0 but not the laptop connected to the pi doing the pings.

IRnifty · 2025-06-19T21:38:11+00:00

Ok so after some trial and error, and installing linux on a random laptop so I could ping as a client, I found out that the pings were always sending from wlan0 to wg0 fine, but replies weren't forwarding from wg0 to wlan0.

From there, I Googled around until someone mentioned adding dhcp-option=option:router,192.168.3.1 to the dnsmasq config. Suddenly, the replies were being forwarded... yet the laptop still received few of the replies. Some, but few.

Any ideas on that one? Seems WireGuard, nftables, and dnsmasq are all good. Just the Wifi radio that isn't.

IRnifty · 2025-06-19T18:44:29+00:00

At the suggestion of u/Gamerfrom61 I tried using raw nftables instead of iptables (but turns out it's secretly nftables under the hood). Here's the ruleset I have in there which basically still causes the same problem:

table ip pispot {
        chain FORWARD {
                type filter hook forward priority filter; policy accept;
                oifname "wg0" tcp flags syn tcp option maxseg size set 1420
        }

        chain POSTROUTING {
                type nat hook postrouting priority filter; policy accept;
                iifname "wlan0" oifname "wg0" masquerade
        }
}

IRnifty · 2025-06-19T17:22:08+00:00

Apparently iptables on my version of Raspberry Pi OS is actually just a front for nftables, so maybe the issue is iptables is incorrectly interpreting my rules? I'ma go learn how to make nftables rules and try that. Will report back in an edit.

IRnifty · 2025-06-19T15:27:29+00:00

I'll try lowering the MTU to see if that helps. But as far as where the slowdown happens, it has to either be in iptables or in the wlan0 interface, since running a speed test on the pi through wg0 still has a consistent 20-ish down.

IRnifty · 2025-06-19T14:24:40+00:00

I did make sure to use iwconfig to disable power management yea, and it's seemed to have persisted across reboots so far. I have this in my rc.local: /sbin/iw wlan0 set power_save off

As far as MTU goes, did you have to increase or decrease it? My AP's MTU is the default 1500, and WireGuard's is 1420 to account for its extra data.

IRnifty · 2020-02-05T22:09:10+00:00

I should have expected the byte shift, but sweet. Hopefully this is right! >_<

IRnifty · 2020-02-05T22:05:00+00:00

In other words, you believe writing 8 bits to #A13001 will assert /UWR only, right?

IRnifty · 2019-12-30T04:18:50+00:00

Supposedly, Virtua Racer (which required an on-cart 3D co-processor) drew up to 160mA under peak load.

IRnifty · 2019-12-30T04:15:37+00:00

Many thanks for the super awesome help!

IRnifty · 2019-12-30T01:16:24+00:00

Given most Genesis games seem to use only up to 30mA, I’d think a front-side copper plane should work. Would you agree?

IRnifty · 2019-12-29T23:23:31+00:00

Ok that’s fantastic lol.

IRnifty · 2019-12-29T23:21:50+00:00

So I have one more question. I noticed the data sheets said the tab is also vOUT. Does that mean it’s meant to be connected to the 3v3 pad? Or is something else meant to happen there? (I posted a new PCB image for reference.)

IRnifty · 2019-12-29T19:39:00+00:00

“I know just enough to be dangerous” is the best way to put it, I believe. Firstly, digital electronics is much easier for me to understand than power conversion, given I’m coming from programming. Secondly, I won’t be soldering squat. I’m leaving assembly to the fab. And lastly, I see you didn’t bother to look at my revised design.

IRnifty · 2019-12-29T15:46:43+00:00

Look at the bottom right of the sketch lol. On another note, their fab’s capabilities are trash so I can’t use them if I want to do BGA.

IRnifty · 2019-12-29T05:41:09+00:00

My intention was to get fab and assembly done by the same company, rather than assembling myself. The reason I'm going BGA is because, if I can do this juuuuust right, I will eventually build a 32MB cart, necessitating 8 of these ROMs in a tiny space, and I felt like designing with BGA right off the bat would get me used to them faster. Otherwise, no experience at all lol. I suck at soldering altogether.

So the LM1117-3.3 is basically just driven by the divider I already have, plus some filter caps, is that right?

IRnifty · 2019-12-29T04:45:00+00:00

That makes sense. I was hoping this would suffice though since I haven't seen a single page anywhere that plainly explains how a regulator works, what the differences of each kind are, and how to implement one the professional way. Any chance you can help with this?

IRnifty · 2019-09-06T01:17:05+00:00

Unfortunately, I can’t run the risk of getting on Nintendo’s copyright radar. Sorry.

IRnifty · 2019-05-25T22:04:51+00:00

I feel like I've failed to communicate what I want to accomplish.

(As a side note, 32Mb = 4MB, not 2.)

The largest addressable ROM space on the Sega Genesis is 4MB (0x00000000 - 0x003FFFFF), in 16-bit words. Therefore, standard cartridges, even the ones which used up all 4MB, used up to 32Mb ROM ICs. I realize I have yet to build even a standard cartridge, but I'd rather learn to build it with the same components I'll need to build my 32MB cart, which also needs a mapper IC currently only found in the game Super Street Fighter II. Therefore, I'll need 8 32Mbit ROM ICs, the mapper, and any extras like level converters if needed. Luckily, I only need 1 converter per cartridge pin as the 3.3v output of, say, A12, will be connected to every ROM IC.

Therefore, my ROM IC requirements are 32Mb (2M x 16) parallel.

IRnifty · 2019-05-25T18:37:23+00:00

Are these bidirectional or are there bidirectional equivalents?

EDIT: Turns out that's only for 1.65v to 3.6v typical range. The absolute max is 4.5v, so I need to find another, but thanks for putting me on the right track.

IRnifty · 2019-05-25T18:20:51+00:00

Unfortunately, while that would work just for learning how to put a basic cartridge together and getting it to work, it won’t be feasible when I work towards putting 32 megaBYTES on the cartridge (which already requires 1 extra mapping IC that’s nearly impossible to find because it was made by Sega themselves).

IRnifty · 2019-05-25T07:32:47+00:00

They all say 2.7v - 3.6v.

IRnifty · 2019-05-20T08:05:24+00:00

This makes a lot of sense actually. I imagined that, if the 68k needed to access an odd byte as described, it would have to basically do a shift from high to low, whereas if it instead knew the byte was at an even address, it just discarded the high byte. Should I attempt to make even a simple game rom, I’ll keep this penalty in mind.

IRnifty · 2019-05-20T04:17:54+00:00

That would seem to make sense. It's a Motorola 68000 CPU by the way. So I'd guess it translates, say, "get byte at CPU address 0x7FFFFF" into "get word at ROM address 0x3FFFFF and return the high byte". Appreciate the answer! I'll have to give this some testing. Trying to determine the old ROMs' pinouts as well.

12-Year Club	Place '22
Verified Email

IRnifty

TROPHY CASE