Jump to content

Kein Empfang mehr von SAT-IP Sendern


Claus Bartetzko

Recommended Posts

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

Link to comment
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.

 

Link to comment

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 ?

Link to comment

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.

Link to comment

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.

 

Link to comment
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?

 

Link to comment

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?

 

Link to comment
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.

 

Link to comment
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 by Trill Ian
Link to comment
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...

 

Link to comment

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 by Trill Ian
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...