@MSGID: <10kj75s$3ktp5$2@dont-email.me> c2e02a16
@REPLY:
<slrn10mpf03.bh8.news-1513678000@a-tuin.ms.intern> 25b12232
@PID: PyGate 1.5.2
@TID: PyGate/Linux 1.5.2
@CHRS: CP1252 2
@TZUTC: 0000
@REPLYADDR tnp@invalid.invalid
@REPLYTO 3:633/10 UUCP
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:  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:  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:  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:  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:  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:  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:  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:  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:  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:  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)
SEEN-BY: 1/19 100 16/0 19/37 50/109 80/1 105/81
106/201 123/130 128/187
SEEN-BY: 129/14 305 142/104 153/7715 154/110 201/0
203/0 218/700 221/0 1 6
SEEN-BY: 226/30 227/114 229/110 112 134 200 206
300 317 400 426 428 470 616
SEEN-BY: 229/664 700 705 230/0 240/1120 5832
266/512 280/5003 291/111 292/854
SEEN-BY: 301/1 113 812 320/119 219 319 2119
322/757 762 325/304 335/364
SEEN-BY: 342/200 396/45 423/81 460/58 463/68 633/10
280 414 418 420 422 509
SEEN-BY: 633/2744 712/848 770/1 902/26 2320/105
5019/40 5020/400 715 848 1042
SEEN-BY: 5020/4441 12000 5030/49 722 1081 1474
5053/55 58 5061/133 5075/35
SEEN-BY: 5075/128
@PATH: 633/10 280 229/426 320/219 221/1 301/1
5020/1042 4441