[PROBLEM] No internet access through Router mode

[psychofaktory]

Hello,

I finally got around to testing the new router mode.
Unfortunately, I found out that it does not work as expected.

My settings are as follows:
Ethernet is connected and set to DHCP.
The wireless settings are untouched
Under "Access Point" the router mode is activated and a SSID and password are set.

What I could observe:
The Raspberry gets assigned an IP configuration via LAN and is therefore reachable in the LAN and can also access the Internet.
At the same time the access point of the Raspberry is active and you can connect to its WLAN with the set password.
An IP from the subnet 172.24.1.0/24 is then assigned. The addresses of the Raspberry 172.24.1.1 are assigned as DHCP, DNS and gateway.
However, no packets are routed from the WLAN to the LAN.
Specifically, I could only access the 172.24.1.1 and the address assigned to the Raspberry via DHCP in the LAN when I was connected to the WLAN of the access point.



A Raspberry Pi 3B with moOde 8.2.2 (32-bit) is used.
I use the integrated WLAN of the Raspberry.
The system was freshly installed.

[psychofaktory]

I did some further testing.

I was able to get the routing working with the following commands:

Code:

sudo apt-get update
sudo apt install iptables
sudo iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT
sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
sudo nano /etc/rc.local
add the following abov "exit 0"
    iptables-restore < /etc/iptables.ipv4.nat

After a reboot, I could also access the Internet via the Moode WLAN.

However, the assigned DNS server 172.24.1.1 was not able to resolve the DNS requests.

[Tim Curtis]

Router mode works OK on my end.

Below are some screen shots from an iPad connected to the "Moode" SSID. Note that moOde uses nftables which is the default framework on RaspiOS 10 and later.

nftables configs

Code:

/etc/nftables.conf
/etc/sysctl.conf
/lib/systemd/system/nftables.service

iPad connected to 172.24.1.1 private WiFi network and playing an Internet radio station via Ethernet connection to Router.
         

Network configuration
             

[psychofaktory]

Tried again with another fresh install.
Everything untouched expect activation of Router mode and "Wait for Ethernet addr".
But still no Internet Access through Moode-Access-Point.

iPad connected to 172.24.1.1 private WiFi network and playing an Internet radio station via Ethernet connection to Router.

Moode is accessible from Ethernet via 10.20.20.115 an from WiFI via 172.24.1.1.
Also Moode has access to Internet and is able to play an Internet radio station.
But clients which are connected to Moodes WiFi doesn't have internet access.
Does your iPad has access to internet through Moodes Access-Point with active Router mode?

   
   

[Tim Curtis]

You mean like accessing google.com via Browser on iPad? That prolly won't work. it would have to be a Browser on the Pi itself.

The iftables rule set being used is in /var/www/inc/network.php.

Code:

.
.
    // Write /etc/nftables.conf
    $fp = fopen('/etc/nftables.conf', 'w');
    $data  = "#########################################\n";
    $data .= "# This file is automatically generated by\n";
    $data .= "# the player Network configuration page. \n";
    $data .= "#########################################\n\n";
    $data .= '#!/usr/sbin/nft -f

flush ruleset

table ip filter {
       # Allow all packets inbound
       chain IMPUT {
               type filter hook input priority 0; policy accept;
       }
       # Forwad packets from WLAN to LAN, and LAN to WLAN if WLAN initiated the connection
       chain FORWARD {
               type filter hook forward priority 0; policy accept;
               iifname "wlan0" oifname "eth0" accept
               iifname "eth0" oifname "wlan0" ct state established accept
               iifname "eth0" oifname "wlan0" ct state related accept
               iifname "eth0" oifname "wlan0" drop
       }
       # Allow all packets outbound
       chain OUTPUT {
               type filter hook output priority 100; policy accept;
       }
}

table ip nat {
       # Accept all packets for prerouting
       chain PREROUTING {
           type nat hook prerouting priority 0; policy accept;
       }
       # Accept and masquerade all packets for postrouting to outbound LAN
       chain POSTROUTING {
           type nat hook postrouting priority 100; policy accept;
           oifname "eth0" masquerade

}';

    fwrite($fp, $data);
    fclose($fp);

    // Configure packet forwarding for AP Router mode
    if ($cfgNetwork[2]['wlan_router'] == 'On') {
        sysCmd('sed -i "s/^#net.ipv4.ip_forward/net.ipv4.ip_forward/" /etc/sysctl.conf');
    } else {
        sysCmd('sed -i "s/^net.ipv4.ip_forward/#net.ipv4.ip_forward/" /etc/sysctl.conf');
    }
}

[psychofaktory]

You mean like accessing google.com via Browser on iPad? That prolly won't work. it would have to be a Browser on the Pi itself.

Yes, exactly this.

This would be an extremely important function of the router mode.

With the router mode it is now possible to control Moode from clients that only have a wireless network connection even if there is no WiFi infrastructure.
If the Wifi connection via Moode then has no Internet connection, however, this brings new problems.

Under Android it is for example so:
If a smartphone has a data connection via the mobile network and WLAN at the same time, the OS uses a connectivity check to decide which connection is actively used. If the WLAN does not have Internet connectivity, the mobile data connection is preferred instead. As a result, controlling Moode via UPnP, for example, is no longer possible.
The only remedy is to manually deactivate the mobile data connection on the smartphone. Moode can then be controlled again, but the smartphone itself is then offline. Messenger apps or VoLTE etc. are then no longer possible.


How a configuration for an access point with internet access for the clients (with NFtables) should look like is described e.g. here:
https://www.raspberryconnect.com/project...pcd-method

It would really be a huge added value if this would be implemented.

[Tim Curtis]

You mean like accessing google.com via Browser on iPad? That prolly won't work. it would have to be a Browser on the Pi itself.

Yes, exactly this.

This would be an extremely important function of the router mode.

With the router mode it is now possible to control Moode from clients that only have a wireless network connection even if there is no WiFi infrastructure.
If the Wifi connection via Moode then has no Internet connection, however, this brings new problems.

Under Android it is for example so:
If a smartphone has a data connection via the mobile network and WLAN at the same time, the OS uses a connectivity check to decide which connection is actively used. If the WLAN does not have Internet connectivity, the mobile data connection is preferred instead. As a result, controlling Moode via UPnP, for example, is no longer possible.
The only remedy is to manually deactivate the mobile data connection on the smartphone. Moode can then be controlled again, but the smartphone itself is then offline. Messenger apps or VoLTE etc. are then no longer possible.


How a configuration for an access point with internet access for the clients (with NFtables) should look like is described e.g. here:
https://www.raspberryconnect.com/project...pcd-method

It would really be a huge added value if this would be implemented.

The challenge is that our project would be on the hook for securing a general purpose Router function and thats not something thats in our scope.

[psychofaktory]

The challenge is that our project would be on the hook for securing a general purpose Router function and thats not something thats in our scope.

I don't see this connection that way.

The router function would only allow WiFi clients to access the LAN, where Moode is already connected anyway.

Further router functions, firewall, etc. are still the responsibility of the router that establishes the connection between WAN and LAN.
From this point of view, there is no requirement for Moode to provide additional security functions.
For this reason, this point is not taken into account in the manual that I had linked.

[Tim Curtis]

The challenge is that our project would be on the hook for securing a general purpose Router function and thats not something thats in our scope.

I don't see this connection that way.

The router function would only allow WiFi clients to access the LAN, where Moode is already connected anyway.

Further router functions, firewall, etc. are still the responsibility of the router that establishes the connection between WAN and LAN.
From this point of view, there is no requirement for Moode to provide additional security functions.
For this reason, this point is not taken into account in the manual that I had linked.

Yes, you could argue that moOde is just providing a proxy between your client and your home Router and it doesn't have to be secure. Let's imagine this is implemented. There will inevitably be "my client can't access the Internet" issues and then we are into supporting a general purpose Router.

Your scenario involved Android and it's "active connection" test. What about IOS, Windows or other Linux clients? How do they behave? 

What I would suggest is looking at the nftables wiki and modifying/swapping in one of their "Home Router" rule sets into /var/www/inc/network.php. If that works then at least there would be a guide for users that want to implement this function.

Another option would be if there is significant demand for a feature like this. Then I'd be inclined to add it to the TODO list but no guarantee there would be enough project bandwidth to take on the additional support.

Remember that every feature and option creates a vector for support.

[psychofaktory]

Let's imagine this is implemented. There will inevitably be "my client can't access the Internet" issues and then we are into supporting a general purpose Router.

Since all requests that are not directly addressed to Moode are directly forwarded, this case should never occur as long as Moode also has an Internet connection.

Conversely, however, (at the latest with my request) a support request has already appeared, which is why no Internet connection is possible via the Moode router mode by default.
From the perspective of an intuitive function, I would have expected that an Internet connection is possible. Especially since from my point of view, there is much more to be said for it than against it.

Your scenario involved Android and it's "active connection" test. What about IOS, Windows or other Linux clients? How do they behave?

For Android and Windows, I can safely say that certain "Connectivity Check URLs" are called to check connectivity. If these do not provide the desired answer, the behavior I described occurs.

For iOS and Linux it should be similar.

What I would suggest is looking at the nftables wiki and modifying/swapping in one of their "Home Router" rule sets into /var/www/inc/network.php. If that works then at least there would be a guide for users that want to implement this function.

Another option would be if there is significant demand for a feature like this. Then I'd be inclined to add it to the TODO list but no guarantee there would be enough project bandwidth to take on the additional support.

Remember that every feature and option creates a vector for support.

I would like to try a manual adjustment here to get the desired function.
In the past, however, such interventions have repeatedly shown that this can lead to conflicts with automatisms integrated in Moode.
In addition, it has already happened that manual adjustments were then rendered unusable by Moode updates or impaired the functionality of the entire system.

The request for a real hotspot solution has already been made several times in the forum.
Therefore, I would absolutely welcome it if the adjustments came from the official side.
That would already contribute to a lower support volume.