Bulle Wifi - site web local diffusé en wifi par un Raspberry Pi
Bonjour à tous,
Afin d'améliorer la communication avec le public reçu dans mon entreprise, mes patrons m'ont chargé de mettre en place ce que j'appelle une "Bulle Wifi".
Il s'agit d'un raspberry pi installé à l'accueil du public qui héberge un site web et le partage en wifi.
J'y ai donc installé Apache, PHP et mySQL, ainsi que dnsmasq, udhcpd et hostapd.
J'ai configuré le serveur en IP fixe :
Puis le serveur DNS :
Enfin, j'ai paramétré le wifi ouvert :
J'indique le chemin de configuration au système :
J'ai également ajouté une règle de routing :
Pour conclure, j'ai injecté mon site dans /var/www
Cela fonctionne mais pas complètement.
Je souhaiterais que, si un smartphone se connecte à mon wifi, au lancement de son navigateur, ce soit mon site qui s'affiche.
Un peu à la façon des passerelles Wifi qui demandent une identification avant de laisser l'accès au net.
Pour l'instant, mon réseau n'ayant pas d'internet, sur Android, c'est la 4G de l'utilisateur qui reste prioritaire, même si je tape l'IP du raspberry pi, alors que sur iOs, mon site est bien accessible.
Afin d'améliorer la communication avec le public reçu dans mon entreprise, mes patrons m'ont chargé de mettre en place ce que j'appelle une "Bulle Wifi".
Il s'agit d'un raspberry pi installé à l'accueil du public qui héberge un site web et le partage en wifi.
J'y ai donc installé Apache, PHP et mySQL, ainsi que dnsmasq, udhcpd et hostapd.
J'ai configuré le serveur en IP fixe :
nano /etc/dhcpcd.conf
static ip_address=192.168.1.1/24
nohook wpa_supplicant
Puis le serveur DNS :
nano /etc/dnsmasq.conf
interface=wlan0 dhcp-range=192.168.1.2,192.168.1.20,255.255.255.0,24h address=/#/192.168.1.1
Enfin, j'ai paramétré le wifi ouvert :
nano /etc/hostapd/hostapd.conf
# interface wlan du Wi-Fi interface=wlan0 # nl80211 avec tous les drivers Linux mac80211 driver=nl80211 # Nom du spot Wi-Fi ssid=WIFI_PUBLIC # mode Wi-Fi (a = IEEE 802.11a, b = IEEE 802.11b, g = IEEE 802.11g) hw_mode=g country_code=FR wmm_enabled=0 macaddr_acl=0 ignore_broadcast_ssid=0 # canal de fréquence Wi-Fi (1-14) channel=5 # Wi-Fi ouvert, pas d'authentification ! auth_algs=1 # Beacon interval in kus (1.024 ms) beacon_int=100 # DTIM (delivery trafic information message) dtim_period=2 # Maximum number of stations allowed in station table max_num_sta=255 # RTS/CTS threshold; 2347 = disabled (default) rts_threshold=2347 # Fragmentation threshold; 2346 = disabled (default) fragm_threshold=2346
J'indique le chemin de configuration au système :
nano /etc/default/hostapd
DAEMON_CONF="/etc/hostapd/hostapd.conf"
J'ai également ajouté une règle de routing :
sudo iptables -t nat -A PREROUTING -d 0/0 -p tcp --dport 80 -j DNAT --to-destination 192.168.4.1:80
Pour conclure, j'ai injecté mon site dans /var/www
Cela fonctionne mais pas complètement.
Je souhaiterais que, si un smartphone se connecte à mon wifi, au lancement de son navigateur, ce soit mon site qui s'affiche.
Un peu à la façon des passerelles Wifi qui demandent une identification avant de laisser l'accès au net.
Pour l'instant, mon réseau n'ayant pas d'internet, sur Android, c'est la 4G de l'utilisateur qui reste prioritaire, même si je tape l'IP du raspberry pi, alors que sur iOs, mon site est bien accessible.
A voir également:
- Bulle Wifi - site web local diffusé en wifi par un Raspberry Pi
- Appdata local - Guide
- Changer wifi chromecast - Guide
- Voir mot de passe wifi android - Guide
- Création site web - Guide
- Adresse mac wifi - Guide
7 réponses
Parce que les portails captifs sont fait pour fonctionner avec Internet.
J'utilise un Raspberry Pi 3 A+ qui n'a pas de port RJ45.
Du coup, si j'utilise un portail Captif, il y a une erreur parce qu'il n'y a qu'une seule carte réseau.
Je me suis donc inspiré de tous les guides pour créer un portail captif pour faire mes paramétrages, mais il semble que le fait que mon Raspberry Pi ne soit pas connecté à internet, sur une seconde carte réseau, pose problème...
J'ai également fait quelques tests avec un Raspberry Pi 2 B+, mais dès que je déconnecte le câble du port RJ45, ça ne fonctionne plus non plus.
J'utilise un Raspberry Pi 3 A+ qui n'a pas de port RJ45.
Du coup, si j'utilise un portail Captif, il y a une erreur parce qu'il n'y a qu'une seule carte réseau.
Je me suis donc inspiré de tous les guides pour créer un portail captif pour faire mes paramétrages, mais il semble que le fait que mon Raspberry Pi ne soit pas connecté à internet, sur une seconde carte réseau, pose problème...
J'ai également fait quelques tests avec un Raspberry Pi 2 B+, mais dès que je déconnecte le câble du port RJ45, ça ne fonctionne plus non plus.
Re bonjour,
Parce que les portails captifs sont fait pour fonctionner avec Internet.
Je pose la question car peut être qu'en s'inspirant de la méthode de ces portails captifs, tu pourrais l'adapter à ta sauce.
Ensuite, ça ne me choque pas que la 4G reste prioritaire si elle est activée. Sur un smartphone tu n'as pas toujours envie d'allumer le wifi (bien plus énergivore), et le choix du réseau d'accès reste à la discrétion de l'utilisateur.
Parce que les portails captifs sont fait pour fonctionner avec Internet.
Je pose la question car peut être qu'en s'inspirant de la méthode de ces portails captifs, tu pourrais l'adapter à ta sauce.
Ensuite, ça ne me choque pas que la 4G reste prioritaire si elle est activée. Sur un smartphone tu n'as pas toujours envie d'allumer le wifi (bien plus énergivore), et le choix du réseau d'accès reste à la discrétion de l'utilisateur.
En fait, ma configuration actuelle est inspirée de ces portails captifs justement.
C'est juste que, plutôt que d'utiliser quelque chose de déjà paramétré, j'ai fait mon propre paramétrage.
Quand je dis que la 4G reste prioritaire, c'est que, une fois connecté au Wifi, si l'utilisateur lance son navigateur et tape l'adresse du site (son IP ou adresse), le smartphone cherche uniquement sur la 4G... lançant Google généralement.
IOs, quant à lui, pose moins de soucis, car il va uniquement sur le Wifi.
J'ai tenté ce genre de paramétrage :
Mais sans que celà change quoi que ce soit...
C'est juste que, plutôt que d'utiliser quelque chose de déjà paramétré, j'ai fait mon propre paramétrage.
Quand je dis que la 4G reste prioritaire, c'est que, une fois connecté au Wifi, si l'utilisateur lance son navigateur et tape l'adresse du site (son IP ou adresse), le smartphone cherche uniquement sur la 4G... lançant Google généralement.
IOs, quant à lui, pose moins de soucis, car il va uniquement sur le Wifi.
J'ai tenté ce genre de paramétrage :
nano /etc/apache2/sites-enabled/captive_portal.conf
# apple
RewriteEngine on
RewriteCond %{HTTP_USER_AGENT} ^CaptiveNetworkSupport(.*)$ [NC]
RewriteCond %{HTTP_HOST} !^192.168.1.1$
RewriteRule ^(.*)$ http://192.168.4.1/index.php [L,R=302]
# android
RedirectMatch 302 /generate_204 http://192.168.1.1/index.php
# windows
RedirectMatch 302 /ncsi.txt http://192.168.1.1/index.php
RewriteCond %{REQUEST_URI} !^/captive/ [NC]
RewriteRule ^(.*)$ http://192.168.1.1/index.php [L]
Mais sans que celà change quoi que ce soit...
Vous n’avez pas trouvé la réponse que vous recherchez ?
Posez votre question
Le truc que je ne comprends pas c'est pourquoi l'utilisateur aurait à la fois la 4G et le wifi allumé. Et dans ce cas, c'est son système qui va choisir d'utiliser l'un ou l'autre. Ce qui serait intéressant de voir, c'est si une connexion purement wifi lui permet d'avoir accès à Internet...
Pour que ce soit plus claire, je vais partir d'un cas pratique.
Une personne du publique se présente à l'accueil de mon entreprise et patiente en salle d'attente.
Un écran de télévision diffuse de l'information.
Ces infos sont un condensé et des messages proposent de se connecter à notre réseau wifi pour en savoir plus.
La personne prends donc son smartphone, se connecte à notre wifi et lance son navigateur pour accéder à un petit site web. (c'est le but à atteindre)
Ce réseau wifi est un réseau fermé, c'est une bulle, sans connexion à internet. Le site est hébergé par le Raspberry Pi qui émet et diffuse également le réseau wifi. (le raspberry pi n'est pas relié à internet)
Mon problème est que quand les utilisateurs se connectent à mon wifi, les smartphones sous Android, détectent que ce réseau n'a pas de connexion internet. Ils restent connectés au wifi mais ne semblent pas l'utiliser.
Si l'utilisateur ouvre son navigateur, la 4G prends le relais et il finit sur internet.... et non sur mon site.
Je voudrais,
- soit pouvoir "pousser" l'ouverture du navigateur et du site à la connexion du wifi, (je ne pense pas que ce soit possible)
- soit faire en sorte que l'ouverture d'un navigateur mène systématiquement à mon site. (peut-être en lui faisant croire qu'il y a bien internet)
Mais ça fait des semaines que je bosse là dessus et je bloque.
A noter que, si l'utilisateur désactive sa 4G/3G, cela fonctionne. Mais ça fait une manip de trop, il faut que ce soit le plus simple possible.
Une personne du publique se présente à l'accueil de mon entreprise et patiente en salle d'attente.
Un écran de télévision diffuse de l'information.
Ces infos sont un condensé et des messages proposent de se connecter à notre réseau wifi pour en savoir plus.
La personne prends donc son smartphone, se connecte à notre wifi et lance son navigateur pour accéder à un petit site web. (c'est le but à atteindre)
Ce réseau wifi est un réseau fermé, c'est une bulle, sans connexion à internet. Le site est hébergé par le Raspberry Pi qui émet et diffuse également le réseau wifi. (le raspberry pi n'est pas relié à internet)
Mon problème est que quand les utilisateurs se connectent à mon wifi, les smartphones sous Android, détectent que ce réseau n'a pas de connexion internet. Ils restent connectés au wifi mais ne semblent pas l'utiliser.
Si l'utilisateur ouvre son navigateur, la 4G prends le relais et il finit sur internet.... et non sur mon site.
Je voudrais,
- soit pouvoir "pousser" l'ouverture du navigateur et du site à la connexion du wifi, (je ne pense pas que ce soit possible)
- soit faire en sorte que l'ouverture d'un navigateur mène systématiquement à mon site. (peut-être en lui faisant croire qu'il y a bien internet)
Mais ça fait des semaines que je bosse là dessus et je bloque.
A noter que, si l'utilisateur désactive sa 4G/3G, cela fonctionne. Mais ça fait une manip de trop, il faut que ce soit le plus simple possible.
Bonjour
Réponse courte
À mon avis c'est un problème de routage (qui se règle au niveau de la configuration du serveur DHCP).
Réponse longue
Une fois la table de routage constituée, dès qu'un paquet doit être envoyé, le système décide de la route la plus appropriée. Cette route doit couvrir la destination du paquet. Il peut rester plusieurs routes candidates. Deux paramètres sont pris en compte : la spécificité de la route (i.e. la longueur du masque de la route) et la métrique de la route.
Exemple : Ici on a deux routes, qui correspondent aux destination *.*.*.* et 192.168.0.* (voir Destination + Genmask). Si je tente de joindre 192.168.1.1, alors les deux routes sont candidates, mais comme la seconde route est plus spécifique, c'est celle qui est utilisée.
Dans ton cas, le problème revient au même. Tu as deux interfaces (wifi et 4g, peu importe), mais en jouant sur la plage de destinations retournée par le serveur DHCP, tu dois être en mesure de redescendre uniquement le préfixe de ton réseau wifi (au lieu d'une route par défaut).
Pour le moment, je pense que ton wifi redescend une route par défaut. Donc l'OS hésite entre celle de la 4G et celle du wifi. Or, comme celle du wifi n'offre pas d'accès internet, il lui assigne probablement une métrique plus forte.
Si maintenant, tu redescends par DHCP uniquement le préfixe associé à ton réseau local (e.g. une route uniquement pour, disons, 192.168.1.*) alors tu retombes dans le cas de l'exemple ci-dessus. Si ensuite l'utilisateur accède à ton serveur web via son IP locale, alors il devrait utiliser le wifi pour la contacter. A contrario, s'il veut aller mettons sur CCM, comme l'adresse de CCM est résolue par le DNS en dehors de ce préfixe il utilisera la route par défaut.
Bonne chance
Réponse courte
À mon avis c'est un problème de routage (qui se règle au niveau de la configuration du serveur DHCP).
Réponse longue
Une fois la table de routage constituée, dès qu'un paquet doit être envoyé, le système décide de la route la plus appropriée. Cette route doit couvrir la destination du paquet. Il peut rester plusieurs routes candidates. Deux paramètres sont pris en compte : la spécificité de la route (i.e. la longueur du masque de la route) et la métrique de la route.
Exemple : Ici on a deux routes, qui correspondent aux destination *.*.*.* et 192.168.0.* (voir Destination + Genmask). Si je tente de joindre 192.168.1.1, alors les deux routes sont candidates, mais comme la seconde route est plus spécifique, c'est celle qui est utilisée.
(mando@silk) (~) $ /sbin/route -n
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
0.0.0.0 192.168.0.254 0.0.0.0 UG 600 0 0 wlp2s0
192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp2s0
Dans ton cas, le problème revient au même. Tu as deux interfaces (wifi et 4g, peu importe), mais en jouant sur la plage de destinations retournée par le serveur DHCP, tu dois être en mesure de redescendre uniquement le préfixe de ton réseau wifi (au lieu d'une route par défaut).
Pour le moment, je pense que ton wifi redescend une route par défaut. Donc l'OS hésite entre celle de la 4G et celle du wifi. Or, comme celle du wifi n'offre pas d'accès internet, il lui assigne probablement une métrique plus forte.
Si maintenant, tu redescends par DHCP uniquement le préfixe associé à ton réseau local (e.g. une route uniquement pour, disons, 192.168.1.*) alors tu retombes dans le cas de l'exemple ci-dessus. Si ensuite l'utilisateur accède à ton serveur web via son IP locale, alors il devrait utiliser le wifi pour la contacter. A contrario, s'il veut aller mettons sur CCM, comme l'adresse de CCM est résolue par le DNS en dehors de ce préfixe il utilisera la route par défaut.
Bonne chance