Re: [lime-users] TODO and Pad for LiMeCat2017q1

2017-03-04 13:15 GMT+01:00 Ilario Gelmetti <iochesonome(a)gmail.com>om>: I copy and paste the pad sorted by assigned person, there are many easy tasks if you want to go for them :) (sorry for cross posting) =================== Whoever can do this ------------------- == Improve online documentation == Fill the gaps in the quick starting guide and add examples of common configs (e.g. 1 port router, set the port as WAN) Add link to Italian translation (NinuxBO) Complete the big tested hardware table http://libremesh.org/docs/hardware/index.html == Test LibreNet6 into LibreMesh and produce documentation on the process == This can be useful for GSoC project on LibreNet6 implementation in LibreMesh https://wiki.freifunk.net/Ideas#LibreMesh_LibreNet6_integration There are users trying it: https://lists.libremesh.org/pipermail/lime-users/2017-March/000400.html Gui and Nico are needed for deciding criteria for delivering /64 from LibreNet6 == WPA access point for clients and for backbone == Thread: https://lists.libremesh.org/pipermail/lime-users/2017-January/000325.html GSoC idea: https://wiki.freifunk.net/Ideas#LibreMesh_WPA2_and_802.11s_mesh_encryption_… It is already supported for AP and client, just we need to document it. == Advertisement of student positions in GSoC program == If we don't advertise it and we're not present in IRC channel for answering them, we'll have just a few students General mailing list for Freifunk's GSoC: http://lists.freifunk.net/mailman/listinfo/wlanware-freifunk.net hackmeeting-es (Ilario) hackmeeting-it (???) guifi-users (Al) hacklab Dontpanic (Al, Gio) eigenLab (Ilario) retroshare forums (Gio) student application period: March 20th - April 3rd suggesting to contact via lime-users list (our presence in IRC is quite scarce) == Use Gio's thesis for lime-web == adapt contents and insert them in lime-web and fix link to the thesis s/~gioacchino/~gio/ in lime-web ===================================================== Whoever can do this but I will do if no one else does ----------------------------------------------------- == Improve offline documentation == Add a reminder for "lime-config" command in the header of the configuration files == lime-build: mt7621 not an available target == just add that target in the available targets in targets.mk https://github.com/libremesh/lime-build/issues/15 This has already been fixed by Pau in f92c2d5 in develop but that commit is not present in branch 17.02 Do a new PR adding just this, ask for merge in 17.02 == lime-build: make bin-clean == A make option for deleting binary images in build/src/bin directory can be useful and should be part of the make process for avoiding confusion: https://lists.libremesh.org/pipermail/lime-users/2017-February/000373.html make clean is not the same as deletes a lot of stuff that has to be compiled again == Add spaces and client_encryption 'psk' to lime-example == https://github.com/libremesh/lime-packages/blob/develop/packages/lime-syste… == lime-build: specify profile in make menuconfig in readme == https://lists.libremesh.org/pipermail/lime-users/2017-February/000371.html == lime-build: Avoid error from make if targets/*.kernel is absent for the current target == https://lists.libremesh.org/pipermail/lime-users/2017-February/000389.html Decision: put an IF before the cp statement ============= I can do this ------------- == Update and reopen lime-example update PR == https://github.com/libremesh/lime-packages/pull/67 ================ Devs can do this ---------------- == Add an option for customizing DHCP range == https://github.com/libremesh/lime-packages/issues/33 https://lists.libremesh.org/pipermail/lime-users/2017-February/000377.html https://lists.libremesh.org/pipermail/lime-dev/2017-February/000842.html == Merge and close PR on IPv6 GW detection == https://github.com/libremesh/lime-packages/pull/71 == Check compatibility with new versions of LuCI == Verify the PR and check for other similar issues https://github.com/libremesh/lime-packages/issues/73 == luci-app-batman-adv and Alfred: a 3 years old problem, still open == https://github.com/libremesh/lime-packages/issues/1 confirmed is still an issue, maybe not needed because the web interface will be rewritten https://github.com/libremesh/lime-packages/blob/develop/packages/luci-app-b… https://github.com/libremesh/lime-packages/blob/develop/packages/luci-app-b… == lime-webui-ng will be included in 17.02? == Pau? Unitl when it does not work should be moved in a specific branch, not in develop as now is. https://github.com/libremesh/lime-packages/tree/develop/packages/lime-basic… == lime-build: Document how to add new hardware targets == Up to now just Pau did it Split specific taget lines from generic lime configs in targets/* files and move these ones to an unique file. == Redirect libre-mesh.org to libremesh.org == And check on the internet where we can fix it https://www.google.es/search?q=%22libre-mesh%22+-site:libre-mesh.org Gui should do this == Update or close repository on GitLab == Having an out of date version there is not good https://gitlab.com/libre-mesh/lime-packages Decision: we will set up syncronization Gio should do this == Update or close repositories on GitHub == We have a lot, that looks like a ugly list https://github.com/libremesh openwrt-oldpackages could be useful for someone compiling 15.09, shall we keep it? Yes, add comments in the repo description https://github.com/libremesh/openwrt-oldpackages lime-field-tools, nicoechaniz... are we using it or updating it or something? https://github.com/libremesh/lime-field-tools an old presentation on LibreMesh, we could make a repo for graphics and move it there, adding logos etc. Or can be moved in lime-web but should be updated. https://github.com/libremesh/libre-mesh-tecnical-presentation-1h-reveal.js libremap moved to its own user 3 years ago, so the repo in our organization is not useful. Delete it. https://github.com/libremesh/libremap ruci is an old script from Gui, let's ask him https://github.com/libremesh/ruci FFT_eval should be needed https://github.com/libremesh/FFT_eval another old presentation, see the previous comment https://github.com/libremesh/libremap-talk-2013-is4cwn super old repo superseeded by libremap https://github.com/libremesh/altermap ask Pau if we can delete this https://github.com/libremesh/dhcpdiscover let's remove this https://github.com/libremesh/demeshtify Devs should confirm we can delete these == Test and document how to use nodogsplash with LibreMesh == During last LiMeCat2016q3 we decided to not include nodogsplash in LibreMesh, but some GSoC projects go in that direction. https://wiki.freifunk.net/Ideas#LibreMesh_Captive_Portal_and_Access_Control Also nodogsplash is something which users ask for: https://lists.libremesh.org/pipermail/lime-users/2016-December/000287.html We need Gui for this. == Verify users reports == === Hostnames propagation === https://lists.libremesh.org/pipermail/lime-users/2016-November/000223.html === Strange errors === This happened long time ago, likely it's solved: https://lists.libremesh.org/pipermail/lime-users/2016-October/000197.html === Publishing on the website a guide for captive portal and coupon sharing? === https://lists.libremesh.org/pipermail/lime-users/2017-January/000317.html === Speed and latency issues === https://lists.libremesh.org/pipermail/lime-users/2017-February/000374.html === Mysterious /8 route in BMX6 === https://lists.libremesh.org/pipermail/lime-dev/2016-October/000787.html info in p.s., not in the main email body not an error, means accept routes in this range === trap in bmx6-auto-gw-mode logic === https://lists.libremesh.org/pipermail/lime-dev/2016-November/000797.html we can fix adding uci commit at the end of each watchping check === not existing luci-i18n-english === https://lists.libremesh.org/pipermail/lime-dev/2016-December/000818.html === Libremesh & qMp don't ping with same BMX6 revision === https://lists.libremesh.org/pipermail/lime-dev/2017-February/000837.html == No watchping, no pingcheck, better a wget == meh meh meh?? == lime-build: Need an alert for non existent profile == It affected an user here: https://lists.libremesh.org/pipermail/lime-users/2017-February/000389.html The issue is equivalent to this but for profile: https://github.com/libremesh/lime-build/issues/1 confirmed to do == Chef should ask for a root user password to be included in cooked firmware == For avoiding attacks while the password is still not set https://lists.libremesh.org/pipermail/lime-dev/2017-January/000827.html Chef could leak cleartext password, Chef should make the hash itself. == Discuss how a testbed for Battlemesh can be obtained from LiMe == Directions to forward to the student who will work on this GSoC idea https://wiki.freifunk.net/Ideas#LibreMesh_based_Battle_Mesh_testbed lime-proto-babel lime-proto-*** ask Nemesis for how they did the alternative WBM firmware == Develop a test suite with qemu or similar == We need to test the new commits against a few sample configurations and check that everything continues working. As doing this with real devices would be hard, something virtual would be accessible. Decision: much more useful to make something with real hardware, but needs to be able to reset to previous firmware. So we will never do it this way. So... Which virtual machines platform we can use for this? ================================================== Devs can do this but I will do if no one else does -------------------------------------------------- == Remove luci-mod-lime-basic == https://github.com/libremesh/lime-packages/issues/72 == Complete and test lime-proto-client == https://github.com/libremesh/lime-packages/issues/47 For now the network "wan" is hardcoded, it should be possible to use it for lan also When we have it for lan, we will have to test a non-mesh network (backbone made by AP-sta links) prio Remove args["network"] = "wan" for avoiding lime-proto-wan dependency of lime-system == lime-build: close an old PR - build sdk for all profiles == either completing it or refusing it https://github.com/libremesh/lime-build/pull/8 == lime-build: Re-add bmx7olsr1 profile to PROFILES_AVAILABLE == https://github.com/libremesh/lime-build/commit/f92c2d5354a62518435823153df2… Pau deleted this by error == Start using projects or labels and milestones for issues on Github == lables can indicate easy-to-address bugs for newbies we can transfer on github the majority of the issues listed in this document or include them as tasks in "projects" in Github Decision: yes for labels == Add topics to lime-packages repository for imrpoving visibility == As we're on Github, let's take advance for having a bit of visibility https://github.com/blog/2309-introducing-topics Decision: yes == Change link to old PabloCastellano repo in alterchef repo == https://github.com/libremesh/alterchef/blob/master/README.md And add description ============================= Completed tasks and decisions ----------------------------- == Discuss if "lime-config" could be inserted in LEDE init == This could broke custom configurations but avoids the common mistake of forgetting lime-config Decision: no. == lime-build: Discuss if we need a profile with 802.11s configured as default == This way it would be easier for the users to build a 802.11s based mesh. Decision: we will have just 802.11s https://github.com/libremesh/lime-web/commit/0d147690bb1a0a97f8c301dfcbe1ed… == Change BSSID and VLAN ID of BMX6 for compatibility with QMP == As we will broke compatibility with 802.11s, we can rediscuss other things like BSSID and VLAN ID of BMX6, we can change these for making easier the interoperability with QMP. For wireless link the same BSSID is not enough as QMP uses ad-hoc and we will use 802.11s Decision: yes In qMp default BSSID: 02:CA:FF:EE:BA:BE default VLANID: 12 == General switch to 802.11s for link layer? == ad-hoc seems to have a poor support by widely used drivers, 802.11s seems better (e.g. https://lists.libremesh.org/pipermail/lime-users/2017-January/000318.html ) The later the more painful will be the change. In LiMeCat2016q3 the change was decided for the next release, which is the 17.02 (cfr the pad of LiMeCat2016q3 https://pad.eigenlab.org/p/LiMeCat2016q3 ) Decision: confirmed, we need testing. We won't have back-compatibility. Network who will stick to ad-hoc will have to keep 16.07. Or configuring 17.02 with ad-hoc in Chef or post-flashing. Can cause problems. Decision: we need a super easy way in the webui for switching from 802.11s to ad-hoc == Plan deployment of LibreNet6 configuration helper webpage == In "mid-2017", similar to vpn.qmp.cat https://lists.libremesh.org/pipermail/lime-users/2016-November/000204.html Decision: WTF? Centralizing TINC configuration on a server? No.