1

I am trying to set up a Raspberry Pi 4 as a wlan0 <-> wlan1 router and followed Ingo's excellent guide here:

Access point as WiFi router/repeater with additional WiFi-dongle

Having gone through all the steps on a fresh, updated Buster installation, I've not been able to make this work.

wlan1 happily connects to the internet (I am typing this on the Raspberry Pi 4 in question) and other computers can connect to the access point I set up at wlan0.

However no internet access is happening for computers connected to wlan0.

ifconfig on computers connected to wlan0 indicates that they are somehow picking up an IP address from wlan1's range instead of wlan0's DHCP range.

I'm tearing my few remaining hairs out here. Have gone through the entire process described in Ingo's answer with a fresh install of Buster.

Any help is greatly appreciated!

Additional info:

# Here is my /etc/resolvconf.conf:
resolvconf=NO
resolv_conf=/etc/resolv.conf
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf    unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf

# My /etc/wpa_supplicant/wpa_supplicant-wlan0.conf:
country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="Illusionary 2"
mode=2
key_mgmt=WPA-PSK
psk="connectme"
frequency=2412
}

# My /etc/wpa_supplicant/wpa_supplicant-wlan1.conf:
country=GB
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="ActualSSID"
psk="ActualPW"
}

# My wpa_supplicant@wlan1.service:
[Service]
ExecStartPre=/sbin/iptables -t nat -A POSTROUTING -o wlan1 -j MASQUERADE
ExecStopPost=-/sbin/iptables -t nat -D POSTROUTING -o wlan1 -j MASQUERADE

# My /etc/systemd/network/08-wlan0.network:
[Match]
Name=wlan0
[Network]
Address=192.168.4.1/16
IPForward=yes
DHCPServer=yes
[DHCPServer]
DNS=84.200.69.80 1.1.1.1
RouteMetric=200

# My /etc/systemd/network/12-wlan1.network:
[Match]
Name=wlan1
[Network]
Address=192.168.1.199/24
DNS=8.8.8.8 8.8.4.4
DHCP=yes
[Route]
Gateway=192.168.1.1
Metric=10
[DHPC]
RouteMetric=100

# ifconfig output:
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 1000  (Local Loopback)
RX packets 12  bytes 600 (600.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 12  bytes 600 (600.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.4.1  netmask 255.255.0.0  broadcast 192.168.255.255
inet6 fe80::dea6:32ff:fe03:2d7c  prefixlen 64  scopeid 0x20<link>
ether dc:a6:32:03:2d:7c  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 121  bytes 42965 (41.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.1.199  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::76da:38ff:feea:7fcb  prefixlen 64  scopeid 0x20<link>
ether 74:da:38:ea:7f:cb  txqueuelen 1000  (Ethernet)
RX packets 6617  bytes 4308027 (4.1 MiB)
RX errors 0  dropped 1625  overruns 0  frame 0
TX packets 3264  bytes 481039 (469.7 KiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

# iwconfig output:
wlan0     IEEE 802.11  Mode:Master  Tx-Power=31 dBm
Retry short limit:7   RTS thr:off   Fragment thr:off
Power Management:on
eth0      no wireless extensions.
lo        no wireless extensions.
wlan1     IEEE 802.11bgn  ESSID:"ActualSSID"  Nickname:"<WIFI@REALTEK>
Mode:Managed  Frequency:2.437 GHz  Access Point: 80:2A:A8:44:F6:19
Bit Rate:72.2 Mb/s   Sensitivity:0/0
Retry:off   RTS thr:off   Fragment thr:off
Power Management:off
Link Quality=99/100  Signal level=49/100  Noise level=0/100
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

# route -n output:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    10     0        0 wlan1
0.0.0.0         192.168.1.1     0.0.0.0         UG    1024   0        0 wlan1
192.168.0.0     0.0.0.0         255.255.0.0     U     0      0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan1
192.168.1.1     0.0.0.0         255.255.255.255 UH    1024   0        0 wlan1`

Updated 2019-10-25:

I've implemented Ingo's suggestions, but so far have had no luck with getting this to work. Access to the internet via wlan1 is (still) working locally, but wlan0 still doesn't connect clients to the internet.

My new /etc/systemd/network/08-wlan0.network:  
[Match]
Name=wlan0
[Network]
Address=192.168.4.1/24
IPForward=yes
DHCPServer=yes
[DHCPServer]
DNS=84.200.69.80 1.1.1.1  


My new /etc/systemd/network/12-wlan1.network:
[Match]
Name=wlan1
[Network]
DHCP=yes 


My new ifconfig output:
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536

        inet 127.0.0.1  netmask 255.0.0.0  
        inet6 ::1  prefixlen 128  scopeid 0x10<host>  
        loop  txqueuelen 1000  (Local Loopback)  
        RX packets 156  bytes 15032 (14.6 KiB)  
        RX errors 0  dropped 0  overruns 0  frame 0  
        TX packets 156  bytes 15032 (14.6 KiB)  
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  
        inet 192.168.4.1  netmask 255.255.255.0  broadcast 192.168.4.255  
        inet6 fe80::dea6:32ff:fe03:2d7c  prefixlen 64  scopeid 0x20<link>  
        ether dc:a6:32:03:2d:7c  txqueuelen 1000  (Ethernet)  
        RX packets 9  bytes 1107 (1.0 KiB)  
        RX errors 0  dropped 0  overruns 0  frame 0  
        TX packets 139  bytes 42957 (41.9 KiB)  
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

wlan1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  
        inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255  
        inet6 fe80::76da:38ff:feea:7fcb  prefixlen 64  scopeid 0x20<link>  
        ether 74:da:38:ea:7f:cb  txqueuelen 1000  (Ethernet)  
        RX packets 2151  bytes 949342 (927.0 KiB)  
        RX errors 0  dropped 129  overruns 0  frame 0  
        TX packets 1043  bytes 244850 (239.1 KiB)  
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0  

My new iwconfig output:
wlan0     IEEE 802.11  Mode:Master  Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off  
          Power Management:on  
           eth0      no wireless extensions.  

lo        no wireless extensions.  

wlan1     IEEE 802.11bgn  ESSID:"ActualSSID"  Nickname:"<WIFI@REALTEK>"  
          Mode:Managed  Frequency:2.437 GHz  Access Point: 80:2A:A8:44:F6:19     
          Bit Rate:72.2 Mb/s   Sensitivity:0/0    
          Retry:off   RTS thr:off   Fragment thr:off  
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open  
          Power Management:off  
          Link Quality=100/100  Signal level=53/100  Noise level=0/100  
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0  
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0  

My new route -n output:
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  

0.0.0.0         192.168.1.1     0.0.0.0         UG    1024   0        0 wlan1  
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan1  
192.168.1.1     0.0.0.0         255.255.255.255 UH    1024   0        0 wlan1  
192.168.4.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0

Updated 2019-10-26, output from 2nd Pi:

iw wlan0 link:
Connected to dc:a6:32:03:2d:7c (on wlan0)
SSID: Illusionary 2
freq: 2412
RX: 21652487 bytes (154629 packets)
TX: 1115276 bytes (7331 packets)
signal: -20 dBm
tx bitrate: 72.2 MBit/s MCS 7 short GI
bbs flags: short preamble short-slot-time
dtim period: 2
beacon int: 100

ip addr:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever 
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether b8:27:eb:14:2d:b1 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.175/24 brd 192.168.2.255 scope global eth0:1
valid_lft forever preferred_lft forever 
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 00:0b:81:87:b9:bb brd ff:ff:ff:ff:ff:ff
inet 192.168.1.114/24 brd 192.168.1.255 scope global wlan0
valid_lft forever preferred_lft forever
inet6 fe80::20b:81ff:fe87:b9bb/64 scope link
valid_lft forever preferred_lft forever 
  • You write "*Having gone through all the steps on a fresh, updated Buster installation*" and "*Have gone through the entire process described in Ingo's answer twice now, with a fresh install of Stretch both times.*" and you tagged with `raspbian-stretch`. Using Stretch doesn't make sense on a RPi 4B so I assume to use a Buster installation. – Ingo Oct 25 '19 at 10:12
  • Yep, correct, Buster - I missed the 2nd instance of "Stretch" when I edited the above,. Fixed now! – Michael Virks Oct 25 '19 at 10:27
  • Now it looks good from the given diagnostic output. I can't see any issues yet. Routing table looks good. What is still not working? Do you can connect to the access point? Do you can `ping google.com` from the RasPi? – Ingo Oct 25 '19 at 18:31
  • Pinging google works, and I'm actually writing these comments and updates from the desktop of this Pi4, so no problems with wlan1 as far as I can see. – Michael Virks Oct 25 '19 at 18:38
  • Connections to wlan0 on my Android phone just hang indefinitely. I unfortunately haven't brought my laptop tonight, so I cannot try to connect from that for more detailed diagnostic/routing info. Will try that tomorrow. – Michael Virks Oct 25 '19 at 18:39
  • With my Android phone I have seen that I have to reboot it after heavy changing/testing wifi. WiFi is mainly an issue of wpa_supplicant.conf. – Ingo Oct 25 '19 at 18:45
  • Just tried connecting to wlan0 from another Raspberry Pi. Connects, authenticates, for some reason receives a 192.168.1.x address rather than a 192.168.4.x address. Tried traceroute 1.1.1.1, fails immediately on the first hop (own 192.168.1.x IP address). Chromium reports that no DNS servers can be found to resolve any address I throw at it. So I think this is a DNS problem - somehow DNS requests are not passed between wlan0 and wlan1 correctly. – Michael Virks Oct 25 '19 at 18:59
  • With 192.168.1.x nothing can work. You have to look why the other RasPi does not get an ip address from 192.168.4.0/24. Are you sure that it is associated to the right access point (RasPi, not router)? What do you get with `ip addr` and `iw wlan0 link` on the other RasPi? – Ingo Oct 25 '19 at 22:15
  • The access point itself has the ip address 192.168.4.1 so if a device is connected to this access point it is completely unknowable why it get an ip address from another subnet. Do you have **dnsmasq** running from a previous installation? – Ingo Oct 26 '19 at 18:01
  • it's a completely fresh buster installation with only the steps in the guide at https://raspberrypi.stackexchange.com/questions/95072/access-point-as-wifi-router-repeater-with-additional-wifi-dongle applied to it – Michael Virks Oct 27 '19 at 22:37
  • Have added ip addr and iw wlan0 link info above. Anything else I can try? – Michael Virks Oct 28 '19 at 18:15
  • 2nd Pi has a wrong interface configuration for wlan0. Seems it has a static ip address. It must have DHCP enabled to get the ip address from the access point 192.168.4.1. – Ingo Oct 28 '19 at 20:44
  • I have just tested a completely fresh buster installation with only the steps in the guide at https://raspberrypi.stackexchange.com/questions/95072/access-point-as-wifi-router-repeater-with-additional-wifi-dongle applied to it. I can confirm that it works. Double check for typos. If your installation does not work, then the problem is not that setup. You have to look at other things around. Maybe your RasPi or USB/wifi dongle is broken. Try another one. Look at your router configuration with focus on DHCP. Check your WiFi setup. Reboot all devices on the network including the router. – Ingo Oct 29 '19 at 18:31
  • @ingo, in order to completely replicate your setup, I'd like to try using exactly the same wifi dongle for wlan1. Currently I'm working with an Edimax EW-7811Un. Which one are you using? – Michael Virks Oct 31 '19 at 19:44
  • I'm using this dongle: https://best-de.tv/shop/usb-w-lan-adapter-hqwl-45/. Sorry but couldn't find an english version. But I believe it's a configuration error. For what I see so far it not possible that a device connected to the access point gets an ip address from subnet 192.168.1.0/24. You can try to swap **wlan0** and **wlan1** to make **wlan1** an access point. – Ingo Nov 01 '19 at 09:50

1 Answers1

1

You try to run Raspbian Stretch on a Raspberry Pi 4. On the release notes you will find:

2019-06-20:
* Based on Debian Buster
* Support for Raspberry Pi 4 hardware

This means Raspbian Stretch as predecessor from Rasbian Buster does not support Raspberry Pi 4. Before continue troubleshooting please start again with Raspbian Buster.

With your updated info I assume you have used a Raspbian Buster installation. I can see some problems with the configuration. You used in

# My /etc/systemd/network/08-wlan0.network:
[Match]
Name=wlan0
[Network]
Address=192.168.4.1/16
IPForward=yes
DHCPServer=yes
[DHCPServer]
DNS=84.200.69.80 1.1.1.1
RouteMetric=200

The [DHCPServer] section does not define an option RouteMetric=. Look at man systemd.network. You must delete this line. But the main problem is that you use bitmask /16 with ip address 192.168.4.1/16. This selects the whole private subnet 192.168.0.0/16 with 65.536 ip addresses including the subnet for wlan1 (192.168.1.0/24 with 256 ip addresses). This superposition cannot work and may explain the problem you have find with ip addresses. Use ip address 192.168.4.1/24.

# My /etc/systemd/network/12-wlan1.network:
[Match]
Name=wlan1
[Network]
Address=192.168.1.199/24
DNS=8.8.8.8 8.8.4.4
DHCP=yes
[Route]
Gateway=192.168.1.1
Metric=10
[DHPC]
RouteMetric=100

Here are some things wrong. You try to use a static ip address. Why? There is no need. Most problems we see here on this site is using a static ip address because it often conflicts with automatic DHCP network management. In addition you enabled getting an ip address by DHCP with DHCP=yes. This cannot work. I also don't understand why you use additional Sections [Route] and [DHPC]. The latter is a typo. Routing with Metric is managed automatically. Fiddling with manual settings will only confuse the routing table.

The routing table reflects the wrong configuration: two default routes to the same gateway with different Metric makes no sense, a big subnet on wlan0 and a part of it as smaller subnet on wlan1 will not work as intended.

Please just use exactly the configuration I have given in my tutorial. If it then run on your RasPi you can modify it to what you like.

Ingo
  • 40,606
  • 15
  • 76
  • 189
  • Hi - thanks for responding! Sorry that I'm being a bit slow here - am travelling a lot right now. I'm now running up-to-date buster and am still having trouble after following your guide. – Michael Virks Oct 22 '19 at 17:31
  • @MichaelVirks Comments are only for simple questions but unusable for extended statements as you can see. Yours are all unreadable and I don't read them. Please edit your question and insert what you like to elaborate. There you can also format it. After doing it you can delete your comments. And having a look at the short [Tour](https://raspberrypi.stackexchange.com/tour) and visit the [Help Center](https://raspberrypi.stackexchange.com/help) is also a good idea ;-) – Ingo Oct 22 '19 at 18:10
  • 1
    Sorry - just realised - diagnostic info is now in main post. It's been a long day :-) – Michael Virks Oct 22 '19 at 18:27
  • @MichaelVirks I have updated the answer in respect to your additional configuration info, which is very good and show what's wrong. – Ingo Oct 25 '19 at 15:05
  • thanks for that detailed response! Annoyingly still not working, but I've added updated diagnostics info to my question above – Michael Virks Oct 25 '19 at 18:09