MSGID: <10kj75s$3ktp5$2@dont-email.me> c2e02a16
REPLY:  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  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: 105/81 106/201 128/187 129/14 305 153/7715 154/110 218/700
SEEN-BY: 226/30 227/114 229/110 112 134 200 206 300 317 400 426 428
SEEN-BY: 229/470 616 664 700 705 266/512 291/111 292/854 320/219 322/757
SEEN-BY: 342/200 396/45 460/58 633/10 280 414 418 420 422 509 2744
SEEN-BY: 712/848 770/1 902/26 2320/105 5020/400 5075/35
PATH: 633/10 280 229/426