Magic spell for PIOS wifi point.

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.

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