[OOR-Devel] [OOR maintainers] LISP Beta network allocation
Albert López
alopez at ac.upc.edu
Thu Apr 13 08:44:10 CEST 2017
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
>>>>>
>>>>> --
>>>>> 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/20170413/3771ff9b/attachment-0001.html>
More information about the devel
mailing list