HybridWulp geen internet

[pdrukker]

Zojuist melding gekregen dat node de Wulp geen Internet-faciliteiten heeft c.q. kan aanbieden. Is het zinvolle om een harde reset uit te laten voeren of zijn de aanvoerproblemen van een andere orde. Binnen dit medium -nog- niets vernomen dat de aanvoer van het Internetsignaal problematisch is.

Altijd bereid om op locatie even een 'noodzakelijke' handeling uit te voeren.

vg,

Peter

[huub]

Volgens Nagios werkt internet, zowel bij TulpenZee als Wulp. Er is vorige week even een probleem geweest met de internetverbinding bij het Bestuurscentrum, maar dat is vrijdag verholpen. Internet loopt voor deze locaties nu via de gateway bij StVictor.
Let wel dat de ssid's bij de Wulp veranderd zijn, zoals eerder gemaild. Bijv. WiFi-DeWulp-west en -oost. Er zijn ook door de camping De Wulp extra repeaters geplaatst, maar die hebben een 'eigen' password. Daar kunnen wij dus niets mee.
HybridWulp# fetch -o /dev/null ​http://www.nu.nl
/dev/null 100% of 4128 B 5196 kBps
dus ruim 40 Mbps
HybridTulpEnZee# fetch -o /dev/null ​http://www.nu.nl
fetch: ​http://www.nu.nl: size of remote file is not known
/dev/null 4212 B 6592 kBps
dus iets van 52 Mbps

[huub]

Peter laat weten:
Wel is geconstateerd dat de toegang tot het Internet wordt belemmerd door de captive portal (CP). Na de akkoord-knop op de CP te hebben geklikt werd er niet door gelinked naar de sponsor-pagina c.q. iedere willekeurige web-pagina.
Gebruik van de proxy-optie (proxy.wleiden.net) gaf wel het gewenste resultaat om naar het Internet te gaan. Om deze reden ben ik in de veronderstelling dat het probleem moet worden gezocht in de afwikkeling van de CP.

Tenslotte ook de node Tulp & Zee geprobeerd. Deze node loopt volgens dezelfde lijn als die van de Wulp. Deze node gaf via de CP direct toegang tot het Internet. Hier dus geen probleem geconstateerd.

Al met al ga ik ervan uit dat de lokale CP van de Wulp de oorzaak is van de huidige onbereikbaarheid van het Internet.

Peter Drukker

[huub]

Ik zie nu al een tijdje actief internetverkeer over de interfaces gaan en inmiddels 42 'authenticated users'. Dus er lijkt op dit moment geen probleem. Wat ik wel veranderd heb: in /usr/local/www/wlportal stond een index.html file van 4 augustus 2014 die ik niet kan thuisbrengen. Hoort alleen een index.cgi te staan. Die heb ik omgedoopt in index.html.watdoetdiehier, zodat i.i.g. de cgi-file gebruikt wordt.
Het zou fijn zijn als iemand kan vertellen wat de bedoeling was.

[rvanswol]

Vanochtend op bezoek geweest bij Tulp en Zee en bij de Wulp.
Die situatie is op beide plaatsen het zelfde.
Internet alleen te gebruiken via proxy. Dit is ook wat een aantal gebruikers bij de wulp doen.
De captive portal linkt niet door naar sponsor, maar bij het opvragen van een internet pagina verschijnt weer de captive portal. Bij het weer akkoord geven verschijnt de error dat er al is ingelogd.

[walter]

Heb helaas geen exacte data (vrijdag 13e en ergens midden vorige week maart) maar heb afgelopen maand een storing ondervonden die de mogelijke oorzaak/verklaring kan geven voor de onverzadigbare captive portal accept button! Er is waarschijnlijk niets mis met "de captiveportal van" beide nodes zowel tulp en zee als de wulp.

Daarentegen, het subnet 172.16.7.49/29 op vr2 van leeuwenhorst2 serveerd namelijk zelf een onverzadigbare captive portal pagina (waargenomen op interlink duinweg .53). Waarschijnlijk (aanname) doet het subnet 172.16.7.33/29 op alias vr2 waar de wulp opzit hetzelfde. Al deze interlinks zitten op deze node.

Interlinks waren toch vrij van captive portals? Een proxy gebruiken kan je wel doorverbinden, maar zonder proxy blijft de CP zichzelf opnieuw aanbieden?

Zou het kunnen dat na de (succesvolle) acceptatie van de captiveportal gebruikers op locale nodes van tulp en zee en de wulp daarna de onverzadigbare captiveportal op de interlink naar het leeuwenhorst2 krijgen?

[huub]

Aha, an astute observation! Er draait een captive portal op de wlan0 interface van leeuwenhorst1 (die in feite gebruikt wordt voor de interlink naar leeuwenhorst2. Dit komt automagiach uit wleiden.yaml rollen omdat wlan0 altijd een gebruikersinterface is (dus niet).
Ik heb het nu uitgezet, zou dus moeten helpen. Ticket aanmaken voor gformat.py aanpassing.

[huub]

Aanpassen van rc.conf.local is niet voldoende (captive_portal="none"). In pf.hybrid.conf staat toch wlan0 als captive portal.

[huub]

Ik heb de configuratie bij Leeuwenhorst nu meer in-lijn gebracht met de standaard WL-setup. De link tussen LH1 en LH2 loopt nu via ethernetpoorten en de switch. Daarvoor zijn aliassen geconfigureerd op de interlink-interfaces LH1-vr0 en LH2-vr1; niet ideaal al dat verkeer via de switch, misschien een VLAN van maken, maar dat is dan weer niet standaard.
De wlan0-en zijn nu lokale ap's handig voor beheer ter plekke. Eentje op 5 GHz en eentje op 2.4 GHz. Ben benieuwd of de Wulp en Tulpenzee-perikelen nu over zijn.

[huub]

Ik moest hier ook nog de firewall config (pf.hybrid.conf) bijwerken omdat er ook hier twee ip's op de internet-ethernetpoort staan (publiek ip en wl-ip). Maar nu lijkt het danook aardig te werken, ook speedtest-cli die voorheen niet echt wilde:
HybridWulp# /tools/speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Ziggo (82.217.240.63)...
Selecting best server based on ping...
Hosted by ColoCenter bv (Zoetermeer) [17.87 km]: 350.714 ms
Testing download speed........................................
Download: 51.27 Mbit/s
Testing upload speed..................................................
Upload: 9.27 Mbit/s

en bij Tulpenzee:
HybridTulpEnZee# /tools/speedtest-cli
Retrieving speedtest.net configuration...
Retrieving speedtest.net server list...
Testing from Ziggo (82.217.240.63)...
Selecting best server based on ping...
Hosted by ColoCenter bv (Zoetermeer) [17.87 km]: 362.635 ms
Testing download speed........................................
Download: 29.43 Mbit/s
Testing upload speed..................................................
Upload: 7.26 Mbit/s

Nu nog de ultieme gebruikerstest....

[huub]

Gebruikerstest geslaagd :-)