Clients cannot access internet once connected about iotwifi HOT 14 CLOSED

@cecchisandrone I'm going to be making some updates in a 2.0 version soon. I'm thinking about allowing the Dnsmasq conf to be entirely overwritten if desired. I think it will need a default state, but for those who need something specific, they could just pass a full config to it.

from iotwifi.

Yes, however, it's going to take a couple of weeks since I am behind on professional projects at the moment. I started an Enhancements project in this repository and added this issue.

from iotwifi.

@Nate0611 thanks for the report, however this is really a feature not a bug when it comes to this project. The main requirement for many IOT projects is to allow wifi configuration (think Nest or Amazon Echo) and not provide network access beyond the local device. This project attempts to help solve that issue for RPI developers. Forwarding network traffic is not too difficult, but it will never have great performance since using the single wifi interface on the Pi as AP and Station is already pushing its limits a bit.

However, I will add some instructions or maybe even an option to auto configure IPTables to allow this. In the meantime checkout [Using iptables and PHP to create a captive portal] (http://www.andybev.com/index.php/Using_iptables_and_PHP_to_create_a_captive_portal) section on Firewall rules required.

You will need to forward traffic from the interface uap0 to wlan0 after wlan0 is connected to a network.

I'll re-categorize this issue as a feature request. Thanks!

from iotwifi.

I was able to create the client + AP behaviour including ipforward for internet connection by following this very good tutorial:
https://github.com/peebles/rpi3-wifi-station-ap-stretch

it shows the iptables config and i think something similar should work here too.

from iotwifi.

I tried

sudo sysctl net.ipv4.ip_forward=1
sudo iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
sudo iptables -A FORWARD -i wlan0 -o uap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -A FORWARD -i uap0 -o wlan0 -j ACCEPT

ping to 8.8.8.8 works so it is probably a dnsmasq configuration issue. I think the command line should be modified to support upstream DNSs here

from iotwifi.

Are you also taking in consideration iptables changes needed for internet connection?

from iotwifi.

Anyone figure out the correct workaround steps to get client internet access?
I tried a few combinations of the recommended above but nothing did the trick.

from iotwifi.

Guys, it depends on how UAP interface is created. If it comes directly from wlan0 interface, ie.

iw dev wlan0 interface add uap0 type __ap

it should work out of the box, without iptables.

from iotwifi.

There's couple of problems with the current setup, if used as wifi gw (e.g. with eth0 )
Here's quick and dirty start cmd I use to get it running with my Pi3+

This needs to be run as root (iptables commands)

(
docker run -d --name wifi --rm --privileged --net host -v $(pwd)/wificfg.json:/cfg/wificfg.json  cjimti/iotwifi

iptables -I FORWARD -o uap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -I FORWARD -s 192.168.0.0/16 -j ACCEPT
iptables -t nat -I POSTROUTING -s 192.168.0.0/16 \! -d 192.168.0.0/16 -j MASQUERADE
sleep 10
docker exec  wifi /bin/sh -c 'pkill dnsmasq; dnsmasq --no-hosts --keep-in-foreground --log-queries --address=/wifi/192.168.27.1 --dhcp-range=192.168.27.100,192.168.27.150,1h --dhcp-vendorclass=set:device,IoT --dhcp-authoritative --log-facility=-'
docker stop wifi
iptables -D FORWARD -o uap0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -D FORWARD -s 192.168.0.0/16 -j ACCEPT
iptables -t nat -D POSTROUTING -s 192.168.0.0/16 \! -d 192.168.0.0/16 -j MASQUERADE
)

This will start iotwifi with "wifi" name (referenced later). Set iptables masquerading and allows packets to go through.
Waits for the dnsmasq to start. Then kills it inside the container and start dnsmasq with --no-resolve option.

After this if your pi can query dns entries so will you clients.

from iotwifi.

Same problem - here are some more observations.
1.) This is a GREAT thing that you have done here. Thanks!
2.) There are more recent changes to how supplicant and hostapd does their thing which is likely the pain you feel.
3.) Oh yea, I'm not not a networking or linux expert - so no advice from me - ha!
4.) Based on the items in the issues regarding the wpa...service, I added the following to my /etc/rc.local

sudo systemctl mask wpa_supplicant.service
sudo pkill wpa_supplicant
docker start uts_wifi
sudo systemctl mask wpa_supplicant.service
sudo pkill wpa_supplicant

5.) Just having it before or after alone did not seem to work.
6.) Once a connection has been made to a WiFi, it is REALLY difficult to change it.
a. Cannot just send a new connect msg (iphone hotspot)
b. disable home wifi, wait for it... until status stops returning the ip for home network, send connect msg, status shows new ip
c. sudo reboot, home info appears to be cached, when both are present it went to home network instead of last one - hotspot

Where is the connection info cached?
Where are the logs going?
Where is the code for /Connect and can it be stepped thru for debugging?
Is JSON the only way to pass config info? Can it be form properties?

Thanks! in advance.
RPi 3B
virgin raspbian 4.14.50-v7+ / 2018-04-18 Raspbian-stretch-lite
no raspi-config for network
ssh via ssh.txt in boot drive
Ethernet to run script

Sorry - looks like this is on the wrong thread - I meant to put it on the one about connecting the Pi as a Client to local wifi
#Cannot connect as client to wifi network of router #7

from iotwifi.

Oh, I'm shocked to read that the internet is not forwarded. What's the necessity of connecting the rpi to a network if it's not going to share that connection? I didn't realize this wasn't a part of this repo until I came looking for someone having a similar issue. Honestly your work is totally awesome here - but it seems a bit disingenuous to me. It'd be nice to have a note at the top clarifying that this doesn't forward the internet through to client devices.

from iotwifi.

"What's the necessity of connecting the rpi to a network if it's not going to share that connection? "

@Aaronik I am sorry to hear that you are shocked. I am sorry I did not make it more clear that the intention of this project is only to provide the ability to operate as a station and AP simultaneously for the purposes of configuration. Everyone has different networking needs and there are many ways to achieve what you want though IP tables, etc.

I feel it is beyond the scope of this project to provide this by default since the core design goal is to provide a configuration interface for IOT projects like Nest, or Amazon Echo. This is a very common use in IOT projects, hence iot -wifi.

Devices like Nest and Alexa use Wifi to allow you to connect and configure them, not as a means to provide network access. Most IOT devices are not intended to be repeaters or hotspot proxies. Having this ability by default may even post a security problem for some users.

However, I am open to adding the functionality if it is something that can be configured explicitly. I am very much open to including any productive pull requests.

If you want to forward communication between interfaces, check out https://serverfault.com/questions/431593/iptables-forwarding-between-two-interface

from iotwifi.

FWIW, I have never seen a true wireless AP/bridge/repeater/hotspot mode work on a Raspberry Pi, in a stable way. You would think it's a common application for the RPi (cheap router), but I think there must be some driver issues that prevents running this configuration over an extended period of time. I've tried dozens of times to set this up using various tutorials, without any success. Here are some tutorials that claim to work but I have been unable to reproduce on a RPi 3B+:

• Using your new Raspberry Pi 3 as a WiFi access point with hostapd
• Raspberry Pi Zero W as a WiFi repeater
• Pi 3 as a Wi-Fi Repeater
• Simple Raspberry Pi WiFi Extender

from iotwifi.

Ok - I've moved on, and just to follow up with your post @breandan, the next container I tried, https://github.com/sdelrio/rpi-hostap, is working flawlessly so far. I can't speak to long term reliability, but it is working for me in the beginning. I'm writing this post connected to my rpi which has an eth0 connection to my home router, and is broadcasting the wifi signal over wlan0 using hostap.

from iotwifi.