Problem mit Netzwerk, WebOS-Insider gefragt / iTunesRemote

Willkommen!

Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.

    Hallo,


    die Kurzfassung:


    Im Webbrowser kann ich URLs aufrufen, alles bestens.
    Ich kann aber keine IPs (wie etwa die Oberfläche der Fritzbox) aufrufen. Ich bekomme dann "Fehler beim Laden der Seite (115)". Die anderen Rechner im Netz haben keine Probleme.


    WebOS und alle Apps auf dem neuesten Stand, jedenfalls behaupten das Preware und die Update-App. Kurzzeitig hatte ich mal den Lighty Web Server installiert zusammen mit Tiddlywiki, ist beides wieder deinstalliert über Preware.


    Gibt es in den Tiefen des WebOS-Linux eine Schraube / eine Konfigdatei, an der es sich zu drehen lohnt?
    Ich würde mir gern den Doktor ersparen, jedesmal ist ein Nachmittag weg... und diesmal auch noch NFS.


    Die Langfassung:


    habe iTunes Remote im Appstore gekauft. Die entsprechenden Helper-Apps von http://hobbyistsoftware.com/itunes geladen und installiert.
    Beim Pairen sehen sich Pre und die Helper-App, zwei der 4 Status-Haken werden gesetzt. Dann aber ist Schluss, die Pre-Software empfiehlt, alle Firewalls auszuschalten. Das sind sie natürlich bereits.


    Ausprobiert mit drei Rechnern, MacOS 10.5, 10.6, WinXP. Die Rechner hängen entweder gemeinsam mit dem Pre am gleichen WLAN-AP (ausprobiert mit einem AirportXpress und einem älteren Dlink) oder über Ethernet am gleichen Switch wie der AP.


    Seltsam ist, dass die Verbindung von iTunes Remote aufgebaut werden kann, wenn ich innerhalb von MacOS das Internetsharing aktiviere und das Macbook, auf dem die Helperapp und das zu steuernde iTunes laufen, damit zum WLAN-AP mache, auf dem sich das Pre einloggt.


    Das Netzwerk selber läuft inkl. Pre, Linux-, Mac- und Windowsrechnern nebst Freigaben seit Monaten und Jahren ohne Probleme, so dass ich grundsätzliche Probleme wie DHCP-Konfig etc. glaube ausschließen zu können.


    Meine These ist, dass irgendwas im Netzwerk-Stack von WebOS die Kommunikation blockiert.


    Hat jemand einen Tip für mich?
    Danke!


    Till

    http://IP-Adresse:Port sollte aber gehen, zumindest bei mir tut es so.
    Wenn man nur die Zahlen (IP) verwendet sollte man vielleicht bedenken das das ein Telefon ist,
    könnte mir vorstellen das da die Intiligenz eingreift ;)


    Ansonsten kann ich mir bei so einem Homenetzwerk nur vorstellen das es mit den internen "Namen"
    hackelt, da ja meist der DNS vom Provider verwendet wird und der kennt ja nicht das interne Netz.
    Aber direckte IP Adressen sollten eigendlich immer gehen (wenn die entsprechende Schnittstelle
    aktiv ist).


    Vielleicht versucht er ja über die Datenleitung zu verbinden, das geht dann natürlich nicht, zum
    Test kannst du in ja in den Flugzeugmodus schicken, dann sollte er wirklich nur wlan nutzen.


    Die andere Möglichkeit liegt dann doch in deinem AP, im Funknetz wird bei dir sowieso wahrscheinlich
    per default abgeschaltet sein das Funk Clients untereinander sharen können. Auf das Lan sollte es aber
    gehen.
    Erster Test währe für mich die Konfigseite vom AP, die solltest du ja in jeden Fall erreichen können (IP).
    Dann kannst du dich ja von dort weitertasten.


    Den Lighty Web Server hab ich auch, das ist ja nur ein Dienst den man selber anbietet, daher, kein Problem.

    Zitat

    Erster Test währe für mich die Konfigseite vom AP, die solltest du ja in
    jeden Fall erreichen können (IP).

    Hast recht - auf die Konfigseite komm ich drauf... hmm dann muss ich doch nochmal am abend zu Hause testen...


    Danke, gruß René

    Nein, weder http://IP-Adresse:Port noch nur IPAdresse. Im Gegensatz zu Rene komme ich auch noch nicht mal auf die AP-Konfigseite. Netzverbindung ist aus + WLAN an; das Telefon geht also garantiert übers WLAN ins Netz.


    Und wenn ich die Configseite des AP über seine IP mit einem Laptop aufrufen kann, der über WLAN dranhängt, sollte das doch auch mit dem Pre gehen, das ebenso dranhängt.
    :verwirrt:

    So, ich muss meine vorige Aussage zurücknehmen - ich komme jetzt mit " IP:Port " auf meinen Squeezecenterserver. Es ging früher definitiv nicht! Die Funktion muss mit einer der letzten Updates dazugekommen sein.


    Gruß René


    PS: ich nehme schon an dass du 1.4.1 drauf hast, oder?

    Die gibt es nicht, weder unter Linux noch Windows.
    Ohne DNS kannst du Adressen mit der IP aufrufen aber nicht mit Namen, mit DNS gehts dann auch mit Namen.
    Eine Einstellung das man nur noch über Namen die Adressen erreicht aber nicht mehr mit der IP eingabe, gibt
    es nicht. Ausnahme sind Virtuelle Server, da zeigt die IP eben nur den Host und die Seiten sind aber nur durch
    eingabe des Namens zu erreichen.
    Wenn du auf deine Konsole kommst kannst du dir ja mal mit "ifconfig" die Adressierung ausgeben lassen, ansonsten
    sehe ich den fehler in deinem Netz, Firewall?

    Zitat von rene_p

    So, ich muss meine vorige Aussage zurücknehmen - ich komme jetzt mit " IP:Port " auf meinen Squeezecenterserver. Es ging früher definitiv nicht! Die Funktion muss mit einer der letzten Updates dazugekommen sein.


    Nein, ganz bestimmt nicht, am Netzwerk gab es keine Änderungen, bis auf das forward auf 1 gesetzt wurde. Das braucht man für Tether, dadurch kann der sich der Pre als Router anbieten.

    Zitat

    Nein, ganz bestimmt nicht, am Netzwerk gab es keine Änderungen


    hmm na dann weiß ich auch nicht. Vielleicht gehts deswegen weil ich den Pre vor einiger Zeit "gedoktort" habe. Ich kann nur sagen dass ich es "damals" desöfteren versucht habe und es nie gegangen ist - jetzt gehts...


    und - bei kodo gehts ja auch nicht, da muss ja irgendwas "im Busch" sein...


    gruß René

    Zitat von opaaladin

    Die gibt es nicht, weder unter Linux noch Windows.
    Ohne DNS kannst du Adressen mit der IP aufrufen aber nicht mit Namen, mit DNS gehts dann auch mit Namen.
    Eine Einstellung das man nur noch über Namen die Adressen erreicht aber nicht mehr mit der IP eingabe, gibt
    es nicht.

    Nixdestoweniger ist das der Effekt hier, und da das "firewalling" sowohl am Airport Express als auch am DLink auftritt, während der IP-Zugriff von einem Lap, der den selben AP benutzt, ohne Probleme funktioniert, sehe ich den Fehler / die Fehlkonfiguration bei WebOS. Oder habe ich einen Denkfehler?

    Zitat

    Wenn du auf deine Konsole kommst kannst du dir ja mal mit "ifconfig" die Adressierung ausgeben lassen, ansonsten
    sehe ich den fehler in deinem Netz, Firewall?

    Habe Terminus installiert; ifconfig bewirft mich mit einer Latte Text. Leider funktioniert hier keine einzige dieser Tastenkombis, so dass ich weder zurückscrollen noch die Ausgabe in eine Datei schreiben lassen kann.


    "ifconfig" auf der Linux Command Line von QuickInstall liefert jenes:


    Da die IP die des Pre-WLAN ist, nehme ich an, der Rest bezieht sich auch aufs Pre. Sehe aber keine Auffälligkeiten.



    Danke für eure Hilfe! :)

    oki, bei soetwas muß man in ruhe schritt für Schritt durch.
    Deine ifconfig sieht für mich auch schlüssig aus, zur erklärung (wenn du es nicht weißt), interessant ist für dich Hauptsächlich die zweite Zeile,

    Code
    inet addr:192.168.0.101 Bcast:192.168.0.255 Mask:255.255.255.0


    IP des Pre ist 192.168.0.101, des Netzwerkes 192.168.0
    Ich gehe deshalb mal davon aus das der Router vermutlich auf 192.168.0.1 ist, also ein http://192.168.0.1 im Pre Browser eingeben und du solltest
    auf die Konfigseite deines Routers kommen.


    Wichtig ist jetzt noch die default route, im WebOSQuickinstall auf der Linuxconsole: route -n eingeben, du solltest dann 4 Zeilen zurückbekommen,
    jeweils 2 für ppp0 (Daten) und eth0 (Wlan), wenn meine Vermutung stimmt gibt es eine Zeile mit

    Code
    0.0.0.0         192.168.0.1     0.0.0.0         UG    2      0        0   eth0


    Ansonsten eben die IP welche in der Spalte Gateway steht.


    Die Namensauflösung (verwendeter DNS) steht unter Linux in /etc/resolv.conf, da steht aber beim Pre 127.0.0.1 (localhost) da dieser Automatisch
    vom PmNetConfigManager gesetzt wird, je nach bedarf (Wlan oder Daten). Den jeweils aktuellen findest du in /tmp/resolv.conf
    Da die Router normal diesen auf sich selbst setzen sollte darin auch die IP des Routers stehen, mit cat /tmp/resolv.conf kannst du da mit QS nachschauen.


    Nächster Test währe meinerseits dann eine Adresse im Inet, also auf dem Pre Browser http://www.nexave.de eingeben und du solltest die Nexave Seite
    aufrufen. Wenn das klappt ist am Pre alles in Ordnung.


    Beim Obigen aufruf (Konfigseite des Routers) bitte auch bedenken das die Portangabe oft nur an einer Schnittstelle nötig ist, meinen Linksys z.b
    erreiche ich aus dem Lan (Kabel) mit http://192.168.20.254:8080 und aus dem Wlan (Funk) http://192.168.1.1 eine Portangabe :8080 schlägt hier fehl,
    :80 würde gehen ist aber unnötig.


    Du hast übrigends auch keine errors, dropped oder collisions in deiner ifconfig ausgabe, was auch nicht darauf hindeutet das da etwas faul währe.
    Probier mal obiges aus und berichte, Netzwerk ist kein Hexenwerk, aber du mußt cool bleiben ;)

    Zitat von opaaladin

    oki, bei soetwas muß man in ruhe schritt für Schritt durch... Probier mal obiges aus und berichte, Netzwerk ist kein Hexenwerk, aber du mußt cool bleiben ;)


    I'm as cool as ice, sir, auf gehts. 8)


    Zitat

    Ich gehe deshalb mal davon aus das der Router vermutlich auf 192.168.0.1 ist, also ein http://192.168.0.1 im Pre Browser eingeben und du solltest
    auf die Konfigseite deines Routers kommen.


    So isses, allerdings kriege ich wie gehabt einen Ladefehler115.


    Zitat

    Wichtig ist jetzt noch die default route, im WebOSQuickinstall auf der Linuxconsole: route -n eingeben, du solltest dann 4 Zeilen zurückbekommen,
    jeweils 2 für ppp0 (Daten) und eth0 (Wlan), wenn meine Vermutung stimmt gibt es eine Zeile mit

    Code
    0.0.0.0 192.168.0.1 0.0.0.0 UG 2 0 0 eth0


    Das ist mein route -n:

    Code
    Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 usb0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.1 0.0.0.0 UG 2 0 0 eth0
0.0.0.0 192.168.0.200 0.0.0.0 UG 40 0 0 usb0


    Zitat

    Die Namensauflösung (verwendeter DNS) steht unter Linux in /etc/resolv.conf, da steht aber beim Pre 127.0.0.1 (localhost) da dieser Automatisch
    vom PmNetConfigManager gesetzt wird, je nach bedarf (Wlan oder Daten). Den jeweils aktuellen findest du in /tmp/resolv.conf
    Da die Router normal diesen auf sich selbst setzen sollte darin auch die IP des Routers stehen, mit cat /tmp/resolv.conf kannst du da mit QS nachschauen.


    Code
    root@palm-webos-device: cat /tmp/resolv.conf
# Autogenerated by PmNetConfigManager. DO NOT MODIFY!!
# Interface eth0
# Priority 2
nameserver 83.169.186.33
nameserver 83.169.186.97


    Das sind die KabelDeutschland-DNS.


    Zitat


    Nächster Test währe meinerseits dann eine Adresse im Inet, also auf dem Pre Browser http://www.nexave.de eingeben und du solltest die Nexave Seite
    aufrufen. Wenn das klappt ist am Pre alles in Ordnung.


    Klappt.


    Zitat


    Beim Obigen aufruf (Konfigseite des Routers) bitte auch bedenken das die Portangabe oft nur an einer Schnittstelle nötig ist, meinen Linksys z.b
    erreiche ich aus dem Lan (Kabel) mit http://192.168.20.254:8080 und aus dem Wlan (Funk) http://192.168.1.1 eine Portangabe :8080 schlägt hier fehl,
    :80 würde gehen ist aber unnötig.


    Ich muss keinen meiner Router auf einem anderen Port als Standard-80 ansprechen, egal, von welcher Schnittstelle ich komme. Probiert hab ichs natürlich trotzdem.


    Zwei Mysterien habe ich beim Rumprobieren noch festgestellt:


    1.) MacOS auf meinem Lap bringt einen Apachen mit, der auf Port 80 läuft. Ruf ich vom Lap oder einem anderen Rechner im Netz aus seine eigene IP auf, dann kriege ich die Site auch zu sehen. Probiere ich das vom Pre (http://IP-vom-Lap) -> Verbindungsfehler.
    Aktivier ich am Mac die Verbindungsfreigabe, so dass der Mac der Router (192.168.2.1) des neuen Netzes ist, und logge ich mich dann am vom Mac aufgespannten neuen WLAN mit dem Pre per DHCP ein, dann kann ich unter http://192.168.2.1 den Mac-Apachen erreichen.


    2.) Vor meinem 192.168.0.x-Netz hängt ein weiteres 192.168.178.x-Netz der Fritzbox, die unsere VOIP-Telefonie macht. Deren Oberfläche kann ich über http://192.168.178.1 erreichen.


    Danke Dir!

    Nur mal auf die Schnelle, ich muß los ;)
    Dein Routing ist interessant, du hast das USB Netz aktiv? Normal bekommst du da zwei Einträge, Daten und Wlan) die letzte ist die die
    verwendet wird. ppp0 (Daten) ist bei dir nicht eingetragen, vermutlich weil du gerade im Flugzeugmode bist.
    Aber deine Anfragen gehen gerade über 192.168.0.200, man beachte das der Router die 200 hat nicht 1.
    Ausserdem hast du zwei aktive Schnittstellen USB und Wlan (usb0, eth0), beide im 192.168.0 Netzwerk, woher soll der Pre den
    wissen welchen weg er nehmen soll.


    Du könnstest als schnellen Test mal die falsche route löschen
    route del default gw 192.168.0.200
    dann sollte er den 192.168.0.1 auf eth0 verwenden.


    Das mit dem DNS ist OK, dachte ich mir schon das du keinen eigenen verwendest, deshalb keine Namensauflösung in deinem privatem
    Netz.

    Zitat

    Du könnstest als schnellen Test mal die falsche route löschen
    route del default gw 192.168.0.200
    dann sollte er den 192.168.0.1 auf eth0 verwenden.


    Das wars nicht.


    Zitat

    Ausserdem hast du zwei aktive Schnittstellen USB und Wlan (usb0, eth0), beide im 192.168.0 Netzwerk, woher soll der Pre den
    wissen welchen weg er nehmen soll.


    Das wars. Über MyTether war das USB-Netz aktiviert. Seit ich es dort ausgeschaltet habe, klappts auch mit den lokalen IPs, und wie gehofft war das auch der Haken, warum iTunesRemote nicht wollte.



    Danke Dir, das hätt' ich ohne doktoren und step-by-step-reinstall der Software nicht gefunden! :thumbup: :thumbup: :thumbup: