Das IAPP dient dazu, beim Roaming eines Clients von einem AP auf den nächsten ein 'Handover' zu bewirken, d.h. der neue AP teilt dem alten übers LAN mit, daß er diesen Client jetzt bedient. Der alte AP trägt daraufhin den Client aus seiner Stationstabelle aus und leitet auch keine Pakete für diesen in seiner Funkzelle mehr weiter - die würden dort ja auch niemanden mehr erreichen und durch Sendewiederholungen den Betrieb in dieser Zelle eher stören.
Der zweite Zweck ist, daß der neue AP ein Broadcast-Paket mit der Quelladresse des Clients (!) ins Netz schickt. Durch dieses Paket lernen im LAN vorhandene Switches, daß die MAC-Adresse des Clients jetzt an einem andere Port zu erreichen ist. Sonst kann es passieren, daß Switches Pakete für diesen Client noch eine Zeit in Richtung des alten APs weiterleiten.
OK, da spinnt wirklich die F-Box - das kann man z.B. an Paketen 1+3 sehen - die Box routet Multicasts zurück in das LAN. Leider scheint das in ihrem Router zu passieren, d.h. die gespiegelten Pakete haben die Quell-MAC-Adresse der F-Box und nicht die des LANCOMs, damit greift die Notbremse nicht, die ich in die 6.06 eingebaut hatte. Werde die wohl noch etwas verfeinern müssen...aber diesen Trace kann man ruhig mal AVM um die Ohren hauen - dieses Verhalten ist definitiv nur als 'kaputt' zu bezeichnen...
Hinweis an den AVM-Support: das LANCOM propagiert die für IAPP benutzte Multicast-Adresse (224.0.1.76) auch per IGMP, damit's in größeren Netzen funktioniert, die Switches mit IGMP-Snooping benutzen. IGMP wird von Routern benutzt, um zu lernen, in welche Netze welche Multicasts geroutet werden sollen - das ist natürlich trotzdem kein Freibrief, Pakete in Netze zurückzuspiegeln, aus denen sie gekommen sind..."