[OOR-Devel] [OOR maintainers] LISP Beta network allocation

Albert López alopez at ac.upc.edu
Wed Apr 5 14:00:32 CEST 2017


Hi Gaurav,

I have found a video <https://www.youtube.com/watch?v=dMp21rAp9Hw> where 
they explain how it works networking in Android 6. May be it could be 
interesting. The first thing you will have to do is to know the table 
assigned to each interface (It will be better if you use netlink). As 
you can see in the video, Android 6 (5 also works the same), have a 
table for each interface and a lot of rules that forward the packets to 
the correct table. So now you will have to add the following two rules 
to each of the rloc interfaces. You can check the function 
configure_routing_to_tun_mn.

     0.0.0.0/1 dev lisTun0 table x
     128.0.0.0/1 dev lispTun0 table x


One thing I have detected in my device is that when I have LTE up and I 
activate wifi, the table of LTE and the rules that foward traffic to LTE 
disappears (at least i have not been able to found them). I don't know 
if this is the normal behavior of android but if it is, you will have to 
monitor the creation and destruction of rules in order to create the 
previous routes when the table is created.  To do that you can check 
iface_mgmt.c file.

In the video, they say that one of the reasons for the new networking 
architecture used in android  is to avoid adding IPs in the routing 
rules. Unfortunately we need to add rules that use IP addresses. An 
example of rules that we add is:
     from <rloc address> lookup <table num>     -> in <table num> we 
copy the default route associated with the interface.     I have seen 
that in Android 5 the default address is not copied to this table. When 
I have time I will  check this point.

I hope with this information you can start to work.

Best regards

Albert






El 04/04/17 a les 18:09, Gaurav Mishra ha escrit:
> Hi Albert,
>
> Since this is something we are really interested in would it be 
> possible for you to help us understand the current code flow and the 
> problem associated with it and what changes are required. We can then 
> try to correct this on our end and try to make a contribution for the 
> same.
>
> Regards,
> Gaurav
>
> On Apr 4, 2017 09:45, "Albert López" <alopez at ac.upc.edu 
> <mailto:alopez at ac.upc.edu>> wrote:
>
>     Hi Kevin,
>
>     I have been checking and it seems that this behavior I was
>     describing started in Android 5. Apart from moving the routes from
>     the main route table to interface specific tables, it seems that
>     the routes we add in the main table are ignored. Unfortunately, to
>     allow OOR works in root devices, we need to do  big changes and at
>     this moments we don't have the required time resources. If you are
>     interested to do it, we will be glad to assesorate you.
>
>     Best regards
>
>     Albert
>
>
>     El 30/03/17 a les 06:47, Kevin Shen ha escrit:
>>     Hi Albert,
>>
>>     Thanks again for the help. We are using Android 5.0.2, and when
>>     the ./liboor.so command is executed without any errors, nothing
>>     is written to the OOR log file. Does the current version of the
>>     OOR code work for your rooted Android devices?
>>
>>     Thanks,
>>     Kevin
>>
>>     On Wed, Mar 29, 2017 at 4:44 AM, Albert López <alopez at ac.upc.edu
>>     <mailto:alopez at ac.upc.edu>> wrote:
>>
>>         [--- Changed maintainers by devel mailing list ---]
>>
>>         Hi Kevin,
>>
>>         OOR in root mode works like the linux version of OOR.
>>
>>           * We define the RLOC interfaces in the configuration file
>>           * We obtain the IP address  and the gateway associated with
>>             the interface (OOR needs to have a gateway defined for
>>             each interface despite they have different metric)
>>           * Add two routes to get all the traffic and overpass the
>>             gateways:
>>               o 0.0.0.0/1 dev lispTun0  proto static
>>               o 128.0.0.0/1 dev lispTun0  proto static
>>           * Assign EID to the lispTun0 interface
>>           * For each RLOC address we create a new routing table with
>>             a higher priority than the main table . We send to this
>>             table all packets with source address the RLOC IP.
>>           * We add to the new table the gateway route associated with
>>             the RLOC interface -> Once the packet is encapsulated
>>             will be reach this table and sent through the gateway
>>           * Same process for IPv6
>>
>>         Example once OOR is started:
>>
>>         ## ifconfig
>>         eth0      Link encap:Ethernet  HWaddr 00:0c:29:c2:84:b0
>>                   inet addr:8.88.81.70 Bcast:84.88.81.79 
>>         Mask:255.255.255.240
>>                   inet6 addr: fe80::20c:29ff:fec2:84b0/64 Scope:Link
>>                   UP BROADCAST RUNNING MULTICAST MTU:1500  Metric:1
>>                   RX packets:1234255 errors:0 dropped:0 overruns:0
>>         frame:0
>>                   TX packets:339517 errors:0 dropped:0 overruns:0
>>         carrier:0
>>                   collisions:0 txqueuelen:1000
>>                   RX bytes:174935927 (174.9 MB)  TX bytes:65482397
>>         (65.4 MB)
>>
>>         lispTun0  Link encap:UNSPEC  HWaddr
>>         00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
>>                   inet addr:153.16.30.48 P-t-P:153.16.30.48 
>>         Mask:255.255.255.255
>>                   UP POINTOPOINT RUNNING  MTU:1440 Metric:1
>>                   RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>>                   TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
>>                   collisions:0 txqueuelen:500
>>                   RX bytes:0 (0.0 B)  TX bytes:248 (248.0 B)
>>
>>         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:0 errors:0 dropped:0 overruns:0 frame:0
>>                   TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>>                   collisions:0 txqueuelen:0
>>                   RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
>>
>>         # ip route
>>         0.0.0.0/1 dev lispTun0  proto static
>>         default via 8.88.81.65 dev eth0  metric 10
>>         8.88.81.64/28 dev eth0  proto kernel  scope link  src 8.88.81.70
>>         128.0.0.0/1 dev lispTun0  proto static
>>
>>         # ip rule
>>         0:    from all lookup local
>>         2:    from 8.88.81.70 lookup 2
>>         32766:    from all lookup main
>>         32767:    from all lookup default
>>
>>         # ip route show table 2
>>         default via 8.88.81.65 dev eth0  proto static metric 100
>>
>>
>>         We obtain the gateway from the main routing table.
>>
>>         Previous to Android version 6, the routing in Android worked
>>         like in Linux (what I explained before). From Android 6 this
>>         has changed. The gateway of the interfaces is no longer
>>         stored in the main routing table. Instead of this, a new
>>         table is created for each interface and it is in this table
>>         where the gateway is stored. For instance, I show you the
>>         information of my phone (OOR is not running):
>>
>>         $ ip route
>>         10.61.76.252/30 dev rmnet_data0  proto kernel  scope link 
>>         src 10.61.76.253
>>
>>         $ ip rule
>>         0:    from all lookup local
>>         10000:    from all fwmark 0xc0000/0xd0000 lookup 99
>>         10500:    from all oif dummy0 uidrange 0-0 lookup 1002
>>         10500:    from all oif rmnet_data0 uidrange 0-0 lookup 1012
>>         13000:    from all fwmark 0x10063/0x1ffff lookup 97
>>         13000:    from all fwmark 0x10068/0x1ffff lookup 1012
>>         14000:    from all oif dummy0 lookup 1002
>>         14000:    from all oif rmnet_data0 lookup 1012
>>         15000:    from all fwmark 0x0/0x10000 lookup 99
>>         16000:    from all fwmark 0x0/0x10000 lookup 98
>>         17000:    from all fwmark 0x0/0x10000 lookup 97
>>         19000:    from all fwmark 0x68/0x1ffff lookup 1012
>>         22000:    from all fwmark 0x0/0xffff lookup 1012
>>         23000:    from all fwmark 0x0/0xffff uidrange 0-0 lookup main
>>         32000:    from all unreachable
>>
>>         $ ip route show table 1012
>>         default via 10.61.76.254 dev rmnet_data0 proto static
>>
>>
>>         If you check the OOR log file you will see that the system is
>>         not able to find the gateway and as a consequence it can not
>>         finish with the process I explained before.
>>         Here you have two options. Use a device with an Android
>>         version previous to 6 to focus in your case or try to solve
>>         this problem. If you try to solve it, considerer that you not
>>         only have to know the gateway but also detect the change of
>>         gateway through netlink.
>>
>>         Another thing you should know is that the netconf module to
>>         configure OOR while runing is only available in Linux. If you
>>         want to change OOR configuration in Android ( add a new RLOC
>>         interface, change MS, change EID ...), you have to restart OOR.
>>
>>         If OOR stops without reason, the first thing to check is the
>>         log file to try to find any clue.
>>
>>         Best regards
>>
>>         Albert
>>
>>
>>
>>
>>         El 29/03/17 a les 06:31, Kevin Shen ha escrit:
>>>         Hi Albert,
>>>
>>>         Thanks a lot for the help. We are now trying to get the
>>>         rooted version of OOR working on Android, but whenever we
>>>         tap the checkbox to run OOR, the service icon quickly
>>>         appears and disappears in the status bar.
>>>
>>>         We made sure that the NDK generated library liboor.so was
>>>         copied over to OOR's app data in the lib/ folder, and that
>>>         the command ./liboor.so was executed without any error
>>>         message from the shell or exception thrown in the Java code.
>>>         The device we are using is properly rooted. However, the
>>>         OORService still quits immediately, which could mean
>>>         ./liboor.so terminates right away.
>>>
>>>         Do you maybe have any insight on this issue? If possible, we
>>>         would also be willing to Skype at any time to solve this. We
>>>         really appreciate all the time you've taken to help us with
>>>         OOR. Thanks so much!
>>>
>>>         Best Regards,
>>>         Kevin
>>>
>>>         On Mon, Mar 27, 2017 at 4:13 AM, Albert López
>>>         <alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>> wrote:
>>>
>>>             Hi Kevin,
>>>
>>>             You should select the interface that has an IP assigned.
>>>             In my device the name is rmnet_data0. You can check it
>>>             using "ip address" from a terminal (if you have wifi on,
>>>             the data interface may not have an IP assigned). If you
>>>             still have problems, you can send me the logs file
>>>             located in your storage card (oor.log).
>>>
>>>             Best regards
>>>
>>>             Albert
>>>
>>>             El 24/03/17 a les 12:13, Kevin Shen ha escrit:
>>>>             Hi Albert,
>>>>
>>>>             Thanks so much for the help! We managed to successfully
>>>>             ping an EID with the wlan0 Wi-Fi interface, but for
>>>>             some reason the rmnet0 LTE interface doesn't work.
>>>>             Would you mind taking a look at the screenshot
>>>>             attached? We are using a device running Android 6, if
>>>>             that makes a difference. Thanks in advance - we really
>>>>             appreciate your time.
>>>>
>>>>             Best Regards,
>>>>             Kevin
>>>>
>>>>             On Thu, Mar 23, 2017 at 5:29 AM, Albert López
>>>>             <alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>> wrote:
>>>>
>>>>                 Hi Kevin,
>>>>
>>>>
>>>>                 El 23/03/17 a les 02:31, Kevin Shen ha escrit:
>>>>>                 Hi Albert,
>>>>>
>>>>>                 Thanks a lot for setting it up!
>>>>>
>>>>>                 We've entered the configuration into the OOR
>>>>>                 Android app and successfully registered into the
>>>>>                 LISP Site Status page. However, when we ping
>>>>>                 active EIDs, we don't get any response. It works
>>>>>                 when we use Wi-Fi/LTE without OOR enabled.
>>>>>                 Attached are screenshots of the configuration.
>>>>                 I think you have selected the wrong intrefaces in
>>>>                 the RLOC interface selection. You should select
>>>>                 something like wlan0, rmnet0 (the interfaces with
>>>>                 an IP selected). If your RLOCs are behind NAT, you
>>>>                 will need to select NAT Traversal Aware.
>>>>>
>>>>>                 Our use case is: developing an API which when
>>>>>                 triggered with necessary parameters can seamlessly
>>>>>                 transition over heterogeneous networks using LISP.
>>>>>
>>>>                 I am not an expert in Android but the last time we
>>>>                 tried to select the output  interface we couldn't.
>>>>                 By default Android only have one active interface
>>>>                 that you can not select (if you are connected to
>>>>                 wifi I think you can not choose to use the LTE
>>>>                 interface to send data). May be it is possible to
>>>>                 do it if you have a rooted device but we didn0t
>>>>                 have time to work with this. On the other hand, we
>>>>                 only have support for root devices for Android
>>>>                 versions previous to 6. Android 6 and above changed
>>>>                 the way to implement the network and we haven't had
>>>>                 time to adapt OOR to it. For this devices we only
>>>>                 support the none root version of OOR which is based
>>>>                 on the VPN API of Android. As far as I know, with
>>>>                 VPN API you can not select the output interface.
>>>>
>>>>                 Best regards
>>>>
>>>>                 Albert
>>>>
>>>>>                 Any help would be greatly appreciated. Thanks in
>>>>>                 advance!
>>>>>
>>>>>                 Best Regards,
>>>>>                 Kevin Shen
>>>>>
>>>>>                 On Mon, Mar 20, 2017 at 5:21 AM, Albert López
>>>>>                 <alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>> wrote:
>>>>>
>>>>>                     Dear Kevin,
>>>>>
>>>>>                     Here's your allocation data:
>>>>>
>>>>>                     Device name: columbia-xtr
>>>>>                     Region: US-East
>>>>>                     Geographic location: New York - USA
>>>>>                     EID-prefix: 153.16.29.128/28 (more specifics
>>>>>                     allowed)
>>>>>                     EID loopback: 153.16.29.129
>>>>>                     EID-prefix ipv6: 2610:D0:1153::/48 (more
>>>>>                     specifics allowed)
>>>>>                     EID loopback ipv6: 2610:D0:1153::153:16:29:129
>>>>>                     Map Servers: {ARIN} {cisco-sjc-mr-ms-1
>>>>>                     173.36.254.164, eqx-ash-mr-ms 206.223.132.89}
>>>>>                     Map Server password: wju6C2ZjV3
>>>>>                     Map Resolvers: {ARIN} {cisco-sjc-mr-ms-1
>>>>>                     173.36.254.164, eqx-ash-mr-ms 206.223.132.89}
>>>>>                     PETR: 69.31.31.98
>>>>>                     Contact: Kevin Shen <ks3206 at columbia.edu>
>>>>>                     <mailto:ks3206 at columbia.edu>
>>>>>                     Expiration date: 30/06/2017
>>>>>
>>>>>                     Please take a look at the
>>>>>                     `oor/oor.conf.example` file in the source
>>>>>                     distribution to see how to build a
>>>>>                     configuration from the above data.  You can
>>>>>                     check if you correctly registered your site
>>>>>                     into the mapping system on the LISP Site
>>>>>                     Status page here:
>>>>>                     http://www.lisp4.net/lisp-site/
>>>>>                     <http://www.lisp4.net/lisp-site/> After one
>>>>>                     day it will probably show up on the LISPmon
>>>>>                     website as well: http://lispmon.net
>>>>>
>>>>>                     You can slice up your prefixes into more
>>>>>                     specifics and distribute them between more
>>>>>                     than one device if that becomes necessary,
>>>>>                     just make sure they don’t overlap.
>>>>>
>>>>>                     If you have any issues or questions, please
>>>>>                     post to the users mailing list for support, or
>>>>>                     join #openoverlayrouter on Freenode for more
>>>>>                     interactive help.
>>>>>                     http://webchat.freenode.net/?randomnick=1channels=#openoverlayrouter&prompt=1
>>>>>                     <http://webchat.freenode.net/?randomnick=1channels=#openoverlayrouter&prompt=1>
>>>>>
>>>>>                     The assigned EIDs will expire the 30 of June
>>>>>                     of 2017. You can request to renew them by mail.
>>>>>
>>>>>                     Best regards,
>>>>>
>>>>>                     Albert
>>>>>
>>>>>
>>>>>                     PS: Notice that OOR for Android is limited to
>>>>>                     one active interface. The other ones are in
>>>>>                     backup mode
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>                     El 20/03/17 a les 00:40, Kevin Shen ha escrit:
>>>>>>                     Dear OpenOverlayRouter Team,
>>>>>>
>>>>>>                     My name is Kevin Shen, and I am a student at
>>>>>>                     Columbia University conducting research with
>>>>>>                     Prof. Henning Schulzrinne. My team and I are
>>>>>>                     interested in the beta network because we are
>>>>>>                     working on seamless transitioning between
>>>>>>                     heterogeneous networks. Here is the
>>>>>>                     information requested:
>>>>>>
>>>>>>                     Full name: Kevin Shen
>>>>>>                     Geographical location: New York, NY
>>>>>>                     Flavor of OOR: Android
>>>>>>                     Make/model: SM-G935U (Samsung Galaxy S7 Edge)
>>>>>>                     Use cases: Mobility
>>>>>>                     How we learned about OOR: Research paper on
>>>>>>                     multihoming protocols
>>>>>>
>>>>>>                     Please let me know if you need anything else.
>>>>>>                     Thanks so much!
>>>>>>
>>>>>>                     Best Regards,
>>>>>>                     Kevin Shen
>>>>>>                     Columbia University | Class of 2018
>>>>>>                     B.S. Candidate in Computer Science
>>>>>>
>>>>>>
>>>>>>                     _______________________________________________
>>>>>>                     Maintainers mailing list
>>>>>>                     Maintainers at mail.openoverlayrouter.org
>>>>>>                     <mailto:Maintainers at mail.openoverlayrouter.org>
>>>>>>                     http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/maintainers
>>>>>>                     <http://mail.openoverlayrouter.org/cgi-bin/mailman/listinfo/maintainers>
>>>>>
>>>>>                 -- 
>>>>>                 Kevin Shen
>>>>>                 Columbia University | Class of 2018
>>>>>                 B.S. Candidate in Computer Science
>>>>
>>>>                 -
>>>>
>>>>             -- 
>>>>             Kevin Shen
>>>>             Columbia University | Class of 2018
>>>>             B.S. Candidate in Computer Science
>>>
>>>         -- 
>>>         Kevin Shen
>>>         Columbia University | Class of 2018
>>>         B.S. Candidate in Computer Science
>>
>>     -- 
>>     Kevin Shen
>>     Columbia University | Class of 2018
>>     B.S. Candidate in Computer Science
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170405/355441bf/attachment-0001.html>


More information about the devel mailing list