Claus Bartetzko Posted January 10, 2022 Share Posted January 10, 2022 Ich habe einen SAT-IP Server von Telestar im Einsatz und der hat die ganze Zeit seit Installation wunderbar zusammen mit DVBViewer Pro funktioniert. Nun kann ich plötzlich kein Programm mehr empfangen und bekomme beim Programmwechsel immer die gleiche Fehlermeldung: "Für diesen Sender ist kein passendes DVB-Gerät verfügbar" Unter Einstellungen->Hardware->Geräte werden alle 4 Kanäle des SAT-IP-Servers angezeigt und auch ein erneuter Server-Suchlauf findet diesen sofort - trotzdem die Fehlermeldung. Die Wiedergabe vom SAT-IP-Server in VLC über m3u-Liste funktioniert für alle Programme problemlos. support.zip Quote Link to comment
Griga Posted January 10, 2022 Share Posted January 10, 2022 vor einer Stunde schrieb Claus Bartetzko: Nun kann ich plötzlich kein Programm mehr empfangen und bekomme beim Programmwechsel immer die gleiche Fehlermeldung: Plötzlich von alleine passiert das nicht. Welche Änderungen hat es letztlich im System gegeben? Auf die Ursache weist die folgende Fehlermeldung im DVBViewer.log hin: Zitat 10.01.22 20:32:01.422 TRTSPNetworkStream DoOpen no ports 10.01.22 20:32:01.425 TfrmMain AllocateHardware Open failed Bevor er sich mit dem Sat>IP Server verbindet, sucht der DVBViewer freie Ports im Bereich 52000 - 52100 (siehe Optionen -> Hardware -> "DIGIBIT-002BB5:SAT>IP DVB-S X" selektieren -> Einstellungen). Er muss dem Server zwei benachbarte Ports angeben, an die dieser Daten schicken kann. Bei dir findet er jedoch keine freien in dem vorgegebenn Bereich, weil sie jemand bzw. etwas für sich reserviert hat. Bekannt ist dieser Effekt bei Verwendung von Hyper-V: https://www.dvbviewer.tv/forum/topic/65881-fritzbox-6591-mit-sap-ip-für-diesen-sender-ist-kein-passendes-dvb-gerät-verfügbar/?do=findComment&comment=499696 Womöglich hilft bei dir auch, für die virtuellen Netzwerkgeräte unter Optionen -> Hardware einen anderen Portbereich vorzugeben. Quote Link to comment
Claus Bartetzko Posted January 11, 2022 Author Share Posted January 11, 2022 Systemänderungen gab es keine. Aber mein Eindruck ist, daß die Probleme nach dem letzten Windows 10 Update entstanden sind. Hyper-V verwende ich nicht. Habe nun versuchsweise die UDP Ports 52000-52100 in der Windows Firewall freigegeben. Hat aber leider nichts gebracht. Was kann ich noch tun ? Quote Link to comment
Claus Bartetzko Posted January 11, 2022 Author Share Posted January 11, 2022 Jetzt habe ich es hinbekommen. Es lag tatsächlich daran, daß der Default-Portbereich von Windows vorbelegt war. (netsh int ip show excludedportrange protocol=udp) Nachdem ich das im HW-Setup auf 42000-42100 geändert hatte, hat alles wieder wie gehabt funktioniert. Vielen Dank für die Hilfestellung. Quote Link to comment
HaraldL Posted January 11, 2022 Share Posted January 11, 2022 Auch wenn du Hyper-V nicht bewußt verwendest: Neuere WIn10/Win11-Versionen aktivieren Hyper-V für neue Sicherheitsfeatures, Sandbox-Funktionen ohne daß man dies als Anwender mitbekommt. Kann also durchaus durch ein Win-Update aktiviert worden sein. Quote Link to comment
Griga Posted January 11, 2022 Share Posted January 11, 2022 vor 40 Minuten schrieb HaraldL: Neuere WIn10/Win11-Versionen aktivieren Hyper-V für neue Sicherheitsfeatures, Sandbox-Funktionen ohne daß man dies als Anwender mitbekommt. Die Konsequenz wäre, den Standard-Portbereich für Sat>IP im DVBViewer zu ändern, z.B. auf die von @Claus Bartetzko nun verwendeten 42000-42100. Weiß jemand noch mehr darüber? Quote Link to comment
Trill Ian Posted January 12, 2022 Share Posted January 12, 2022 Also die von Windows automatisch vergebenden Ports sind 49152 - 65535. Wenn ihr Kollisionen vermeiden wollt, müsst Ihr im Bereich 10000 - 49151 bleiben (unter 10000 tummeln sich öfters Serverdienste wie RDP oder MySQL. Sind zwar nur einzelne Ports, aber man könnte aus Versehen was treffen und killen). Du kannst natürlich auch Port "0" öffnen und Dir damit ein freies Port dynamisch zuweisen lassen, aber das ist wohl nicht so in Deinem Sinne? Quote Link to comment
Griga Posted January 12, 2022 Share Posted January 12, 2022 vor 22 Minuten schrieb Trill Ian: Du kannst natürlich auch Port "0" öffnen und Dir damit ein freies Port dynamisch zuweisen lassen, aber das ist wohl nicht so in Deinem Sinne? Bei Sat>IP muss der Client dem Server ein freies Port-Paar mitteilen, damit dieser weiß, wo er seine UDP-Daten hinschicken soll. Das Gespräch eröffnet der Client typischerweise via TCP so: Request SETUP rtsp://192.168.128.5/?src=1&fe=1&freq=12402&pol=v&msys=dvbs&sr=27500&fec=34&pids=0,16,50,104,166,1707 RTSP/1.0 CSeq: 1 Transport: RTP/AVP;unicast;client_port=1400-1401 <CRLF> Response RTSP/1.0 200 OK CSeq: 1 Session: 12345678;timeout=60 Transport: RTP/AVP;unicast;client_port=1400-1401 com.ses.streamID: 1 <CRLF> Der erste der client_ports muss geradzahlig sein. Da kommen Video, Audio etc. als UDP/RTP hin. Der nachfolgende Port empfängt UDP/RTCP-Daten (Real-time Transport Control Protocol ), also z.B. die Signalstärke und sonstiges Beiwerk. Um die Ports zu ermitteln, beginnt der DVBViewer mit einem zufällig gewählten geradzahligen Port aus der ersten Hälfte des vorgegebenen Intervalls und führt mit ihm und dem nachfolgenden ungeradzahligen Port eine Operation (Bind) aus, die scheitert, wenn die Ports bereits belegt sind. Ist das der Fall, macht er mit dem nächsten geradzahligen Port weiter, bis das Ende des Intervalls erreicht ist und er mit dem Eintrag "no ports" im Log aufgibt. Wenn Windows sich gleich ganze Portbereiche ab 49152 reserviert, sollten DVBViewer und DMS in Zukunft besser in einen weniger bevölkerten Bereich ausweichen, also z.B. 42000-42100 oder 47000-47100, wie bereits in zwei Fällen erfolgreich angewandt. Das würde dann ab dem nächsten Release für alle neu erzeugten (!) virtuellen RTSP-Netzwerkgeräte gelten. Wenn in dem Bereich einzelne Ports belegt sind, sollte das wegen der vom Client durchgeführten Suche normalerweise nichts ausmachen. Quote Link to comment
Trill Ian Posted January 12, 2022 Share Posted January 12, 2022 (edited) vor 55 Minuten schrieb Griga: Wenn Windows sich gleich ganze Portbereiche ab 49152 reserviert, sollten DVBViewer und DMS in Zukunft besser in einen weniger bevölkerten Bereich ausweichen, also z.B. 42000-42100 oder 47000-47100, wie bereits in zwei Fällen erfolgreich angewandt. Die sind nicht "gleich" reserviert, sie gehören einfach zum "dynamic address range" pool Siehe https://docs.microsoft.com/de-de/troubleshoot/windows-server/networking/default-dynamic-port-range-tcpip-chang kannst Du selber checken mit der Eingabe von "netsh int ipv4 show dynamicport tcp" (bzw udp). kommt sowas bei raus: Protokoll tcp Dynamischer Portbereich --------------------------------- Startport : 49152 Anzahl von Ports : 16384 Ist kein Hexenwerk ? und wurde erst 2008 eingeführt :-))) Und Hyper-V ist nicht "böse" oder macht böse Dinge. Er tut nur das, was SAT-IP vergessen hat: Ports Reservieren beim Start. Im Prinzip arbeiten beide gleich: sie brauchen ein Rückport auf dem Klienten (quasi "passives FTP", nur statisch). Hyper V erzeugt beim Start einfach ein paar Hundert (oder tausend?) Proforma Sockets und bindet sie. Klingt nach massiver Ressourcenverschwendung, ist es aber nicht. Die schlafenden Sockets (bzw deren Threads) werden rausgepaged und fressen kein Brot. Erst, wenn eine Verbindung ankommt, wird der Thread hervorgekramt und angeworfen. Geht schneller, als jedesmal einen neuen Socket anlegen und binden. Ist aber eine Stilfrage (ich mags auch nicht, aber es ist legal). Hyper V wird wohl als erstes 52000 anfordern, da es normalerweise beim Booten erfolgt, wird der wohl noch frei sein zu der Zeit. Für alles, was danach kommt, sind die Ports dann blockiert. Edited January 12, 2022 by Trill Ian Quote Link to comment
Griga Posted January 12, 2022 Share Posted January 12, 2022 vor 46 Minuten schrieb Trill Ian: Die sind nicht "gleich" reserviert, "Wenn Windows gleich ganze Portbereiche ab 49152 ausschließt" wäre präsize formuliert. "Reserviert" oder "belegt" treffen hier nicht ganz zu. Die Fälle, in denen der DVBViewer als RTSP Client mit "no ports" scheitert, häufen sich jedenfalls. Ob nun durch Hyper-V oder sonstige dunkle Machenschaften bedingt, bleibt dahingestellt... hier finden sich Informationen dazu: https://www.fatalerrors.org/a/the-solution-of-win10-port-occupation-problem.html https://www.programmerall.com/article/5309892031/ Die Probleme treten offenbar auch auf, wenn man Docker für Windows verwendet, da dies wiederum Hyper-V aktiviert: https://github.com/docker/for-win/issues/3171 Die ausgeschlossenen Portbereiche lassen sich mit netsh int ip show excludedportrange protocol=udp ermitteln, wie bereits hier beschrieben. Soweit mein aktueller Kenntnisstand nach einer Web-Recherche. Wie auch immer, wir sollten den Portbereich lieber verlassen... Quote Link to comment
Trill Ian Posted January 12, 2022 Share Posted January 12, 2022 (edited) na ja, man braucht "excludedportrange" aber gar nicht, wenn man sich an die üblichen Vorgaben hält: 1-1023 Reserviert für Unix Standard Dienste (nur für "Root" verfügbar) 1024-49151 User Port Range (nicht-root Prozesse wie Datenbanken, Mediaserver, Proxies usw. "general purpose") 49152-65535 Windows Dynamic Port Range (seit 2008/Vista) reserviert für Windows Dienste/Apps Der Artikel da mit Docker und Co ist falsch. Wenn niemand an den Standardeinstellungen von Windows rumgebastelt hat, "wandern" die Ports nicht und belegen auch nicht den unteren Bereich. Ich vermute, er hatte da noch irgendwelchen Kram auf der Kiste, der da nicht hingehört. Wie gesagt, Windows selber macht das nicht. Übrigens kannst Du ganz einfach überprüfen, welche Ports vorbelegt sind: "netstat -an" Da kommen dann Unmengen von Einträgen wie: ... TCP 127.0.0.1:55244 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55245 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55246 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55247 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55248 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55249 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55250 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55251 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55252 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55253 127.0.0.1:8037 WARTEND TCP 127.0.0.1:55254 127.0.0.1:8037 WARTEND ... Ich hab sie nicht durchgezählt, aber es ist schon ein Haufen. Seit W10-21H2 ist der Defender mal wieder etwas schärfer und startet Hyper-V um (??? keine Ahnung, M$ macht da Geheimnisse draus). Bei W11 ist noch schlimmer, da geht gar nix mehr ohne. Allerdings hat man sich das Problem bei SAT-IP schlichtweg selber eingebrockt, es hat niemand daran gedacht, dass bestimmte Ressource belegt sein könnten und somit hat auch niemand im Protokoll gleich die Lösung eingebaut (siehe "passives FTP", da teilt der Klient auch dem Server sein Wunschport mit und FTP stammt noch aus den 60er Jahren des letzten Jahrhunderts.). Nachträglich ist das allerdings leider nicht mehr einzubauen, es setzt vorraus, dass der Klient ERST die Empfangsports (mit #0) öffnet, dann die erhaltene Portnummer ermittelt und an den Server mitsendet. Der weis daraufhin, wohin er zu senden hat. Also, wenn Du nun einfach den Bereich wechselst, ist das Grundproblem nicht beseitigt sondern nur auf einen zukünftigen Termin verschoben. Ach ja, kleine Ergänzung: Hyper-V ist gar nicht "böse". Wie man aus der obigen Liste sehen kann, sind diese Sockets rein lokal (immer nur 127.0.0.1) und auch nur auf V4. Es ist also ausgeschlossen, dass ein Programm im LAN damit Probleme hat. Es würde schon reichen, wenn der Klient sich nicht Adresse IN_ADDR_ANY binden würde, sondern an die reale LAN Adresse. Es passiert also nur, wenn man von derselben Kiste aus versucht zuzugreifen. Edited January 12, 2022 by Trill Ian Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.