freifunk-berlin / falter-packages Goto Github PK

We need this basic functionality for inselnodes. I think it is okay if we keep it a separate package to be installed manually. Of course, a wizard option would be nice to have, too.

Here is some nice documentation by Perry: https://lists.berlin.freifunk.net/pipermail/berlin/2019-January/038865.html

The file /etc/config/freifunk is both a config file and a list of defaults for the wizard to use when setting up a router. This especially causes issues when upgrading as any changes to freifunk and the profiles will not get updated as they are in a special folder where all configurations are kept. The only way currently is to write a migration script.

I would propose that we do something new. How about we create a new directoy /etc/freifunk with a sub directory under it /etc/freifunk/communities where we can put the defaults defined in /etc/config/freifunk along with all the profiles. Then, the file /etc/config/freifunk would only have the sections "contact" and "community"

This idea was mentioned in #13 (comment)

Das Upgrade von Hedy hat nicht funktioniert. Das WLAN war nicht konfiguriert. Der Wizard konnte wegen nil nicht speichern.
Das Factory-Image sah sehr gut aus, der Wizard lief durch.
Aber nach einem Reboot kein GUI, nur dies:

/usr/lib/lua/luci/dispatcher.lua:1203: bad argument #1 to 'pairs' (table expected, got nil)
stack traceback:
[C]: in function 'pairs'
/usr/lib/lua/luci/dispatcher.lua:1203: in function 'createtree'
/usr/lib/lua/luci/dispatcher.lua:694: in function 'menu_json'
/usr/lib/lua/luci/dispatcher.lua:795: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>

For now, there are scripts for showing mesh neighbors and their link quality and all received HNAs. Maybe it's cool to have a script, which shows all the services available.

It should read the services from /tmp/etc/services.olsr and print them in a nice way.

Do we need such a little script? Would it be useful? Please give me some opinion on that.

Powered by LuCI openwrt-19.07 branch (git-20.247.75781-0d0ab01) / OpenWrt 19.07.4 r11208-ce6496d796

Upgrade war nicht möglich, nur durch Factory-Reset wiederbelebt.
Jetzt vermisse ich den Kanal 13 - es wird nur bis 11 angeboten.
Vermutlich hatte der Assistent damit auch Probleme ...

Tryed 5 times via GUI and via console per sysupgrade (notunnel-image).
Connection lost .. reboot ... old system (falter-beta1).

Ist there any logfile?
(this Picostation ist WLAN-only, no eth ...)

PS: tunneldigger-image on GL.iNet GL-AR150 updated via GUI works great!

factory-install auf gl.150 mit tunneldigger-Image von http://download-master.berlin.freifunk.net/falter/

Mit WAN an Fritzbox angeschlossen. Nach einigen Stolpersteinen mit dem Assistenten die Daten alle eingetragen. Mesh mit 802.11s. Nach Augenschein OK - aber keine Verbindung zum Internet.
GUI über WAN OK, GUI über LAN OK - Nachbar-Mesh-Clients werden angezeigt, WLAN-Client wird angezeigt.

• Bug Passwort-setzen nach Admin-Login ist hier auch, aber man kann direkt über das Admin-Menü arbeiten
• die Kontakt-Seite wird hier angezeigt

Aber keine Verbindung ins Internet, auch keine Anzeige auf Monitor oder Karte:
( http://monitor.berlin.freifunk.net/host.php?h=Ahoernchen )

Aus dem Log:
Mon Sep 7 09:49:01 2020 daemon.err td-client: [a.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:01 2020 daemon.err td-client: [b.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:01 2020 daemon.err td-client: [c.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:01 2020 daemon.err td-client: [d.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:01 2020 daemon.err td-client: [e.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:01 2020 daemon.err td-client: [f.tunnel.berlin.freifunk.net:8942] Hostname resolution timed out.
Mon Sep 7 09:49:02 2020 daemon.info td-client: [a.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.info td-client: [b.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.err pingcheck[2228]: Failed to resolve
Mon Sep 7 09:49:02 2020 daemon.info td-client: [c.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.info td-client: [d.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.info td-client: [e.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.info td-client: [f.tunnel.berlin.freifunk.net:8942] Reinitializing tunnel context.
Mon Sep 7 09:49:02 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Mon Sep 7 09:49:04 2020 daemon.err odhcp6c[1296]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)

Place Holder

[..]
Finalizing root filesystem...
/home/spolack/git/wilgu10-configs/wilgu10_/wilgu10-core/builder/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/root-ipq40xx/etc/init.d/freifunk-policyrouting: line 4: /lib/functions/network.sh: No such file or directory
/home/spolack/git/wilgu10-configs/wilgu10_/wilgu10-core/builder/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/root-ipq40xx/etc/init.d/freifunk-policyrouting: line 5: /lib/functions.sh: No such file or directory
Enabling boot
Enabling bootcount
Enabling collectd
Enabling cron
Enabling dnsmasq
Enabling done
Enabling dropbear
Enabling firewall
Enabling freifunk
./etc/init.d/freifunk-policyrouting: line 4: /lib/functions/network.sh: No such file or directory
./etc/init.d/freifunk-policyrouting: line 5: /lib/functions.sh: No such file or directory
Enabling freifunk-policyrouting
Enabling gpio_switch
Enabling led

Found that issue fixed in another project: openwrt/packages@5a69b9c

.. But this will only work for /lib/functons.sh

Permission Error:

RPCError: RPC call to file/list failed with error -32002: Access denied
at handleCallReply (http://scharni-core.olsr/luci-static/resources/rpc.js?v=unknown:12:3)
at promise callbackparseCallReply (http://scharni-core.olsr/luci-static/resources/rpc.js?v=unknown:10:70)
at promise callbackcall (http://scharni-core.olsr/luci-static/resources/rpc.js?v=unknown:6:110)
at declare/</< (http://scharni-core.olsr/luci-static/resources/rpc.js?v=unknown:24:320)
at declare/< (http://scharni-core.olsr/luci-static/resources/rpc.js?v=unknown:21:436)
at probePreloadClasses (http://scharni-core.olsr/luci-static/resources/luci.js?v=unknown:190:206)
at setupDOM (http://scharni-core.olsr/luci-static/resources/luci.js?v=unknown:199:405)

If batman not comes with the image, an existing mesh ap may have an invalid network config after update/upgrade.

currently root passwords might be transferred in plain-text over unencrypted wifi.

Many people complain "berlin.freifunk.de" often doesnt work. The goal of that ticket is to setup a mechanism which modifies the SSID to "offline.berlin.freifunk.de" or similar to prevent mobile devices from automatically connecting to offline freifunk.

Pingcheck could be utilized for that.

Current Situation

At the second page of the firmware wizard, there are only two profiles avaiable.

What would you expect it to be?

There should also be the profiles of the communities from the old wizard. At least, I would like to have the profile for Fürstenwalde there.

Unfortunately I didn't find, where the community profiles in OpenWrt did go. Maybe that's helpful:
https://openwrt.org/packages/pkgdata_owrt18_6/community-profiles

The iif br-dhcp lookup olsr-tunnel rule is not created automatically for every interface in the firewall zone.
You can add it by using:

ip rule add from all iif br-dhcp lookup olsr-tunnel

Cmds useful for debugging:

ip r g 8.8.8.8 from [client-IP-addr] iif br-dhcp

cat /etc/iproute2/rt_tables

What it should look like:

19999:	from all iif tunl0 lookup olsr-tunnel 
19999:	from all iif br-dhcp lookup olsr-tunnel 
19999:	from all iif bbbdigger lookup olsr-tunnel 
19999:	from all iif eth0.11 lookup olsr-tunnel 
19999:	from all iif wlan1-adhoc-5 lookup olsr-tunnel 
19999:	from all iif wlan0-adhoc-2 lookup olsr-tunnel 

ip tun

uci show firewall.zone_freifunk.network 

This issue was reported at the mailing list.

Test auf TL-WDR3600
Firmware
openwrt-ath79-generic-tplink_tl-wdr3600-v1-squashfs-sysupgrade.bin

"Schoenheitsfehler" unter Luci:
Unter:
http://frei.funk/cgi-bin/luci/freifunk/contact:

500 Internal Server Error

Sorry, the server encountered an unexpected error.

/usr/lib/lua/luci/template.lua:97: Failed to execute template 
'freifunk/contact'.
A runtime error occurred: [string 
"/usr/lib/lua/luci/view/freifunk/contact.htm"]:12: bad argument #1 to 
'ipairs' (table expected, got string)
stack traceback:
     [C]: in function 'ipairs'
     [string "/usr/lib/lua/luci/view/freifunk/contact.htm"]:12: in main 
chunk
stack traceback:
     [C]: in function 'error'
     /usr/lib/lua/luci/template.lua:97: in function
     (tail call): ?
     /usr/lib/lua/luci/dispatcher.lua:1020: in function 'dispatch'
     /usr/lib/lua/luci/dispatcher.lua:478: in function

OpenWrt 19.07.4 r11208-ce6496d796 / LuCI openwrt-19.07 branch git-20.247.75781-0d0ab01
comes with 2.4GHz only - this seems working great, but second radio is missing

... or other freifunk-related packages / updates?

What I would really like help with is the mcast_rate for 802.11s (both freq). I need an educated decision from someone, and I can code it. Right now the value is unset.

if you are connected to the web, using the map to click on your location, before(older fw) the fields of lat and long. are filled with the coordinates, this does not work right now.

In a meeting at 25th november 2020, we spoke about maintenance on bbb-sites. To make maintenance more easy, we should create a falter-package with the ssh-keys of freifunk-berlin admin team.
This would get mutual maintenance of backbone sites easy.

That package should only be included into costum backbone-images generated with falter-bbb-configs.

Sometimes in Network/Wireless start this:

Wireless configuration migration

The existing wireless configuration needs to be changed for LuCI to function properly.

Upon pressing "Continue", anonymous "wifi-iface" sections will be assigned with a name in the form wifinet# and the network will be restarted to apply the updated configuration.

But then "There are no changes to apply."

We need to find a way to grant access so certain status admin pages like the olsr one.

Currently accessing http://knoten.olsr/cgi-bin/luci/admin/status/olsr gives a 403.

https://forum.openwrt.org/t/access-some-admin-status-pages-without-login/68524

I think it would be really handy to enable bbbdigger via the wizard. This would need bbbdigger to be installed, but deactivated on tunneldigger and notunnel-node-images. Then we can control it easily via the wizard.

This idea came up in issue #44.

Description

When I load http://frei.funk, i get to the welcome-page. Then I click on Administration and log into the router. After Login, the router displays the wizard-page, though the wizard ran already.

What is your expectation?

After login, we should get the Page Status -> Overview.

Test-Environment

Tested with an image of @PolynomialDivision at ArcherC5v1.
OpenWrt SNAPSHOT, r13902-5e86877

Current Situation

At the last page of the wizard, we can configure the ip-addresses and the mesh-modes of the interfaces. Switching to adhoc-mode gives a crash of LuCI.

What would you expect it to be?

Normally, the wizard should configure the interfaces in adhoc-mode. This is fairly relevant, as most of Freifunk-Berlin-Routers mesh still in adhoc-mode.

Test-Environment

Tested with an image of @PolynomialDivision at ArcherC5v1.
OpenWrt SNAPSHOT, r13902-5e86877

no Upgrade possible via GUI

Hi,
thanks so much for this. Can we sysupgrade to falter images from LEDE-based Hedy nodes or does it need additional migration scripts?

I tried to build an image for the er-x-sfp today and it failed because of the dependency on iwinfo. This package is not needed on the er-x-sfp, er-x, rb750gr3 and many other routers which don't have wireless.

This dependency seems be be needed for the uci-default script freifunk-berlin-correct-nsm2-txpower which is only needed for one specific device, the nanostation M2 or M2-loco.

Instead to hedy-1.0.x-branch, the olsr plugin now get loaded by their name, but not by the ending .so.$VERSIONNo

Candela is a company that has signed an NDA to get the source code for ath10k. A person named Ben then added patches to the firmware. This person always rebase his changes to the latest official firmware.

But now there is the problem that Mesh-Point aka 802.11s is not available for wave1 products. Mesh-Point still works fine with the official firmware. But now the ct firmware has become openwrt default.

Now the weakness is that we only have a "packagefeed", because the user may have to intervene himself. This means that the user has to unselect the ct driver and install the non-ct firmware.

I still think that we can do that in the buildbot and it's good. That automatically compiled images of us have the non-ct firmware.

I think the Makefiles should be adapted to apply with https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md

In the future we could simply merge the packages into the OpenWrt infrastructure.
I would suggest we add @Akira25, @pmelange and me as maintainer.

I think I would add this?
https://github.com/openwrt/packages/tree/master/.github

Description

In the LuCI-Admin-Interface theres a OLSR status page at Status -> OLSR. On the top of that page there some tabs with more detailed information. Clicking on the tabs Routes and Topology gives that error:

Bad Gateway
The process did not produce any response

What do you expect to happen?

I can't remember for sure what the result should be, but I think it should display at least something.

Test-Environment

Tested with an image of @PolynomialDivision at ArcherC5v1.
OpenWrt SNAPSHOT, r13902-5e86877

EDIT:

As mentioned below, the timeout results from the router rendering the webpage not fast enough. This issue should be solved by doing a rewrite of the app in the new JS-LuCI.

As seen in #65 we should give some advice for the users to not use the wizard twice.

I propose, to embed a warning into the first wizard page, to not run it twice. This will hopefully prevent strange bugs, until we finish a new wizard or modify the current, so that it won't break configs anymore.

I built the current version of Falter-Feed against OpenWrt-19.07.3. After flashing and a wizard run on a WR842v3, I got a fairly blank LuCI-Screen. There aren't any buttons.

The loginpage at http://frei.funk/cgi-bin/luci/admin/ is reachable anyway. I can login normally and in the admin-interface, everthing works fine.

when running falter beta4 on the popular unifi ac mesh, we need to switch to classic firmware for 802.11s mesh support on both radios.

opkg update
opkg remove ath10k-firmware-qca988x-ct kmod-ath10k-ct
opkg install ath10k-firmware-qca988x kmod-ath10k
reboot

this does not work currently as the -ct version is reinstalled in current state. We should provide the classic firmware with our repo as well, maybe ship it as standard to support the distribution of 802.11s mesh across the network. This is also the standard option with our wizard and does not work with the current configuration, at least the 5 ghz radio cannot 802.11s with -ct.

As we have seen in #46 and #43, there is quite strong demand to host falter-packages, namely bbbdigger and so on, in the internet to make them accessible via opkg.

I suggest to host the feed at http://download-master.berlin.freifunk.net/falter-feed/

For building the whole feed, we can use the falter-repo-builder. Currently I am not quite sure, how to give the feeds web-address to opkg. Do we need to patch opkg.conf at runtime? Does exist a way to include the address at buildtime of the images?

When sysupgrading from earlier OpenWrt versions to 19.07.3 snapshot (20.x) while keeping configs, the path of the resolvfile in /etc/config/dhcp must be updated as follows:

option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'

And again the same topic: "What to do with migration?". xD
In the new OpenWrt Goals you can read that something called compat-version is introduced.

We regularly encounter the situation that devices are subject to changes that will make them incompatible to previous versions. This typically happens when the setup of a device has changed in a way so that the configuration cannot be migrated or filesystem changes won't allow sysupgrade.

We will face that, too.

Maybe we have no chance of migrating to 20.X.

after "Confirm" ther ist something working - then it return to the windows with file-list

expected: Message with OK / not OK an closing that popup-window

Current Situation

On top of the wizard, there are some tabs showing up.

What would you expect it to be?

This tabs weren't there at stable-releases of the firmware.

This issue is not too important, as it doesn't seem to affect the functionality of the wizard.

Test-Environment

Tested with an image of @PolynomialDivision at ArcherC5v1.
OpenWrt SNAPSHOT, r13902-5e86877

try to switch on a Unifi AC-M:

...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:178: attempt to concatenate field 'mode' (a nil value)
stack traceback:
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:178: in function 'callback'
	/usr/lib/lua/luci/model/uci.lua:269: in function 'foreach'
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:122: in function 'write'
	...b/lua/luci/model/cbi/freifunk/assistent/wireless.lua:100: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:248: in function 'parse'
	/usr/lib/lua/luci/cbi.lua:713: in function 'parse'
	/usr/lib/lua/luci/dispatcher.lua:1491: in function '_form'
	/usr/lib/lua/luci/dispatcher.lua:1026: in function 'dispatch'
	/usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>

There are some boards like the AVM Fritzbox 7530 that perform great as a tunneldigger uplink, but do not offer a dedicated WAN ethernet port (only LAN 1-4 for example).
At the moment the Wizard does not create a WAN port at all if ran on these boards.

For the tunneldigger uplink usecase I suggest defining LAN1 as WAN on these routers and show a hint in the wizard during setup.

We have a similar situation with routers that sport only one eth port. Currently, it will always be configured as Freifunk DHCP, even if the user decides to use the device as a tunneldigger uplink node.

Other affected devices include TP-Link CPE210/510 V2 & V3, TL-MR3020, Comfast CF-E130N v2, ... – essentially all boards that either lack a labelled WAN port or have only one eth port at all.

Devices are shown on the map as "routeronly":
https://hopglass.berlin.freifunk.net/#!v:m;n:Ahoernchen.olsr
https://hopglass.berlin.freifunk.net/#!v:m;n:Ahoernchen2a.olsr

in the current state way too many non-existent plugins are tried to be loaded. also rrdtool throws an error, for traditional freifunk stats behavior the config file should look more like

config statistics 'rrdtool'
	option default_timespan '1hour'
	option image_width '600'
	option image_path '/tmp/rrdimg'

config statistics 'collectd'
	option BaseDir '/var/run/collectd'
	option Include '/etc/collectd/conf.d'
	option PIDFile '/var/run/collectd.pid'
	option PluginDir '/usr/lib/collectd'
	option TypesDB '/usr/share/collectd/types.db'
	option Interval '30'
	option ReadThreads '2'

config statistics 'collectd_ping'
	option enable '1'
	option TTL '127'
	option Interval '10'
	option Hosts 'ping.berlin.freifunk.net'

config statistics 'collectd_interface'
	option enable '1'
	option Interfaces 'ffuplink'

config statistics 'collectd_load'
	option enable '1'

config statistics 'collectd_rrdtool'
	option enable '1'
	option DataDir '/tmp/rrd'
	option RRARows '100'
	option RRASingle '1'
	option RRATimespans '1hour 1day 1week 1month 1year'

config statistics 'collectd_memory'
	option enable '1'

config statistics 'collectd_olsrd'
	option enable '1'
	option Port '2006'
	option Host '127.0.0.1'

config statistics 'collectd_iwinfo'
	option enable '0'
	option Interfaces 'wlan0-mesh-2 wlan0-dhcp-2'

config statistics 'collectd_uptime'
	option enable '1'

config collectd_network_server
	option host 'monitor.berlin.freifunk.net'

config statistics 'collectd_network'
	option enable '1'

with adjusted interface names, of course.

Hello!
I installed the sysupgrade version of this firmware, opened the webinterface, but there is no wizard opening and no login is possible.
ssh is possible, setting a password via passwd also works, but i can't login to luci with this.
after reboot the webinterface is presenting me:
/usr/lib/lua/luci/dispatcher.lua:1203: bad argument #1 to 'pairs' (table expected, got nil) stack traceback: [C]: in function 'pairs' /usr/lib/lua/luci/dispatcher.lua:1203: in function 'createtree' /usr/lib/lua/luci/dispatcher.lua:694: in function 'menu_json' /usr/lib/lua/luci/dispatcher.lua:795: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:478: in function </usr/lib/lua/luci/dispatcher.lua:477>
I'd be happy to help.
matrix/mail is possible
@lightcatcher:matrix.org

Problem

After setting up the router we can see that the migrate.log was generated in the /root/ directory. In the file:

no Freifunk Berlin system detected ...

This gives a hint, that the migration-system does not recognize Freifunk-Spalter correctly.
This might lead into issues, when updating from a hedy-release to Freifunk-Spalter.

Test-Environment

Tested with an image of @PolynomialDivision at ArcherC5v1.
OpenWrt SNAPSHOT, r13902-5e86877