Hi,
Ultimately, I would like to get rid of the double SSID broadcasting, and have only our mesh network name as SSID no matter what nodes.
I see how to do that from Luci or the config. But then I'm not sure how I would acces a particular node Luci UI.
What am I missing?
Thanks,
Antoine
Hi,
I just added some detail to a open issue for luci:
https://github.com/openwrt/luci/issues/1192
Basically I cannot set a password on a fresh 17.01.02 install for mini. normal disbrib works fine.
Do you have any workaround for that issue?
Thanks!
Antoine
Hi
In order to understand how to start using 802.11s from SDK, I’ve downloaded a pre-built image from http://repo.libremesh.org/lime-17.04/ [downloads.libremesh.org isn’t responding at least for me - I think I need a 17.02 version to compare with an SDK output, no?].
I’ve noticed a few changes such as the directory /etc/config/ becoming /etc/lime-config-firstboot/ and more in luci-defaults and so on.
Do you have a list of changes?
How do I maintain a https://github.com/libremesh/network-profiles/ community in a way that is future-consistent?
I’d like to be able to have details in there that really only override things I’ll always want to override, such as the SSID, but allow for all other file changes [like adhoc becoming 802.11s for instance] from upstream to pour down into my SDK images, with no interference at all and no risk of having conflicts. Also because images I’m building now, once flashed, don’t work at all, so there is a big risk in upstream changes conflicting with network-profiles, don’t you think?
I know this means a line-based granularity and not a file-based one such as now, but there must be a way, no?
In any event, for now, what changes do I have to make to my community files in order to get SDK to cook valid and up-to-date in every way images?
Thank you!
Nk
Hello all
I am new to the LibreMesh hacking community.
I am trying to build the LibreMesh firmware so as to format my router with
it.
I have followed All instructions as stated here
https://github.com/libremesh/lime-sdk
and all seems good.
When I try to build the packages using the command ./cooker -b
ar71xx/generic
I get the error
*make -r world: build failed. Please re-run make with -j1 V=s to see what's
going on/home/nges/lime-sdk/lede/ar71xx/generic/sdk/include/toplevel.mk:200
<http://toplevel.mk:200>: recipe for target 'world' failedmake: *** [world]
Error 1make: Leaving directory
'/home/nges/lime-sdk/lede/ar71xx/generic/sdk'-> Error compiling SDK*
I have tried looking for a solution from the internet but I have not
gotten any concrete solution .
Please anyone with any Idea of how I can solve this problem ??
I am using Ubuntu 15.10 , 64Bits OS
Thanks and waiting to hear from you
At your Service
Nges Brian
"A Goal is a Dream with a Plan and a Dateline"
Do On to Others what you will like them to do on to you.'The Golden Rule'
The CEO of ABEBOH
Computer Software Engineering Student
Music DJ . Artiste at Casky Black's Record
Regional Coordinator and CAC Member at Mozilla Campus Club Program.
Hi all!
Seems that [1] we want to deprecate the use of Tip4commit [2] for
receiving donations.
So we need to re-discuss the way for receiving donations and how to
use them (in tip4commit it was straightforward, 1% of the donations
was delivered for each commit to the committer).
I would suggest to not restrict donations to bitcoin, as it was in tip4commit.
Ideas on how to receive them? Platforms?
Clearly the platform for collecting donations could restrict their use
(e.g. Bountysource [3] gives donations to issues solvers).
How we could use donations?
A few ideas:
* not defined, each time someone needs funds asks and the community decides
* helping developers to survive, dedicate more time to LiMe and
dignify their volunteer work (this is what tip4commit did)
* encourage non developers to get into the code, implement stuff,
debug and write documentation (e.g. I suppose Bountysource would have
this effect)
* contributing to server maintaining costs (up to now we use them as
freeloaders, hosting communities (qMp and Altermundi I think) let us
use their servers for free)
* produce loads of stickers and super cool LiMe t-shirts...
* organize internationals LiMe hackatons and pay travelling (up to now
LiMeCat meetings were zero budget events)
* pay travelling and food for developers attending BattleMesh or other
related events
* buy routers to test support (Pau and Daniel have some)
* build a small real network for continuous testing of develop branch
(it would be great to have an university collaborating on this)
[1] https://github.com/libremesh/lime-packages/pull/165https://github.com/libremesh/lime-web/pull/27
[2] https://tip4commit.com/github/libremesh%2Flime-packages/
the donation fund present in tip4commit will continue working until emptiness
[3] https://www.bountysource.com/
Hi all!
Here in Hackmeeting-it [1] we reflashed every router in the original
network setup with LibreMesh :D
We used unstable image taken from repo.libremesh.org using 802.11s and
up to now works perfect with 30 clients :D
Bye!
Ilario
[1] https://hackmeeting.org/hackit17/
Hi all! Sorry for the very brief OT. I've finally arrived at Hackmeeting and I'm seeing a whole lotta LiMe networks! Among you who all is here? It'd be so cool to actually meet you finally ;]
Thanks in advance!
Nk
________________________________
From: bruno vianna <bruno(a)pobox.com>
Sent: Jun 17, 2017 3:58 PM
To: libremesh users
Subject: Re: [lime-users] Hackmeeting-it
What a mix!
On Fri, Jun 16, 2017 at 10:58 PM, Ilario Gelmetti <iochesonome(a)gmail.com> wrote:
> We're using TP-Link WDR3600, TP-Link WDR4300, Ubiquiti NanoStation M5
> XW, Ubiquiti NanoStation M5 LoCo XM, Ubiquiti NanoStation M2 XW, Unifi
> AP AC LR (yes, it's working! But the flashing procedure has to be
> carefully followed), TP-Link CPE220, TP-Link WR1043ND v4
>
> I was willing to try to compile also for TP-Link WDR4900 (which is not
> currently in the lime-sdk available profiles) but lime-sdk has some new
> problem. Seems like a compatibility issue between old version of
> libwebsockets and a new version of cyassl/wolfssl, used by the new LiMe
> web interface...
>
> On 06/16/2017 10:02 PM, bruno vianna wrote:
>> Which routers are you using?
>>
>> Em 16 de jun de 2017 4:20 PM, "Ilario Gelmetti" <iochesonome(a)gmail.com
>> <mailto:iochesonome@gmail.com>> escreveu:
>>
>> The graph is a screenshot from the LuCI web interface of the routers,
>> you can find it in the BMX6/Graph menu :)
>>
>> The number "30" were the clients, I meant smartphones and laptops (now
>> the number increased). I don't know if there's a graph including those.
>> I _suppose_ it can be obtained using batadv-vis.
>> https://www.open-mesh.org/projects/alfred/wiki/Batadv-vis
>> <https://www.open-mesh.org/projects/alfred/wiki/Batadv-vis>
>> But when I try to use it I get an error:
>>
>> # batadv-vis -s
>> can't connect to unix socket: Connection refused
>>
>> Now we're going to deploy 4-6 more routers for covering more area.
>>
>>
>>
>> On 06/16/2017 08:42 PM, Paul Spooren wrote:
>> > Aw snap, I mean picture :)! Was it auto created?
>> > It just shows 4 nodes, do you have a picture of the full setup with 30
>> > nodes?
>> >
>> > Thanks!
>> >
>> > On 16.06.2017 20:40, Ilario Gelmetti wrote:
>> >> Hey!
>> >> I didn't, as I wrote in the email I downloaded the image from
>> >> repo.libremesh.org <http://repo.libremesh.org>
>> >> When I try to compile it with lime-sdk I'm having problems:
>> >>
>> >> make[3] -C
>> /home/ilario/software/lime-sdk/feeds/limeui/libwebsockets compile
>> >> make -r world: build failed. Please re-run make with -j1 V=s to see
>> >> what's going on
>> >> make: ***
>> >>
>> [/home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/include/toplevel.mk:193
>> <http://toplevel.mk:193>:
>> >> world] Error 1
>> >>
>> >> cd 17.01.2/ar71xx/generic/sdk
>> >> make -r world
>> >>
>> >> make[3]: Entering directory
>> >> '/home/ilario/software/lime-sdk/feeds/limeui/libwebsockets'
>> >> if [ -f
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/staging_dir/target-mips_24kc_musl-1.1.16/pkginfo/libwebsockets.cyassl.install.clean
>> >> ]; then rm -f
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/staging_dir/target-mips_24kc_musl-1.1.16/pkginfo/libwebsockets.cyassl.install
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/staging_dir/target-mips_24kc_musl-1.1.16/pkginfo/libwebsockets.cyassl.install.clean;
>> >> fi
>> >> mkdir -p
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/bin/targets/ar71xx/generic/packages
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/build_dir/target-mips_24kc_musl-1.1.16/libwebsockets-0c7e5a94182b8bf5b5be2fc58141466bf54d5812/ipkg-mips_24kc/libwebsockets-cyassl/CONTROL
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/staging_dir/target-mips_24kc_musl-1.1.16/pkginfo
>> >> install -d -m0755
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/build_dir/target-mips_24kc_musl-1.1.16/libwebsockets-0c7e5a94182b8bf5b5be2fc58141466bf54d5812/ipkg-mips_24kc/libwebsockets-cyassl/usr/lib
>> >> cp -fpR
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/build_dir/target-mips_24kc_musl-1.1.16/libwebsockets-0c7e5a94182b8bf5b5be2fc58141466bf54d5812/ipkg-install/usr/lib/libwebsockets.so*
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/build_dir/target-mips_24kc_musl-1.1.16/libwebsockets-0c7e5a94182b8bf5b5be2fc58141466bf54d5812/ipkg-mips_24kc/libwebsockets-cyassl/usr/lib/
>> >> find
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/build_dir/target-mips_24kc_musl-1.1.16/libwebsockets-0c7e5a94182b8bf5b5be2fc58141466bf54d5812/ipkg-mips_24kc/libwebsockets-cyassl
>> >> -name 'CVS' -o -name '.svn' -o -name '.#*' -o -name '*~'| xargs
>> -r rm -rf
>> >> Package libwebsockets-cyassl is missing dependencies for the
>> following
>> >> libraries:
>> >> libz.so.1
>> >> make[3]: *** [Makefile:116:
>> >>
>> /home/ilario/software/lime-sdk/17.01.2/ar71xx/generic/sdk/bin/packages/mips_24kc/limeui/libwebsockets-cyassl_0c7e5a94182b8bf5b5be2fc58141466bf54d5812-1_mips_24kc.ipk]
>> >> Error 1
>> >>
>> >> We're going to deploy more routers (see attached image, work
>> going on).
>> >>
>> >> An interesting thing we noticed:
>> >> using 802.11s for link layer the network doesn't fragment as expected
>> >> when changing the ESSID (using adhoc it was the preferred method for
>> >> splitting networks in layer 2 routing) as the domain now is
>> defined by
>> >> ieee80211s_mesh_id [1]. I suppose we should change this default or
>> >> re-discuss this mechanism for splitting L2 network.
>> >>
>> >> [1]
>> >>
>> https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste…
>> <https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste…>
>> >>
>> >>
>> >> On 06/16/2017 05:48 PM, Paul Spooren wrote:
>> >>> HI Ilario, how did you created the image?
>> >>>
>> >>> Cheers,
>> >>> Paul
>> >>>
>> >>> On 16.06.2017 16:59, Ilario Gelmetti wrote:
>> >>>> Hi all!
>> >>>> Here in Hackmeeting-it [1] we reflashed every router in the
>> original
>> >>>> network setup with LibreMesh :D
>> >>>> We used unstable image taken from repo.libremesh.org
>> <http://repo.libremesh.org> using 802.11s and
>> >>>> up to now works perfect with 30 clients :D
>> >>>> Bye!
>> >>>> Ilario
>> >>>>
>> >>>> [1] https://hackmeeting.org/hackit17/
>> <https://hackmeeting.org/hackit17/>
>
>
> _______________________________________________
> lime-users mailing list
> lime-users(a)lists.libremesh.org
> https://lists.libremesh.org/mailman/listinfo/lime-users
--
bruno(a)pobox.com ▀─█▄██▄▀▄
http://brunovianna.net ─█▄██▄▀█▀█▄
skype: randomico▀─█▄██▄▀█▀█▄▌██─█▌█▌
_______________________________________________
lime-users mailing list
lime-users(a)lists.libremesh.org
https://lists.libremesh.org/mailman/listinfo/lime-users
