Wenn Android 13 eine statische IP festlegt, führt dies dazu, dass das kabelgebundene Netzwerk ständig die Verbindung trennt und wieder herstellt. Analyse und Lösung

Artikelverzeichnis

Wenn Android 13 eine statische IP festlegt, führt dies dazu, dass das kabelgebundene Netzwerk ständig die Verbindung trennt und wieder herstellt. Analyse und Lösung

In diesem Artikel wird ein Fehler im kabelgebundenen Android13-Netzwerk beschrieben! Oder besser gesagt eine Modifikation des neuen kabelgebundenen Netzwerks.

Android13 hat beim Festlegen einer statischen IP-Adresse ein Problem festgestellt: Das kabelgebundene Netzwerk wurde ständig getrennt und wieder verbunden.

Bei einem normalen Gateway tritt dieses Problem nicht auf, bei einem falschen Gateway tritt dieses Problem jedoch auf.

1. Einfache Analyse und Lösung

1. Log-Hinweise:

Suchen Sie das Schlüsselprotokoll der zyklischen Trennung und ermitteln Sie das Protokoll der Netzwerktrennung nach dem Herstellen der Verbindung anhand des Protokolls.


05-13 15:28:38.768  1186  3064 W IpClient.eth0: [IpReachabilityMonitor] WARN ALERT neighbor went from: null to: NeighborEvent{@43196,RTM_NEWNEIGH,if=14,170.168.20.1,NUD_FAILED,[null]}
05-13 15:28:38.768   445  3068 W resolv  : Validation failed
05-13 15:28:38.769  1186  3064 W IpReachabilityMonitor: FAILURE: LOST_PROVISIONING, NeighborEvent{@43196,RTM_NEWNEIGH,if=14,170.168.20.1,NUD_FAILED,[null]}
05-13 15:28:38.770   802  1023 I EthernetNetworkFactory: updateNeighborLostEvent FAILURE: LOST_PROVISIONING, NeighborEvent{@43196,RTM_NEWNEIGH,if=14,170.168.20.1,NUD_FAILED,[null]}
05-13 15:28:38.771   802  1023 D EthernetNetworkFactory: reconnecting Ethernet
05-13 15:28:38.845   802  1023 D EthernetNetworkFactory: Starting Ethernet IpClient(eth0)
05-13 15:28:38.846   802  1024 D ConnectivityService: [105 ETHERNET] EVENT_NETWORK_INFO_CHANGED, going from CONNECTED to DISCONNECTED
05-13 15:28:38.846   802  1024 D ConnectivityService: [105 ETHERNET] disconnected, was satisfying 16
05-13 15:28:38.851   802  1024 W BestClock: java.time.DateTimeException: Missing NTP fix

Aus dem Protokoll oben können wir ersehen, dass die IpReachabilityMonitor-Klasse die Überprüfungsfehlerinformationen ausgibt
und dann EthernetNetworkFactory und ConnectivityService benachrichtigt.

Und die zugehörige Prozessklasse ist im Protokoll leicht zu erkennen:

2. Verwandte Codeklassen:

Pakete\modules\Connectivity\service\src\com\android\server\ConnectivityService.java

Pakete\modules\Connectivity\service-t\src\com\android\server\ethernet\EthernetNetworkFactory.java

Pakete\Module\NetworkStack\src\Android\net\ip\IpReachabilityMonitor.java

3. Schlüsselcode für die erneute Verbindung

EthernetNetworkFactory.java


        void updateNeighborLostEvent(String logMsg) {
            Log.i(TAG, "updateNeighborLostEvent " + logMsg); //上面日志是有打印这个方法的！
            // Reachability lost will be seen only if the gateway is not reachable.（这里写了网关不可用会回调这里）
            // Since ethernet FW doesn't have the mechanism to scan for new networks
            // like WiFi, simply restart.
            // If there is a better network, that will become default and apps
            // will be able to use internet. If ethernet gets connected again,（这里写了有线网会重连！）
            // and has backhaul connectivity, it will become default.
            restart(); // 注释了这行代码，就不会一直断开重连了！
        }

        void restart() {
            restart(null);
        }


        //断开重连的重要流程
        void restart(@Nullable final INetworkInterfaceOutcomeReceiver listener) {
            if (DBG) Log.d(TAG, "reconnecting Ethernet");
            stop();//断开有线网
            start(listener);//启动有线网
        }

Aus dem obigen Code ist ersichtlich, dass ein Neustart der entscheidende Punkt dafür ist, dass das System immer wieder die Verbindung zum kabelgebundenen Netzwerk trennt und wieder herstellt.

Wo das Gateway überprüft werden soll, gibt es eine Trace-Analyse von IpReachabilityMonitor.

Tatsächlich können Sie wahrscheinlich vermuten, dass es sich irgendwo im Kabelnetzwerkdienst befinden sollte. Nach dem Festlegen des Gateways
gibt es ein Client-Objekt. Verwenden Sie den Sub-Thread, um eine Verbindung zur Gateway-Adresse herzustellen, um festzustellen, ob die Verbindung normal ist. Wenn die Wenn die Verbindung fehlschlägt, erfolgt ein Rückruf und der Rückruf erfolgt später.

4. Die Lösung besteht darin, die Verbindung immer wieder herzustellen:

(1) Entfernen Sie die Überprüfung des Gateways durch das kabelgebundene Netzwerk

Dies besteht darin, den Code zu verfolgen,
Idee 1, um ihn vor IpReachabilityMonitor zu verfolgen und zu analysieren;
Idee 2, das Konfigurationsobjekt des kabelgebundenen Netzwerk-Gateways von EthernetManager aus festzulegen und bis zum Ende zu analysieren.

Es besteht keine Notwendigkeit, dies vorübergehend zu analysieren, und Interessenten können es automatisch analysieren.

(2) Entfernen Sie den Wiederverbindungsvorgang

Entfernen Sie in EthernetNetworkFactory.java einfach den Aufruf der restart()-Methode.

andere:

Im Vergleich zu Android11 weist das kabelgebundene Netzwerk von Android13 weitere Änderungen auf.

Änderungen an kabelgebundenen Netzwerken für Android 13:
https://blog.csdn.net/wenzhi20102321/article/details/130607641

Android11-Prioritätseinstellungen für kabelgebundene Netzwerke und WLAN:
https://blog.csdn.net/wenzhi20102321/article/details/122243516

Weitere Einführung in Kabelnetze:
https://so.csdn.net/so/search?q=%E6%9C%89%E7%BA%BF%E7%BD%91&t=blog&u=wenzhi20102321