Fritz Box 7170 sendet UDP Telegrame wieder zurück!

[Mables]

Hallo Zusammen,

nachdem ich schon seit November das Problem an AVM gemeldet habe, aber bis zum heutigen Tag keine Lösung vorhanden ist (ich glaub die wissen selbst nicht was da abgeht) suche ich hier Hilfe!!!

Folgendes Problem hat jede Fritz Box 7170 wenn diese beim Start (Reset oder Netzteil ziehen und wieder einstecken) an einen Switch betrieben wird.

Die Box frägt alle Teilnehmer nach ihren Broadcast Adressen ab und wenn einer dabei ist der die Antwort "IGMP V2 Membership Report" sendet, dann werden alle UDP / Multicast Telegramme wieder zurück gesendet (quasi wie ein Echo).

Wird die Box aber beim Reset ca. 5 min. vom Switch getrennt und erst dann an den Switch angeschlossen so tritt dieser Fehler nicht auf, obwohl die Box die gleichen Abfragen macht und auch die gleichen Antworten der Teilnehmer kommen.

Wer kann mir hier Hilfe oder Unterstützung geben?

Im Anhang ist der Trace den ich mit einem HUB und der Soft "Wireshark" erstellt habe.

In der Zeile 164 ist die IGMP Abfrage der Fritz Box zu sehen und in der Zeile 168 die IGMP Antwort vom Teilnehmer (bei mir Siemens mit der IP Adresse 192.168.178.2).

Ab der Zeile 169 gehen dann die Probleme los und die Fritz Box sendet jedes Telegramm mit einer falschen IP Adresse (bei mir mit der Adresse vom Siemens 192.168.178.2) wieder zurück!!!

Das Ergebnis ist dann eine Telegramm Verdopplung und in Verbindung mit EIB/KNX legt die Fritz Box ein Haus lahm!!!

Also liebe Linux Gemeinde, bitte um Hilfe da AVM nicht im Stande ist!


Viele Grüße
Mables

 

[gandalf94305]

# multid -h
illegal option 'h'
usage: multid multid [options]
options:
  -?                 - print this help
  -f                 - run in forground. (NOTSET)
  -s                 - stop daemon. (NOTSET)
  -v                 - verbose. (NOTSET)
  -p STRING          - Pidfile. ("/var/run/multid.pid")
  -M STRING          - memory debug output. (NULL)
  -S STRING          - script to call when onlinestatus changes. ("/bin/onlinech
anged")
  -t                 - disable simple NTP client. (NOTSET)
  -i                 - disable IGMP proxy. (NOTSET)
  -D STRING          - switch debug logs on. (NULL)
start server:   multid
stop server :   multid -s
#

Ich betreibe die FBF mit "multid -i -v" ;-) Wozu braucht man als normaler Anwender schon IGMP... :gruebel:

--gandalf.

 

[Mables]

Hallo Gandalf,

wie und wo muß ich die Option "Multiip -i -v" einbinden.

Was macht eigentlich die Fritz Box mit der IGMP Abfrage?


Danke im voraus.
Mables

 

[gandalf94305]

multid (nicht multiip) ist ein Prozess in der Fritz!Box und Du solltest zum Abschalten des IGMP-Traffics in /var/flash/debug.cfg auf der FBF folgendes eintragen:

multid -s
sleep 5
killall multid
sleep 5
multid -i

Dies stoppt und startet den multid neu.

--gandalf.

 

[Mables]

Hallo Gandalf,

erst mal DANKE DANKE DANKE für die Lösung!!!
Einfach super, muß man sich mal Vorstellen die bei AVM schicken mir immer noch mails in denen steht ich soll dies und das ausprobieren und ihnen das Ergebnis wieder mailen... Die spinnen doch! Die sollen ihr Zeugs selbst ausprobieren.
Mir scheint als ob die Entwicklung sowieso hier im Forum geschieht und wenns ne fertige Lösung gibt dann übernehmen die die ganze Geschichte einfach und machen daraus Kohle.

Gibt es eine Möglichkeit die "Debug.cfg" quasi als Firmware Update einzuspielen?
So dass ich nach einen echten Firmware Update nicht jedesmal mit Telnet und dem Editor die Debug.cfg editieren muß.

Danke im voraus.
Mables

 

[niemand0815]

also ich muss avm mal in schutz nehmen. eine lösung für das problem ist das ja nicht, der daemon und igmp wird halt abgeschaltet.

wenn sich die box falsch verhält will avm wohl eher den fehler fixen als es einfach abzuschalten ;-)

aber als workaround funktioniert es ja.

achja, und es ist eher andersrum:
nicht avm verdient mit den sachen hier im forum geld, sondern weil avm ein recht gutes gerät entwickelt hat existiert ein grossteil der posts hier im forum überhaupt ;-)

EDIT:
zu deinem trace:
eigentlich macht die box nichts wirklich falsches (siehe weiter unten warum es doch unglücklich ist). das igmp paket hat damit übrigens nix zu tun...

dein siemens teil schickt einen multicast-datenstrom an adresse 224.0.23.12. das ist wohl dein EIB/KNX strom.

die box macht nun nichts anderes als multicast-router zu spielen.
die multicast source ist die siemens kiste. da diese ich auch per igmp bei der box als reciver registriert macht diese nun das was ein multicast router halt so tut:
sie nimmt die ankommenden multicast-pakete und verteilt diese an alle abgerouteten netzwerksegment die angeschlossen sind und diesen strom per igmp angefordert haben (also auch an das segment mit der siemens kiste).

so weit so gut, nur leider ist die implementierung wohl unglücklich gewählt:
denn eigentlich sollte die box multicast pakete niemals an die interfaces zurückliefern von denen sie kommen zumindest gute router machen das so.
leider ist das verhalten des routers in den rfc's nicht festgelegt, so das da jeder sein eigenes süppchen kocht. diese verhalten ist bei consumer(billig)routern aber leider oft anzutreffen
ggf könnte das an einstellungen oder einem bug im zugrundeliegenden linux-kernel liegen.

durch das abschalten des multicast deamons wird übrigens nur das weiterleiten von multicasts unterbunden. somit geht auch upnp z.B. nicht mehr durch die box durch.
so wie andere mutlicasts. könnte gerade beim streaming von medien dann probleme bereiten...

btw:
kann da mal jemand von den linux profis nachschauen woran das verhalten der box liegen könnte? vielleicht muss man ja nur etwas an der kernelconfig ändern oder treiber bzw den multicastdaemon ausschalten.

 

[Mables]

Hallo Niemand0815,

die haben schon mit Absicht Linux auf den Boxen und wissen genau wozu die Freaks im stande sind. siehe DreamBox.

Ich weis noch zu Zeiten des ISA-Bus was die damals für eine scheiss ISDN Karte gebaut haben... da war AVM echt die letzte Firma.

Schau dir doch mal den DS-Mod an, da kommen jetzt auf einmal Firmware von AVM raus, die auch solche Dinge wie Samba und VPN unterstützen.

Aber ist ja egal.
Die Geschichte mit IGMP werden die wohl erst lösen können wenn ein neuer Linux Kernel erscheint, denn bis zur V 2.6.9 ist das Problem noch drin.

Gruß
Mables

 

[niemand0815]

witzig dabei finde ich:

das was die box macht hat mit igmp proxy gar nichts zu tun.

denn dann dürfte es nur die igmp-pakete (membership reports) duplizieren.
(und zwar wenn igmp auf dem upstram interface zusammen mit igmp proxy aktiviert ist)... nicht die multicast pakete selbst.

schon komisch.

 

[Mables]

ich kanns auch nicht erklären, aber auf jeden fall scheint es mit dem IGMP was auf sich zu haben, denn wenns dekativiert ist funzt alles so wies soll.

Gott sei Dank.

Mables

 

[gandalf94305]

@niemand0815, ich kenne keinen vernünftigen Grund, warum die FBF standardmäßig IGMP verwenden oder sogar einen IGMP Proxy haben sollte. Die FBF unterstützt doch nicht mbone oder Ähnliches ;-)

Hast Du mal nachgeschaut, was dieses Protokoll überhaupt tut? Also sehe ich auch keinen Grund, dieses Protokoll in der FBF abzuschalten...

--gandalf.

 

[niemand0815]

natürlich weiss ich was igmp macht.
und warum sie igmp proxy braucht? keine ahnung, war vermutlich im kernel default *g*

also zu igmp und multicast routing (kurzfassung):
igmp ist primär für den einsatz innerhalb von lokalen netzen gedacht. dient zur signalisierung welche geräte an einer bestimmten multicastgruppe teilnehmen wollen.
(sprich: die geräte melden sich per igmp joins bei dem lokalen multicast router an. dieser weiss dann das er multicasts an das entsprechende interface schicken muss wenn diese für die gruppe bei ihm ankommen).
igmp hängt nicht unbedingt mit dem mbone zusammen. es wird in allen multicast enableten netzen eingesetzt.

wenn die box als router zwischen den einzelnen interfaces (lan und wlan z.B.) konzipiert wäre dann bräuchte man multicast routing zwischen den interfaces um z.B. upnp verbindungen zwischen den einzelnen netzen zu erlauben.

somit wäre da ein einsatz als MULTICAST ROUTER mit enabletem IGMP legitim.

warum igmp proxy? naja, ich hab bisher noch keinen sinnvollen einsatz dafür entdecken können......

warum die box multicast router spielt obwohl sie gar nicht die interfaces gegeneinander routet? keine ahnung.
da dies aber wohl potentiell möglich wäre (oder geplant ist) macht das doch irgendwo sinn. zumal es im kernel ja vorgesehen ist.

und offensichtlich, wie du am trace (wenn du ihn "gelesen" hast) siehst routed die box wohl wirklich multicasts (wenn auch nicht so wie man es erwarten würde).

eventuell könnte ja multicast und somit igmp im lan der box für audio/videostraming in zukunft verwendet werden?

who knows.

EDIT:
achja, zum thema igmp proxy:
bei abgesetzem router fürs internet wäre es vielleicht doch sinnvoll, dann aber nur auf dem "WAN" interface welches richtung internet zeigt. eben für mbone.
und auf jeden fall nicht richtung lan.

und ist wirklich sicher das die box kein mbone supported?

 

[gandalf94305]

Genau Und was mbone anbelangt, so halte ich das für sehr unwahrscheinlich, denn das sind doch ganz andere Protokolle... Vielleicht war es wirklich im Kernel einfach mal drin :lach:

--gandalf.

 

[niemand0815]

denk ich auch.

aber wollte nicht arcor oder die t-com mal was mit echtem streaming machen?
(bis zum endgerät per multicast).

bin mir aber nicht sicher was draus geworden ist.
die bisher erhältlichen geräte machen ja unicast soweit ich weiss.