When working with Linux network interfaces, particularly USB-based networking devices, you might encounter repetitive kernel messages like:
Mar 8 23:17:25 saas1 kernel: martian source 169.254.1.1 from 169.254.95.118, on dev usb0
Mar 8 23:17:25 saas1 kernel: ll header: ff:ff:ff:ff:ff:ff:00:21:5e:de:1b:be:08:06
The 169.254.0.0/16 range is reserved for link-local addressing as defined in RFC 3927. These addresses are:
- Automatically assigned when DHCP fails (APIPA)
- Strictly for single-link communication
- Never routed between network segments
The Linux kernel considers these packets "martian" when:
- A packet arrives with source address from different link-local subnet
- The routing table indicates the source shouldn't be reachable via that interface
- ARP packets appear to be coming from unexpected networks
To suppress these messages while maintaining system security:
# Add to /etc/sysctl.conf
net.ipv4.conf.all.log_martians = 0
net.ipv4.conf.default.log_martians = 0
net.ipv4.conf.usb0.log_martians = 0
# Apply changes immediately
sysctl -p
For deeper investigation, use tcpdump to examine the traffic:
tcpdump -i usb0 -nn -v "net 169.254.0.0/16"
tcpdump -i usb0 -nn -v "arp"
Create a persistent configuration to properly handle the interface:
# /etc/network/interfaces.d/usb0
auto usb0
iface usb0 inet static
address 169.254.1.1
netmask 255.255.0.0
up route add -net 169.254.0.0 netmask 255.255.0.0 dev usb0
For systems using firewalld or iptables:
# Block problematic ARP requests
iptables -A INPUT -i usb0 -s 169.254.0.0/16 -j DROP
iptables -A OUTPUT -o usb0 -d 169.254.0.0/16 -j DROP
When you see messages like this in your logs:
Mar 8 23:17:25 saas1 kernel: martian source 169.254.1.1 from 169.254.95.118, on dev usb0
Mar 8 23:17:25 saas1 kernel: ll header: ff:ff:ff:ff:ff:ff:00:21:5e:de:1b:be:08:06
The kernel is telling you it's receiving packets with source addresses that don't make logical sense for the network interface they're arriving on. These are called "martian" packets because they appear to come from impossible network locations.
The 169.254.0.0/16 range is reserved for IPv4 Link-Local addressing (APIPA). Key characteristics:
- Automatically assigned when DHCP fails
- Never routed between network segments
- Designed for single-link communication only
Based on your log entries, several possibilities exist:
1. Misconfigured USB network device (usb0 interface)
2. Device sending malformed ARP packets
3. Network loop causing packets to bounce back
4. Faulty network hardware generating invalid traffic
First, let's check interface configuration:
# Check usb0 interface details
ip addr show usb0
# Monitor ARP traffic specifically
tcpdump -i usb0 -nn -v 'arp'
Option 1: Filter the traffic at kernel level (if legitimate)
# Add route for link-local network
ip route add 169.254.0.0/16 dev usb0
# Or disable martian logging temporarily
echo 0 > /proc/sys/net/ipv4/conf/all/log_martians
Option 2: Fix the underlying network issue
# If USB device is problematic
sudo rmmod usbnet
sudo modprobe usbnet
# Or reconfigure the interface
sudo ifdown usb0
sudo ifup usb0
For production systems, consider implementing these measures:
# Permanent martian logging control
echo "net.ipv4.conf.all.log_martians = 0" >> /etc/sysctl.conf
# Firewall rules to block link-local traffic
iptables -A INPUT -s 169.254.0.0/16 -j DROP
iptables -A OUTPUT -d 169.254.0.0/16 -j DROP
While often benign, these messages can indicate:
- Network misconfiguration that needs attention
- Potential security issues if unexpected devices appear
- Hardware failures causing packet corruption