udp multicast support in fhem

[justme1968]

@rudi: ich bin gerade dabei mdns für fhem zu bauen. im ramen dessen sind wir auch auf multicast im allgemeinen zu sprechen gekommen. aktuell gibt es 5 module die alle IO::Socket::Multicast verwenden. das hat leider den nachteil das es ein externes perl modul ist das auch noch eine c abhängigkeit hat und sich nicht immer so einfach installieren lässt. bei mir geht es z.b. mit einem aktuellen mac os (mit oder ohne homebrew) nicht out of the box. ausserdem gibt es bei einem externen modul den nachteil das sich jeder selbst dum das zusammenspiel mit fhemfork kümmern muß.

ich habe vorhin im prinzip eine reine perl varante von udp multicast zum laufen bekommen. ich denke das wäre auf dieser basis ein gute möglichkeit udp multicast ohne externe abhängigkeiten direkt in fhem einzubauen.

ich würde TcpServerUtils.pm für den server teil (d.h. primär empfangen und eventuell antworten) und DevIO für den client teil (d.h. primär senden und eventuell die antwort darauf empfangen) als passend erachten.

spricht aus deiner sicht etwa dagegen? wenn nein: ich würde demnächst einen vorschlag machen.


ps: zum mdns modul: die routine die die mdns antworten parsed ist mehr oder weniger kompatibel zu routine die du für HttpUtils_gethostbyname gebaut hast (ist ja das gleiche message format ). ist aber allgemeiner (d.h. kommt mit mehr record typen und mit mehreren records pro message zurecht) wäre es eventuell sinnvoll nur eine solche routine zu haben? eigentlich gilt das auch für das zusammenbauen der query. eventuell könnte man auch einen dns cache gemeinsam nutzen.das hätte den nebeneffekt das man überall wo HttpUtils_gethostbyname verwendet wird auch .local adressen angeben könnte. das geht aktuell nicht. ich weiss aber nicht ob sich das vereinheitlichen lohnt.

[rudolfkoenig]

spricht aus deiner sicht etwa dagegen?

Gar nichts.
Ich ueberlege, ob es nicht sinnvoll ist die beiden Hilfsmodule so zu erweitern, dass man weitere Protokolle nachladen kann.
Aber vielleicht fangen wir erstmal monolitisch an.

Ich habe auch nichts gegen einen universelleren noblocking-gethostbyname, gerne ausgeloest aus HttpUtils.pm.

[erwin]

Hi Rudi,
ich kann ein snipped anbieten zu noBlockning dns...
in define:

Code Auswählen Erweitern

                if ($host !~ /$PAT_IP/ix) { # not an ip-address, lookup name
=pod
                        # blocking variant !
                        my $phost = inet_aton($host);
                        return "KNXIO_define: host name $host could not be resolved" if (! defined($phost));
                        $host = inet_ntoa($phost);
                        return "KNXIO_define: host name could not be resolved" if (! defined($host));
=cut
                        # do it non blocking! - use HttpUtils to resolve hostname
                        $hash->{PORT} = $port; # save port...
                        $hash->{timeout} = 5; # TO for DNS req.
                        $hash->{DNSWAIT} = 1;
                        my $KNXIO_DnsQ = HttpUtils_gethostbyname($hash,$host,1,\&KNXIO_gethostbyname_Cb);
                }

                else {
                        $hash->{DeviceName} = $host . q{:} . $port; # for DevIo
                }
der callback:

Code Auswählen Erweitern

### called from define-HttpUtils_gethostbynam when hostname needs to be resolved
### process callback from HttpUtils_gethostbyname
sub KNXIO_gethostbyname_Cb {
        my $hash  = shift;
        my $error = shift;
        my $dhost = shift;

        my $name  = $hash->{NAME};
        delete $hash->{timeout};
        delete $hash->{DNSWAIT};
        if ($error) {
                delete $hash->{DeviceName};
                delete $hash->{PORT};
                Log3($name, 1, "KNXIO_define: hostname could not be resolved: $error");
                return  "KNXIO_define: hostname could not be resolved: $error";
        }
        my $host = ip2str($dhost);
        Log3($name, 3, "KNXIO_define: DNS query result= $host");
        $hash->{DeviceName} = $host . q{:} . $hash->{PORT};
        delete $hash->{PORT};
        return;
}

und dann etwas später:

Code Auswählen Erweitern

### called from define - after init_complete
### return undef on success
sub KNXIO_openDev {
              ..........
               if (exists $hash->{DNSWAIT}) {
                $hash->{DNSWAIT} += 1;
                if ($hash->{DNSWAIT} > 5) {
                        Log3 ($name, 2, "KNXIO_openDev: $name - DNS failed, check ip/hostname");
                        return; #  "KNXIO_openDev: $name - DNS failed, check ip/hostname";
                }
                InternalTimer(gettimeofday() + 1,\&KNXIO_openDev,$hash);
                Log3 ($name, 2, "KNXIO_openDev: waiting for DNS");
                return; # waiting for DNS
        }
Das müsste man natürlich "generisch/universell" machen....

Ad. Multicast Client: das hab ich dzt. via DevIo: FHEM:DEVIO:$devname:$port gelöst, allerdings unter Verwendung von IO:Socket:Multicast....
l.g. erwin

[rudolfkoenig]

@erwin: ich sehe den Codestueck als Beispielaufruf fuer HttpUtils_gethostbyname, und nicht als Erweiterungsvorschlag. Irre ich mich?

[justme1968]

der angehängte patch erweitern TcpServerUtils.pm um die möglichkeit udp multiucast zu empfangen. bitte noch nicht einchecken . der code für ipv6 ist zwar schon da, aber noch ungetestet.


@erwin: vielleicht magst du mal schauen ob das in dieser art zu deinem modul passen würde.

verwendet wird es so:

• das socket mit gesetztem optionalen vierten paramter von TcpServer_Open erzeugen:
  d.h. im define oder sonst wo mit my $ret = TcpServer_Open($hash, '5353', '0.0.0.0', 1); initialisieren. statt der 0.0.0.0 kann man auch die multicast adresse angeben, ich bin mir nicht sicher was richtiger ist und ob es einen unterschied macht. funktionieren tut bei mir beides.


• TcpServer_Open schaltet automatisch den loopback mode aus.
  d.h. man empfängt seine eigenen daten nicht. ich vermute das ist der normalfall.
  mit TcpServer_SetLoopbackMode($hash,[0|1]); kann man das ändern wenn man es braucht.


• mit TcpServer_MCastAdd die multicast adresse zum socket explizit hinzufügen:
  z.b.: TcpServer_MCastAdd($hash,'224.0.0.251');
  erst ab jetzt bekommt man auch tatsächlich daten.


• im (device) hash wird für jedes udp packet die ReadFn aufgerufen.
  dort kann man mit TcpServer_MCastRecv dann die empfangenen daten abholen:
  my($peer_host, $peer_port) = TcpServer_MCastRecv($hash,$data,$length);
  
  alternativ kann man auch die low leven routinen direkt aufrufen:
  
  • my $sockaddr = $hash->{SERVERSOCKET}->recv($data, 4096);
    der empfang geht über SERVERSOCKET, nicht wie bei tcp über CD, es wird auch kein accept verwendet
  • aus $sockaddr kann man sich die gegenstelle zum udp packet holen falls man die braucht:
    my ($peer_port, $addr) = Socket::sockaddr_in($sockaddr);
    my $peer_host = inet_ntoa($addr);
    
    


• eigene daten sendet man mit TcpServer_MCastSend:
  TcpServer_MCastSend($hash,$data[,$host[,$port]]);
  hier bei wird der port aus dem TcpServer_Open und die adresse aus TcpServer_MCastAdd verwendet. alternativ kann man beides auch beim aufruf mitgeben.


• mit TcpServer_MCastRemove kann man die multicast adresse auch wieder vom socket entfernen:
  z.b.: TcpServer_MCastRemove($hash,'224.0.0.251');
  das socket empfängt dann keine daten für diese adresse mehr.


• mit wechselweisem TcpServer_MCastAdd und TcpServer_MCastRemove kann man auch zeitweise zwischen empfangen und ignorieren hin und her wechseln. z.b. als reaktion auf disable.


• mit TcpServer_Close($hash); das ganze am ende z.b. in der UndefFn wieder zu machen.

[erwin]

HI,

@Rudi:
...Ist ein Implementations-Beispiel, da hab ich vermutlich deinen Satz falsch verstanden...

Ich habe auch nichts gegen einen universelleren noblocking-gethostbyname, gerne ausgeloest aus HttpUtils.pm.

@Andre:
mache ich gerne, wird allerdings (urlaubsbedingt) ein paar Tage dauern...
l.g. erwin

[erwin]

Hi Andre!
Erstes Feedback:
Multicast - read: funktioniert !
Multicast - write: ich muss im TcpServer_Open die richtige MC-addresse (nicht '0.0.0.0') angeben, sonst funktioniert das $hash->{SERVERSOCKET}->send($msg) NICHT, auch nicht mit $hash->{SERVERSOCKET}->send($completemsg,0,'244.0.x.y')
Ich muss jetzt allerdings noch error-recovery testen, und etliches an code-cleanup machen....
...ich hab das perl-multicast modul noch nicht ausgebaut, hoffentlich spielt das mir keinen Streich....
Schaut gut aus, Danke!
erwin

[justme1968]

du hast recht. das multicast senden hatte ich noch garnicht probiert. damit wäre dann auch der unterschied beim open geklärt .

für mdns hatte ich das ganze schon tagelang laufen und es hat stabil funktioniert. wenn das bei dir auch weiterhin stabil funktioniert und niemand mehr eine idee für änderungen hat könnte rudi diesen teil dann eigentlich übernehmen.

[erwin]

Hi Andre,
eine Kleinigkeit hab ich noch:
in sub TcpServer_MCastRemove das

Code Auswählen Erweitern

readingsSingleUpdate($hash, "state", "Multicast listen", 0); auf

Code Auswählen Erweitern

readingsSingleUpdate($hash, "state", "Multicast disabled", 0); oder ähnlich ändern.
Warum die ganzen readingsSingleUpdate ohne event definiert sind erschließt sich mir nicht, aber Rudi hatte da wohl seine Gründe.
Noch was (für mich) kurioses:

Code Auswählen Erweitern


               $ret = TcpServer_Open($hash, $port, '224.0.23.12', 1); # funktioniert
               $ret = TcpServer_Open($hash, $port, $host, 1); # funktioniert NICHT !!!
               $ret = TcpServer_Open($hash, $port, "$host", 1); # FUNKTIONIERT !!!
               .....
                $ret = TcpServer_MCastAdd($hash,$host);
               ....
# und zwar kommt der Fehler erst beim Versuch zu schreiben:
              $ret = $hash->{SERVERSOCKET}->send($completemsg);
# und zwar: send: Cannot determine peer address at ./FHEM/00_KNXIO2.pm line ....
# es hilft auch nicht die Addresse im send mitzugeben....

Allerdings kommts mir auf ein paar Hochkommas mehr nicht an 
ich möchte auch noch das IO::Socket::Multicast ausbauen und testen, ob es dann noch immer funktioniert....
l.g.erwin

[justme1968]

ich hab es auf "Multicast removed" geändert. disabled ist in fhem ja normalerweise etwas anderes.

das es mit $host ohne anführungszeichen nicht geht liegt vielleicht daran das perl versucht die adresse als zahl zu interpretieren. schau mal ob es mit "".$host geht. dann würde ich das direkt in die routine einbauen.

[erwin]

Das mit den Anführungszeichen ist offensichtlich eine Fehlinterpretation von mir!!!
Es funktioniert auch ohne !!!!

Was mich in die Irre geführt hat: Es gibt unmittelbar nach einem shutdown/restart ein Zeitfenster (etliche Sekunden), wo ein write schiefgeht. - mit der besagten Message- und FHEM damit abschmiert!
Ob es ein wirklich ein Zeitfenster ist oder ob es damit zu tun hat, dass zuerst ein Receive passieren muss, weiss ich noch nicht... (irgendwo hab ich gegoogld, das send auf die peeraddr des letzten receive geht...)

Code Auswählen Erweitern

2022.03.03 19:24:47.718 0: Server started with 14 defined entities (fhem.pl:25644/2022-02-06 perl:5.032001 os:linux user:fhem pid:21068)
2022.03.03 19:24:47.805 3: KNXIO_openDev: device myKNXIO_R opened
2022.03.03 19:24:47.843 5: KNXIO_openDev: M, 224.0.23.12, 3671, reopen=0
2022.03.03 19:24:47.843 2: KNXIO_openDev: myKNXIOTest 224.0.23.12 3671
2022.03.03 19:24:47.844 3: myKNXIOTest: port 3671 opened
2022.03.03 19:25:23.247 5: KNXIO_write: started
2022.03.03 19:25:23.247 5: KNXIO_write: sending w0a00900931917
2022.03.03 19:25:23.248 5: KNXIO_Write: str/size/acpi/src/dst= 34/4/128/323533/3230343839
send: Cannot determine peer address at ./FHEM/00_KNXIO2.pm line 556.
2022.03.03 19:25:23.750 1: Including fhem.cfg
.....

In diesem Beispiel sind es ca. 30 sec nach dem port open....
l.g. erwin

[justme1968]

ich bin noch nicht dazu gekommen das senden selber zu testen.

ich bin aber sicher das du immer die version mit drei parametern, also

Code Auswählen Erweitern

$hash->{SERVERSOCKET}->send($data,0,'244.0.x.y') verwenden musst.

die variante ohne adresse geht wenn überhaupt nur ab dem zweiten mal und verwendet automatisch die adresse aus dem vorherigen send mit adressangabe.

die zeitabhängigkeit die du siehst kann ich mir nicht erklären, ich vermute das ist eher ein seiteneffekt von irgendetwas anderem.

[erwin]

Hi Andre,
das mit der Zeitabhängigkeit ist FALSCH!
Richtig ist, das zuerst ein receive kommen muss, damit die peeraddr. definiert ist! Und das war unmittelbar nach einem FHEM restart nicht der Fall, daher die Verwirrung!
Ich kann mich auch nicht darauf verlassen, dass vom KNX-Bus irgendwann eine msg (receive) kommt, der KNX-Router/deamon ist in diesem Fall der Server und FHEM der Client.
Allerdings funktioniert dein Vorschlag auch nicht, das hatte ich schon probiert...

Code Auswählen Erweitern

$hash->{SERVERSOCKET}->send($data,0,'244.0.x.y')
hab etliches versucht, die peeraddr vor dem send zu setzen, zb.

Code Auswählen Erweitern

$iaddr = inet_aton('224.0.23.12');
$hash->{SERVERSOCKET}->bind($iaddr);
$hash->{SERVERSOCKET}->send($data,0,$iaddr)
allerdings ohne Erfolg....

[erwin]

Hi Andre,

scheint, dass ich das write gelöst habe:

Code Auswählen Erweitern

my $paddr = Socket::sockaddr_in($port, inet_aton($host));
$ret = $hash->{SERVERSOCKET}->send($completemsg,0,$paddr);
so funktioniert das write, das hat etwas gedauert, bis ich durchschaut hab, wie $paddr aussehen muss....

Aus meiner Sicht spricht nichts dagegen, die TcpServerUtils einzuchecken!
l.g. & Danke erwin

[justme1968]

ah. das klingt gut.

ich denke ich baue noch so etwas wie TcpServer_MCastSend ein und mache dann den kompletten patch mit doku für rudi fertig.

[erwin]

ich baue noch so etwas wie TcpServer_MCastSend ein...

Sehr gut,
falls es was zu testen gibt, bitte darum!

[justme1968]

wenn du magst probier mal die angehängte version.

TcpServer_MCastSend($hash,$data) sendet an den port aus dem TcpServer_Open und die adresse aus TcpServer_MCastAdd.

optional kannst du auch noch nach $data aber auch adresse (und port) noch mit angeben.

[erwin]

ja, die Version ist ok!
l.g. erwin

[justme1968]

@erwin: ich habe analog zum TcpServer_MCastSend auch noch ein TcpServer_MCastRecv eingebaut das peer host und peer port auch für ipv6 ermittelt und zurück liefert.

@rudi: ich habe die aktuelle version des patch ganz oben (https://forum.fhem.de/index.php/topic,126290.msg1209591.html#msg1209591) angehängt und dort die doku komplettiert. da es bisher keine explizite doku für die TcpServerUtils könnte man den teil auch ins wiki stecken. oder fällt dir etwas besseres ein?

[erwin]

@Andre,

Die _MCastRecv($$$;$) funktioniert so nicht:
1) es fehlt:

Code Auswählen Erweitern

my $name = $hash->{NAME};
  my $sock = $hash->{SERVERSOCKET};
2) es werden die rx-daten nicht returned!

Mir ist nicht klar, wozu du in der routine peerhost,peerport brauchst....
l.g. erwin

[justme1968]

danke. keine ahnung was da beim diff schief gegangen ist. hab es oben repariert.

es kommt auf das protokoll und die anwendung an ob man peer host und port braucht.

beim plex modul senden alle player ihre aktuelle abspielposition per multicast ins netz und nur am peer host kann man feststellen um welchen player es sich handelt da der absender nicht teil der eigentlichen nachricht ist, bei mdns kann man z.b. am absenden port der gegenseite feststellen ob es eine voll umfänglich implementierung ist (5353) oder eine abgespeckte (alle anderen ports) da im rfc festlegt ist das nur eine komplette implementierung 5353 auch als sende port verwenden darf.

[erwin]

Ok, so funktionierts, ich war nur etwas verwirrt, weil ich (ohne nachzudenken...) erwartet hatte, dass die rx-daten returniert würden.
Danke für die Erklärung, das macht dann Sinn. Ich muss überlegen, ob ich den peerhost evtl. auch auswerten soll....
Danke Erwin

[rudolfkoenig]

@rudi: ich habe die aktuelle version des patch ganz oben (https://forum.fhem.de/index.php/topic,126290.msg1209591.html#msg1209591) angehängt und dort die doku komplettiert.

Ich habe den Patch mit leichten Aenderungen uebernommen:
- TcpServerUtils_Initialize entfernt
- die %opts Initialisierung angepasst, damit es fuer die bisherigen Protokolle garantiert nichts geaendert wird. Ich habe angenommen, dass fuer $multicast kein Unterschied zwischen undef und 0 gibt.
- Zeilen auf 80 Spalten umformatiert. Etwas irritierend ist die im Kommentar 4-mal gestellte gleiche Frage.

da es bisher keine explizite doku für die TcpServerUtils könnte man den teil auch ins wiki stecken. oder fällt dir etwas besseres ein?

Ich habe die obern erwaehnte Doku mit einem Hinweis auf dem Forumsartikel am Ende des Moduls zwischen =pod und =cut eingefuegt.
Wird entfernt, falls wir was Besseres gefunden haben.

[CoolTux]

Könnt Ihr Euch bitte einmal diesen Post anschauen.

https://forum.fhem.de/index.php/topic,126818.msg1214020.html#msg1214020

[rudolfkoenig]

Bessere Logs gibts hier: https://forum.fhem.de/index.php/topic,126789
Kurz: mit dem perl, was debian wheezy ausliefert, kann man TcpServerUtils.pm nicht laden.

Wheezy ist aus 2013, letzter Update aus 2016.
Perl 5.16 (aus 2012) enthaelt etliche der benoetigten Konstanten aus Socket.pm nicht, 5.18 (aus 2013) hat sie aber, soweit ich es beurteilen kann.
Da ist die Diskussion wieder: welche perl-Version ist eine Voraussetzung fuer "core FHEM".

Das Problem kann man vertagen, wenn man die Multicast-Routinen in eine separate Datei auslagert.
Vorteile:
- fachkundiger Maintainer
- Multicast brauchen die meisten Benutzer nicht.
- das "wheezy" Problem ist geloest.

Meinungen?

[Beta-User]

Meinungen?

Vielleicht unpopulär, aber m.E. sollten wir es mit dem support für "uralt-OS-Installationen" nicht übertreiben. Wer unbedingt (!) FHEM up-to-date halten will _und_ ein Uralt-OS behalten, muss halt perlbrew&Co bemühen. (Was aber möglicherweise dann wieder nicht gegen uralt-SSL-Versionen usw. hilft...)

Schon alleine, um "update-Muffel" etwas zu animieren, mit einer gewissen (2-3-jährlichen...!) Regelmäßigkeit mal die erforderlichen Wartungsarbeiten anzugehen. Die nächste Meldung, die von solchen Kandidaten dann nämlich kommt, ist "SD-Karte ist abgekachelt..."

(Das bedeutet nicht, dass man nicht die Option nutzen könnte, die Routinen in libraries auszulagern)

[justme1968]

wer auf der alten os version bleiben möchte soll auch auf der alten fhem version bleiben.

laut statistics betrifft es scheinbar sehr wenige anwender. und ich würde sagen es sind jetzt schon weniger als multicast nutzer. und bei letzterem kommen ganz sicher noch welche dazu.

ich würde die routinen eigentlich gerne zusammen lassen. auch wenn die überlappung klein ist funktionieren sie ja nur miteinander und verwenden die gleichen internals.

wie wäre es das Initialize wieder zu aktivieren, per eval zu prüfen ob multicast vorhanden ist und nur dann auch anzubieten? in verbindung mit einer möglichkeit das aus dem eigenen code auch abzufragen könnte man das dann später auch auf andere features ausdehnen. z.b. json und xml.

ssl wird ja auch per eval getestet und hat im prinzip das gleiche problem.

[CoolTux]

Ich bin Andres Meinung. Ich finde die Leute sollten anfangen ihre Systeme zu erneuern. Mittlerweile bin ich auch so das ich die Leute "zwinge" auf wenigstens Perl 5.18 zu gehen. Besser wäre 5.28.

Wir sollten empfehlen die TcpServerUtils.pm vom update aus zu schließen wenn sie auf ihrem alten System bleiben wollen.

[Beta-User]

Wenn, dann sollte man ein 6.1-legacy-deb mit unmittelbarem Stand vor dem update der TcpServerUtils.pm fertig machen, das dann _keine_ update.pm enthalten sollte ...

Kern-Module nur teilweise zu aktualisieren, funktioniert erfahrungsgemäß eine Zeitlang, bis es knallt. Wer so eine Murmel meint fahren zu müssen, dem sollte man nicht versuchen zu vermitteln, dass das eine Dauer-Lösung wäre, die mit minimalst-invasiven Mitteln langfristig funktioniert.

Just my2ct.

[rudolfkoenig]

wie wäre es das Initialize wieder zu aktivieren, per eval zu prüfen ob multicast vorhanden ist und nur dann auch anzubieten?

Ich wuerde mich freuen, wenn wir eine optionale Version hinkriegen wuerden.
Ich kann auch anbieten, das selbst zu machen, brauche aber dafuer einen Testfall.

[erwin]

Ich habe den Verdacht, daß das Problem am schon am IPV6 liegt, (und an den Konstanten, die dort definiert sind...)
jedenfalls zeigt sich bei mir ein ähnlicher Fehler mit einer simplen test.pl, die ein new versucht...

Code Auswählen Erweitern

my $hash->{SERVERSOCKET} = IO::Socket::INET6->new(%opts);
Can't locate object method "new" via package "IO::Socket::INET6" (perhaps you forgot to load "IO::Socket::INET6"?) at ./testMC.pl
und es gibt kein INC IO::Socket::INET6 auf dem system!
System:

Code Auswählen Erweitern

cat /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"
ID=raspbian
ID_LIKE=debian
ANSI_COLOR="1;31"
perl version = 5.14

...ich hab eine alte sd-card herausgekramt und auf einem pi-1 gestartet....
Die folgenden Konstanten werden aufgelöst:

Code Auswählen Erweitern

Socket::IPPROTO_IP
Socket::IP_MULTICAST_LOOP
Socket::IP_ADD_MEMBERSHIP
Socket::IPV6_ADD_MEMBERSHIP
Socket::IPV6_MULTICAST_LOOP
Socket::IPPROTO_IPV6
Aber diese NICHT:

Code Auswählen Erweitern

Socket::IPV6_JOIN_GROUP
Socket::IPV6_LEAVE_GROUP
Falls ich was testen soll, jederzeit! (Auf dem Ding läuft allerdings kein FHEM!)
l-g- erwin

[erwin]

Ad: TcpServerUtils auf wheezy....
So, oder so ähnlich könnte es gehen... Ist zwar nicht wirklich elegant aber compiliert auf wheezy und buster.
IPV6 kann ich nicht testen!
l.g. erwin

[rudolfkoenig]

@erwin: konntest Du deine Aenderungen testen? Eine initialize Funktion wird bei "use TcpServerUtils.pm" nicht aufgerufen.

Ich habe jetzt bei mir perl-5.16.3 installiert (ist gar nicht so trivial, gcc-11 uebersetzt sie nicht mehr, ich musste erst gcc-9 besorgen), und TcpServerUtils.pm solange bearbeitet, bis ein fhem.cfg mit telnet und FHEMWEB gestartet werden konnte.

Waere gut, wenn jemand Multicast mit der angehaengten Datei testet, dann wuerde ich das einchecken.

[erwin]

@Rudi: ich hab jetzt dein Modul getestet, naja Testen ist der falsche Ausdruck-
Unter wheezy hab ich nicht mehr machen können, als ein use TcpServerUtils -  und ein TcpServerOpen - mit Hilfe einer test.pl
Im Gegensatz zur SVN Version kompiliert das Modul fehlerfrei. - sprich FHEM sollte damit nicht mehr bei einem use... abstürzen. Ob multicast funktionell ist unter wheezy- sicher nicht!
das open steigt aus mit der FehlerMeldung:

multicast not supported without SO_REUSEPORT

, weil  &SO_REUSEPORT nicht definiert ist, und das ist gut so!

Im Prinzip gehts um diese beiden Variablen aus meinem diff, die untere wheezy nicht definiert sind, und einen fatal error (Bareword) beim kompilieren machen. Du hast jetzt konsequenterweise alle "predefined".

Funktionstest (mit IPV4) -multicast mit FHEM hab ich auf Buster gemacht. - Evtl. könnte das noch wer anderer verifizieren. Mit IPV6 kann ich nicht dienen...
Ich würde die Log - msg weglassen/ändern, weil die kommt ja jedesmal wenn wer use TcpServerUtils schreibt und gar nichts mit multicast oder IPV6 im Sinn hat - unter wheezy.....(Vorschlag: "you are using an outdated operating system, this function ist not supported.." 
l.g. erwin

[rudolfkoenig]

Ich habe diese Version eingecheckt, ohne die Log-Ausgabe.

, weil  &SO_REUSEPORT nicht definiert ist, und das ist gut so!

Diesen Teil habe nicht verstanden: wer verwendet SO_REUSEPORT, wieso koennte man das nicht auch setzen, und warum ist das gut, wenn wheezy kein multicast kriegt?

[erwin]

Diesen Teil habe nicht verstanden

Das hat Andre eingeführt, multicast braucht reuse-port support (von perl bzw. OS) falls das nicht da ist, schlägt ein MC-open fehl!
Ich hab kein Problem damit, das MC auf wheezy nicht funktioniert (das hat es bisher auch nicht gegeben), was du jetzt gemacht hast verhindert  nur das fehlschlagen des use unter wheezy - Soll heissen, was bisher funktionierte, geht auch weiterhin! Neue Funktionen für wheezy zu implementieren halte ich für kontraproduktiv.
Danke für die Unterstützung!
erwin