On 2026-01-13, mm0fmf <none@invalid.com> wrote:

I may be wrong and sometimes am but I thought all you needed to add was
edit /etc/sysctl.conf and ensure it contains "net.ipv4.ip_forward = 1",
save and reboot. Mine came with the line in there but commented out.

That is for IP routing, using seperate IP networks on the ethernet and wifi side. You can do that, but it may make the setup more complicated and cause problems with prototols that rely on broadcast/multicast packets, as these
are not routed. Also, if your WIFI clients require internet access, you need
to setup routes on your internet router so it can forward packages back to
the WIFI gateway. You need to decide if routing or bridging best suits your needs.

"normal" WIFI access points usually operate in bridging mode.



For bridging, you need to set up a bridge device, with both the ethernet and wifi devices slaved to the bridge. In that scenario, the slave devices do
not get IP addresses assigned - the bridge device is the one with the IP address.

Looking at a running example (on custom hardware, not a raspberry),
with a single of the 3 wifi modules active, it looks like this (eth1 is the ethernet interface, phy0-ap0 is wifi):

root@lx6500-dev:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.00a057802bee no eth1
phy0-ap0

root@lx6500-dev:~# ip l
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
6: phy0-ap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state DOWN mode DEFAULT group def0
link/ether 04:f0:21:bf:45:cc brd ff:ff:ff:ff:ff:ff

root@lx6500-dev:~# ip a
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fe80::2a0:57ff:fe80:2bee/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
6: phy0-ap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state DOWN group default qlen 1000
link/ether 04:f0:21:bf:45:cc brd ff:ff:ff:ff:ff:ff

Using that configuration, WIFI clients get addresses from the existing DHCP server on the LAN, and are in the same IP network as the LAN devices.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-01-13, The Natural Philosopher <tnp@invalid.invalid> wrote:

Sorry, I should have been clearer. It only does one band at once.
There is only one radio.

David

Does that preclude 2 band operation?

It precludes what vendors call concurrent dual-band operation. You can
operate on both bands, but only one at a time.

For an accesspoint, that basically means single-band, but you get to pick
which band is used.

cu
Michael
--
Some people have no respect of age unless it is bottled.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 18/01/2026 10:54, Michael Schwingen wrote:

On 2026-01-13, mm0fmf <none@invalid.com> wrote:

I may be wrong and sometimes am but I thought all you needed to add was
edit /etc/sysctl.conf and ensure it contains "net.ipv4.ip_forward = 1",
save and reboot. Mine came with the line in there but commented out.

That is for IP routing, using seperate IP networks on the ethernet and wifi side. You can do that, but it may make the setup more complicated and cause problems with prototols that rely on broadcast/multicast packets, as these are not routed. Also, if your WIFI clients require internet access, you need to setup routes on your internet router so it can forward packages back to the WIFI gateway. You need to decide if routing or bridging best suits your needs.

"normal" WIFI access points usually operate in bridging mode.

For bridging, you need to set up a bridge device, with both the ethernet and wifi devices slaved to the bridge. In that scenario, the slave devices do
not get IP addresses assigned - the bridge device is the one with the IP address.

Looking at a running example (on custom hardware, not a raspberry),
with a single of the 3 wifi modules active, it looks like this (eth1 is the ethernet interface, phy0-ap0 is wifi):

root@lx6500-dev:~# brctl show
bridge name bridge id STP enabled interfaces
br-lan 7fff.00a057802bee no eth1
phy0-ap0

root@lx6500-dev:~# ip l
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP mode DEFAULT group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
6: phy0-ap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state DOWN mode DEFAULT group def0
link/ether 04:f0:21:bf:45:cc brd ff:ff:ff:ff:ff:ff

root@lx6500-dev:~# ip a
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:a0:57:80:2b:ee brd ff:ff:ff:ff:ff:ff
inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
valid_lft forever preferred_lft forever
inet6 fe80::2a0:57ff:fe80:2bee/64 scope link proto kernel_ll
valid_lft forever preferred_lft forever
6: phy0-ap0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state DOWN group default qlen 1000
link/ether 04:f0:21:bf:45:cc brd ff:ff:ff:ff:ff:ff

Using that configuration, WIFI clients get addresses from the existing DHCP server on the LAN, and are in the same IP network as the LAN devices.

cu
Michael

Yes. a bridge is - a bridge! and that is how normal wifi access points work

My issue is not with the basic config. It is with the performance - and
in fact a subset of the performance - access to my LAN is FINE access
the internet beyond is dire, but not impossible

For reference this is what IP link shows:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master
nm-bridge state UP mode DEFAULT group default qlen 1000
link/ether d8:3a:dd:85:22:b1 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
master nm-bridge state UP mode DORMANT group default qlen 1000
link/ether d8:3a:dd:85:22:b2 brd ff:ff:ff:ff:ff:ff
4: nm-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether d8:3a:dd:85:22:b1 brd ff:ff:ff:ff:ff:ff


Everything seems as it should be. No interface reports packet loss, yet
still it is massive but *only when going to/from wifi client to.from the Internet*.

I do not understand what is so different about a packet going to or from
the internet that causes the problem.

--
?But what a weak barrier is truth when it stands in the way of an
hypothesis!?

Mary Wollstonecraft


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

The Natural Philosopher <tnp@invalid.invalid> writes:

4: nm-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether d8:3a:dd:85:22:b1 brd ff:ff:ff:ff:ff:ff

Hmm, mtu 9000 on the bridge? That means jumbo frames and your
performance issue might be because something chokes on them. Your router
or whatever is in the other end. So try setting it to 1500 in your
chosen config tool.

--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 19/01/2026 10:08, Anssi Saari wrote:

The Natural Philosopher <tnp@invalid.invalid> writes:

4: nm-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue
state UP mode DEFAULT group default qlen 1000
link/ether d8:3a:dd:85:22:b1 brd ff:ff:ff:ff:ff:ff

Hmm, mtu 9000 on the bridge? That means jumbo frames and your
performance issue might be because something chokes on them. Your router
or whatever is in the other end. So try setting it to 1500 in your
chosen config tool.

It made no difference. I added that in case it helped. It didnt.

--
Civilization exists by geological consent, subject to change without notice.
? Will Durant


--- PyGate Linux v1.5.2
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)