Internet sharing works only when using bridge mode

[marmistrz]

I created a new access point in the following way sudo create_ap wlp3s0 enp2s0 Archnet passwd The log

$ sudo create_ap wlp3s0 enp2s0 Archnet passwd
Config dir: /tmp/create_ap.wlp3s0.conf.GkWsk3N6
PID: 30458
Network Manager found, set ap0 as unmanaged device... DONE
Creating a virtual WiFi interface... ap0 created.
Sharing Internet using method: nat
hostapd command-line interface: hostapd_cli -p /tmp/create_ap.wlp3s0.conf.GkWsk3N6/hostapd_ctrl
Configuration file: /tmp/create_ap.wlp3s0.conf.GkWsk3N6/hostapd.conf
Using interface ap0 with hwaddr 40:e2:30:f1:3d:74 and ssid "Archnet"
ap0: interface state UNINITIALIZED->ENABLED
ap0: AP-ENABLED 
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: authenticated
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: associated (aid 1)
ap0: AP-STA-CONNECTED ec:9b:5b:fd:6d:c0
ap0: STA ec:9b:5b:fd:6d:c0 RADIUS: starting accounting session 33935DD9-00000000
ap0: STA ec:9b:5b:fd:6d:c0 WPA: pairwise key handshake completed (RSN)
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: authenticated
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: associated (aid 1)
ap0: AP-STA-DISCONNECTED ec:9b:5b:fd:6d:c0
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: authenticated
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: authenticated
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: associated (aid 1)
ap0: AP-STA-CONNECTED ec:9b:5b:fd:6d:c0
ap0: STA ec:9b:5b:fd:6d:c0 RADIUS: starting accounting session 33935DD9-00000000
ap0: STA ec:9b:5b:fd:6d:c0 WPA: pairwise key handshake completed (RSN)
ap0: AP-STA-DISCONNECTED ec:9b:5b:fd:6d:c0
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: authenticated
ap0: STA ec:9b:5b:fd:6d:c0 IEEE 802.11: associated (aid 1)
ap0: AP-STA-CONNECTED ec:9b:5b:fd:6d:c0
ap0: STA ec:9b:5b:fd:6d:c0 RADIUS: starting accounting session 33935DD9-00000001
ap0: STA ec:9b:5b:fd:6d:c0 WPA: pairwise key handshake completed (RSN)

Then I connected my phone (Nokia N900). There is no Internet connection. I can ping the AP (by local IP) but no other external IP (such as 208.67.222.222)

[marmistrz]

Just a note: creating a Wireless Hotspot via the Cinnamon GUI doesn't work either. Using Arch Linux.

[marmistrz]

This isn't specific to Nokia N900. I tried connecting another computer to my AP, yields the same result.

Besides, disabling NetworkManager doesn't help - on dhcpcd the result is the same.

[oblique]

Run the following in the client:

nslookup google.com 192.168.12.1

Does it resolve the ip? Also again on the client, try to ping 8.8.8.8, does it reply?

[marmistrz]

Output from nslookup resolves the IP. ping 8.8.8.8 gives a 100% packet loss

[oblique]

Run the following commands on the machine that has creates the AP while create_ap is running and give me the output.

iptables -S
iptables -S -t nat
cat /proc/sys/net/ipv4/conf/all/forwarding
cat /proc/sys/net/ipv4/conf/enp2s0/forwarding
cat /proc/sys/net/ipv4/ip_forward

[marmistrz]

[root@arch marcin]# iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -p udp -m udp --dport 5353 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 5353 -j ACCEPT
-A FORWARD -d 192.168.12.0/24 -i enp2s0 -j ACCEPT
-A FORWARD -s 192.168.12.0/24 -i ap0 -j ACCEPT
[root@arch marcin]# iptables -S -t nat
-P PREROUTING ACCEPT
-P INPUT ACCEPT
-P OUTPUT ACCEPT
-P POSTROUTING ACCEPT
-A PREROUTING -s 192.168.12.0/24 -d 192.168.12.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353
-A PREROUTING -s 192.168.12.0/24 -d 192.168.12.1/32 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 5353
-A POSTROUTING -s 192.168.12.0/24 -o enp2s0 -j MASQUERADE
[root@arch marcin]# cat /proc/sys/net/ipv4/conf/all/forwarding
1
[root@arch marcin]# cat /proc/sys/net/ipv4/conf/enp2s0/forwarding
1
[root@arch marcin]# cat /proc/sys/net/ipv4/ip_forward
1

[marmistrz]

So, do you have any idea why this happens?

[oblique]

I really don't. Packet forwarding looks fine. Try to ping 8.8.8.8 on the computer that creates the AP while you are running create_ap. Another think that maybe will help is to give me a pcap file of the client and the AP (of-course filter out any sensitive information).

[marmistrz]

ping on the computer works perfectly fine. How do I get this pcap? I have two thoughts:

1. May it be that it's the ISP that does something nasty? We have to login via ssh to get access to the Internet, maybe they're doing something else.
2. Maybe something is not configured on my computer. I'm using Arch so it happens sometimes that things that are usually enabled on normal desktops are not in Arch
3. Is there any way to know whether the packets reach the host computer at all?

[oblique]

I also use Arch and I don't have this problem. Probably your ISP allows only a specific TTL on the packets. If they do, then you will have the same problem if you put a router behind ISP's modem.

If this is the restriction then you can bypass it with (run them in the computer that has create_ap):

iptables -t mangle -I PREROUTING -i ap0 -j TTL --ttl-inc 1
iptables -t mangle -I PREROUTING -i enp2s0 -j TTL --ttl-inc 1

The first rule increase by 1 the TTL of the outgoing packets, so the ISP will think that you are attached to their modem. The second rule it increase by 1 the TTL of the incoming packets, so if the ISP sets the TTL to a specific number of nodes, they will not be dropped from the computer that has the AP.

Let me know if it works or not.

[marmistrz]

Yes, this works. Thanks!

[oblique]

Cool. On the weekend I will add a parameter to the script to workaround this problem.

[marmistrz]

And is there any way for the script to detect itself this workaround is needed?

[oblique]

If create_ap was written in some system programming language then it could detect it by sending some raw packets. But in bash, I don't know.. Maybe there is a way via traceroute or ping.

Can give me the output of your ping and traceroute? (without using the iptables from above)

[macmpi]

On the weekend I will add a parameter to the script to workaround this problem.

For records, which parameter allows for this special mode? Thanks.

[oblique]

I didn't implement it, you need to run the commands manually.

[marmistrz]

Ok, but I think that detection would be handy (if possible). Something like: Your ISP blocks routed packages. See <url> for more details

[cassioalmeidas]

I have the same problem.

Already tested with itself wireless card of my laptop (Intel Wireless 7265) and with usb wireless adapter (D-Link System AirPlus G DWL-G122 Wireless Adapter (rev.C1) [Ralink RT2571W]) and the problem persists. I have already tested the solutions suggested above. Already tested on different ISPs.

` [root@acernitro cassio]# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -p udp -m udp --dport 67 -j ACCEPT -A INPUT -p udp -m udp --dport 5353 -j ACCEPT -A INPUT -p tcp -m tcp --dport 5353 -j ACCEPT -A FORWARD -d 192.168.12.0/24 -i enp3s0f1 -j ACCEPT -A FORWARD -s 192.168.12.0/24 -i ap2 -j ACCEPT [root@acernitro cassio]# iptables -S -t nat -P PREROUTING ACCEPT -P INPUT ACCEPT -P OUTPUT ACCEPT -P POSTROUTING ACCEPT -A PREROUTING -s 192.168.12.0/24 -d 192.168.12.1/32 -p udp -m udp --dport 53 -j REDIRECT --to-ports 5353 -A PREROUTING -s 192.168.12.0/24 -d 192.168.12.1/32 -p tcp -m tcp --dport 53 -j REDIRECT --to-ports 5353 -A POSTROUTING -s 192.168.12.0/24 ! -o ap2 -j MASQUERADE [root@acernitro cassio]# cat /proc/sys/net/ipv4/conf/all/forwarding 1 [root@acernitro cassio]# cat /proc/sys/net/ipv4/conf/enp3s0f1/forwarding 1 [root@acernitro cassio]# cat /proc/sys/net/ipv4/ip_forward 1

`

[cassioalmeidas]

I solved the problem, firewalld was running on my ArchLinux. :confused: