We're going to write on the web a list of tested routers, just for
helping the visitors to have an idea of the supported/recommended
routers without copying and pasting the whole list provided by
OpenWrt/LEDE.
The discussion on this is here:
https://github.com/libremesh/lime-web/pull/14
Please answer with the routers you tried with LibreMesh.
I played with:
TP-Link WDR3600
TP-Link WR1043ND-v1
Ubiquiti NanoBridge M5
Ubiquiti NanoStation M5 XM
Ubiquiti NanoStation LoCo M2
Hi Leonardo
This is to protect those who share their Internet connection with the mesh network from being responsible for other people's traffic. Streisand is amazing and the VPSs available on arubacloud.com only cost 1€ a month, the lowest price we have ever found, with the benefit of being close to us [they're located in Arezzo and we're in Milano] for very low latency and they have of course an IP recognized as Italian in all of the geoIP databases, so that users don't notice any difference when navigating to websites like Google that trace your ip location and adapt the language of their website.
Im getting speeds between 100 and 120mbps down with l2tp+ipsec on my Hex and that makes for a very good amount of bandwidth to be shared with the network.
Nicolas
Sent from Nine
________________________________
From: Leonardo Taborda <leonardotaborda(a)networkbogota.org>
Sent: Feb 16, 2017 23:46
To: lime-users(a)lists.libremesh.org
Subject: Re: [lime-users] VPN
>
> Hello Nicolas and Marvin
>
> This is really interesting, I had no idea about streisand. If you guys
> are setting up this in a mesh network, is it for browsing safely or
> taking advantage of the ease of setting up vpns?
>
> El 16/02/17 a las 10:00, Nicolas North escribió:
> > Hi again!
> >
> > I’m glad you received it this time and are testing it out.
> >
> > I definitely have no windows machines either ;]
> >
> > And actually you don’t need any configuration files for streisand.
> > Once you’ve set up your instance just navigate to your server’s web
> > address and log in with the provided credentials. Then when you see
> > this screen:
> >
> >
> > Select L2TP/IPsec. Then on the next screen press linux, and copy the
> > credentials you find there in the Hex admin page’s configuration in
> > the appropriate fields.
> >
> > That will get you up and running in no time. Remember to select max
> > MTU and RMU to 1280 if you’re getting fragmented packets [I for
> > instance could not access http://speedtest.net before I corrected
> > these values, exactly because of packet fragmentation].
> >
> > Let me know if you need any further help!
> >
> >
> > Nicolas
> >
> >
> > From: Marvin Arnold <marvin(a)unplugged.im> <mailto:marvin@unplugged.im>
> > Reply: libremesh users <lime-users(a)lists.libremesh.org>
> > <mailto:lime-users@lists.libremesh.org>
> > Date: 16 February 2017 at 15:49:26
> > To: lime-users(a)lists.libremesh.org <lime-users(a)lists.libremesh.org>
> > <mailto:lime-users@lists.libremesh.org>
> > Subject: Re: [lime-users] VPN
> >
> >> Thanks for resharing Nicolas, the original never did find my mailbox.
> >>
> >> We tried configuring this setup but hit a wall because we don't have
> >> windows machines. Is there no easy way to take the configuration
> >> files Streisand spits out and upload them directly to the hex?
> >> Alternatively, we're not sure what which settings to copy over from
> >> that file and put into the hex.
> >>
> >>
> >> On 02/15/2017 02:27 AM, Nicolas North wrote:
> >>> Hi Marvin
> >>>
> >>> I’m sorry but I’m having some serious spam issues since i’ve
> >>> migrated my mailserver.
> >>>
> >>> Here is the mail i had sent you. Hope you receive it!
> >>>
> >>> ––––––––––––––––
> >>>
> >>> Hi Marvin
> >>>
> >>> Sorry for the late reply.
> >>>
> >>> We’re using Hexes as vpn-only devices, with the following setup:
> >>>
> >>> ||| ISP Router ||| <=> ||| Hex VPN Router ||| <=> ||| LiMe Router |||
> >>> |
> >>> wifi adhoc
> >>> |
> >>> [other LiMe routers]
> >>>
> >>> This is the guide we’ve been following
> >>> [https://matthewmcclatchey.com/using-private-internet-accesss-vpn-with-mikro…],
> >>> with the exception of the fact that our vpn is lt2p+ipsec, and that
> >>> we’ve had to set max mtu and max mru values to 1280 for some reason
> >>> as packets were getting fragmented with our setup.
> >>>
> >>> If you connect a cable from the ISP’s router’s lan to the Hex’s wan,
> >>> and another cable from the Hex’s lan to the LiMe router’s wan,
> >>> you’ll have all of your internet-bound traffic from inside your mesh
> >>> network sandboxed inside the VPN with no exceptions. The hex has
> >>> some kind of "persistent tunnel” enabled by default, so drops the
> >>> connection if the vpn breaks for some reason, even though it never
> >>> has unless we actually rebooted the remote vpn server for testing
> >>> purposes.
> >>>
> >>> I suggest giving the Hex an address like 172.16.0.1 to avoid
> >>> conflicts with other more common subnets. We set all our ISP routers
> >>> to 192.168.0.1 and LiMe uses 10.13.0.1 etc… so we’re good to go.
> >>> Also, as a bonus, we try to pair all LiMe routers with an openwrt
> >>> “simple AP” router, that takes care of the AP level and lets the
> >>> LiMe router handle only the adhoc meshing level, for maximum
> >>> wireless efficiency.
> >>>
> >>> We give APs static addresses of 10.13.64.1, 2, 3, and so on. They
> >>> must all be different. Try and stay out of the DHCP range which
> >>> starts at 100 I think. This last part [the AP addressing] is all
> >>> trial and error and experimental so it might be wrong, but for us it
> >>> works. We still need to figure out how to scale addressing for APs
> >>> so we’re open to suggestions. While we’re at it:
> >>>
> >>> *TLDR question: what static IPv4 address to give a simple AP
> >>> connected to the lan of a LiMe router? Is 10.13.64.1 - 10.13.64.99 a
> >>> good range? How do we scale beyond that since every AP in the entire
> >>> network must have a different IP?*
> >>>
> >>> Let me know how this works for you. To those answering the question:
> >>> thank you in advance.
> >>>
> >>>
> >>> Nicolas
> >>>
> >>>
> >>>
> >>> From: Marvin Arnold <marvin(a)unplugged.im> <mailto:marvin@unplugged.im>
> >>> Reply: Marvin Arnold <marvin(a)unplugged.im> <mailto:marvin@unplugged.im>
> >>> Date: 14 February 2017 at 02:19:38
> >>> To: pau(a)dabax.net <pau(a)dabax.net> <mailto:pau@dabax.net>, nk(a)os.vu
> >>> <nk(a)os.vu> <mailto:nk@os.vu>
> >>> Subject: Re: [lime-users] VPN
> >>>
> >>>> Hi Pau, Nicolas,
> >>>>
> >>>> Maybe I'm losing my head, but I can't find the original email from
> >>>> Nicolas being quoted. It looks like it may be the additional VPN setup
> >>>> tips we are looking for. I've checked my spam and don't see any hidden
> >>>> messages...
> >>>>
> >>>>
> >>>> On 02/13/2017 06:43 PM, Ilario wrote:
> >>>> > Hi Nicolas!
> >>>> > I think I missed some of your emails in Gmail's spam folder...
> >>>> > Answer inline:
> >>>> >
> >>>> > 2017-02-13 1:51 GMT+01:00 Nicolas North <nk(a)os.vu>:
> >>>> >> Also, as a bonus, we try to
> >>>> >> pair all LiMe routers with an openwrt “simple AP” router, that
> >>>> takes care of
> >>>> >> the AP level and lets the LiMe router handle only the adhoc
> >>>> meshing level,
> >>>> >> for maximum wireless efficiency.
> >>>> > That's really wise :)
> >>>> >
> >>>> >> We give APs static addresses of 10.13.64.1, 2, 3, and so on.
> >>>> They must all
> >>>> >> be different. Try and stay out of the DHCP range which starts at
> >>>> 100 I
> >>>> >> think.
> >>>> > A very interesting question. There's no option for DHCP range in
> >>>> > /etc/config/lime* files (and this is ok).
> >>>> > But I supposed that the range was defined in /etc/config/dhcp, which
> >>>> > on LibreMesh is identical than on OpenWrt/LEDE and contains:
> >>>> > # cat /etc/config/dhcp
> >>>> > [...]
> >>>> > config dhcp 'lan'
> >>>> > option interface 'lan'
> >>>> > option start '100'
> >>>> > option limit '150'
> >>>> > option leasetime '1h'
> >>>> >
> >>>> > But trying to ask for a DHCP lease I received an IPv4 out of the
> >>>> > 10.x.x.100-250 range, looking around I found that the DHCP range for
> >>>> > anygw is hardcoded:
> >>>> >
> >>>> https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3…
> >>>> > resulting in the whole subnet... No good. @devs?
> >>>> >
> >>>> > Anyway, do you need static IP addresses at the AP routers? You could
> >>>> > also let them take the IP from LiMe (and LiMe would take care of
> >>>> > avoiding collisions).
> >>>> >
> >>>> > Additionally, if you let LiMe routers to autoassign their own IPv4,
> >>>> > they will span over the whole subnet, unless you specify a smaller
> >>>> > "subnet" (not a real subnet, just a range) for auto-assignment, as
> >>>> > explained in /etc/config/lime-example in the comment on the
> >>>> > main_ipv4_address option:
> >>>> >
> >>>> https://github.com/libremesh/lime-packages/blob/2ce5ffa96de5b0b5abb507076b0…
> >>>> >
> >>>> > For example:
> >>>> > # cat /etc/config/lime
> >>>> > config lime 'network'
> >>>> > option main_ipv4_address '10.13.128.0/16/17'
> >>>> >
> >>>> > will limit the autoassignment of IPv4 to the second half of the
> >>>> > broadcast domain.
> >>>> > Bye!
> >>>> > Ilario
> >>>> > _______________________________________________
> >>>> > lime-users mailing list
> >>>> > lime-users(a)lists.libremesh.org
> >>>> > https://lists.libremesh.org/mailman/listinfo/lime-users
> >>
> >> _______________________________________________
> >> lime-users mailing list
> >> lime-users(a)lists.libremesh.org
> >> https://lists.libremesh.org/mailman/listinfo/lime-users
> >
> >
> > _______________________________________________
> > lime-users mailing list
> > lime-users(a)lists.libremesh.org
> > https://lists.libremesh.org/mailman/listinfo/lime-users
>
> --
> Cordialmente
>
> Leonardo Taborda Ángel
> leonardotaborda(a)networkbogota.org
> www.networkbogota.org
>
> "When there is a will, there is a way"
>
>
>
Now we can start working on LibreMesh 17.03 :D
From: Jo-Philipp Wich <jo(a)mein.io>
To: LEDE Development List <lede-dev(a)lists.infradead.org>
Subject: [LEDE-DEV] LEDE v17.01.0 final
Hi,
The LEDE Community is proud to announce the first stable version of the
LEDE 17.01 version series.
LEDE 17.01.0 "Reboot" incorporates thousands of commits over the last
nine months of effort. With this release, the LEDE development team
closes out an intense effort to modernize many parts of OpenWrt and
incorporate many new modules, packages, and technologies.
---
Some selected highlights of this release are:
* Linux kernel updated to version 4.4.50 (from 3.18 in Chaos Calmer)
* Update of essential software:
* dnsmasq updated to 2.76 (from 2.73 in Chaos Calmer)
* busybox updated to 1.25.1 (from 1.23.2 in Chaos Calmer)
* mbedtls version 2.4.0 (from polarssl 1.3.14 in Chaos Calmer)
* openssl updated to 1.0.2k
* Improved Security Features
* Use SHA256 instead of MD5 to validate source code for packages
* mbedtls: disable SSLv3 support
* OpenSSL: disable support for compression, heartbeats, NPN,
Whirlpool, and J-PAKE
* Memory Corruption Mitigation Methods
* gcc -Wformat -Wformat-security
* User space Stack-Smashing Protection (Regular)
* Kernel space Stack-Smashing Protection (Regular)
* buffer-overflows detection (FORTIFY_SOURCE) (Conservative)
* RELRO protection (Full)
* Improved Networking Support
* Smart Queue Management (SQM) minimizes bufferbloat by using the
cake and fq_codel qdisc's.
* Improvements to the WiFi stack eliminating bufferbloat on ath9k,
mt76 and some ath10k chipsets
* Airtime fairness scheduler for ath9k to prevent slow stations
from hogging too much airtime
* Various stability and regression fixes to the Linux wireless
stack and ath9k in particular
* Provide alternative Candela-Tech ath10k-ct driver
* IPv6 hardening
* Updated toolchain
* musl 1.1.16
* gcc 5.4.0
* binutils 2.25.1
* Platform and Driver Support
* Lantiq
* Added redistributable DSL firmware
* Updated DSL phy drivers
* Added new targets:
* apm821xx (AppliedMicro APM821xx)
* arc770 (Synopsys DesignWare ARC 770D)
* archs38 (Synopsys DesignWare ARC HS38)
* armvirt (QEMU ARM Virtual Machine)
* ipq806x (Qualcomm Atheros IPQ806X)
* layerscape (NXP Layerscape)
* zynq (Xilinx Zynq 7000 SoCs)
* Reorganized x86 target:
* Drop dedicated Xen DomU target, merged with x86/generic
* Enable AES-NI support
* Removed targets:
* realview, replaced by armvirt
* ppc44x, disabled due to code brokeness
* netlogic, dropped due to no available hardware
* Build system improvements
* Separation of base system and community feeds to simplify
distribution of binary package updates
* Fixes and enhancements in package dependency handling, better
support for virtual provides
* Per-device rootfs images to better tune package selection to each
individual device profile
* New image build code improving compilation times and simplifying
device profile declarations
* New package/.../check make target to run a series of standard
diagnostics on Makefiles
* Support for fetching sources using Curl
* Generate reproducible source tarballs when packing SCM checkouts
* Image Builder / SDK
* Rework library bundling to allow for better portability between
different Linux distributions
* Add support for building kernel modules using the SDK
* Added support for a many new routers and boards
For a detailed list of changes since 17.01.0-rc2 refer to
https://lede-project.org/releases/17.01/changelog-17.01.0-final
For a complete list of changes since the start of the LEDE project, see
https://lede-project.org/releases/17.01/changelog-17.01.0
---
Known issues:
* Available space on devices with only 4MB flash is very low,
users requiring extra packages might want to consider using the
image builder to repack custom images
* The available memory on devices with 32MB RAM might be too low to
reliably run opkg or sysupgrade operations, especially in
conjunction with LuCI
* Any outstanding issues reported at https://bugs.lede-project.org/
---
For latest information about the 17.01 series, refer to the wiki at:
https://lede-project.org/releases/17.01/
To download the v17.01.0 images, navigate to:
https://downloads.lede-project.org/releases/17.01.0/
---
A big thank you goes to all our active package maintainers, testers,
documenters and supporters.
Have fun!
The LEDE Community
Hi,
is now 5 days we are trying to register to the chef platform and we get
the following error, (user and password included).
check it out:
> error at /accounts/register/
>
> [Errno 113] No route to host
>
> Request Method: POST
> Request URL: https://chef.altermundi.net/accounts/register/?next=/
> Django Version: 1.4.5
> Exception Type: error
> Exception Value:
>
> [Errno 113] No route to host
>
> Exception Location: /usr/lib/python2.7/socket.py in create_connection, line 571
> Python Executable: /home/openwrt/altermeshfc/venv/bin/python
> Python Version: 2.7.3
> Python Path:
>
> ['/home/openwrt/altermeshfc/altermeshfc/altermeshfc',
> '/home/openwrt/altermeshfc/altermeshfc',
> '/home/openwrt/altermeshfc/venv/bin',
> '/home/openwrt/altermeshfc/venv/local/lib/python2.7/site-packages/distribute-0.6.24-py2.7.egg',
> '/home/openwrt/altermeshfc/venv/local/lib/python2.7/site-packages/pip-1.1-py2.7.egg',
> '/home/openwrt/altermeshfc/venv/lib/python2.7',
> '/home/openwrt/altermeshfc/venv/lib/python2.7/plat-linux2',
> '/home/openwrt/altermeshfc/venv/lib/python2.7/lib-tk',
> '/home/openwrt/altermeshfc/venv/lib/python2.7/lib-old',
> '/home/openwrt/altermeshfc/venv/lib/python2.7/lib-dynload',
> '/usr/lib/python2.7',
> '/usr/lib/python2.7/plat-linux2',
> '/usr/lib/python2.7/lib-tk',
> '/home/openwrt/altermeshfc/venv/local/lib/python2.7/site-packages',
> '/home/openwrt/altermeshfc/venv/local/lib/python2.7/site-packages/IPython/extensions']
>
> Server time: Tue, 28 Feb 2017 20:48:32 +0000
Can you please have a look ?
thanks.
bye
--
ɐqɯ@s
Let's organize a couple of meetings for getting this 17.02 release done!
I suggest to meet one weekend as soon as possible and another one in April.
Here you are the website for expressing your availability (this time the
results will be hidden, for the sake of participants' privacy):
https://framadate.org/LiMeCat2017q1q2
The venue will be in Valldoreix (Bcn), not yet exactly defined.
See you!
Ilario
This is a super good news!
We're in, now we just need students!
-------- Forwarded Message --------
Subject: [Battlemesh] GSoC 2017 - Freifunk accepted!
Date: Mon, 27 Feb 2017 22:33:48 +0100
From: Andreas Bräu <ab(a)andi95.de>
To: battlemesh(a)ml.ninux.org
Hi there,
today Google announced the organizations they choosed for GSoC 2017. I’m
happy to tell you: Freifunk is again accepted as mentoring organization
for Google Summer of Code together with 200 other OpenSource
organizations! Our friends from OpenWISP.org got accepted, too! Thanks
to all who helped making this application successful: those who
collected all the ideas (this year we have really a lot of ideas!),
those who talked to possible mentors and those who wrote the application
texts.
>From now on students can find us on the GSoC Website, and we should
start talking to students that want to propose projects to freifunk. If
you know students, point them to our Ideas page
at https://wiki.freifunk.net/Ideas so they can get in touch with our
mentors.
The official Students Application period will start on March, 20. Then
students can start submitting their applications.
As a next step we’ll add the possible mentors to a mailing list.
If you have any questions regarding GSoC, our ideas or as organization,
please don’t hesitate to ask!
Best regards,
Andi
---------- Forwarded message ----------
From: Monic Meisel <monic(a)monic.de>
Date: 2017-02-23 16:34 GMT+01:00
Subject: [Battlemesh] WCW - Call for participation
To: Battle of the Mesh Mailing List <battlemesh(a)ml.ninux.org>,
Deutschlandweite Liste für WLAN Neuigkeiten <wlannews(a)freifunk.net>
Cc: mitglieder(a)foerderverein.freie-netzwerke.de
Dear community activists and friends,
The WirelessCommunityWeekend will follow the 13 years of tradition
also in 2017 and take place in the c-base space station in Berlin.
>From the 26th to the 28th of May the Freifunk community will meet with
their guests to create an unconference and hackathon.
How to WCW
> Add your nick/name and meal prefences to participants page
https://wiki.freifunk.net/Wireless_Community_Weekend_2017/Participants
> Add your session and timeslot to
https://wiki.freifunk.net/Wireless_Community_Weekend_2017/Timetable
> Looking for accommodation or for offering a couch, use
https://wiki.freifunk.net/Wireless_Community_Weekend_2017/Accomodation
> Invite people that may be interested or you find interesting to meet
> Use #ffwcw as hashtag on twitter to spread the event
> Forward this mail also to other channels, groups
> Add your endorsement here
https://wiki.freifunk.net/Wireless_Community_Weekend_2017/Endorsements
> Land around 12:00 at the space station
> There is free coffee but no free beer* :p
> Do only smoke outside the building
> Get an eco, fair-trade Freifunk Hoodie or Tee close to the cost price
> Donate food specialties** or EUR for the endless BBQ on site
> Have fun and make new friends :))
The first program points are already there and some more ideas ... so
we are looking forward to your contribution and meeting you in Berlin!
<3 Monic
*Of course you can buy some, if there is a bar-bot
** Please tell upfront, since we need to calculate the meals
_______________________________________________
Battlemesh mailing list
Battlemesh(a)ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh
Hi there!
I discovered your truly fantastic project through Ninux. I’m creating a mesh network here in Milano, Italia, with my project openspace. We are trying to build something truly scalable that could one day work all over the city. We started out with the excellent Commotion, and have moved onto a MetaMesh-like setup with pure openwrt and manual configurations for a lack of pre-compiled images of Commotion.
I’ve now discovered your project which seems to be a dream come true, which is Commotion-like ease of creation and deployment, but with much wider compatibility. If I manage to embrace and understand this new world outside of olsr and if we can get a few details figured out I really think this could be the definitive way to go, at least for the time being.
You can check out the details of our current MetaMesh-like configuration here should you be curious: https://openspacex.github.io/openNET.io [temporary address]. It basically adds on top of MetaMesh to try and reach Commotion’s configuration flexibility, like WPA2 on AP and MESH levels, olsrd-secure, and other nifty little details. The writing of this howto is a work in progress, but we should be finished in about a week.
All of this is the result of over a year of work on our part, thank to all of the amazing projects like yours out there. While approaching your project as a total newbie that has only worked with Commotion and MetaMesh, is there anything in the large scale that works so fundamentally differently in libremesh from how our previous setup works, that we should be considering before starting out?
If we start using LiMe to our network, we’d like to introduce WPA2 encryption on the AP and MESH wireless networks. And is it possible to separate the 2.4ghz and 5ghz MESH wireless networks SSIDs? Also, do you authenticate nodes on the network, like olsrd-secure does? If so, how? Is it possible to change the ssh port of the various nodes [security-by-obscurity self-alert]?
To better explain, we’re always trying to figure out how to make the infrastructure solid and resilient, and how to protect traffic and authenticate devices with more advanced crypto than simple symmetric keys [like the very WPA2 on mesh level and olsrd-secure passphrase that I’m inquiring about] that will leak in a matter of days after we start using them, so we’re the first to recognise the weakness of these protections, but they could be considered better than nothing perhaps? Do you have any other ideas?
At the risk of going off-topic, may I ask what your approach to security matters like this is? In terms of traffic security, device authentication, and network-wide resistance to “attacks”? What are the weak spots of the protocols you’re using here, in the event of someone actually trying to take down a part of the network? I ask because I know that with olsr for instance it’s enough to set an already-in-use static IP to a device to break the meshing in a serious way, like in traditional networks. How are things here instead? A friend of mine was thinking of using a blockchain to authenticate the various routers entering the network, towards the dream of a network that can’t be stopped by anyone or anything, exactly like bitcoin.
Anyway, back to us. How can I specify these extra details in the config file? I’m obviously happy to dig through documentation, but I have found nothing specific enough for my understanding. I’ve been able to change some parameters in chef under /etc/config/lime-defaults, but not all. I might be completely misunderstanding some fundamental details here, please excuse my ignorance.
Thank you so much in advance and super-kudos for your amazing work in any event!
Nicolas
Thanks for resharing Nicolas, the original never did find my mailbox.
We tried configuring this setup but hit a wall because we don't have
windows machines. Is there no easy way to take the configuration files
Streisand spits out and upload them directly to the hex? Alternatively,
we're not sure what which settings to copy over from that file and put
into the hex.
On 02/15/2017 02:27 AM, Nicolas North wrote:
> Hi Marvin
>
> I’m sorry but I’m having some serious spam issues since i’ve migrated
> my mailserver.
>
> Here is the mail i had sent you. Hope you receive it!
>
> ––––––––––––––––
>
> Hi Marvin
>
> Sorry for the late reply.
>
> We’re using Hexes as vpn-only devices, with the following setup:
>
> ||| ISP Router ||| <=> ||| Hex VPN Router ||| <=> ||| LiMe Router |||
> |
> wifi adhoc
> |
> [other LiMe routers]
>
> This is the guide we’ve been following
> [https://matthewmcclatchey.com/using-private-internet-accesss-vpn-with-mikro…],
> with the exception of the fact that our vpn is lt2p+ipsec, and that
> we’ve had to set max mtu and max mru values to 1280 for some reason as
> packets were getting fragmented with our setup.
>
> If you connect a cable from the ISP’s router’s lan to the Hex’s wan,
> and another cable from the Hex’s lan to the LiMe router’s wan, you’ll
> have all of your internet-bound traffic from inside your mesh network
> sandboxed inside the VPN with no exceptions. The hex has some kind of
> "persistent tunnel” enabled by default, so drops the connection if the
> vpn breaks for some reason, even though it never has unless we
> actually rebooted the remote vpn server for testing purposes.
>
> I suggest giving the Hex an address like 172.16.0.1 to avoid conflicts
> with other more common subnets. We set all our ISP routers to
> 192.168.0.1 and LiMe uses 10.13.0.1 etc… so we’re good to go. Also, as
> a bonus, we try to pair all LiMe routers with an openwrt “simple AP”
> router, that takes care of the AP level and lets the LiMe router
> handle only the adhoc meshing level, for maximum wireless efficiency.
>
> We give APs static addresses of 10.13.64.1, 2, 3, and so on. They must
> all be different. Try and stay out of the DHCP range which starts at
> 100 I think. This last part [the AP addressing] is all trial and error
> and experimental so it might be wrong, but for us it works. We still
> need to figure out how to scale addressing for APs so we’re open to
> suggestions. While we’re at it:
>
> *TLDR question: what static IPv4 address to give a simple AP connected
> to the lan of a LiMe router? Is 10.13.64.1 - 10.13.64.99 a good range?
> How do we scale beyond that since every AP in the entire network must
> have a different IP?*
>
> Let me know how this works for you. To those answering the question:
> thank you in advance.
>
>
> Nicolas
>
>
>
> From: Marvin Arnold <marvin(a)unplugged.im> <mailto:marvin@unplugged.im>
> Reply: Marvin Arnold <marvin(a)unplugged.im> <mailto:marvin@unplugged.im>
> Date: 14 February 2017 at 02:19:38
> To: pau(a)dabax.net <pau(a)dabax.net> <mailto:pau@dabax.net>, nk(a)os.vu
> <nk(a)os.vu> <mailto:nk@os.vu>
> Subject: Re: [lime-users] VPN
>
>> Hi Pau, Nicolas,
>>
>> Maybe I'm losing my head, but I can't find the original email from
>> Nicolas being quoted. It looks like it may be the additional VPN setup
>> tips we are looking for. I've checked my spam and don't see any hidden
>> messages...
>>
>>
>> On 02/13/2017 06:43 PM, Ilario wrote:
>> > Hi Nicolas!
>> > I think I missed some of your emails in Gmail's spam folder...
>> > Answer inline:
>> >
>> > 2017-02-13 1:51 GMT+01:00 Nicolas North <nk(a)os.vu>:
>> >> Also, as a bonus, we try to
>> >> pair all LiMe routers with an openwrt “simple AP” router, that
>> takes care of
>> >> the AP level and lets the LiMe router handle only the adhoc
>> meshing level,
>> >> for maximum wireless efficiency.
>> > That's really wise :)
>> >
>> >> We give APs static addresses of 10.13.64.1, 2, 3, and so on. They
>> must all
>> >> be different. Try and stay out of the DHCP range which starts at
>> 100 I
>> >> think.
>> > A very interesting question. There's no option for DHCP range in
>> > /etc/config/lime* files (and this is ok).
>> > But I supposed that the range was defined in /etc/config/dhcp, which
>> > on LibreMesh is identical than on OpenWrt/LEDE and contains:
>> > # cat /etc/config/dhcp
>> > [...]
>> > config dhcp 'lan'
>> > option interface 'lan'
>> > option start '100'
>> > option limit '150'
>> > option leasetime '1h'
>> >
>> > But trying to ask for a DHCP lease I received an IPv4 out of the
>> > 10.x.x.100-250 range, looking around I found that the DHCP range for
>> > anygw is hardcoded:
>> >
>> https://github.com/libremesh/lime-packages/commit/3a6596d50b3c0446b988f84d3…
>> > resulting in the whole subnet... No good. @devs?
>> >
>> > Anyway, do you need static IP addresses at the AP routers? You could
>> > also let them take the IP from LiMe (and LiMe would take care of
>> > avoiding collisions).
>> >
>> > Additionally, if you let LiMe routers to autoassign their own IPv4,
>> > they will span over the whole subnet, unless you specify a smaller
>> > "subnet" (not a real subnet, just a range) for auto-assignment, as
>> > explained in /etc/config/lime-example in the comment on the
>> > main_ipv4_address option:
>> >
>> https://github.com/libremesh/lime-packages/blob/2ce5ffa96de5b0b5abb507076b0…
>> >
>> > For example:
>> > # cat /etc/config/lime
>> > config lime 'network'
>> > option main_ipv4_address '10.13.128.0/16/17'
>> >
>> > will limit the autoassignment of IPv4 to the second half of the
>> > broadcast domain.
>> > Bye!
>> > Ilario
>> > _______________________________________________
>> > lime-users mailing list
>> > lime-users(a)lists.libremesh.org
>> > https://lists.libremesh.org/mailman/listinfo/lime-users
Hi Marvin
I've done a lot of tests with VPNs for the standard setup of the mesh network we're building here in Milano, Italia, and I've found that usually routers are rather terrible at handling VPNs with reasonable speeds, openvpn being the slowest [10mbps up and down] and l2tp+ipsec being faster [15 to 20mbps], at the expense of being less secure. Also, I've gotten to the conclusion that doing the VPN routing in the same device as the one doing the meshing makes it rather difficult to diagnose issues over time and to pinpoint the bottleneck for slow overall speeds.
I know this is not the answer you were looking for, but our definitive setup involves setting up getting a microtik hex router that you can buy for about 60 to 80€ and running l2tp+ipsec to a Streisand instance [a fully self installing VPN and anonymity server]. We've been getting stable 120/120mbps speeds.
This setup also makes it very simple to understand what device is doing what, and how the routing is done on the large scale from the ISPs router, to the VPN router, to the meshing router, to the AP router, and so on [this is our setup].
I don't know how to solve your problem directly, but I thought I'd share my experience with you. Sorry for going slightly off topic.
Hope you can get your setup working nicely however you decide to do it!
Nicolas
________________________________
From: Marvin Arnold <marvin(a)unplugged.im>
Sent: Jan 31, 2017 06:34
To: lime-users(a)lists.libremesh.org
Subject: [lime-users] VPN
>
> I would like to finally make my internet at home available to my
> neighbors over lime. I called my ISP and they made it pretty clear they
> would take action against me if one of the users accessed illicit
> content. So I'm thinking about routing all web traffic through a VPN. Is
> this the most sensible thing to do?
>
> Assuming it is, I already setup the VPN server and now I'm trying to
> connect my lime router as a client.
>
> http://wiki.openwrt.org/inbox/vpn.howto
>
> https://www.robertkehoe.com/2015/08/setup-openvpn-using-openwrt/
>
> But as far as I can tell, opkg is not installed on the router. What's
> the best way to install it or install the openvpn client without it?
>
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
