[OOR-Devel] [OOR maintainers] LISP Beta network allocation
Albert López
alopez at ac.upc.edu
Wed Mar 29 10:44:21 CEST 2017
[--- 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170329/d36f5a2b/attachment-0001.html>
More information about the devel
mailing list