snappy-hwe-snaps

[wifi-ap] Connected client can't access the network via shared interface

Bug #1707016 reported by Tony Espy on 2017-07-27

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	snappy-hwe-snaps	Confirmed	Undecided	Unassigned

Bug Description

Hardware: Dell Edge Gateway 3100 (DVT1)

A client connected to an access point provided by the wifi-ap snap cannot access the network via the shared Ethernet interface.

Snaps:
bluez 5.44-2 84 canonical -
caracalla 16.04-1.29 39 canonical -
caracalla-kernel 4.4.0-2002.2 40 canonical -
core 16-2.26.9 2381 canonical -
docker 17.03.2-ce-1 159 docker-inc -
locationd 4.0.0 71 canonical -
modem-manager 1.6.2-5 82 canonical -
network-manager 1.2.2-10.2 166 canonical -
snapweb 0.26-10 300 canonical -
tpm2 1.0-5 42 canonical -
uefi-fw-tools 1.4.1-0.7.2+git 7 canonical -
wifi-ap 15 146 canonical -

The BT/WiFi driver is confirmed to be AP mode (Bluetooth legacy & low energy):

root@caracalla:~# cat /sys/module/ven_rsi_sdio/parameters/dev_oper_mode
14

The wifi-ap configuration appears to be correct:
root@caracalla:~# wifi-ap.config get
debug: false
dhcp.lease-time: 12h
dhcp.range-start: 10.0.60.2
dhcp.range-stop: 10.0.60.199
disabled: false
share.disabled: false
share.network-interface: eth0
wifi.address: 10.0.60.1
wifi.channel: 6
wifi.hostapd-driver: nl80211
wifi.interface: wlan0
wifi.interface-mode: direct
wifi.netmask: 255.255.255.0
wifi.operation-mode: g
wifi.security: open
wifi.security-passphrase:
wifi.ssid: Ubuntu

The shared interface also appears to be active:

root@caracalla:~# nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 1158e56d-436e-376b-8eec-0ac56418cd3b 802-3-ethernet eth0
docker0 99a4aae0-7944-40a3-91e0-12a21597a1bb bridge docker0
veth540af6f 9c2f5bb5-03de-4a55-be22-a8ab356c5cbd 802-3-ethernet veth540af6f
Wired connection 3 46cbf376-a5a9-36be-a29f-29a55494f63a 802-3-ethernet --

The gateway's Ethernet connection was validated by logging into the gateway and confirming that the Internet was reachable, and that DNS functions properly.

The client connected to the AP is able to ping the gateway, however the Internet isn't reachable via the NAT configured between WiFi and Ethernet by the wifi-ap snap.

IP forwarding is enabled:

root@caracalla:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

And the iptables (default & nat) are as follows:

root@caracalla:~# iptables -t filter -L -v
Chain INPUT (policy ACCEPT 37491 packets, 7193K bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 368 packets, 22056 bytes)
pkts bytes target prot opt in out source destination
36204 69M DOCKER-ISOLATION all -- any any anywhere anywhere
19621 1564K DOCKER all -- any docker0 anywhere anywhere
72 10008 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
13459 68M ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
1035 63405 ACCEPT all -- wlan0 any anywhere anywhere

Chain OUTPUT (policy ACCEPT 4188 packets, 410K bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
    0 0 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:60002
    0 0 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:6474
  154 21659 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:6443
    0 0 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:3000
    0 0 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:1884
  991 70154 ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:1883
18404 1462K ACCEPT tcp -- !docker0 docker0 anywhere 172.17.0.2 tcp dpt:https

Chain DOCKER-ISOLATION (1 references)
pkts bytes target prot opt in out source destination
36204 69M RETURN all -- any any anywhere anywhere
root@caracalla:~# iptables -t nat -L -v
Chain PREROUTING (policy ACCEPT 1089 packets, 238K bytes)
pkts bytes target prot opt in out source destination
494 31612 DOCKER all -- any any anywhere anywhere ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 999 packets, 233K bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 3289 packets, 241K bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER all -- any any anywhere !127.0.0.0/8 ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 3435 packets, 242K bytes)
pkts bytes target prot opt in out source destination
   36 2304 MASQUERADE all -- any !docker0 172.17.0.0/16 anywhere
  503 47168 MASQUERADE all -- any eth0 anywhere anywhere
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:60002
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:6474
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:6443
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:3000
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:1884
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:1883
    0 0 MASQUERADE tcp -- any any 172.17.0.2 172.17.0.2 tcp dpt:https

Chain DOCKER (2 references)
pkts bytes target prot opt in out source destination
    0 0 RETURN all -- docker0 any anywhere anywhere
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:60002 to:172.17.0.2:60002
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:6474 to:172.17.0.2:6474
    6 384 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:6443 to:172.17.0.2:6443
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:3000 to:172.17.0.2:3000
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:1884 to:172.17.0.2:1884
   86 5504 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:1883 to:172.17.0.2:1883
  194 12416 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443

See original description

Tony Espy (awe) on 2017-07-27

Changed in snappy-hwe-snaps:
status:	New → Confirmed

Revision history for this message

Butch Anton (butchanton) wrote on 2017-07-27:

3100_syslog Edit (14.3 KiB, text/plain)

Syslog from the system

Tony Espy (awe) on 2017-07-27

description:

updated

Revision history for this message

Tony Espy (awe) wrote on 2017-07-27:

Another bit from Butch:

I rebooted the gateway, which reset all the iptable rules. Before starting docker, I was able to connect via Wi-Fi from another machine and then ping the outside world. After starting docker, this connectivity went away.

It appears, as you suggested, to be an issue with conflicting iptable rules between Snappy and docker.

But then:

I just repeated the exercise (reboot, test, run docker, test) and everything worked.

Revision history for this message

Tony Espy (awe) wrote on 2017-07-27:

@Butch

Did you compare your iptables after you ran the exercise the second time? I'm not expert on iptables, however I do note that on my Caracalla, the wifi-ap is currently working, and the POSTROUTING chain in the nat table looks like this:

Chain POSTROUTING (policy ACCEPT 15 packets, 1254 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any !docker0 172.17.0.0/16 anywhere
273 18481 MASQUERADE all -- any eth1 anywhere anywhere

Whereas the same chain that you originally shared with me, looks like:

So this could be a docker bug. If you get the system into the same state again, you could try to delete rules from the NAT table one by one and see if doing so causes the network to resume.

My other suggestion would be to run a tail on syslog the next time the problem happens and see if there any log messages indicating packets are being dropped. That said, this may not be default behavior...

Revision history for this message

Alfonso Sanchez-Beato (alfonsosanchezbeato) wrote on 2017-08-02:

Hi @Butch,

I have tried to reproduce this error, but have not been successful. However, I have the feeling that these entries in the routing table might be provoking the issue:

It looks like the configuration for container at 172.17.0.2 is doing some port redirections that might be affecting the device connected to the AP in caracalla. The one for https might be the one causing the issue. But it is a bit strange as we should not enter the DOCKER chain unless destination is a local address. So a couple of questions here:

1. When you try to access internet from the connected device does it make any difference accessing http or https?

2. Can you ping, say, 8.8.8.8, from the connected device?

3. Which image is the base for the container at 172.17.0.2? Is this container doing some port redirections using iptables?

4. Could you try with a different docker image, start a container created from that image (as unique running container), and check if you still see the issue? Which is the iptables configuration in that case? Try something like "sudo docker run -it ubuntu bash".

5. Finally, please include the output of these commands if you reproduce the issue again:
ip rule
ip route show table local
ip route show table main
ip route show table default

Hi @Butch,

I have tried to reproduce this error, but have not been successful. However, I have the feeling that these entries in the routing table might be provoking the issue:

Chain DOCKER (2 references)
 pkts bytes target prot opt in out source destination
    0 0 RETURN all -- docker0 any anywhere anywhere
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:60002 to:172.17.0.2:60002
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:6474 to:172.17.0.2:6474
    6 384 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:6443 to:172.17.0.2:6443
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:3000 to:172.17.0.2:3000
    0 0 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:1884 to:172.17.0.2:1884
   86 5504 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:1883 to:172.17.0.2:1883
  194 12416 DNAT tcp -- !docker0 any anywhere anywhere tcp dpt:https to:172.17.0.2:443

1. When you try to access internet from the connected device does it make any difference accessing http or https?

2. Can you ping, say, 8.8.8.8, from the connected device?

3. Which image is the base for the container at 172.17.0.2? Is this container doing some port redirections using iptables?

5. Finally, please include the output of these commands if you reproduce the issue again:
ip rule
ip route show table local
ip route show table main
ip route show table default

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Bug attachments

3100_syslog Edit

Add attachment

Remote bug watches

Bug watches keep track of this bug in other bug trackers.