[OOR-Devel] [OOR maintainers] LISP Beta network allocation
Albert López
alopez at ac.upc.edu
Fri Apr 7 10:53:20 CEST 2017
Hi Kevin,
I have fixed the logs and now the file is generated. The new code is in
the testing branch. I recommend that if your modifications are in the
oor code and not in the Android app, to run oor from a terminal. Connect
to your device using adb shell and you will find the executable in the
directory /data/app/org.openoverlayrouter.noroot-?/lib/arm/. The command
to run is "liboorexec.so -f /sdcard/oor.conf". You should be root to run
this command (su).
Best regards
Albert
On 06/04/17 23:27, Kevin Shen wrote:
> Hi Albert,
>
> Thanks for the help. Quick question, are you seeing anything in the
> log file when you run OOR for rooted devices? We don't see anything
> being written to the log on any of our devices. Thanks in advance!
>
> Best,
> Kevin
>
> On Wed, Apr 5, 2017 at 8:00 AM, Albert López <alopez at ac.upc.edu
> <mailto:alopez at ac.upc.edu>> wrote:
>
> 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
>>
> --
> 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/20170407/d5b9c444/attachment-0001.html>
More information about the devel
mailing list