Bulle Wifi - site web local diffusé en wifi par un Raspberry PiFermé

Question

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 : 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.

mamiemando · Answer

Bonjour,

Pourquoi n'utilises-tu pas directement un portail captif ?

Bonne chance

Aklain52 · Answer

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.

mamiemando · Answer

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.

Aklain52 · Answer

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 : 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...

mamiemando · Answer

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...

Aklain52 · Answer

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.

mamiemando · Answer

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.

(mando@silk) (~) $ /sbin/route -nTable de routage IP du noyauDestination     Passerelle      Genmask         Indic Metric Ref    Use Iface0.0.0.0         192.168.0.254   0.0.0.0         UG    600    0        0 wlp2s0192.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

Bulle Wifi - site web local diffusé en wifi par un Raspberry Pi

7 réponses

Discussions similaires

Newsletters