Client won't connect to internet

[ihavenoface]

Not quite sure what I'm doing wrong, so I would like to request some guidance.

Creating the hotspot seems to work fine. The device (Nexus 4) is able to connect to it but is unable to reach anything but the local network.

The command I'm using to run the hotspot is /usr/bin/create_ap wlp5s0 enp5s1 FreeInternet.

Some outputs as asked in other issues:

ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 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
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 90:2b:34:d0:2f:11 brd ff:ff:ff:ff:ff:ff
3: enp5s1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether a0:f3:c1:04:94:7e brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.100/24 brd 192.168.2.255 scope global enp5s1
       valid_lft forever preferred_lft forever
    inet6 2003:45:4779:4c00:a2f3:c1ff:fe04:947e/64 scope global mngtmpaddr dynamic 
       valid_lft 14388sec preferred_lft 1788sec
    inet6 fe80::a2f3:c1ff:fe04:947e/64 scope link 
       valid_lft forever preferred_lft forever
4: wlp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 00:0f:b5:88:49:bd brd ff:ff:ff:ff:ff:ff
5: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default 
    link/sit 0.0.0.0 brd 0.0.0.0
12: ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0f:b5:88:49:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.12.1/24 brd 192.168.12.255 scope global ap0
       valid_lft forever preferred_lft forever
    inet6 fe80::20f:b5ff:fe88:49be/64 scope link 
       valid_lft forever preferred_lft forever

ip route

default via 192.168.2.1 dev enp5s1  proto static 
192.168.2.0/24 dev enp5s1  proto kernel  scope link  src 192.168.2.100 
192.168.12.0/24 dev ap0  proto kernel  scope link  src 192.168.12.1 

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.12.0/24     
ACCEPT     all  --  192.168.12.0/24      anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  192.168.12.0/24      anywhere            

[oblique]

Give me the output of the following commands:

cat /proc/sys/net/ipv4/ip_forward
ping -c3 8.8.8.8

The ping also run it on the client.

[ihavenoface]

cat /proc/sys/net/ipv4/ip_forward

1

ping -c3 8.8.8.8 on host

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=58 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=58 time=18.7 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=58 time=18.7 ms

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 18.766/18.773/18.786/0.112 ms

ping -c3 8.8.8.8 on client

PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2004ms

[oblique]

The setup looks correct.
Do you have the same problem with other clients? What wifi adapter do you use?

[ihavenoface]

I'm getting the same issue on a laptop.
The wireless adapter is a Qualcomm Atheros AR5212/AR5213.

It might be worth noting that letting the client connect to a proxy like squid pretty much solves the issue, which makes it only half the dealbreaker.

[oblique]

Checkout 4d654b7 and try again. Does it work?
If not, checkout back to master and try again with --no-virt.
Try to use another channel, channels 1, 6 and 11 are the best choices because they don't overlap with each-other.

[ihavenoface]

4d654b7 does not seem to change anything (the module is loaded). Neither does --no-virt.

[oblique]

Can you use wireshark on the client and the server to confirm that the packets are sent from client to server and then routed to the ethernet? Also, check for the replies, if the IP is correct. If the TTL is not expired etc.
I can not think what probably is wrong. The only way to find out is by checking the packets.

[oblique]

Also, give me your dmesg and iw list

[ihavenoface]

I found a solution to this issue.
When using systemd 219 you will have to set IPForward=yes in the respective configuration for an interface you're planning to share the connection from.

See https://bugs.freedesktop.org/show_bug.cgi?id=89509 for details.

[oblique]

Cool thanks. It's strange that I didn't find this problem before. Anyway, I just checked the code of systemd that enables the forwarding and I found that it just enables 2 kernel flags through procfs (create_ap enables only one).
So, can you please remove IPForward=yes, run create_ap and make sure that it doesn't work and then run the following:

echo 1 > /proc/sys/net/ipv4/conf/enp5s1/forwarding

Please let me know if this makes it to work or not.

[ihavenoface]

Can confirm that echo 1 > /proc/sys/net/ipv4/conf/enp5s1/forwarding enabled the connection to work properly when IPForward is disabled.

[oblique]

Thanks! I will add this in create_ap tomorrow, I'm a bit busy now.

[oblique]

Fixed. Try it and let me know if you have any problems.

Thanks!