Quantcast
Channel: Processors forum - Recent Threads
Viewing all articles
Browse latest Browse all 17527

Linux/PROCESSOR-SDK-AM335X: device responds to ping to ethernet alias address even when cable is unplugged

$
0
0

Part Number:PROCESSOR-SDK-AM335X

Tool/software: Linux

We have a device with 2 ethernet ports configured in dual_emac mode:

eth0 - no cable plugged in.  I assign an alias address eth0:0 169.254.0.2

eth1 - plugged into switch with dhcp server.  It gets assigned 10.1.58.115 in the example below

When I do this, I can ping both the IP address assigned to eth1 and eth0:0 from a host computer, despite the fact that there is no ethernet cable plugged into eth0.

Here's the output of ifconfig on device:

eth0 Link encap:Ethernet HWaddr 38:d2:69:57:14:e2
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Interrupt:176

eth0:0 Link encap:Ethernet HWaddr 38:d2:69:57:14:e2
inet addr:169.254.0.2 Bcast:169.254.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
Interrupt:176

eth1 Link encap:Ethernet HWaddr 38:d2:69:57:14:e4
inet addr:10.1.58.115 Bcast:10.1.59.255 Mask:255.255.254.0
inet6 addr: fe80::3ad2:69ff:fe57:14e4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:439 errors:0 dropped:0 overruns:0 frame:0
TX packets:41 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:40475 (39.5 KiB) TX bytes:4645 (4.5 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:90 errors:0 dropped:0 overruns:0 frame:0
TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1
RX bytes:6995 (6.8 KiB) TX bytes:6995 (6.8 KiB)

And here's some debug info from the host:

ping -c 5 10.1.58.115

PING 10.1.58.115 (10.1.58.115): 56 data bytes
64 bytes from 10.1.58.115: icmp_seq=0 ttl=63 time=21.777 ms
64 bytes from 10.1.58.115: icmp_seq=1 ttl=63 time=126.102 ms
64 bytes from 10.1.58.115: icmp_seq=2 ttl=63 time=111.071 ms
64 bytes from 10.1.58.115: icmp_seq=3 ttl=63 time=1.287 ms
64 bytes from 10.1.58.115: icmp_seq=4 ttl=63 time=39.056 ms

--- 10.1.58.115 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.287/59.859/126.102/49.648 ms


ping -c 5 169.254.0.2
PING 169.254.0.2 (169.254.0.2): 56 data bytes
64 bytes from 169.254.0.2: icmp_seq=0 ttl=63 time=3.858 ms
64 bytes from 169.254.0.2: icmp_seq=1 ttl=63 time=2.361 ms
64 bytes from 169.254.0.2: icmp_seq=2 ttl=63 time=2.742 ms
64 bytes from 169.254.0.2: icmp_seq=3 ttl=63 time=1.235 ms
64 bytes from 169.254.0.2: icmp_seq=4 ttl=63 time=1.680 ms

--- 169.254.0.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.235/2.375/3.858/0.907 ms

arp -a
? (10.1.56.1) at 2c:54:2d:3e:b9:c9 on en0 ifscope [ethernet]
? (169.254.0.2) at 38:d2:69:57:14:e4 on en0 [ethernet]
? (224.0.0.251) at 1:0:5e:0:0:fb on en0 ifscope permanent [ethernet]
? (239.255.255.250) at 1:0:5e:7f:ff:fa on en0 ifscope permanent [ethernet]

It looks like the host's arp cache has the mac address for the device's eth1 for 169.254.0.2.  That seems like it should be impossible.


Viewing all articles
Browse latest Browse all 17527

Trending Articles