2.1.2 Lan port nicht immer aktiv

Die Netzwerk-Funktionen des Hifidelio, sowie die Anbindung von NAS- und Streaming-Komponenten



Benutzeravatar
aeppler42
Beiträge: 161
Registriert: 26.01.2005 15:35
Wohnort: Rhein-Main Gebiet

Beitrag von aeppler42 »

Also erklären kann ich das nicht. Bin schon froh, dass ich UPnP schreiben kann und bin "totally lost" es zu verstehen. Auf die Idee, dass der Router das Problem ist hat mich die Roku (Soundbridge) Seite gebracht.
http://www.rokulabs.com/support/sbaccesspoints.php

Dort werden zur Soundbrige kompatible Router aufgelistet. Jetzt ist die SB natürlich kein HF Server aber bei mir hat es geholfen.

Ich wollte an sich nur einen Tip geben und nicht die Kommunikationseingeweide zwischen HF und Router verstehen oder erklären.

Grüsse

Aeppler
RESISTOR
Moderator
Beiträge: 1194
Registriert: 27.02.2005 13:05

Beitrag von RESISTOR »

Jetzt habe ich Dein Posting verstanden. Du hattest einfach nur Probleme über Deinen Router eine Verbindung zu einen Streaming - Client herzustellen, der UPnP unterstützt. Dein angegebener Link zu Roku war sehr hilfreich. Steht da doch geschrieben, dass die Soundbridge bei der Verschlüsselung den Betriebsmodi " Open " verlangt und nicht " Shared ". Vielleicht hängen unsere Probleme ja damit zusammen. Meine Verschlüsselung steht auf Shared. Stellt sich für mich die Frage, was der HF erwartet. Kennt sich jemand mit diesen Verschlüsselungseinstellungen aus?

[Edit: Wobei dieses Thema ja jetzt eigentlich unter Netzwerk gehört ]
hifi war gestern, hifidelio ist heute!
Uwe
Moderator
Beiträge: 480
Registriert: 29.03.2005 17:14
Wohnort: 91077 Neunkirchen

Beitrag von Uwe »

für handfeste Infos müsste ich noch mal nachlesen, aber "Standard" ist auf alle Fälle "open" und wird auch empfohlen. Hat nichts damit zu tun, dass dann Dein ganzes Netz "offen" wäre.
Uwe
Moderator
Beiträge: 480
Registriert: 29.03.2005 17:14
Wohnort: 91077 Neunkirchen

Beitrag von Uwe »

so, hab mal noch schnell was zu dem Thema rausgesucht:

WEP definiert dazu zwei Verfahren, die 'Open-System' Authentication (OSA) und die Shared Key Authentication (SKA).
Open System Authentication ist genaugenommen keine Authentifizierung. Jede Station kann sich mit einem Access Point assoziieren
und unverschlüsselte Daten empfangen. Bei der 'Shared-Key' Authentication prüft der Access Point während der Assoziierung einer Funkstation
im Challenge-Response-Verfahren, ob ein gültiger Schlüssel vorhanden ist. Erst nach erfolgreicher Prüfung können angemeldete Stationen Daten übertragen.
WEP definiert keine weiteren Verfahren zum Schlüsselmanagement. Die Schlüssel müssen auf allen Stationen und Access Points lokal vorhanden sein.
In der Regel können allerdings vier verschiedene Schlüssel bei Sender und Empfänger eingetragen werden, was den Schlüsselwechsel erleichtert,
weil zu einer Zeit mehr als ein gültiger Schlüssel zur Decodierung vorhanden sein kann. Der Sendeschlüssel wird jedoch an jeder Station fest vorgegeben.

Der Nachteil beim Shared-Key Verfahren ist, dass der WLAN-Client zunächst ein vom Server geliefertes Datenpaket (128 Bit unverschlüsselt!!) korrekt verschlüsselt zurücksenden muss, um authentifiziert zu werden. Erst danach werden von Ihm verschlüssellte Daten akzeptiert und weitergeleitet. Dadurch steht einem Angreifer allerdings ein Datenpaket in seiner unverschlüsselten und in seiner verschlüsselten Form zur Verfügung, wodurch der Schlüssel selbst angreifbar wird.

Es wird daher grundsätzlich das Open-System-Authentifizierungsverfahren empfohlen.

Solltest also noch mal überlegen, ob Deine Einstellung "Shared" wirklich nötig/sinnvoll ist.
Uwe
Moderator
Beiträge: 480
Registriert: 29.03.2005 17:14
Wohnort: 91077 Neunkirchen

Beitrag von Uwe »

und jetzt verschieb ich das ganze noch nach "Netzwerk" und sperre hier
gigi
Moderator
Beiträge: 2436
Registriert: 27.01.2005 21:11

Beitrag von gigi »

Uwe hat geschrieben:und jetzt verschieb ich das ganze noch nach "Netzwerk" und sperre hier

Aehm, warum sperren?

Hier werden doch mindestens zwei unterschiedliche Phänomene diskutiert:
1.) LAN-Port an der Bridge im HF nicht aktiv (siehe Topic)
2.) Andere Netzwerkprobleme (UPnP, Router, WEP)

Man müsste die meines Erachtens schon etwas besser auseinanderhalten, aber gelöst ist doch keines der Probleme, oder?
RESISTOR
Moderator
Beiträge: 1194
Registriert: 27.02.2005 13:05

Beitrag von RESISTOR »

...ich denke mir mal Uwe wollte den Thread nicht sperren sondern nur unter Bugs beenden, nach Netzwerk verschieben und hier weiterlaufen lassen.Oder? Habe mir deshalb erlaubt, hier wieder zu öffnen.OK?
hifi war gestern, hifidelio ist heute!
RESISTOR
Moderator
Beiträge: 1194
Registriert: 27.02.2005 13:05

Beitrag von RESISTOR »

...und mach auch gleich weiter.
Habe meine Verschlüsselung nun auf Open umgestellt. Bis jetzt hat der HF das Netz als alleiniger Teilnehmer gefunden. Ob das so bleibt, werde ich beobachten und posten.
hifi war gestern, hifidelio ist heute!
Uwe
Moderator
Beiträge: 480
Registriert: 29.03.2005 17:14
Wohnort: 91077 Neunkirchen

Beitrag von Uwe »

gigi hat geschrieben:
Uwe hat geschrieben:und jetzt verschieb ich das ganze noch nach "Netzwerk" und sperre hier

Aehm, warum sperren?

Sorry, war mein Fehler! Ich hatte gestern nicht kapiert, das der Thread unter Bugs und unter Netzwerk ein und der selbe ist! Ich wollte nur den unter Bugs sperren, damit hier unter Netzwerk weiterdiskutiert wird.
dirkU
Beiträge: 7
Registriert: 18.10.2005 22:27

Netgear nix Schuld...

Beitrag von dirkU »

Ich denke auch nicht, dass der Netgear Router schuld ist - zumal ich das Problem solange habe, wie den Fidel (JAN'05). Dazwischen liegen drei Firmware Versionen des Netgear DG834B, z. Zt. die allerneueste 2.10.22.
Mit keiner Firmware gab es je ein Problem mit anderen Geräten, bei jeder jedoch mit dem Fidel ;-)
Vielleicht stimmt ja was nicht mit dem Timing bei den DCHP Anfragen oder so? Ich habe jedenfalls keine Regelmässigkeit entdecken können - allerdings ist mir aufgefallen, dass sich mit FW2.1.2 der Fidel beim Starten meistens aufhängt, wenn der Ethernet Stecker drinsteckt. Ohne Netzwerstecker kein Problem. Mit FW2.1.3 sind die Aufhänger wieder weg, dafür sind die Netzwerkfehler mit ungefähr der gleichen Häufigkeit wieder da.
Ob es da wohl irgendeinen Zusammenhang gibt?
Das Seiende hat sein Sein am Nichtsein seines Gegenteils (Hegel)
gigi
Moderator
Beiträge: 2436
Registriert: 27.01.2005 21:11

Re: Netgear nix Schuld...

Beitrag von gigi »

dirkU hat geschrieben:Mit FW2.1.3 sind die Aufhänger wieder weg, dafür sind die Netzwerkfehler mit ungefähr der gleichen Häufigkeit wieder da.
Ob es da wohl irgendeinen Zusammenhang gibt?

Welche Netzwerkfehler? Ist der Port am Router aktiv? Wenn ja, dann gehört das hier nicht hin (siehe Topic). Wenn nein, hiesse das, das der im Topic beschriebene Fehler (den ich in sehr HW-nah einschätze) sich vielleicht doch durch SW beheben liesse.
unkraut
Beiträge: 22
Registriert: 06.10.2005 21:58
Wohnort: Mannheim

Beitrag von unkraut »

das es am den netgear liegt glaub ich kaum, weil wenn ich das lan kabel ziehe und so den HF starte sind genauso alle lanports am HF tod. die frage ist jetzt ob das so sein soll wenn nix dran hängt?? ich werd mal bei gelegenheit den HF auf 2.1.3 updaten. wenn das immernoch so bleibt dann weiß ich auch nicht mehr weiter. :?
Musikuss
Godfather of Hifidelio
Beiträge: 2040
Registriert: 03.02.2005 12:45
Wohnort: Rheinhessen

Re: Netgear nix Schuld...

Beitrag von Musikuss »

dirkU hat geschrieben:Vielleicht stimmt ja was nicht mit dem Timing bei den DCHP Anfragen oder so? Ich habe jedenfalls keine Regelmässigkeit entdecken können - allerdings ist mir aufgefallen, dass sich mit FW2.1.2 der Fidel beim Starten meistens aufhängt, wenn der Ethernet Stecker drinsteckt. Ohne Netzwerstecker kein Problem.


Das lag daran, dass sich in der Anwendung zwei Threads verklemmt haben (jeder hielt eine Semaphore und wollte die jeweils andere, ein Klassiker), wenn die IP-Adresse zu einem ungünstigen Zeitpunkt zugeteilt wurde. Das Problem wurde in der 2.1.3 behoben.

Mit FW2.1.3 sind die Aufhänger wieder weg, dafür sind die Netzwerkfehler mit ungefähr der gleichen Häufigkeit wieder da.
Ob es da wohl irgendeinen Zusammenhang gibt?


Obwohl man das nicht völlig ausschließen kann, war das Problem der 2.1.2 eigentlich nicht direkt netzwerkspezifisch. Da sich die Threads nicht mehr verklemmen, wüsste ich nicht, wie sich der Zusammenhang noch ergeben könnte.
Verallgemeinerungen sind generell schlecht.
dirkU
Beiträge: 7
Registriert: 18.10.2005 22:27

Re: Netgear nix Schuld...

Beitrag von dirkU »

gigi hat geschrieben:
dirkU hat geschrieben:Mit FW2.1.3 sind die Aufhänger wieder weg, dafür sind die Netzwerkfehler mit ungefähr der gleichen Häufigkeit wieder da.
Ob es da wohl irgendeinen Zusammenhang gibt?

Welche Netzwerkfehler? Ist der Port am Router aktiv? Wenn ja, dann gehört das hier nicht hin (siehe Topic). Wenn nein, hiesse das, das der im Topic beschriebene Fehler (den ich in sehr HW-nah einschätze) sich vielleicht doch durch SW beheben liesse.

Naja, der Port am Router ist OK, der Port am HF jedoch _inaktiv_ (leider hat der Fidel keine Status LEDs am Netzwerk Anschluss).
Der HF holt sich offenbar über DHCP nicht bei jedem Einschalten eine IP Adresse, aber er sagt nicht, warum.
Eine Zeit lang dachte ich, alles sei OK, wenn auch WLAN eingeschaltet ist, das hat sich aber nicht bestätigt.
Gut, ich muss nicht so sehr oft auf den Fidel über Ethernet zugreifen, es wäre aber doch schön, wenn das im Bedarfsfall immer funktionieren würde...;-)
[Edit Uwe: hab die Quotes korrigiert]
Das Seiende hat sein Sein am Nichtsein seines Gegenteils (Hegel)
gigi
Moderator
Beiträge: 2436
Registriert: 27.01.2005 21:11

Re: Netgear nix Schuld...

Beitrag von gigi »

Naja, der Port am Router ist OK, der Port am HF jedoch _inaktiv_ (leider hat der Fidel keine Status LEDs am Netzwerk Anschluss).
Der HF holt sich offenbar über DHCP nicht bei jedem Einschalten eine IP Adresse, aber er sagt nicht, warum.

Ich muss mich wiederholen: Wenn der Port inaktiv ist, hat das doch nichts mit einem evtl. fehlenden DHCP-Request zu tun...
Ich steig' da jetzt nicht mehr durch und halte nochmal fest, dass keiner der hier beschriebenen Fehler bei mir je aufgetreten ist.
Antworten