Neues Public-Access-Gateway Captive::Portal in Betrieb
Karl Gaissmaier
den Weihnachtstagen 2010 eine neue Captive::Portal Software in Betrieb.
Leider kam es heute Morgen zu einem Missgeschick: Wir haben wegen eines
Hardwaredefekts dieses Gateway fï¿œlschlicherweise 2x rebooted, obwohl ein
anderer Server defekt war! Das wï¿œre eigentlich wiederum nicht so schlimm,
da wir die neue Software so ausgelegt haben, dass auch ein Reboot die
bestehenden Sitzungen nicht lï¿œscht sondern nach Wiederanlauf des Gateways
aus dem Cache ï¿œbernommen werden, die Nutzer nur ein kurzes Ruckeln
merken, sich aber nicht nochmals neu anmelden mï¿œssen.
Ja, auï¿œer man legt den Session-Cache in ein Directory, welches bei einem Reboot
neu angelegt wird (/var/run/capo/...).
Shit happens und man lernt jeden Tag etwas dazu, wenn man nur will..
Sorry, wir versprechen, dass wir es nï¿œchstes mal besser machen.
Charly und Bing
P.S. Fï¿œr Interessierte: Es gibt dazu auch eine neue ï¿œberwachungsseite
um aus einem Topview den Zustand dieses Dienstes schnell beurteilen
zu kï¿œnnen:
http://noc.rz.uni-ulm.de/cgi-bin/tgweb.pl?p=welcome
Grmml, man sieht die 2 unnï¿œtigen reboots sehr schï¿œn auf der Seite!
Karl Gaissmaier
> Wie sicherlich die meisten WLAN Nutzer schon bemerkt haben, ist seit
> den Weihnachtstagen 2010 eine neue Captive::Portal Software in Betrieb.
Ich brauche Erfahrungsberichte von Windows-7 Nutzern die den IE als
Browser verwende, ob dabei das Captive Portal sauber funktioniert.
Neben Apple iOS hat leider auch inzwischen Windows-7 eine starke
Tendenz nach Hause zu telefonieren. Wenn dies wegen dem Captive Portal
initial nicht geht. könnte es sein, dass der IE auf Offline geht.
Kann das bitte jemand mit der config verifizieren?
Danke
Charly
Harald Losert
Hallo,
zur Problematik mit Windows 7 und dem Internetexplodierer (benutzt den
überhaupt noch jemand?) kann ich leider nichts beitragen, aber ich kann
berichten, dass sich auch der integrierte Browser eines webOS Smartphones
(Palm Pre) beharrlich weigert die Seite aufzurufen und stattdessen nur
eine Fehlermeldung wirft (wie übrigens auch schon beim alten Portal).
In diesem Zusammenhang kann man auch das alte Ärgernis des VPN Zugangs
nochmal erwähnen, da es z.B. auch fürs Palm Pre keine VPN-Unterstützung
seitens Palm/HP gibt und mit Ausnahme von OpenVPN nichts wirklich
vernünftig zu benutzen ist ohne das Pre routen zu müssen. Was es natürlich
ungemein erschwert mit einem webOS-Phone überhaupt ins Uninetz zu kommen
seit der OpenVPN-Server abgeschaltet wurde...
Bezüglich der VPN-Problematik gilt ähnliches für Android- und
Symbian/Nokia-Nutzer, die ebenfalls keine Möglichkeit per VPN haben. Nur
für das ach so tolle Eierphone gibt's die passende VPN-Unterstützung, aber
das muss wohl in Zeiten von "Apple on Campus" und ähnlichen Aktionen hier
an der Uni wohl so sein. In diesem Zusammenhang zitier' ich gern mal einen
Eintrag bezüglich der OpenVPN Abschaltung:
> Am 11.10.2010 10:35 schrieb Karl Gaissmaier:
> ...
> Mit AnyConnect SSL, IPSec, WebVPN und ssh socks können wir
> alles abdecken, warum sollten wir dann zusätzlich etwas
> anbieten was Aufwand beim Betrieb und Hotline macht?
> ...
Ohne das Thema nochmal ausweiten zu wollen. Beim OpenVPN Server wurde ja
kritisiert, dass er zu wenig frequentiert sei. Ist das denn nicht logisch
wenn (zumindest Anfang Dezember) nichts dazu auf der VPN-Info-Seite der
Uni davon zu lesen war? Kein Wunder dass das nur eingeweihte benutzt haben.
Gruß,
Harald
Karl Gaissmaier
On 28.01.2011 18:33, Harald Losert wrote:
>
> Hallo,
>
> zur Problematik mit Windows 7 und dem Internetexplodierer (benutzt den
> ï¿œberhaupt noch jemand?) kann ich leider nichts beitragen, aber ich kann
> berichten, dass sich auch der integrierte Browser eines webOS Smartphones
> (Palm Pre) beharrlich weigert die Seite aufzurufen und stattdessen nur eine
> Fehlermeldung wirft (wie ï¿œbrigens auch schon beim alten Portal).
Hellsehen kann ich leider immer noch nicht, meine Kristallkugel ist schon
wieder so trￜbe. Wenn ich von dem Problem nichts weiￜ, kann ich Dir auch nicht
helfen. Hast du denn dem Helpdesk schon mal von dem Problem berichtet?
Also mit mir eine debug-session ausmachen und wir bekommen das gebacken, wenn
nur dein Browser anstï¿œndiges HTTP und SSL kann. Kann er das?
Dazu musst Du nicht mal unbedingt bei mir vorbeikommen, eine
Telefonsitzung geht auch.
Ein Vorort-Termin bei mir in O26/5202 wï¿œre natï¿œrlich einfacher fï¿œr mich
und auch erfolgversprechender.
>
> In diesem Zusammenhang kann man auch das alte ï¿œrgernis des VPN Zugangs nochmal
> erwï¿œhnen, da es z.B. auch fï¿œrs Palm Pre keine VPN-Unterstï¿œtzung seitens
> Palm/HP gibt und mit Ausnahme von OpenVPN nichts wirklich vernï¿œnftig zu
> benutzen ist ohne das Pre routen zu mï¿œssen. Was es natï¿œrlich ungemein
> erschwert mit einem webOS-Phone ï¿œberhaupt ins Uninetz zu kommen seit der
> OpenVPN-Server abgeschaltet wurde...
s.o. bitte melden und nicht vor sich hin bruddeln.
Hoffe, dass wir in 2-3 Monaten eduroam fï¿œhig sind, dann kann ev. auch dein
Gadget sich mit 802.1X-Enterprise verbinden und du brauchst keine weitere
Tunnellï¿œsung.
>
> Bezï¿œglich der VPN-Problematik gilt ï¿œhnliches fï¿œr Android- und
> Symbian/Nokia-Nutzer, die ebenfalls keine Mï¿œglichkeit per VPN haben. Nur fï¿œr
s.o. die kï¿œnnen aber Captive::Portal, oder?
> das ach so tolle Eierphone gibt's die passende VPN-Unterstï¿œtzung, aber das
> muss wohl in Zeiten von "Apple on Campus" und ï¿œhnlichen Aktionen hier an der
Nicht ich habe die Eierunterstï¿œtzung programmiert sondern Cisco fï¿œr Apple oder
Apple fï¿œr Cisco oder wer auch immer. Und wenn das Land einen Mobilfunkvertrag
fï¿œr alle Einrichtungen abschlieï¿œt, der auch angebissene ï¿œpfel-Handys
beinhaltet, braucht man sich nicht wundern, wenn man darum goldene Brï¿œcken
bauen muss. AnyConnect Client gibt es dafï¿œr aber auch erst in der aktuellsten
Release und der IPSec Client wurde auch von einem Release zum nï¿œchsten
geschrottet. Also da ist auch nicht alles Gold was glï¿œnzt- inzwischen sogar in
weis.
> Uni wohl so sein. In diesem Zusammenhang zitier' ich gern mal einen Eintrag
> bezï¿œglich der OpenVPN Abschaltung:
>
>> Am 11.10.2010 10:35 schrieb Karl Gaissmaier:
>> ...
>> Mit AnyConnect SSL, IPSec, WebVPN und ssh socks kï¿œnnen wir
>> alles abdecken, warum sollten wir dann zusï¿œtzlich etwas
>> anbieten was Aufwand beim Betrieb und Hotline macht?
>> ...
Dazu stehe ich auch, und solange du mit deinem Problem noch nicht bei mir
warst, gehe ich davon aus, dass wir sogar fï¿œr deinen Exoten eine Lï¿œsung finden.
>
> Ohne das Thema nochmal ausweiten zu wollen. Beim OpenVPN Server wurde ja
> kritisiert, dass er zu wenig frequentiert sei. Ist das denn nicht logisch wenn
nope, zu wenig fï¿œr die Endnutzer mit 2 linken Daumen verwendbar! Das war das
was mich von einem Mass-Rollout abhielt.
> (zumindest Anfang Dezember) nichts dazu auf der VPN-Info-Seite der Uni davon
> zu lesen war? Kein Wunder dass das nur eingeweihte benutzt haben.
s.o. Hast Du eigentlich Erfahrung mit Diensten die du fï¿œr ein paar tausend
Nutzer anbieten musst? Glaub mir, meistens weiￜ ich warum ich was mache.
Gruￜ
Charly
Harald Losert
Danke für deine prompte Reaktion, und bitte nicht in den falschen Hals
bekommen ;-).
> Hellsehen kann ich leider immer noch nicht, meine Kristallkugel ist schon
> wieder so trübe. Wenn ich von dem Problem nichts weiß, kann ich Dir auch
> nicht
> helfen. Hast du denn dem Helpdesk schon mal von dem Problem berichtet?
>
> Also mit mir eine debug-session ausmachen und wir bekommen das gebacken,
> wenn
> nur dein Browser anständiges HTTP und SSL kann. Kann er das?
Das Problem ist wohl wirklich, dass der Browser SSL nicht vernünftig
unterstützt. Basieren tut das Ding auf WebKit (wie ein Großteil der
Gadget-Browser), allerdings scheint die Implementierung wohl nicht
ausreichend zu sein. (Überhaupt ist der Browser eigentlich unter aller
Sau..) Browseroptionen hat man quasi keine, aber wenn man mal
SSL-Testabfragen macht, dann sieht man, dass da so gut wie gar nix geht.
Da wird vermutlich der Hund begraben liegen. (Für genauere Analysen bin
ich dann doch zu wenig Experte für sowas...)
Entsprechend muss ich jetzt den Helpdesk oder dich mit diesem
aussichtslosen Fall wohl nicht mehr belästigen.
Das seit 3 Monaten angekündigte Update für ~März-April auf die neue webOS
2.0 Version wird übrigens SSL vernünftig unterstützen, so wie auch einen
Cisco Anyconnect-Client, von daher ist das Problem sowieso bald gegessen.
Allerdings ist das ja immer so eine Sache mit neuen Firmwareversionen bei
Auslaufmodellen. Da kanns dann auch mal ein halbes Jahr später werden.
Dass seit über einem Jahr Flash-Unterstützung versprochen ist und nix
passiert muss ich wohl nicht erwähnen? ;-)
In der Hoffnung, dass das demnächst wohl dann doch was wird werde ich das
Ganze mal abwarten. Ansonsten werd ich wohl mal einen Besuch abstatten
müssen.
Eigentlich war der Beitrag hier nur als kleiner Hinweis gemeint, dass
bezüglich Smartphones noch ein etwas größeres Problem in der
VPN-Unterstützung besteht. Was aber wohl hauptsächlich an der
fehlenden/mangelhaften Implementierung auf Seiten der Smartphones liegt.
Und wie du ja schon geschrieben hast, haben auch die Apfelmänner die
VPN-Sache ziemlich versaut, aber inzwischen läufts, zumindest teilweise.
Palm/HP sind aber drum und dran einfach alle Fehler komplett
nachzumachen....
>>
>> Bezüglich der VPN-Problematik gilt ähnliches für Android- und
>> Symbian/Nokia-Nutzer, die ebenfalls keine Möglichkeit per VPN haben.
>> Nur für
>
> s.o. die können aber Captive::Portal, oder?
Die Android/Symbian User können Captive::Portal (da hat der Entwickler
beim Browser halt nicht gepennt), nur VPN-mäßig läuft halt gar nix. Was an
sich etwas ärgerlich ist, da man manchmal doch nach recht kurzer idle-Zeit
wieder unsanft vor die Tür gesetzt wird.
Und vermutlich wird bei beiden Betriebssystemen in nächster Zeit keine
Besserung bezüglich VPN zu erwarten sein. Anscheinend ist da die Nachfrage
einfach nicht groß genug.
>>
>> Ohne das Thema nochmal ausweiten zu wollen. Beim OpenVPN Server wurde ja
>> kritisiert, dass er zu wenig frequentiert sei. Ist das denn nicht
>> logisch wenn
>
> nope, zu wenig für die Endnutzer mit 2 linken Daumen verwendbar! Das war
> das
> was mich von einem Mass-Rollout abhielt.
>
>> (zumindest Anfang Dezember) nichts dazu auf der VPN-Info-Seite der Uni
>> davon
>> zu lesen war? Kein Wunder dass das nur eingeweihte benutzt haben.
>
> s.o. Hast Du eigentlich Erfahrung mit Diensten die du für ein paar
> tausend
> Nutzer anbieten musst? Glaub mir, meistens weiß ich warum ich was mache.
>
> Gruß
> Charly
Ich hab keine Erfahrung damit, und ich hab auch großen Respekt, dass das
ganze so sauber läuft. Ich möchte den Job wirklich nicht machen.
Und wenn wir doch mal ganz ehrlich sind, dann ist das doch ein ziemliches
Luxusproblem mit dem Smartphone nicht ins Uni-WLAN zu kommen.
Gruß,
Harry
Karl Gaissmaier
Am 29.01.2011 00:39, schrieb Harald Losert:
> Hey Charlie,
>
> Danke für deine prompte Reaktion, und bitte nicht in den falschen Hals
> bekommen ;-).
no problem
...
> Das Problem ist wohl wirklich, dass der Browser SSL nicht vernünftig
> unterstützt. Basieren tut das Ding auf WebKit (wie ein Großteil der
> Gadget-Browser), allerdings scheint die Implementierung wohl nicht
> ausreichend zu sein. (Überhaupt ist der Browser eigentlich unter aller
> Sau..) Browseroptionen hat man quasi keine, aber wenn man mal
> SSL-Testabfragen macht, dann sieht man, dass da so gut wie gar nix geht.
> Da wird vermutlich der Hund begraben liegen. (Für genauere Analysen bin
> ich dann doch zu wenig Experte für sowas...)
>
> Entsprechend muss ich jetzt den Helpdesk oder dich mit diesem
> aussichtslosen Fall wohl nicht mehr belästigen.
Würde mich schon interessieren. Wenn ich mal Blut geleckt habe, bringe
ich es ganz gern zu Ende. Könnte auch sein, dass das Gadget auch nur
den HTTP-redirect auf HTTPS nicht anständig kann und es deshalb nicht
geht. Versuch mal Dich direkt am CaPo anzumelden:
Also folgende URL im Browser eingeben:
https://welcome.uni-ulm.de/capo
Wenn das nicht geht, dann ist alles hoffnungslos.
...
> Eigentlich war der Beitrag hier nur als kleiner Hinweis gemeint, dass
> bezüglich Smartphones noch ein etwas größeres Problem in der
> VPN-Unterstützung besteht. Was aber wohl hauptsächlich an der
> fehlenden/mangelhaften Implementierung auf Seiten der Smartphones liegt.
...
>
> Die Android/Symbian User können Captive::Portal (da hat der Entwickler
> beim Browser halt nicht gepennt), nur VPN-mäßig läuft halt gar nix. Was
> an sich etwas ärgerlich ist, da man manchmal doch nach recht kurzer
> idle-Zeit wieder unsanft vor die Tür gesetzt wird.
Auch das kann man verbessern, wenn ich nur über konkrete Probleme
informiert werde. Habe sowieso letzte Woche den IDLE-Algorithmus
verbessert. Ich verwende jetzt _zusätzlich_ Cookies (allerdings nicht
als Voraussetzung sondern nur zum Komfort). Wenn man eine alte IDLE
session hat, und innerhalb einer bestimmten Zeit (im Moment 1h) wieder
mit der gleichen IP/MAC Adresskombi auf dem Captive::Portal aufschlägt,
dann wird beim erfolgreichen Cookiematch die IDLE session wieder
automatisch in den ACTIVE Zustand gehoben. Läuft aber gerade erst
auf dem Development-Server zum Test. Dürfte aber nächste Woche in
Produktion gehen. Allerdings habe ich dafür die MAX-SESSION-TIME
auf 2 Tage beschränkt. Wenn man nämlich den Komfort zu hoch treibt
vergessen ein paar der vielen Nutzer, dass man sich ja immer
noch anmelden muss und beschweren sich dann, dass kaum dass sie nach 4
Wochen mal gebootet haben, unser 'WLAN' nicht mehr geht, sigh.
...
>
> Und wenn wir doch mal ganz ehrlich sind, dann ist das doch ein
> ziemliches Luxusproblem mit dem Smartphone nicht ins Uni-WLAN zu kommen.
Sehe ich im Prinzip auch so, aber man kann den Luxus auch genießen wenn
es ihn gibt.
Im Moment sind mein Kollege Bing und ich noch daran, die mehrere hundert
bis zu mehr als tausend dynamischen Firewall-rules so zu
perfektionieren, dass die Kiste dann immer noch 1 Gigabit wirespeed
durchsetzt, ohne in die Knie zu gehen und trotzdem weiterhin auf
mehrere tausend Nutzer skaliert.
Bin ganz zuversichtlich, dass wir das hinbekommen.
Gruß
Charly
Sebastian Bauer
jetzt muss ich mich in der Diskussion doch auch kurz zu Worte melden.
Ich bin einer der (mehr oder weniger) geplagten Android Benutzer, die
sich möglichst komfortabel über ihr Smartphone ins Uni-Wlan einloggen
möchten.
Bei Android ist das, wie Harry schon schrieb, über den Browser
problemlos möglich. Tatsächlich ist hier aber auch der
Idle-Rausschmiss ein großes Problem.
Es ist eine tolle Sache, dass man hier Hilfe zu solchen
"Luxusproblemchen" bekommen kann. Das muss ich hier schon auch mal
erwähnen. Wie es sich anhört, wird es ja in der kommenden Zeit noch
einige Verbesserungen für uns geplagte Smartphone-Generation geben ;-)
>> Eigentlich war der Beitrag hier nur als kleiner Hinweis gemeint, dass
>> bezüglich Smartphones noch ein etwas größeres Problem in der
>> VPN-Unterstützung besteht. Was aber wohl hauptsächlich an der
>> fehlenden/mangelhaften Implementierung auf Seiten der Smartphones
>> liegt.
> ...
>>
>> Die Android/Symbian User können Captive::Portal (da hat der Entwickler
>> beim Browser halt nicht gepennt), nur VPN-mäßig läuft halt gar nix. Was
>> an sich etwas ärgerlich ist, da man manchmal doch nach recht kurzer
>> idle-Zeit wieder unsanft vor die Tür gesetzt wird.
Hier brauche ich nichts dazu erzählen. Ich habe, wie Harry, schon
viele Stunden meines Lebens investiert, um festzustellen, dass VPN auf
einem Android-Gerät nicht klappt.
Hier möchte ich nur auf die Google-Code-Seite zu Android verweisen,
auf der seit September 2009 die Implementierung von Cisco-VPN an
zweiter Stelle von den Usern gefordert wird (über 5000 Sternchen)
>
> Auch das kann man verbessern, wenn ich nur über konkrete Probleme
> informiert werde. Habe sowieso letzte Woche den IDLE-Algorithmus
> verbessert. Ich verwende jetzt _zusätzlich_ Cookies (allerdings nicht
> als Voraussetzung sondern nur zum Komfort). Wenn man eine alte IDLE
> session hat, und innerhalb einer bestimmten Zeit (im Moment 1h) wieder
> mit der gleichen IP/MAC Adresskombi auf dem Captive::Portal aufschlägt,
> dann wird beim erfolgreichen Cookiematch die IDLE session wieder
> automatisch in den ACTIVE Zustand gehoben. Läuft aber gerade erst
> auf dem Development-Server zum Test. Dürfte aber nächste Woche in
> Produktion gehen. Allerdings habe ich dafür die MAX-SESSION-TIME
> auf 2 Tage beschränkt. Wenn man nämlich den Komfort zu hoch treibt
> vergessen ein paar der vielen Nutzer, dass man sich ja immer
> noch anmelden muss und beschweren sich dann, dass kaum dass sie nach 4
> Wochen mal gebootet haben, unser 'WLAN' nicht mehr geht, sigh.
>
Wie sieht es denn mit den Cookies aus, wenn ich eine IDLE-Session habe
und dann mein Mail-Programm eine Anfrage an einen unifremden
Mailserver startet? Dann steht der Cookie ja nicht zur Abfrage bereit,
richtig?
Die Frage kam mir gerade in den Sinn, da ich ja nicht immer mit dem
Webbrowser unterwegs bin.
> Hoffe, dass wir in 2-3 Monaten eduroam fähig sind, dann kann ev. auch dein
> Gadget sich mit 802.1X-Enterprise verbinden und du brauchst keine weitere
> Tunnellösung.
Das wäre natürlich sehr luxoriös, dann bräuchte man keinen Tunnel.
Laut diverser Internetforen ist diese Methode auf Android auch nicht
völlig aussichtslos, so wie Cisco-VPN. Vielleicht wäre das auch eine
einfache Lösung für WebOS und Symbian Nutzer.
Grüße
Sebastian
Karl Gaissmaier
Am 31.01.2011 11:14, schrieb Sebastian Bauer:
> Hallo zusammen,
>
> jetzt muss ich mich in der Diskussion doch auch kurz zu Worte melden. Ich bin einer der (mehr oder weniger) geplagten Android Benutzer, die sich mï¿œglichst komfortabel ï¿œber ihr Smartphone ins Uni-Wlan einloggen mï¿œchten.
> Bei Android ist das, wie Harry schon schrieb, ï¿œber den Browser problemlos mï¿œglich. Tatsï¿œchlich ist hier aber auch der Idle-Rausschmiss ein groï¿œes Problem.
>
> Es ist eine tolle Sache, dass man hier Hilfe zu solchen "Luxusproblemchen" bekommen kann. Das muss ich hier schon auch mal erwï¿œhnen. Wie es sich anhï¿œrt, wird es ja in der kommenden Zeit noch einige Verbesserungen fï¿œr uns geplagte Smartphone-Generation geben ;-)
>
...
>>>
>>> Die Android/Symbian User kï¿œnnen Captive::Portal (da hat der Entwickler
>>> beim Browser halt nicht gepennt), nur VPN-mￜￜig lￜuft halt gar nix. Was
>>> an sich etwas ï¿œrgerlich ist, da man manchmal doch nach recht kurzer
>>> idle-Zeit wieder unsanft vor die Tï¿œr gesetzt wird.
>
> Hier brauche ich nichts dazu erzï¿œhlen. Ich habe, wie Harry, schon viele Stunden meines Lebens investiert, um festzustellen, dass VPN auf einem Android-Gerï¿œt nicht klappt.
> Hier mï¿œchte ich nur auf die Google-Code-Seite zu Android verweisen, auf der seit September 2009 die Implementierung von Cisco-VPN an zweiter Stelle von den Usern gefordert wird (ï¿œber 5000 Sternchen)
>
>>
>> Auch das kann man verbessern, wenn ich nur ï¿œber konkrete Probleme
>> informiert werde. Habe sowieso letzte Woche den IDLE-Algorithmus
>> verbessert. Ich verwende jetzt _zusï¿œtzlich_ Cookies (allerdings nicht
>> als Voraussetzung sondern nur zum Komfort). Wenn man eine alte IDLE
>> session hat, und innerhalb einer bestimmten Zeit (im Moment 1h) wieder
>> mit der gleichen IP/MAC Adresskombi auf dem Captive::Portal aufschlï¿œgt,
>> dann wird beim erfolgreichen Cookiematch die IDLE session wieder
>> automatisch in den ACTIVE Zustand gehoben.
...
>
> Wie sieht es denn mit den Cookies aus, wenn ich eine IDLE-Session habe und dann mein Mail-Programm eine Anfrage an einen unifremden Mailserver startet? Dann steht der Cookie ja nicht zur Abfrage bereit, richtig?
> Die Frage kam mir gerade in den Sinn, da ich ja nicht immer mit dem Webbrowser unterwegs bin.
Fie Frage hast Du ja schon selbst beantwortet. Natï¿œrlich brauchst du zuerst
immer http traffic, damit das Captive::Portal eine Chance hat dir eine
Loginseite vor den latz zu knallen oder Cookies auszulesen.
Wenn Du Deine externe E-Mail mit was anders als dem Webbrowser liest,
dann musst du eben vorher nochmals einen reload mit dem Browser
veranstalten, solltest dich dazu dann aber nicht mehr einloggen mï¿œssen.
>
>> Hoffe, dass wir in 2-3 Monaten eduroam fï¿œhig sind, dann kann ev. auch dein
>> Gadget sich mit 802.1X-Enterprise verbinden und du brauchst keine weitere
>> Tunnellï¿œsung.
>
> Das wï¿œre natï¿œrlich sehr luxoriï¿œs, dann brï¿œuchte man keinen Tunnel. Laut diverser Internetforen ist diese Methode auf Android auch nicht vï¿œllig aussichtslos, so wie Cisco-VPN. Vielleicht wï¿œre das auch eine einfache Lï¿œsung fï¿œr WebOS und Symbian Nutzer.
Dann gibt es andere Probleme, dein Gadget muss dazu jedenfalls PAP in EAP-TTLS
unterstï¿œtzen, kann es das?
Gruￜ
CHarly
thion
mir stößt die Sache mit dem neuen Portal übel auf, da ich als
Android-User bisher 2 Wege hatte mich komfortabel ins WLAN einzuwählen.
Zum einen mit OpenVPN, zum anderen über ein kleines Programm, was bei
Erkennung des welcome-WLANs den Login automatisch macht.
Funktioniert beides nicht mehr, das Programm weil derjenige ders
geschrieben hat bisher nicht in der Lage war es stabil fürs neue Portal
anzupassen (worauf ich hoffe, danke für die erste Version an dieser
Stelle ;) ).
Abschaltung des OpenVPN ist das nächste, was ich eigentlich noch
schlimmer finde, da es heisst er wurde zu wenig frequentiert... ich hab
von diesem Server über Umwege erfahren, wenn der wenigstens auf der
VPN-Seite stehen würde wärs ja okay, war aber nicht der Fall.
Die Gründe dafür kann ich auch nicht verstehen, weil für OpenVPN im
Gegensatz zum Cisco für mehr Systeme eine Implementierung besteht.
Also wenn ihr Leute sucht die sich dafür stark machen den OpenVPN-Server
wieder aufzumachen hätte ich da einige Android-User in meinem Umfeld.
MfG,
Thion
Karl Gaissmaier
Am 31.01.2011 17:32, schrieb thion:
> Hallo,
>
> mir stößt die Sache mit dem neuen Portal übel auf, da ich als Android-User bisher 2 Wege hatte mich komfortabel ins WLAN einzuwählen.
das mit dem übel aufstoßen ist nicht unbedingt der Ton um etwas zu erreichen...
> Zum einen mit OpenVPN, zum anderen über ein kleines Programm, was bei Erkennung des welcome-WLANs den Login automatisch macht.
>
> Funktioniert beides nicht mehr, das Programm weil derjenige ders geschrieben hat bisher nicht in der Lage war es stabil fürs neue Portal anzupassen (worauf ich hoffe, danke für die erste Version an dieser Stelle ;) ).
>
so ein Automatismus sollte für das neue Portal viel leichter zu
schreiben sein als für das alte. Woran klemmt's, wie und mit was habt ihr es geschrieben?
> Abschaltung des OpenVPN ist das nächste, was ich eigentlich noch schlimmer finde, da es heisst er wurde zu wenig frequentiert... ich hab von diesem Server über Umwege erfahren, wenn der wenigstens auf der VPN-Seite stehen würde wärs ja okay, war aber nicht der Fall.
Übrigens hat das neue Captive::Portal nichts mit der Abschaltung des OpenVPN Servers zu tun und der Mär von
dem 'Grund: zu wenig genutzt' habe ich in diesem Thread an anderer Stelle schon widersprochen. Bitte nachlesen, so
lange ist der Thread ja nicht.
> Die Gründe dafür kann ich auch nicht verstehen, weil für OpenVPN im Gegensatz zum Cisco für mehr Systeme eine Implementierung besteht.
s.o.
>
> Also wenn ihr Leute sucht die sich dafür stark machen den OpenVPN-Server wieder aufzumachen hätte ich da einige Android-User in meinem Umfeld.
das wird es nicht geben. Warum benötigst Du einen automatischen Login?
Gruß
Charly
Harald Losert
also beim alten Portal konnte ich es nicht einmal direkt aufrufen, beim
neuen Portal ging das bis Anfang letzter Woche (da hab ich es das letzte
Mal probiert) auch nicht.
Aber heute ging es interessanterweise.
Was auch immer da oben bei euch gedreht wurde, es hat dazu geführt, dass
ich mich jetzt über das Webinterface einloggen kann. (Es funktioniert
sowohl der redirect beim Aufrufen einer beliebigen Seite wie auch der
Direktzugriff über deinen Link)
Von daher bin ich ja fast schon wunschlos glücklich :-D
Dann kann VPN ja noch ein wenig bis zur neuen Firmware warten, wenn
wenigstens das Weblogin jetzt funktioniert.
Gruß,
Harry
Karl Gaissmaier
Am 31.01.2011 21:12, schrieb Harald Losert:
> Hey Charly,
>
> also beim alten Portal konnte ich es nicht einmal direkt aufrufen, beim
das war damals prinzipbedingt nicht möglich. Das ist einer der vielen,
vielen Punkte die ich gelernt und in der neuen Version verbessert habe.
Das alte Captive Portal hatte als Basis die Software NoCat, vielfach
von mir gepatcht um sie in einer Uni-Umgebung lauffähig zu machen und
über die Jahre am Laufen zu halten. All die Lehrjahre habe ich in der
von Scratch auf neu geschriebenen Software versucht reinzupacken, ohne
in die Falle des 'second-system-syndrom' zu laufen.
> neuen Portal ging das bis Anfang letzter Woche (da hab ich es das letzte
> Mal probiert) auch nicht.
> Aber heute ging es interessanterweise.
Wir haben an der Software in diesem Punkt nichts verändert, aber mein
Kollege (Apache Guru, Uni-Ulm Webmaster, ...) hat an den rewrite-rules
noch gedreht. Aber das mit dem direkten Einloggen hätte auf jeden Fall
vorher schon funktionieren müssen, deshalb wollte ich ja, dass du mir
vor Ort wirklich zeigst, was nicht geht. Nur eine fehlerhafte
SSL-Implementation Deines Gadgets hätte es zum Scheiten bringen können.
> Was auch immer da oben bei euch gedreht wurde, es hat dazu geführt, dass
> ich mich jetzt über das Webinterface einloggen kann. (Es funktioniert
> sowohl der redirect beim Aufrufen einer beliebigen Seite wie auch der
> Direktzugriff über deinen Link)
>
> Von daher bin ich ja fast schon wunschlos glücklich :-D
Freut mich. Wie man in den Wald ruft schallt es eben zurück.
>
> Dann kann VPN ja noch ein wenig bis zur neuen Firmware warten, wenn
> wenigstens das Weblogin jetzt funktioniert.
Könnte Dein gadget eigentlich EAP-TTLS und PAP in dem TTLS Tunnel?
Das ist nämlich eine der Voraussetzungen für Eudroam.
Gruß
Charly
Harald Losert
>> also beim alten Portal konnte ich es nicht einmal direkt aufrufen, beim
>
> das war damals prinzipbedingt nicht möglich. Das ist einer der vielen,
> vielen Punkte die ich gelernt und in der neuen Version verbessert habe.
Ok, das wusste ich natürlich nicht...
>
>> neuen Portal ging das bis Anfang letzter Woche (da hab ich es das letzte
>> Mal probiert) auch nicht.
>> Aber heute ging es interessanterweise.
>
> Wir haben an der Software in diesem Punkt nichts verändert, aber mein
> Kollege (Apache Guru, Uni-Ulm Webmaster, ...) hat an den rewrite-rules
> noch gedreht. Aber das mit dem direkten Einloggen hätte auf jeden Fall
> vorher schon funktionieren müssen, deshalb wollte ich ja, dass du mir
> vor Ort wirklich zeigst, was nicht geht. Nur eine fehlerhafte
> SSL-Implementation Deines Gadgets hätte es zum Scheiten bringen können.
Dann muss ich mich da wohl irgendwo im Browser vertippt haben, wenn ich
die Seite nicht erreicht habe... Auf jeden Fall funktioniert die
Weiterleitung auf WebOS erst seit einigen Tagen.
>> Dann kann VPN ja noch ein wenig bis zur neuen Firmware warten, wenn
>> wenigstens das Weblogin jetzt funktioniert.
>
> Könnte Dein gadget eigentlich EAP-TTLS und PAP in dem TTLS Tunnel?
> Das ist nämlich eine der Voraussetzungen für Eudroam.
>
> Gruß
> Charly
Also laut Herstellerspezifikation ist EAP-TTLS möglich, PAP ist explizit
nicht erwähnt.
Aber wenns soweit ist, dann werden wir ja sehen was passiert.
Aber vielleicht kommt ja die neue Version von WebOS doch im März wie
angekündigt, dann würde der integrierte AnyConnect-Client das Ganze
Problem elegant lösen.
Ansonsten freu ich mich natürlich auf die Eudroam-Lösung.
Gruß,
Harry
Simon Fuchs
On 31.01.2011 17:32, thion wrote:
> mir stￜￜt die Sache mit dem neuen Portal ￜbel auf, da ich als
> Android-User bisher 2 Wege hatte mich komfortabel ins WLAN einzuwï¿œhlen.
> Zum einen mit OpenVPN, zum anderen ï¿œber ein kleines Programm, was bei
> Erkennung des welcome-WLANs den Login automatisch macht.
>
> Funktioniert beides nicht mehr, das Programm weil derjenige ders
> anzupassen (worauf ich hoffe, danke fï¿œr die erste Version an dieser
> Stelle ;) ).
Ich glaube das wï¿œre kein Problem eine entsprechende App zu schreiben.
*nachdenk*
*google*
Ah, es gibt so etwas in die Richtung sogar schon.
http://andhsli.sourceforge.net/
Allerdings natï¿œrlich nicht fï¿œrs welcome CaPo. Wird aber glaub nicht so
einfach, ich kenne den aktuellen Code vom CaPo (noch) nicht, aber das
NoCat von frï¿œher wollte immer noch ein Token und die MAC haben. Das lies
sich mittels einiger Zeilen Java lï¿œsen, mal sehen ob sich noch freie
Zeit fï¿œr so Spielchen findet ;-)
Welche CaPo Software lï¿œuft da aktuell? selfmade wenn ich das richtig lese?
Gruￜ Fuchs
Karl Gaissmaier
> Hi,
> On 31.01.2011 17:32, thion wrote:
>> Android-User bisher 2 Wege hatte mich komfortabel ins WLAN einzuwählen.
>> Zum einen mit OpenVPN, zum anderen über ein kleines Programm, was bei
>> Erkennung des welcome-WLANs den Login automatisch macht.
>>
>> Funktioniert beides nicht mehr, das Programm weil derjenige ders
>> anzupassen (worauf ich hoffe, danke für die erste Version an dieser
>> Stelle ;) ).
> Ich glaube das wäre kein Problem eine entsprechende App zu schreiben.
> *nachdenk*
> *google*
> Ah, es gibt so etwas in die Richtung sogar schon.
> http://andhsli.sourceforge.net/
> einfach, ich kenne den aktuellen Code vom CaPo (noch) nicht, aber das
> sich mittels einiger Zeilen Java lösen, mal sehen ob sich noch freie
> Zeit für so Spielchen findet ;-)
>
> Welche CaPo Software läuft da aktuell? selfmade wenn ich das richtig lese?
Captive::Portal liegt nach Abschluss der Arbeiten hier am kiz auf CPAN: www.cpan.org
Geht ohne Java und scripting Gedöns, schaut euch mal die POST Parameter beim
Login an, das CaPo liest die Parameter auch via GET. Ich gebe hier keine allgemeine
Anleitung wie ihr den Login auf einen URL legt, mit Username und Passwort
drin, denn dann heißt es wieder, das kiz habe gesagt, dass man das so machen soll.
Klar ist, wenn ihr den URL mit Usercredentials ungesichert in den Lesezeichenspeicher
ablegt, dann kann das Passwort jeder lesen, der das Gerät in die Finger bekommt.
Nehmt am besten dafür einen Passwortmanager, so was wird es für die verschiedenen
Gadgets wohl in irgendeiner Art geben.
Gruß
Charly
thion
> so ein Automatismus sollte für das neue Portal viel leichter zu
> schreiben sein als für das alte. Woran klemmt's, wie und mit was habt
> ihr es geschrieben?
Wurde nicht von mir geschrieben, aber ich habs nun vor mir und werd mal
drüberschauen ob ich was dran machen kann, dann kann ich genaueres dazu
sagen.
> das mit dem übel aufstoßen ist nicht unbedingt der Ton um etwas zu
> erreichen...
Sorry, das wurde schlimmer aufgefasst als es gemeint war.
Was ich zu OpenVPN / Autologin meine, ist:
Ja, es ist Luxus.
Ja, man "braucht" es nicht zwingend.
Aber:
Es war vorher ohne Probleme möglich.
Und es wurde eingespart.
Nur um das aus Usersicht darzustellen.
Mir ist klar dass das Problem recht weit unten auf der Prioritätenliste
steht. Meine Frage ist nur, wäre es denn viel Aufwand, den OpenVPN offen
zu halten?
Weil es gibt Möglichkeiten nen Autologin zu kriegen, z.B. über nen
automatisiertes Programm oder über ein gerootetes Android und einen
gemoddeten VPN-Client, aber warum kompliziert, wenns auch einfach geht?
Wie gesagt, ist nur nen nice-to-have, wobei der Anteil von
Android-Geräten zunehmen wird und es sicher nichts schlimmes wäre eine
simple Möglichkeit zu haben.
Warum man den Autologin braucht?
Nun, ein Handy(und auch künftige Tablet-PCs) hat im Gegensatz zu einem
Laptop ein anderes Nutzungsprofil. Es ist always-on und synchronisiert
im Hintergrund, was einen Autologin wichtiger macht als auf dem Laptop.
Einen Laptop hingegen macht man on-demand lokalisiert an, ein Handy bzw
Smartphone ist immer verbunden und schält beim erkennen eines WLANs
direkt drauf um. Wenn das jedesmal nen "manuellen" Login erfordert oder
man sich bewegt, sprich zwischen Access-points herläuft und die
Verbindung verliert, ist es doch sehr nervig sich jedesmal wieder
einzuloggen. Ich würd meines ja gerne auf UTMS fest einstellen, aber der
Handyempfang ist nicht unbedingt ideal in der Uni ;)
Wie gesagt, nicht nötig, aber wäre doch etwas Komfort den man zusätzlich
zum im Vergleich eh schon guten IT-Support zu schätzen wissen würde.
MfG,
Thion
Karl Gaissmaier
Am 01.02.2011 14:32, schrieb thion:
> Hallo,
>
>> so ein Automatismus sollte fï¿œr das neue Portal viel leichter zu
>> schreiben sein als fï¿œr das alte. Woran klemmt's, wie und mit was habt
>> ihr es geschrieben?
>
> Wurde nicht von mir geschrieben, aber ich habs nun vor mir und werd mal drï¿œberschauen ob ich was dran machen kann, dann kann ich genaueres dazu sagen.
>
schau dir mal meinen Hint in einem vorigen Posting bzgl. GET versus POST
login Daten an.
> Was ich zu OpenVPN / Autologin meine, ist:
> Ja, es ist Luxus.
> Ja, man "braucht" es nicht zwingend.
> Aber:
> Es war vorher ohne Probleme mï¿œglich.
> Und es wurde eingespart.
>
> Nur um das aus Usersicht darzustellen.
> Mir ist klar dass das Problem recht weit unten auf der Prioritï¿œtenliste steht. Meine Frage ist nur, wï¿œre es denn viel Aufwand, den OpenVPN offen zu halten?
Ja, es ist auch schon abgebaut und entsorgt. Es war nie ein ï¿œffentlicher
Dienst und wurde es nach einer lï¿œngeren Testphase auch nicht.
> Weil es gibt Mï¿œglichkeiten nen Autologin zu kriegen, z.B. ï¿œber nen automatisiertes Programm oder ï¿œber ein gerootetes Android und einen gemoddeten VPN-Client, aber warum kompliziert, wenns auch einfach geht?
> Wie gesagt, ist nur nen nice-to-have, wobei der Anteil von Android-Gerï¿œten zunehmen wird und es sicher nichts schlimmes wï¿œre eine simple Mï¿œglichkeit zu haben.
>
Ein Autologin sollte ï¿œber den Browser eigentlich noch einfacher mï¿œglich sein,
bzw. ein keliens Script, welches mit dem CaPo SSL spricht.
Gruￜ
Charly
Karl Gaissmaier
...
>>> Auch das kann man verbessern, wenn ich nur über konkrete Probleme
>>> informiert werde. Habe sowieso letzte Woche den IDLE-Algorithmus
>>> verbessert. Ich verwende jetzt _zusätzlich_ Cookies (allerdings nicht
>>> als Voraussetzung sondern nur zum Komfort). Wenn man eine alte IDLE
>>> session hat, und innerhalb einer bestimmten Zeit (im Moment 1h) wieder
>>> mit der gleichen IP/MAC Adresskombi auf dem Captive::Portal aufschlägt,
>>> dann wird beim erfolgreichen Cookiematch die IDLE session wieder
>>> automatisch in den ACTIVE Zustand gehoben.
ist seit Freitag Nachmittag auf dem Produktionsserver in Betrieb.
Bitte Ungereimtheiten in dem Zusammenhang an mich melden.
Zudem haben wir die iptables(8) chains, die eine große Anzahl
von rules bzw. Dynamik aufweisen, komplett auf ipset(8) umgestellt, so
dass der Server bei großer Netzbelastung und vielen Sessions
nicht mehr in der Leistung einbricht.
In einer Nacht- und Nebelaktion hatten wir Donnerstag nacht den
DHCP-Bereich für das WLAN von ~1000 auf ~2000 Adressen erhöht.
Ein paar späte Nutzer werden den Ruckler gemerkt haben. Es musste
natürlich unter anderem auch das Interface des public-access
Gateways angepasst werden, und vieles mehr ...
Außerdem tauschen wir demnächst noch die Hardware, von einem 1-Core auf
4-Core Server. Läuft momentan schon eine Weile als Testserver und
kann 1-GBit/s wirespeed-Durchsatz, ohne dass der http(s) Handler
merklich langsamer anspricht.
Gruß
Charly
P.S. An eduroam (802.1X-Enterprise, EAP-TTLS) ist ein Kollege von mir
auch aktuell dran.
Karl Gaissmaier
On 05.02.2011 11:10, Karl Gaissmaier wrote:
...
> Außerdem tauschen wir demnächst noch die Hardware, von einem 1-Core auf
> 4-Core Server. Läuft momentan schon eine Weile als Testserver und
> kann 1-GBit/s wirespeed-Durchsatz, ohne dass der http(s) Handler
> merklich langsamer anspricht.
wurde soeben getauscht. Leider sind uns dabei 14 aktive sessions
verloren gegangen, sorry.
14 Nutzer werden jetzt wohl über das kiz schimpfen, ohne
Kenntnis dessen, dass wir diese Umzüge extra zu so später Stunde
vornehmen.
So ist es eben: Undank ist der Welten Lohn ;-)
Gruß
Charly und Bing
Harald Losert
was auch immer ihr da in den letzten Tag gedreht habt, es hat nun dazu
geführt, dass ihr mich mit WebOS wieder vom Uninetz ausgeschlossen habt.
Weder funktioniert das abfangen über das Captive Portal bei einem
http-request, noch kann ich direkt auf das Portal über
welcome.uni-ulm.de/capo zugreifen. Ich werde in beiden Fällen mit der
Meldung "Seite kann nicht angezeigt werden" abgespeist.
Selbiges war ja auch das Problem im letzten Jahr mit dem alten Portal und
mit dem neuen CaPo bis vor zwei oder drei Wochen. Deswegen war ich ja so
erfreut, dass es dann ging. Und jetzt kann ich wieder nicht mal mehr auf
das CaPo zugreifen. Letzte Woche ging's noch, obwohl ich Freitag dann auch
schon geringere Probleme hatte sofern ich mich erinnere. Also erst nach
mehrmaligem Versuchen wurde ich zum Portal durchgestellt.
Gruß,
Harry
P.S.: Ansonsten ist das neue CaPo ja echt schön, auch da es eine
smartphoneoptimierte Mobile-Variante bietet. Neulich ist mir aber mal zu
Ohren gekommen, dass einige Nokia-Symbians (z.B. E71) nicht erkannt werden
und man dann auf dem Standardinterface landet... Auf einigen Androiden
scheint die Erkennung wohl auch nicht perfekt zu funktionieren. Da landet
der ein oder andere nach dem Einloggen wohl auch wieder auf der
Standard-Auslog-Seite und nicht auf der smartphoneoptimierten... Aber
immerhin funktioniert es überhaupt...
Karl Gaissmaier
On 07.02.2011 20:17, Harald Losert wrote:
> Hey Charly,
>
> was auch immer ihr da in den letzten Tag gedreht habt, es hat nun dazu
> geführt, dass ihr mich mit WebOS wieder vom Uninetz ausgeschlossen habt.
die neue Hardware kann es nicht gewesen sein ;-)
> Weder funktioniert das abfangen über das Captive Portal bei einem
> http-request, noch kann ich direkt auf das Portal über welcome.uni-ulm.de/capo
> zugreifen. Ich werde in beiden Fällen mit der Meldung "Seite kann nicht
> angezeigt werden" abgespeist.
Da ich das letzte mal auch nichts gedreht hatte, als es bei dir plötzlich
ging, wasche ich auch diesmal meine Hände in Unschuld. Bleibt nichts anderes
übrig, als dass du mal mit dem *blöden* Teil vorbei kommst.
>
> Selbiges war ja auch das Problem im letzten Jahr mit dem alten Portal und mit
> dem neuen CaPo bis vor zwei oder drei Wochen. Deswegen war ich ja so erfreut,
> dass es dann ging. Und jetzt kann ich wieder nicht mal mehr auf das CaPo
> zugreifen. Letzte Woche ging's noch, obwohl ich Freitag dann auch schon
> geringere Probleme hatte sofern ich mich erinnere. Also erst nach mehrmaligem
> Versuchen wurde ich zum Portal durchgestellt.
s.o., vielleicht liegt es an der Mondphase?
> P.S.: Ansonsten ist das neue CaPo ja echt schön, auch da es eine
> smartphoneoptimierte Mobile-Variante bietet. Neulich ist mir aber mal zu Ohren
> gekommen, dass einige Nokia-Symbians (z.B. E71) nicht erkannt werden und man
> dann auf dem Standardinterface landet... Auf einigen Androiden scheint die
> Erkennung wohl auch nicht perfekt zu funktionieren. Da landet der ein oder
> andere nach dem Einloggen wohl auch wieder auf der Standard-Auslog-Seite und
> nicht auf der smartphoneoptimierten... Aber immerhin funktioniert es überhaupt...
Auch hier gilt: Bringt die Dinger vorbei, kann nur sein, dass ich das ein
oder andere Gadget, das sich komplett daneben verhält, aus dem Fenster werfe.
Gruß
Charly
Karl Gaissmaier
>
> ...
>>>> Auch das kann man verbessern, wenn ich nur ï¿œber konkrete Probleme
>>>> informiert werde. Habe sowieso letzte Woche den IDLE-Algorithmus
>>>> als Voraussetzung sondern nur zum Komfort). Wenn man eine alte IDLE
>>>> session hat, und innerhalb einer bestimmten Zeit (im Moment 1h) wieder
>>>> dann wird beim erfolgreichen Cookiematch die IDLE session wieder
>>>> automatisch in den ACTIVE Zustand gehoben.
>
> ist seit Freitag Nachmittag auf dem Produktionsserver in Betrieb.
> Bitte Ungereimtheiten in dem Zusammenhang an mich melden.
Es sind noch Ungereimtheiten im IDLE Mechanismus sichtbar, sorry.
Wir analysieren noch das Zusammenspiel der Grￜￜe der ARP-Tabelle, der
Anzahl der mï¿œglichen IP Adressen im WLAN Netzwerk und verschiedenen Timern
und Zï¿œhlern im IP Stack und den sessions sowie im DHCP-renewal interval.
Ich bin mir sicher, dass wir nï¿œchste Woche ein stabiles System,
ohne unnï¿œtige IDLE Zyklen der Sessions, am Laufen haben.
Gruￜ
Charly
Karl Gaissmaier
On 07.02.2011 20:17, Harald Losert wrote:
> Hey Charly,
>
> was auch immer ihr da in den letzten Tag gedreht habt, es hat nun dazu
> geführt, dass ihr mich mit WebOS wieder vom Uninetz ausgeschlossen habt.
wir waren weiterhin fleißig, manchmal haben es ein paar Nutzer wohl
auch schmerzhaft gespürt, aber wir haben die ganze Woche über weiter
entwickelt und am offenen Herzen operiert.
Seit Freitag Nachmittag und aktuell gerade jetzt nach dem letzten Hotfix
sollte eine Client-Session wirklich nur noch IDLE gehen, wenn der Client
auch nicht mehr aktiv am Netz ist, also wenn kein DHCP-renewal kommt und wenn
das Gadget nicht mehr auf ARP-Anfragen antwortet.
Bitte bei weiteren Problemen und Ungereimtheiten unbedingt bei mir melden!
Momentan habe ich die komplette Komplexität fullstack im Kopf, so dass eine
Fehlersuche effizient und eine Verbesserung sehr wahrscheinlich
erfolgreich sein wird. Wenn erst mal das nächste Projekt am Laufen ist, dann
braucht die Einarbeitung und Fehlersuche in so ein relativ komplexes System
wesentlich länger.
Wir brauchen aber Feedback, positiv wie auch negativ.
Viele Grüße
Charly und Bing
Harald Losert
Nachdem ich viel um die Ohren hatte und jetzt erstmal das Firmwareupdate
für mein Palm Pre abgewartet habe, melde ich mich jetzt wieder.
Nachdem ich ja vor ein paar Wochen schon angemerkt habe, dass das CaPo
nicht mehr geht, obwohl es knapp zwei Wochen lang bei mir ging hat sich
daran auch nichts geändert.
Jetzt habe ich die neue Firmware aufgespielt (WebOS 2.1.0 statt wie bisher
1.4.5) mit dem Ergebnis: CaPo geht immer noch nicht (mir wird eine leere
Seite angezeigt...) und jetzt das Beste:
Seit dieser Version ist ein offizieller Cisco AnyConnect-Client
integriert. Und naja, du kannst dir schon denken was los ist. Der weigert
sich eine VPN-Verbindung zur Uni herzustellen. Langsam glaube ich ihr mögt
mich da oben nicht, wenn auch der VPN-Client nicht tut. (Ich habe es
mehrmals versucht. Von meinem WLAN aus hier, über EDGE, über UMTS, vom
Uni-WLAN aus. An meinem Router hier liegts nicht, da ich mit meinem PC
problemlos über Cisco AnyConnect eine Verbindung herstellen kann.) Nur
eben der Client aufm Plam weigert sich... Ich bekomme noch ein "All
Connections are logged" und dann nur noch ein böses "Verbindungsfehler:
Unable to establish VPN".
Und ich dachte mit dem Firmwareupdate und dem offiziellen
AnyConnect-Client wäre die Welt jetzt in Ordnung... Der Client selbst
funktioniert wohl, zumindest gibts genug Bereichte im Netz, dass Leute
Verbindung mit Cisco-VPNs hergestellt haben. Von daher nehme ich mal an,
dass das prinzipiell bei mir auch gehen müsste.
Aber mir würde es ja schon reichen wenn ichs auf CaPo zugreifen könnte, da
die neue Firmware jetzt endlich ne schöne Funktion hat die CaPos automisch
beim Herstellen der Verbindung mit dem WLAN erkennt, mich zur CaPo Seite
redirected und sich die Daten merkt. Entsprechend loggt sich das Handy
dann automatisch bei jeder neuen Verbindung mit dem WLAN ins CaPo ein.
Eine sehr luxuriöse Sache... Nur ist eben Ebbe mit der Weiterleitung zum
CaPo...
Aber machen wirs kurz...
Ich muss wohl oder übel doch mal vorbeikommen. Wann würde es denn zeitlich
passen (ich bin da recht flexibel), dann würde ich mal reinplatzen (und
vorher noch ne Schnur an meinem Gadget befestigen, für den Fall dass du es
ausm Fenster werfen willst :-D).
Gruß,
Harry
Karl Gaissmaier
> Hey Charly,
>
> Aber machen wirs kurz...
> Ich muss wohl oder übel doch mal vorbeikommen. Wann würde es denn
> zeitlich passen (ich bin da recht flexibel), dann würde ich mal
> reinplatzen (und vorher noch ne Schnur an meinem Gadget befestigen, für
> den Fall dass du es ausm Fenster werfen willst :-D).
Kontaktvereinbarung per PM. Das mit der Schnur solltest du lassen!
Oder willst du wirklich deinem Gadget hinterherfliegen ;-)
Gruß
Charly
Rainer Kaluscha
> Kontaktvereinbarung per PM. Das mit der Schnur solltest du lassen!
> Oder willst du wirklich deinem Gadget hinterherfliegen ;-)
Vorsicht Dachlawinen am O26 (auch bei Schneefreiheit) :-)
Othmar Marti
automatisch um auf capo. Opera Mini Version 10 sagt: es gäbe keine
Verbindung, auch wenn ich als Adresse https://welcome.uni-ulm.de/cap
eingebe.
Fazit: es hängt an der Software, die gewisse Mechanismen von CAPO nicht
akzeptieren will. Könnte es sein dass die Anti-Phishing-Mechanismen da
interferieren?
Viele Grüsse,
Othmar Marti
Arno Luppold
Am 07.03.2011 16:59, schrieb Othmar Marti:
> Ein kleiner Beitrag: Nokia E71. Der Nokia Browser schaltet sich
> automatisch um auf capo. Opera Mini Version 10 sagt: es gäbe keine
> Verbindung, auch wenn ich als Adresse https://welcome.uni-ulm.de/cap
> eingebe.
Das liegt daran, dass Opera Mini kein richtiger Browser ist. Opera Mini
hat keine HTML Rendering Engine und sendet *alle* Verbindungsanfragen
zwangsläufig über die "Opera Turbo"-Server.
Opera Mobile hingegen ist ein vollwertiger mobiler Browser (mit
optionaler "Opera Turbo"-Funktion) und kooperiert zumindest bei mir (mit
deaktiviertem "Opera Turbo") problemlos mit dem Login-Portal.
Siehe auch http://www.opera.com/mobile/specs/
Viele Grüße
Arno
Simon Fuchs
wrote:
> > Ein kleiner Beitrag: Nokia E71. Der Nokia Browser schaltet sich
> > automatisch um auf capo. Opera Mini Version 10 sagt: es gäbe keine
> > Verbindung, auch wenn ich als Adresse
https://welcome.uni-ulm.de/cap
> > eingebe.
> Das liegt daran, dass Opera Mini kein richtiger Browser ist. Opera
Mini
> hat keine HTML Rendering Engine und sendet *alle*
Verbindungsanfragen
> zwangsläufig über die "Opera Turbo"-Server.
Opera Mini hat aber auch die Option, über HTTP anstatt Socket zu
verbinden, das könnte funktionieren.
Grüße Fuchs
Karl Gaissmaier
> Ein kleiner Beitrag: Nokia E71. Der Nokia Browser schaltet sich
> automatisch um auf capo. Opera Mini Version 10 sagt: es gäbe keine
> Verbindung, auch wenn ich als Adresse https://welcome.uni-ulm.de/cap
nur damit kein falscher Link haften bleibt, richtig ist natürlich:
https://welcome.uni-ulm.de/capo
Viele Grüße
K. Gaissmaier
Karl Gaissmaier
und noch eine Anmerkung:
Jeglicher http-Traffic auf Standard-http-Port 80, der nicht am
Captive::Portal sowieso unauthentisiert durchgeschossen wird,
liefert einen redirect auf https://welcome.uni-ulm.de/capo
Dies gilt insbesondere auch für den einfach zu merkenden URL:
Bedeutet allerdings, dass diese &$§!^#?! Gadget-Browser einen
http-redirect standardkonform auswerten.
Beste Grüße
Charly
Othmar Marti
Opera Mini war auf http gestellt. Mit Socket funktioniert es auch nicht.
Vielen Dank und viele Grüsse,
Othmar Marti
Othmar Marti
Ihren Kollegen empfohlenes Diensthandy. Das &$§!^#?! Verhalten ärgert
mich auch.
Viele Grüsse,
Othmar Marti
Karl Gaissmaier
Am 08.03.2011 07:51, schrieb Othmar Marti:
>...
>> Bedeutet allerdings, dass diese &$ￜ!^#?! Gadget-Browser einen
>> http-redirect standardkonform auswerten.
>>
>> Beste Grￜￜe
>> Charly
> Vielen Dank fￜr die Korrektur des Links. Das Handy ist ￜbrigens ein von Ihren Kollegen empfohlenes Diensthandy. Das &$ￜ!^#?! Verhalten ￜrgert mich auch.
na ja, telefonieren kann es ja auch und der mitgelieferte Nokia Browser funktioniert
auch.
Mein Kollege hat da demnach keinen Fehler gemacht und vor allem ï¿œnderte sich
auch die Technik und die Mï¿œglichkeiten seit Frï¿œhjahr 2009.
Viele Grￜￜe
K. Gaissmaier
Arno Luppold
> Opera Mini war auf http gestellt. Mit Socket funktioniert es auch nicht.
Das wird mit Opera Mini nie funktionieren (ich hatte das Problem auch),
weil Opera Mini schlichtweg keine Webseiten direkt anzeigen kann. Und
den notwendigen Zugang zum Opera-Proxy bekommst du erst nach erfolgtem
Login...
Aber was spricht denn dagegen, Opera Mobile zu nehmen? Der sollte auf
dem E71 doch problemlos laufen?
Grüße
Arno
Harald Losert
Nachdem sowohl mein Gadget als auch ich unbeschadet zurück sind... Spaß
beiseite, war wirklich produktiv und hilfreich der Besuch bei Charly. Auch
wenn das Ergebnis nicht so ganz befriedigend ist, aber ich fasse mal kurz
zusammen, falls sich noch ein WebOS-Nutzer hierher verirren sollte.
Grund für das Problem mit dem CaptivePortal ist wohl eine fehlerhafte
SSL-Implementierung seitens Palm/HP, also der worst case. Nachdem das
feststand hab ich mich heut Abend mal ans googlen gemacht mit dem
Ergebnis, dass sich diese fehlerhafte Implementierung wohl durch alle
Firmware-Versionen bisher zieht und es wohl durchaus bekannt ist, dass
dort mit manchen Servern Probleme bestehen. Soviel zum Thema "bei einem
Business-Gerät wird das schon korrekt implementiert sein"...
Eine Lösung seitens Palm/HP ist also eher nicht in Sicht, von daher wird
man mit dieser Implementierung wohl leben müssen.
Ich vermute mal (ohne dass ich da über das ausreichende Hintergrundwissen
verfüge...), dass diese Implementierung auch mit daran Schuld ist, dass
Cisco AnyConnect ebenfalls seinen Dienst verweigert. Aber da kenn ich mich
dann doch viel zu wenig aus, und irgendwie hab ich heute auch vergessen
das noch kurz anzusprechen.
Aber als Lösung für alle WebOS-Nutzer kann das zukünftige eduroam wohl
gesehen werden, denn sowohl laut Datenblatt, wie auch laut einigen
Berichten im Netz, wird 801.x Enterprise mit den entsprechneden
Protokollen wohl problemlos unterstützt. Ich freu mich drauf :-)
Danke jedenfalls nochmal an Charly für die wirklich schnelle,kompetente
und unkomplizierte Hilfe bei diesem Luxusproblemchen. Jetzt ist zumindest
klar auf welcher Seite der Fehler liegt (Kein Wunder, dass Palm fast
insolvent war und dann von HP gekauft wurde ;-)).
Gruß,
Harry
Am 05.03.2011, 19:13 Uhr, schrieb Karl Gaissmaier
<vorname....@uni-ulm.de.invalid>:
Karl Gaissmaier
Am 08.03.2011 23:08, schrieb Harald Losert:
> Nabend zusammen,
>
> Nachdem sowohl mein Gadget als auch ich unbeschadet zurück sind... Spaß beiseite, war wirklich produktiv und hilfreich der Besuch bei Charly. Auch wenn das Ergebnis nicht so ganz befriedigend ist, aber ich fasse mal kurz zusammen, falls sich noch ein WebOS-Nutzer hierher verirren sollte.
>
> Grund für das Problem mit dem CaptivePortal ist wohl eine fehlerhafte SSL-Implementierung seitens Palm/HP, also der worst case.
wir (speziell Bing, unser kiz Webmaster) ist dran, auch diese Klippe zu umschiffen.
Wir denken, dass es eine fehlerhafte Implementation des TLS Protokolls im
Palm/HP WebOs ist, im Zusammenhang mit 'Name-based virtual hosts'
http://en.wikipedia.org/wiki/Virtual_hosting#Name-based
Eventuell umschiffen wir das, können es aber nicht mit Sicherheit versprechen.
Viele Grüße
Charly
Karl Gaissmaier
> Hallo zusammen,
>
> Am 08.03.2011 23:08, schrieb Harald Losert:
>> Nabend zusammen,
>>
>> Nachdem sowohl mein Gadget als auch ich unbeschadet zurück sind... Spaß beiseite, war wirklich produktiv und hilfreich der Besuch bei Charly. Auch wenn das Ergebnis nicht so ganz befriedigend ist, aber ich fasse mal kurz zusammen, falls sich noch ein WebOS-Nutzer hierher verirren sollte.
>>
>> Grund für das Problem mit dem CaptivePortal ist wohl eine fehlerhafte SSL-Implementierung seitens Palm/HP, also der worst case.
>
> wir (speziell Bing, unser kiz Webmaster) ist dran, auch diese Klippe zu umschiffen.
Bing hat es gelöst, es geht nun auch mit Palm/HP.
Viele Grüße
Charly