Understanding Network Layers, MAC, DHCP, TCP Handshake/Teardown and Common WiFi Issues on Android

The article begins with an overview of why network layers are used, comparing them to software design patterns like MVC and emphasizing decoupling, clearer responsibilities, and easier troubleshooting.

1. Network Layering Rationale

Each layer solves a specific problem: the transport layer handles process location, the network layer routes packets, and the data‑link layer manages local network transmission. The MAC layer provides local addressing while IP provides global routing.

2. Role of the MAC Layer

Before a packet reaches its final destination, it is encapsulated multiple times with different MAC addresses as it hops between routers. The final destination IP is constant, while the MAC address changes at each hop.

3. DHCP Process

DHCP Offer and ACK are broadcast packets only when the client sets the BROADCAST flag. Static IP conflicts are detected by sending an ARP request for the allocated address before binding. If a conflict is found, the client sends a DHCPDECLINE.

IsLost (SeqNum): // Returns true when the sequence number is considered lost based on SACKed sequences. return true/false;

4. TCP Handshake and Teardown

The three‑way handshake is an optimization of a four‑step process, merging SYN‑ACK into a single packet. The four‑step teardown is required because the connection is full‑duplex; the side that finishes sending data must wait for the peer to acknowledge before closing.

TCP achieves reliability over unreliable IP by using loss detection, timeout retransmission, sliding windows, and congestion control (covered in a future article).

ACK delay (cumulative ACK) reduces bandwidth usage but can increase latency and cause spurious retransmissions.

RTO is calculated from RTT (RFC 2988) but may be inaccurate in noisy or congested environments, leading to false retransmissions.

public static final int DEFAULT_TCP_PACKETS_FAIL_PERCENTAGE = 80;

5. Common Android Wi‑Fi Problems and Analysis Methodology

Connection failures are often caused by password errors, authentication failures, handshake issues, or DHCP problems. Log excerpts show EAPOL handshake attempts and failures.

17:29:23.276148 [cds_ol][0x10cb45409a9] wlan: ... EAPOL: [0] [M1] SA: ec:41:18:08:df:9d <-- DA: bc:7f:a4:35:0a:95

DHCP failures usually stem from weak signal causing large DHCP frames to be lost; checking RSSI values helps diagnose.

2021-02-07 09:29:31.941 - CMD_START wlan0/30 ... onProvisioningSuccess({InterfaceName: wlan0 LinkAddresses: [192.168.31.45/24] ...})

Authentication failures are indicated by non‑zero failure codes in driver logs, e.g., code 1 meaning the AP rejected authentication.

2021-05-12 10:22:43.578514 wlan: Auth RX: ... failure code 1 54:75:95:e7:6f:61

Disconnection analysis distinguishes lower‑layer DISCONNECT events from upper‑layer disconnection requests by the order of log messages.

DISCONNECT Event → supplicant state change to DISCONNECTED

RSSI and beacon time‑outs are diagnosed by examining RSSI values (‑40 ~ ‑60 dBm is good; <‑65 dBm is poor) and beacon miss counters; exceeding thresholds triggers roaming or disconnection.

gRoamBmissFirstBcnt = 10 gRoamBmissFinalBcnt = 20

ARP/DNS failures are detected by keywords like "CMD_IP_REACHABILITY_LOST" or "NUD_FAILED" in logs.

rec[135]: processed=L2ConnectedState ... CMD_IP_REACHABILITY_LOST

Data stall detection uses packet loss percentages (>80 %) or consecutive DNS time‑outs (>5) to flag stalls.

public static final int DEFAULT_CONSECUTIVE_DNS_TIMEOUT_THRESHOLD = 5;

TX/RX anomalies are monitored via driver statistics; stagnant RX counters indicate possible issues.

TX: pkt cnt 267148, RX: pkt cnt 450071 … later RX: pkt cnt 450073 (no growth)

AP‑side events such as deauthentication frames or security mode changes can force a client to disconnect.

Rx Deauth frame from BSSID=[aa:63:df:5c:db:c5] Reason code = 7

6. Roaming Triggers

Various reasons (poor RSSI, beacon miss, high PER, etc.) cause roaming; the article details the beacon‑miss trigger thresholds and the sequence of firmware messages leading to a roam attempt.

# Set beacon missed count threshold gRoamBmissFirstBcnt = 10 gRoamBmissFinalBcnt = 20

When the combined miss count exceeds the threshold, a scan is initiated; if no suitable AP is found, the connection is dropped.

Conclusion

The article provides a comprehensive overview of network fundamentals and a practical workflow for diagnosing Android Wi‑Fi issues, encouraging readers to use log analysis and systematic checks to pinpoint problems.

References: https://blog.csdn.net/shuyan1115/article/details/102476599 https://juejin.cn/post/6844903986189844493 https://blog.csdn.net/dog250/article/details/52548345