“
There is a crack in everything, that’s how the light gets in.
- Leonard Cohen

1. Overview
When driving and using in-car navigation to load maps, have you ever thought about the “brain” behind the navigation – the IVI domain SOC (such as the Qualcomm 8155 chip), which has an IP of 192.168.2.20 (belonging to the in-car local subnet 192.168.2.0/24), while the IP of the Gaode navigation server is 203.107.46.150 (not in this “in-car small network”)? How does the map data find its way to the screen? The answer lies in the “default route”.
The default route is the “in-car signpost” for automotive electronic network communication and an essential tool for in-car SOCs to work across networks: when in-car devices (such as IVI domain SOCs, ADAS domain chips) need to access a target (such as a navigation server, OTA upgrade server, or body domain controller) that is not in their “in-car local subnet” and do not know the specific communication path, the default route will guide the data to first be sent to an “in-car transfer station” (such as a 4G-connected T-BOX or inter-domain gateway), which will then forward the data to the final target. It’s like driving a long distance to an unfamiliar scenic spot; when you don’t know the specific county road, you first drive to the highway service area (gateway) and then find the scenic spot using the service area’s signposts – without this “in-car signpost”, the data would get “lost”, resulting in navigation loading failures, OTA upgrades getting stuck, or even ADAS being unable to obtain the vehicle’s status.
This article will start with the core concept of the default route, dissect the differences between “in-car data forwarded through the default route and the original data”, and then detail the configuration methods commonly used in automotive electronics for Linux and QNX systems, finally supplementing verification techniques and unique considerations for in-car scenarios, helping you thoroughly understand and effectively utilize the default route in automotive electronics.
2. Core Concept of Default Route
The default route (Default Route) is a “catch-all rule” in the computer routing table. When the target IP address that a device wants to access is not in the local subnet and there are no specific routing rules for that target network in the routing table, all such data packets will be uniformly forwarded to the “gateway device” specified by the default route, with the gateway responsible for further forwarding.
For example, the command<span>route add default 172.16.16.97</span> sets 172.16.16.97 as the default gateway. After this, all data packets that “cannot find a specific path” will first be sent to this gateway, which will then forward them to the target network.
3. Differences Between Messages Forwarded by Default Route and Original Messages
The core differences between messages forwarded by the default route and those sent directly within the same subnet are primarily reflected in the “link layer encapsulation” and “forwarding path”, while the core content of the message remains unchanged. We can use the analogy of “letter delivery” to understand this:
1. Core Content Remains Consistent
Whether sent directly or forwarded through the default route, the “core information” of the data packet, like the content of a letter and the final recipient address, remains unchanged, including:
- Source IP address (the IP of the sending device, such as a personal computer’s IP);
- Destination IP address (the IP of the final recipient, such as the IP of an internet server);
- Transport layer and application layer data (such as web content, file data, etc.).
2. Link Layer Encapsulation (“Temporary Collection Address”) Differs
When data packets are transmitted over a physical network (such as Ethernet), they need to encapsulate “link layer information” (similar to the “house number” on a letter), where the “destination MAC address” may change depending on the forwarding method. Here are specific scenario examples:
Scenario Setup
- Device A (Sender): IP is 192.168.1.10/24, MAC is 00:1B:24:7D:25:01, default gateway is 192.168.1.254 (Gateway MAC: 00:11:BC:7D:25:03);
- Device C (Target in the Same Subnet): IP is 192.168.1.20/24, MAC is 00:1C:24:7D:25:02;
- Device B (Target Across Subnet): IP is 192.168.2.5/24, MAC is 00:26:18:45:D7:88;
- Gateway Device: The interface IP connecting to Device A is 192.168.1.254 (MAC: 00:11:BC:7D:25:03), and the interface IP connecting to Device B is 192.168.2.254 (MAC: AA:BB:CC:DD:EE:FF).
(1) Communication Within the Same Subnet (Device A → Device C)
- Link Layer Encapsulation: Device A obtains Device C’s MAC address through the ARP protocol, and the link layer’s “destination MAC” is directly Device C’s MAC (00:1C:24:7D:25:02);
- Analogy Scenario: It’s like delivering a letter directly to a neighbor in the same building, where the envelope is addressed with the neighbor’s house number.
(2) Communication Across Subnets (Device A → Device B via Default Route)
- Device A’s Link Layer Encapsulation: Device A determines that Device B is not in the local subnet, obtains the gateway’s MAC address through ARP, and the link layer’s “destination MAC” changes to the gateway’s MAC (00:11:BC:7D:25:03);
- Gateway’s Re-Encapsulation: After receiving, the gateway strips the original link layer encapsulation, obtains Device B’s MAC through ARP, and during re-encapsulation, the “destination MAC” changes to Device B’s MAC (00:26:18:45:D7:88), while the source MAC changes to the MAC of the gateway’s interface connecting to Device B (AA:BB:CC:DD:EE:FF);
- Analogy Scenario: The letter is first sent to the community’s delivery locker (gateway), and the locker then forwards it to the recipient in another city, where the envelope’s temporary address is the locker’s number, not the final recipient’s address.
3. Different Forwarding Paths
- Same Subnet Communication: The path is “Device A → Device C”, direct point-to-point transmission;
- Cross-Subnet Communication: The path is “Device A → Gateway → Device B”, with the gateway acting as an intermediary; the default route is a “catch-all path” that only takes effect when there is no specific route.
4. Default Route Configuration Methods for Different Systems
When setting the default gateway to 192.168.2.88, the configuration methods for Linux and QNX systems are as follows:
1. Linux System Configuration
(1) Temporary Configuration (Invalid after Restart)
- Using the route command (compatible with older systems):
route add default gw 192.168.2.88 - Using the ip route command (modern recommendation):
ip route add default via 192.168.2.88
(2) Permanent Configuration (Retained after Restart)
-
Ubuntu/Debian (netplan): Edit the configuration file (e.g., /etc/netplan/01-network-manager-all.yaml):
network: version: 2 renderer: NetworkManager ethernets: eth0: # Replace with actual network card name dhcp4: no addresses: [192.168.1.10/24] gateway4: 192.168.2.88 nameservers: addresses: [8.8.8.8, 114.114.114.114]Apply configuration:
<span>sudo netplan apply</span> -
CentOS/RHEL (network-scripts): Edit the network card file (e.g., /etc/sysconfig/network-scripts/ifcfg-ens33):
BOOTPROTO=static IPADDR=192.168.1.10 NETMASK=255.255.255.0 GATEWAY=192.168.2.88 DNS1=8.8.8.8Restart the network:
<span>sudo systemctl restart network</span>
2. QNX System Configuration
(1) Temporary Configuration (Invalid after Restart)
route add default 192.168.2.88
# or full syntax
route add 0.0.0.0/0 192.168.2.88
(2) Permanent Configuration (Retained after Restart)
Edit the startup script (e.g., /etc/rc.d/rc.local) and add the temporary configuration command:
route add default 192.168.2.88
Grant execution permissions:<span>chmod +x /etc/rc.d/rc.local</span>
5. Configuration Verification and Management
1. Verify if the Default Route is Effective
-
Linux System:
route -n # Traditional command ip route show # Modern recommendationIf the output contains
<span>default via 192.168.2.88</span>, it is effective. -
QNX System:
route showIf the output contains
<span>default 192.168.2.88</span>, it is effective.
2. Delete Default Route
- Linux System:
route del default gw 192.168.2.88 ip route del default via 192.168.2.88 - QNX System:
route delete default 192.168.2.88
6. Precautions
- Temporary configurations are suitable for testing; permanent configurations require modifying system files to take effect long-term;
- The gateway IP (192.168.2.88) must be a real device present in the local subnet (such as a router), otherwise, it will lead to network disconnection;
- After configuration, it is necessary to confirm the effectiveness of the gateway through verification commands to avoid network communication issues due to configuration errors;
- In automotive electronic scenarios, it is recommended to choose stable in-car devices (such as T-BOX, inter-domain gateways) as the default gateway, and prioritize configuring dual gateway redundancy (automatic switch to backup gateway in case of primary gateway failure) to ensure uninterrupted network during driving.
Conclusion
The default route is a core mechanism for devices to access external networks, and in automotive electronics, it is the foundation for in-car SOCs to achieve navigation, OTA, and inter-domain communication – its essence is to forward data packets without a specific path through the gateway. The core content of the message remains unchanged, only the link layer encapsulation (destination MAC address) and forwarding path change due to gateway intermediation. In commonly used Linux and QNX systems in automotive electronics, the default route can be configured temporarily or permanently, and after configuration, the effectiveness status must be verified, with additional considerations for the stability requirements of in-car scenarios (such as dual gateway redundancy). Mastering this knowledge can effectively solve routing configuration issues in automotive electronic network communication.
For more exciting content, please follow the public account “Embedded Knowledge and Practice”