0

I have a STB device (reference board) having Android-M with Linux kernel 3.14.28-1.9pre.

On this board, I have 2 network interfaces:

  1. gphy: Wired Interface (10.131.24.211)
  2. wlan0: Wireless Interface (192.168.1.3)

Using wireless interface i associated to an AP on channel 6. Thereafter I try to ping to AP (192.168.1.1). But ping fails.

root@bcm_platform:/system/bin/amar/43242a1 # ping 192.168.1.1                  
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
^C
--- 192.168.1.1 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 999ms

On another terminal, tcpdump for wired interface shows that arp request is sent from wired interface for address 10.131.24.1 and ARP reply also came for wired interface. But when I tried tcpdump on wireless interface, no arp request/response were seen.

130|root@bcm_platform:/system/bin/amar/43242a1 # tcpdump -nni gphy arp
[ 2938.268561] device gphy entered promiscuous mode
[ 2938.273205] device eth0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on gphy, link-type EN10MB (Ethernet), capture size 65535 bytes
13:51:20.047056 ARP, Request who-has 10.131.24.1 tell 10.131.24.211, length 28
13:51:20.048108 ARP, Reply 10.131.24.1 is-at 00:00:0c:07:ac:18, length 46
13:50:50.047057 ARP, Request who-has 10.131.24.1 tell 10.131.24.211, length 28
13:50:50.048132 ARP, Reply 10.131.24.1 is-at 00:00:0c:07:ac:18, length 46

On checking the arp entries, there were only 2 entries related to wired interface. First wired entry was for wired interface and second entry was for adb connection from host machine (10.131.24.203) through wired interface. There was no entry added for wireless interface.

root@bcm_platform:/system/bin/amar/43242a1 # /system/xbin/busybox arp          
? (10.131.24.1) at 00:00:0c:07:ac:18 [ether]  on gphy
? (10.131.24.203) at d4:be:d9:6a:f8:77 [ether]  on gphy

Then i tried to ping by specifying wireless interface name, which worked fine.

root@bcm_platform:/system/bin/amar/43242a1 # ping -I wlan0 192.168.1.1    
64 bytes from 192.168.1.3 wlan0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=72.2 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=8.25 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=9.12 ms

On another terminal the tcpdump on wireless interface for arp packets clearly shows arp request for 192.168.1.1 and arp reply.

130|root@bcm_platform:/system/bin/amar/43242a1 # tcpdump -nni wlan0 arp        
[ 3191.490560] device wlan0 entered promiscuous mode
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
13:54:58.395951 ARP, Request who-has 192.168.1.3 tell 192.168.1.1, length 28
13:54:58.396032 ARP, Reply 192.168.1.3 is-at 00:90:4c:a5:12:38, length 28

Now again i checked the arp entries and found that an entry for wireless interface (wlan0) is added.

130|root@bcm_platform:/system/bin/amar/43242a1 # /system/xbin/busybox arp      
? (192.168.1.1) at 00:90:4c:0f:f1:47 [ether]  on wlan0
? (10.131.24.203) at d4:be:d9:6a:f8:77 [ether]  on gphy
? (10.131.24.1) at 00:00:0c:07:ac:18 [ether]  on gphy

From this analysis, it is observed that arp requests are being sent on wired interface and for wired ip address even though arp is requested for wireless interface on wireless interface.

If I disable the wired interface, things work fine.

1|root@bcm_platform:/system/bin/amar/43242a1 # ifconfig gphy down

1|root@bcm_platform:/system/bin/amar/43242a1 # ping 192.168.1.1       
64 bytes from 192.168.1.3 wlan0: 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=72.2 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=8.25 ms

arp table shows entry for 192.168.1.1

Could someone please provide solution for this problem?

Regards, Amar

  • Check that you have the correct subnet on the wireless interface. – Michael Hampton Dec 2 '15 at 16:51
  • Can you put the result of: ip route get 192.168.1.1 ? – Xavier Nicollet Dec 3 '15 at 14:44
  • I have 2 STBs. On one STB, ping works fine while in the other it does not. Below are the ip route get results on both STBS. Non-working STB =============== root@bcm_platform:/system/bin/amar/43242a1 # ip route get 192.168.1.1 192.168.1.1 via 10.131.24.1 dev gphy src 10.131.24.211 uid 0 cache root@bcm_platform:/system/bin/amar/43242a1 # Working STB =============== root@bcm_platform:/system/bin/amar/43242a1 # ip route get 192.168.1.1 192.168.1.1 dev wlan0 src 192.168.1.2 uid 0 cache – Amar Shankar Dec 4 '15 at 5:42
  • Could someone please resolve it asap. – Amar Shankar Dec 7 '15 at 6:29
0

Try this:

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce

From https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

arp_announce - INTEGER Define different restriction levels for announcing the local source IP address from IP packets in ARP requests sent on interface:

0 - (default) Use any local address, configured on any interface

1 - Try to avoid local addresses that are not in the target's subnet for this interface. This mode is useful when target hosts reachable via this interface require the source IP address in ARP requests to be part of their logical network configured on the receiving interface. When we generate the request we will check all our subnets that include the target IP and will preserve the source address if it is from such subnet. If there is no such subnet we select source address according to the rules for level 2.

2 - Always use the best local address for this target. In this mode we ignore the source address in the IP packet and try to select local address that we prefer for talks with the target host. Such local address is selected by looking for primary IP addresses on all our subnets on the outgoing interface that include the target IP address. If no suitable local address is found we select the first local address we have on the outgoing interface or on all other interfaces, with the hope we will receive reply for our request and even sometimes no matter the source IP address we announce.

The max value from conf/{all,interface}/arp_announce is used.

Increasing the restriction level gives more chance for receiving answer from the resolved target while decreasing the level announces more valid sender's information.

  • Even with echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce, still the issue persists. – Amar Shankar Dec 3 '15 at 6:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.