[OOR-Devel] [OOR maintainers] LISP Beta network allocation
Albert López
alopez at ac.upc.edu
Mon May 8 09:46:28 CEST 2017
Hi Kevin,
It is not necessary. You can use the MS
Intouch-ams-mr-ms-1.rloc.lisp4.net. This MS has support for NAT
traversal and will configure the RTR that you need.
Best regards
Albert
El 06/05/17 a les 02:15, Kevin Shen ha escrit:
> Hi Albert,
>
> Thanks for your help, we found that these networks are behind NAT.
> When enabling NAT in the configuration file, the log file shows that
> OOR is unable to find any RTRs. Would this mean that we would have to
> set up our own RTR/MS that are NAT traversal capable, or is it
> possible to make use of RTRs in the beta network?
>
> Thanks,
> Kevin
>
> On Wed, Apr 19, 2017 at 3:24 AM, Albert López <alopez at ac.upc.edu
> <mailto:alopez at ac.upc.edu>> wrote:
>
> Hi Kevin,
>
> Are these wireless networks behind a NAT box? In that case you
> have to enable NAT support in the configuration file. Another
> possibility is that these wireless networks use a firewall that
> filters UDP packets to port 4341 and 4342.
> Just a suggestion for other occasions, it is better if you send me
> the oor.log file that is stored in the storage of you device
> instead of screen shoots. It is better to see all the logs from
> the beginning.
>
> Best regards
>
> Albert
>
>
>
> El 18/04/17 a les 23:16, Kevin Shen ha escrit:
>> Hi Albert,
>>
>> Thanks for your help. We are currently testing OOR for unrooted
>> devices on a phone running Android 6.0.1. Our test is ping'ing an
>> EID, 153.16.15.1. We have managed to send and receive packets
>> when connected to a public Wi-Fi network "Columbia University"
>>
>> Inline image 1
>>
>> However, when we tried connecting to any other public Wi-Fi
>> network, mobile hotspot, or LTE, we are unable to receive a map
>> reply after sending a map request. All of these networks work
>> fine when OOR is not running, and the wlan0 interface is always
>> selected. Here are screenshots:
>>
>> Inline image 2Inline image 3
>>
>> Please let us know if you have any insight regarding this
>> problem. I've also attached details of each Wi-Fi network we
>> tried connecting to - only "Columbia University" works when OOR
>> is running. Thanks in advance!
>>
>> Best regards,
>> Kevin
>>
>> On Thu, Apr 13, 2017 at 2:44 AM, Albert López <alopez at ac.upc.edu
>> <mailto:alopez at ac.upc.edu>> wrote:
>>
>> Hi Gaurav,
>>
>> In the testing branch, the code has been updated to be
>> compiled using android studio with gradle . The README has
>> not been updated but you just need to import the project in
>> Android Stuido ( the android folder of the project) and
>> compile from there.
>>
>> Best regards
>>
>> Albert
>>
>> El 12/04/17 a les 15:40, Gaurav Mishra ha escrit:
>>> Hi Albert,
>>>
>>> Is there any documentation on how to compile testing branch
>>> code. Because few files which are needed for compiling
>>> from(as in master branch) are missing in test branch.
>>>
>>> Regards,
>>> Gaurav
>>>
>>> On Wed, Apr 12, 2017 at 3:21 AM, Albert López
>>> <alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>> wrote:
>>>
>>> I think it should work. We used to do the test with
>>> android 4.3. The master branch doesn't have the last
>>> code and it is not ported to android studio. I recommend
>>> you to use the testing branch.
>>>
>>> Best regards
>>>
>>> Albert
>>>
>>>
>>> El 12/04/17 a les 03:14, Kevin Shen ha escrit:
>>>> Hi Albert,
>>>>
>>>> Thanks for the help. Quick question, since the new
>>>> behavior of routes being moved from the main routing
>>>> table to interface specific tables started in Android
>>>> 5.0, would that mean that OOR for rooted devices should
>>>> work for Android 4.4.4? Or does it not work for any
>>>> version of Android? We are compiling the code in the
>>>> master branch.
>>>>
>>>> Best regards,
>>>> Kevin
>>>>
>>>> On Fri, Apr 7, 2017 at 4:53 AM, Albert López
>>>> <alopez at ac.upc.edu <mailto:alopez at ac.upc.edu>> wrote:
>>>>
>>>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170508/4b570038/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 231470 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170508/4b570038/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 216705 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170508/4b570038/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 169558 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170508/4b570038/attachment-0005.png>
More information about the devel
mailing list