Project: webrtc Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 14 users
Status: Available
Owner: ----
Cc:
Components:
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment
Android custom getifaddrs implementation resolves an invalid IP address for point-to-point interfaces
Reported by joonas.j...@gmail.com, Oct 4 2013 Back to list
What steps will reproduce the problem?
1. Get a 3G dongle or other device which acts as a P-t-P (point-to-point) interface (built-in 3G connectivity doesn't seem to be affected, but USB dongles are!)
2. Try to make a call with AppRTC

What is the expected result?

getifaddrs resolves the correct IP (10.171.121.113 in the attached example) for the P-t-P interface, and the call will succeed (assuming no other faults)

What do you see instead?

getifaddrs resolves an incorrect IP address (10.64.64.64 in the attached example), low-level STUN/TURN socket bindings fail (verifiable with logcat if using a debug build) -> call fails

What version of the product are you using? On what operating system?

r4925. Android version doesn't matter, since the custom getifaddrs can be compiled on any Linux-based system, and can be easily verifiable with e.g. an Ubuntu-based machine.

Please provide any additional information below.

Since bionic on Android doesn't have getifaddrs, WebRTC has a custom implementation of that functionality. The implementation gets interface addresses using the rtnetlink feature of the Linux kernel.

However, when inspecting the response data from kernel, the implementation only considers addresses of type IFA_ADDRESS, and ignores IFA_LOCAL addresses. Normally this is fine, but at least with P-t-P interfaces, IFA_ADDRESS seems to be the "remote address" for the interface, and IFA_LOCAL is the address, which can be used in socket bindings.

I am not an expert on this, but several pieces of evidence supports the idea that IFA_LOCAL should always be preferred if it exists:

A post on Avahi message list:
http://lists.freedesktop.org/archives/avahi/2011-January/001970.html

Address tracker implementation in Chromium project (please note that based on my experience the comments are NOT 100% correct! But the implementation seems to be):
http://src.chromium.org/svn/trunk/src/net/base/address_tracker_linux.cc

Comment in <linux/if_addr.h> :
/*
 * Important comment:
 * IFA_ADDRESS is prefix address, rather than local interface address.
 * It makes no difference for normally configured broadcast interfaces,
 * but for point-to-point IFA_ADDRESS is DESTINATION address,
 * local address is supplied in IFA_LOCAL attribute.
 */


The problem is easily verifiable using a normal Linux machine with an affected 3G dongle. I've attached a simple test application (with ifaddrs-android.cc/h), and outputs from ifconfig and results from the test application with both native and custom getifaddrs. You can easily see that the custom implementation gets the incorrect address (labeled as P-t-P in ifconfig output). This address can NOT be used to bind sockets, and the custom implementation would fail all STUN/TURN-stuff if the dongle would be used on an Android device.
 
ifaddrs-testapp.tar.bz2
3.5 KB Download
linux-ifconfig.txt
411 bytes View Download
linux-native-ifaddrs.txt
69 bytes View Download
linux-custom-ifaddrs.txt
102 bytes View Download
Project Member Comment 1 by jansson@webrtc.org, Oct 7 2013
Cc: sergel@webrtc.org
Labels: OS-Android
Status: Available
I download your test app I can confirm your findings by just changing IFA_ADDRESS to IFA_LOCAL in ifaddrs-android.cc and:

#ifconfig:
ppp0      Link encap:Point-to-Point Protocol  
          inet addr:95.192.21.100  P-t-P:10.64.64.64  Mask:255.255.255.255

IFA_LOCAL in ifaddrs-android.cc results in:
(14:30:36) # ./test
ppp0: 95.192.21.100 mask 255.255.255.255

IFA_ADDRESS in ifaddrs-android.cc results in:
(14:31:45) # ./test
ppp0: 10.64.64.64 mask 255.255.255.255

I believe the comment you included sums up the issue:
Comment in <linux/if_addr.h> :
/*
 * Important comment:
 * IFA_ADDRESS is prefix address, rather than local interface address.
 * It makes no difference for normally configured broadcast interfaces,
 * but for point-to-point IFA_ADDRESS is DESTINATION address,
 * local address is supplied in IFA_LOCAL attribute.
 */

Project Member Comment 2 by tnakamura@webrtc.org, Oct 7 2013
Cc: braveyao@webrtc.org vikasmarwaha@webrtc.org juberti@webrtc.org
Project Member Comment 3 by jansson@webrtc.org, Oct 8 2013
Cc: mallinath@webrtc.org
Cc: -mallinath@webrtc.org
Owner: mallinath@webrtc.org
Labels: Mstone-32
Comment 6 by juberti@google.com, Oct 8 2013
This only occurs in Android standalone, not Chrome for Android, right?
I think it happens on chrome too.
Project Member Comment 8 by juberti@webrtc.org, Oct 10 2013
Labels: Area-PeerConnection
This happens only on standalone android not in chromium.
Labels: -Mstone-32 Mstone-38
Can I ask why this issue has been postponed? We have a broken use case android set-top box with 3G dongle. Thanks.
Yes we have an operator customer who would require this feature.
Cc: -sergel@webrtc.org pthatcher@webrtc.org mallinath@webrtc.org jiayl@webrtc.org
Owner: glaznev@webrtc.org
Alex, can you take a look at this? Should be a simple change in android-getifaddrs.cc
Project Member Comment 14 by guoweis@webrtc.org, Aug 28 2014
Cc: guow...@gmail.com
Project Member Comment 15 by juberti@webrtc.org, Aug 28 2014
Labels: -Mstone-38 Mstone-39
Owner: guoweis@webrtc.org
Reassigning.
Does this have to be in M39? 
Can  you please resolve this issue, thanks.
Comment 18 by vrk@webrtc.org, Oct 16 2014
Labels: -Mstone-39 Mstone-40 EngTriaged
No, does not have to be in M39. Moving to 40.
Project Member Comment 19 by pthatcher@google.com, Dec 5 2014
Labels: -Mstone-40 Mstone-42
Project Member Comment 20 by guoweis@webrtc.org, Dec 13 2014
Probably we should consider reuse AddressTracker from chromium code base as it has many edge cases taken care of.
Project Member Comment 21 by pthatcher@webrtc.org, Feb 19 2015
Labels: -Mstone-42 Mstone-44
This looks like it's not hitting m42.  Update it if I'm wrong.
Project Member Comment 22 by tnakamura@webrtc.org, Jan 29 2016
Cc: -vikasmarwaha@webrtc.org -mallinath@webrtc.org -guow...@gmail.com guoweis@webrtc.org
Labels: -Mstone-44
Owner: ----
I don't see any CLs linked to this bug, so I don't think it's been fixed. guoweis@ is moving on, so I'm also clearing the milestone label.
Project Member Comment 23 by pthatcher@webrtc.org, Nov 8 2016
Labels: Pri-3
Sign in to add a comment