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