Das von Ihnen erfasste Paket enthält eine Port-Control-Anforderung (Port Control Protocol, PCP: IETF-Nachfolger für NAT-PMP-Anschlusszuordnung). Der Client-Port für die angeforderte Zuordnung lautet 9 / TCP. Der Client hat keinen Vorschlag, wie der externe Port aussehen soll, und lässt das vorgeschlagene Feld für den externen Port auf Null gesetzt. IETF RFC 6887, das PCP definiert, macht deutlich, dass Null in diesem Feld "Kein Vorschlag" bedeutet.
Ich denke, wer PCP für diesen Milliarden-Router implementiert hat, hat den RFC falsch verstanden. Sie sehen, in einigen sehr begrenzten und genau definierten Fällen könnte eine Null im Feld OTHER-Port "alle Ports" bedeuten. Wenn die angeforderte Lebensdauer für diese Zuordnungsanforderung gleich Null ist, würde ein Null-Client-Port bedeuten: "Alle Zuordnungen für alle Ports auf dieser Client-IP-Adresse löschen".
Aber auch im Feld für den vorgeschlagenen externen Port bedeutet Null immer "Kein Vorschlag". Es soll niemals "alle Ports" in diesem Bereich bedeuten.
Es scheint also ziemlich klar zu sein, dass Sie einen PCP-Fehler in diesem Milliarden-Router gefunden haben.
Eine andere seltsame Sache ist hier der Client-Port. Traditionell ist 9 / TCP der discard
Port des Dienstes, aber der discard
Dienst ist veraltet. Daher bin ich mir nicht sicher, wer ihn noch ausführen wird oder warum irgendetwas eine Portzuordnung für ihn anfordert.
Warum mDNSResponder diese Anfragen sendet, liegt einfach daran, dass mDNSResponder auf macOS als PCP / NAT-PMP / UPnP-Dämon fungiert und zusätzlich zu den üblichen Aufgaben von mDNS, DNS-SD und DNS-Resolver. Wenn ein Prozess unter macOS das System dazu veranlasst, ein Port-Mapping vom Router anzufordern, ist es immer die Aufgabe des mDNSResponder, die eigentlichen Port-Mapping-Anforderungspakete zu erstellen und zu senden.