[OOR-Devel] [OOR maintainers] LISP Beta network allocation

Kevin Shen ks3206 at columbia.edu
Tue Apr 18 23:16:58 CEST 2017


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"

[image: 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:

[image: Inline image 2][image: Inline 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> 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> 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> 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> 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> 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>
>>>>> 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:
>>>>>>       - 0.0.0.0/1 dev lispTun0  proto static
>>>>>>       - 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>
>>>>>> 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>
>>>>>>> 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>
>>>>>>>> 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> <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/ 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/?r
>>>>>>>>> andomnick=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 listMaintainers at mail.openoverlayrouter.orghttp://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
>>
>>


-- 
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/20170418/543b4161/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 231470 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 169558 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 216705 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20170417-203851.png
Type: image/png
Size: 154791 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0010.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20170417-204024.png
Type: image/png
Size: 118759 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0011.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20170417-204252.png
Type: image/png
Size: 171129 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0012.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20170417-204436.png
Type: image/png
Size: 175348 bytes
Desc: not available
URL: <http://mail.openoverlayrouter.org/pipermail/devel/attachments/20170418/543b4161/attachment-0013.png>


More information about the devel mailing list