This is the problem and this applies to EVERY OS image ‘Team BPi’ provides. It’s a well known problem, it’s easy to fix but you made the mistake to buy hardware from a vendor that doesn’t give a sh*t about software issues. They only want to sell hardware and they even don’t test the crappy OS images they release every few days. They simply don’t care.
Congrats. You and me are the only 2 M3 users in the world that do not suffer from this limitation any longer (there are 3 more necessary fixes for kernel sources/sys_config.fex – but I won’t share since this is 'Team BPi’s strategy: Let their customers do all the work).
So now let’s have a look how long it takes until ‘Team BPi’ fixes their beginner’s mistake (can be also done in a running installation without recompiling the kernel).
I’ve got very weird behaviour. I don’t have WiFi device.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether aa:6e:a1:b9:2a:3c brd ff:ff:ff:ff:ff:ff
inet 192.168.1.8/16 brd 192.168.255.255 scope global eth0
inet6 fe80::a86e:a1ff:feb9:2a3c/64 scope link
valid_lft forever preferred_lft forever
3: tunl0: <NOARP> mtu 1480 qdisc noop state DOWN group default
link/ipip 0.0.0.0 brd 0.0.0.0
4: sit0: <NOARP> mtu 1480 qdisc noop state DOWN group default
link/sit 0.0.0.0 brd 0.0.0.0