[OOR-Devel] [OOR maintainers] LISP Beta network allocation
Albert López
alopez at ac.upc.edu
Wed Apr 19 09:24:11 CEST 2017
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
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170419/d2b3bb45/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/20170419/d2b3bb45/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/20170419/d2b3bb45/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/20170419/d2b3bb45/attachment-0005.png>
More information about the devel
mailing list