From Newsgroup: comp.sys.raspberry-pi

On 12/01/2026 20:16, David Higton wrote:

In message <10k2bri$272ps$1@druck.eternal-september.org>
druck <news@druck.org.uk> wrote:

On 11/01/2026 14:40, David Higton wrote:

Note that the RPi4 only does one wifi band; I don't know the RPi5.

The Raspberry Pi 3B+, 4 and 5 have both 2.4GHz and 5GHz Wifi bands, the
Zero W, Zero 2W and older Pi's only have 2.4GHz

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?
--
"Nature does not give up the winter because people dislike the cold."

― Confucius

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 11/01/2026 12:58, The Natural Philosopher wrote:

But I have never seen it configured as a *bridge* to the network and
DHCP server via the Ethernet.

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.

You need to allocate IP for ethernet and the TV manually and maybe play
with routing.

I have it running on a PI somewhere, I'll dig it out.





--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 12/01/2026 20:16, David Higton wrote:

In message <10k2bri$272ps$1@druck.eternal-september.org>
druck <news@druck.org.uk> wrote:

On 11/01/2026 14:40, David Higton wrote:

Note that the RPi4 only does one wifi band; I don't know the RPi5.

The Raspberry Pi 3B+, 4 and 5 have both 2.4GHz and 5GHz Wifi bands, the
Zero W, Zero 2W and older Pi's only have 2.4GHz

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

You can always add another USB WiFi dongle if you want to act as an
access point on both bands simultaneously.

---druck
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 13/01/2026 13:27, mm0fmf wrote:

On 11/01/2026 12:58, The Natural Philosopher wrote:

But I have never seen it configured as a *bridge* to the network and
DHCP server via the Ethernet.

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.

You need to allocate IP for ethernet and the TV manually and maybe play
with routing.

I have it running on a PI somewhere, I'll dig it out.

That would be kind




--
“Ideas are inherently conservative. They yield not to the attack of
other ideas but to the massive onslaught of circumstance"

- John K Galbraith


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 13/01/2026 14:45, druck wrote:

On 12/01/2026 20:16, David Higton wrote:

In message <10k2bri$272ps$1@druck.eternal-september.org>
           druck <news@druck.org.uk> wrote:

On 11/01/2026 14:40, David Higton wrote:

Note that the RPi4 only does one wifi band; I don't know the RPi5.

The Raspberry Pi 3B+, 4 and 5 have both 2.4GHz and 5GHz Wifi bands, the
Zero W, Zero 2W and older Pi's only have 2.4GHz

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

You can always add another USB WiFi dongle if you want to act as an
access point on both bands simultaneously.

---druck

I saw something (hostapd) that implies it can in fact do both...

Well in due course I will find out.
--
“Ideas are inherently conservative. They yield not to the attack of
other ideas but to the massive onslaught of circumstance"

- John K Galbraith


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On Tue, 13 Jan 2026 13:27:40 +0000, mm0fmf 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.

Set that line in /etc/sysctl.conf, and also do it manually this one
time, just to save a reboot.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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.
--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

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

--- Synchronet 3.21b-Linux NewsLink 1.2

From Newsgroup: comp.sys.raspberry-pi

On 19/01/2026 10:59, The Natural Philosopher wrote:

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.

It's a setting almost guaranteed not to help. There are vast numbers of devices that choke on anything more than the normal Ethernet MTU.

---druck
--- Synchronet 3.21b-Linux NewsLink 1.2