freifunk-berlin / firmware Goto Github PK

Wir sollten nochmal die Patches für openwrt auf ihre Wichtigkeit überprüfen. Siehe:

https://github.com/freifunk-berlin/firmware/tree/master/patches

If I restart the network with /etc/init.d/network restart network rules (ip rule) like the policy routing rules from freifunk-policyrouting do not show up. In particular the rules for devices in IBSS mode are missing. If I reload the network instead of reastarting it the rules netifd creates the rules.

A short term fix would be to change the freifunk-policyrouting init script to use reload instead of restart to create the rules. In the longterm this should be fixed by openwrt.

Betrift den aktuellen Buildbot build #153. mpc85xx Routermodell WDR4900.
Ganz frische Installation, keine Aenderungen vorgenommen und keine config angelegt, weder mit dem Wizard noch manuell.

wenn man sich einloggen moechte ueber die Website kommt folgende Fehlermeldung:

/usr/lib/lua/luci/sys.lua:777: bad argument #1 to 'getsp' (supported values: )
stack traceback:
[C]: in function 'getsp'
/usr/lib/lua/luci/sys.lua:777: in function 'getpasswd'
/usr/lib/lua/luci/sys.lua:791: in function 'validator'
/usr/lib/lua/luci/dispatcher.lua:151: in function 'authen'
/usr/lib/lua/luci/dispatcher.lua:370: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>

kleiner Nachtrag: ich habe vorher ein passwd ueber telnet ausgefuehrt.

As we discuessed on several meetings we need a replacement for the old IPAM (IP address management) system (http://ip.berlin.freifunk.net). It lacks the following features:

• ipv6 support
• good useability
• support for new prefix 10.31.0.0/16 (we want to get rid of 104.0.0.0/8)

@egmont1227 favors https://github.com/SpriteLink/NIPAP. I looked at their documentation at http://nipap.readthedocs.org/. I think we should implement our own frontend just for getting an IP address for the mesh interfaces and a small prefix for dhcp. You can communicate with an NIPAP server through XML-RPC. There exist as well a python client library. I think we do not need a fancy web 2.0 frontend and would therefor favor a small web app written with the nipap python client library and for example flask.

We need fancy names for our releases.

I suggest we name our releases after important female computer scientists, hackers, etc.

Folgende Abfolge von make Aufrufen führt zu einem Fehler, wenn wir die Feeds ebenfalls mit quilt patchen (patches branch): make, make clean, make. Das make clean target sollte meiner Meinung nach openwrt/scripts/feeds.sh clean aufrufen. Das sorgt dafür, dass die Feeds neu gedownloaded werden.

Community information and contact information should also be set to /etc/config/freifunk by wizard.
These information will be visible on the router's start page.

The wizard reads olsrd section defaults from profile for IPv4.
Can we do the same for olsrd6? Currently it sets just something I copied from ffwizard-pberg. A difference is the LinkQualityAlgorithm...

Some communities alter the mcast rate from 1Mbits (openwrt default) to 12Mbits (see https://github.com/freifunk-gluon/site-ffhl/blob/master/site.conf#L27 ). This excludes old clients and some routers which do not support these mcast rates . Additionaly it limits the range a bit but on the other side boosts speed. What is your opinion about this?

Wir sollten luci-firewall zur Verwaltung der Firewall noch bauen und in die Firmware aufnehmen. @geirkairam hat berichtet, das dies zur Zeit nicht der Fall ist.

Die derzeitigen Mesh-SSIDs verleiten User dazu sich in das ADHOC/IBSS Netz einzuloggen. Das hat zur Folgen, dass sie kein "Internet" erhalten.

Vorschläge und eine Diskussion zur Umbennenung der SSIDs gibt es hier:

https://github.com/freifunk/firmware-berlin/issues/34#issuecomment-5119098

Wie in #9 schon angemerkt wäre es gut wenn die Firmware einen festen DNS-Eintrag für den Router hat. Ähnlich wie bei FritzOS mit 'fritz.box'. So müssen Menschen ohne Kentnisse sich nicht mit IP-Adressen rumschlagen. Einstellbar ist sowas in /etc/config/dhcp:

config 'domain'
    option 'name' 'frei.funk'
    option 'ip'   '192.168.42.1'

On the OpenWRT devel mailinglist users are complaining that dnsmasq hangs silently (https://lists.openwrt.org/pipermail/openwrt-devel/2014-August/027514.html). We are using the same revision 2.71 of dnsmasq in our firmware. Can we confirm this bug and should we try the fix with procd_set_param limits core="unlimited" ?

Wie schon in https://github.com/freifunk/firmware-berlin/issues/35 diskutiert, wäre es gut wenn der Wizard nach dem Boot direkt aufgerufen wird (ohne sich Einloggen zu müssen und über das Menü den Wizard aufrufen)

Das luci gui sollte https unterstützen.

https://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/community-profiles/files/etc/config/profile_berlin has still freifunk.net instead of berlin.freifunk.net

At the moment we mix up german and english everywhere (commit messages, pull requests, issues). I prefer if we could talk in one language (perhaps english?). What do you think?

Im Wizard sollten beim IP-Adresse vergeben 104er als deprecated visuell der Benutzer_in mitgeteilt werden. Dadurch kommen die Menschen vlt nicht auf den Gedanken neue Knoten mit solchen Adressen zu konfigurieren.

the wizard deletes olsrd_dyn_gw.so.0.5 that is in /etc/config/olsrd after flashing and configures olsrd_dyn_gw_plain.so.0.4. We do that because it is smaller?

A lot of defaults are set in the wizard, they are always the same and do not depend on user input:

firewal: https://github.com/freifunk-berlin/packages-berlin/blob/master/utils/luci-app-ffwizard-berlin/luasrc/tools/freifunk/assistent/firewall.lua
olsr plugins: https://github.com/freifunk-berlin/packages-berlin/blob/master/utils/luci-app-ffwizard-berlin/luasrc/tools/freifunk/assistent/olsr.lua

We should check what are defaults by openwrt and what we could put in another firmware-berlin-defaults package

Currently you need to run the wizard twice to get all the settings. I guess the scripts do not get which profile is selected in the first run.

Zur Zeit schlägt der build von alfred fehl, da die Abhängigkeit libgps nicht gefunden werden kann. libgps muss wahrscheinlich noch ins neue openwrt package repo übernommen werden.

Wir bauen alfred zur Zeit aus diesem Grund nicht. Alfred wäre für ein batman-adv Firmware wichtig.

At the moment there is only packages/minimal.txt as package list for a firmware. I think the Makefile should support arbitrary amount of package lists files like the old script did. Then we could generate different firmwares like for VPN or BBB.

In Gluon gibt es einen Mechanismus Knoten automatisch auf eine neuere Firmware zu aktualisieren (siehe http://gluon.readthedocs.org/en/latest/features/autoupdater.html ). Die Packete dazu sind admin/autoupdate und gluon/gluon-autoupdater in https://github.com/freifunk-gluon/packages. Wollen wir auch so etwas in der berliner Firmware?

Die Administrationsoberfläche für openvpn, die von luci offiziell zur Verfügung gestellt wird, ist zur Zeit als BROKEN markiert. Möglicher Grund: luci-openvpn ist für openvpn 1.* gedacht.

Luci-openvpn können erfahrene Nutzerinnen zur Konfiguration von openvpn nutzen.

Wenn der Assistent durchgeklickt wird und man sich dafür entscheidet nur am Freifunknetz teil zunehmen (kein VPN), kriegen Clients kein Internet.
Mein Meshparnter der Wohnzimmertouter hat nur IPv4. Andere Router (die nicht diekt verbunden sind) sind pingbar (z.b. das Rathaus).
Entferne ich die interfaces zum meshen in Administration>Services>OLSR IPv6 und starte neu, hab ich Internet.
Ich weiß leider nicht was ich prüfen müsste um das weiter einzugrenzen.

Die Switch-Ports sollten in die dhcp bridge mit aufgenommen werden, sodass die Userinnen an den Switch-Ports eine IP aus dem Freifunk-Netz erhalten.

Ubiquiti changed the chipset for their Nanostation M series in 2014. OpenWRT does support this new device but unfortunately not in 14.07 (our base release) but in their devel branch (see http://git.openwrt.org/?p=openwrt.git;a=commit;h=cfc296b15f439ef13ac0d4c4b4e4c533a21ed11d ). We should backport this patch to support the new Nanostation M xw devices.

Some people want to have a private encrypted SSID besides the open freifunk SSID. It would be cool if the wizard would support this. In general you would add another wifi-iface like this:

config wifi-iface
        option ifname       'ap2private'
        option device       'radio0'
        option network      'wan'
        option mode         'ap'
        option ssid         'NAME_OF_ENCRYPTED_SSID'
        option encryption   'psk2'
        option key          'KEY_OF_ENCRYPTED_SSID'

Other communities have implemented this by adding a checkbox to their wizard if they generally want a private ssid and in the next step they ask for ssid name and key.

The old wizard supported many profiles. The new wizard should do the same. At the moment only Berlin is supported.

/usr/lib/lua/luci/dispatcher.lua:448: Failed to execute template dispatcher target for entry '/owm'.
The called action terminated with an exception:
/usr/lib/lua/luci/template.lua:104: Failed to execute template 'owm'.
A runtime error occured: [string "/usr/lib/lua/luci/view/owm.htm"]:9: attempt to perform arithmetic on local 'latitude' (a nil value)
stack traceback:
[C]: in function 'assert'
/usr/lib/lua/luci/dispatcher.lua:448: in function 'dispatch'
/usr/lib/lua/luci/dispatcher.lua:195: in function </usr/lib/lua/luci/dispatcher.lua:194>

Im FF Assistenten sollten das System Prüfen ob die Korrekte Adresssyntax eingetragen wird.
Wenn nur die IP eingetragen wird, wird das nicht moniert, erzeugt aber beim Speichern eine
Konfig mit der man sich nicht mehr als Admin auf der LUCI Oberfläche anmelden kann.
Inclusive einer Fehlermeldung die den FF Assistenten zum hängen bringt.

Das System sollte also Prüfen ob die Syntax richtig ist bzw. wäre eine Vorgabe sinnvoll.
Ich hab nämlich nur die IP aus meinem Addressbereich eingegben statt IP/32 o.ä.

Diskussion: http://lists.berlin.freifunk.net/pipermail/berlin/2014-August/025404.html

Auf der Mailingliste wurde vorgeschlagen die von der Firmware verwendeten DNS-Server zu verändern:

http://lists.berlin.freifunk.net/pipermail/berlin/2014-August/025317.html

Kritierien für die Auswahl sollten sein:

• Keine freiwillige Zensur von Inhalten
• Erreichbarkeit
• Nahe am/im Freifunk-Netz?

there is a http 404 error

root@router:~# opkg update
Downloading http://firmware.berlin.freifunk.net/barrier_breaker/stable/ar71xx/packages/Packages.gz.
wget: server returned error: HTTP/1.1 404 Not Found
Collected errors:
 * opkg_download: Failed to download http://firmware.berlin.freifunk.net/barrier_breaker/stable/ar71xx/packages/Packages.gz, wget returned 1.

server answers "The requested URL /barrier_breaker/stable/ar71xx/packages/ was not found on this server." when I enter the url in my browser. Is there a correct package repository url?

If the router has ipv6 connectivity on the wan port traffic from clients (lan/wifi) gets routed over the wan port. The traffic does not take the route over the vpn03 because there is no ipv6 as far as I know. We should drop traffic at the router. In the long term we should provide ipv6 over vpn03 as well.

Ein neues Release von OLSR würde es uns erlauben das openwrt-routing feed zu updaten und den folgenden Patch zu entfernen:

https://github.com/freifunk-berlin/packages-routing/commit/c288ddc2c8e88faaeed808d2bbfcbbff627e244e

Die /etc/config/olsrd enthält eine fehlerhafte Konfiguration für das dyn-gw Plugin:

pluginoption library 'olsrd_dyn_gw_plain.so.0.4..ignore=1..ignore=1..ignore=1..ignore=1'

The functionality of the freifunk-watchdog package overlaps at some points with functionality provided by procd. Maybe we should remove the package or update the source code.

http://luci.subsignal.org/trac/browser/luci/trunk/contrib/package/freifunk-watchdog

The default ssid in the wizard currently is set to freifunk.net. Please update to berlin.freifunk.net.

See freifunk/meshkit/issues/14. Is this issue still present in the current firmware?

Our buildprocess or openwrt does not honor the VERSIONOPT=y and other version options. The version options are not present in the openwrt/.config after a call to make.

Die default IP des Routers im LAN sollte nicht aus dem 192.168.1.1/24 Netz kommen. Das Netz ist auf vielen Routern konfiguriert, die als Uplink für den Freifunk-Router dienen und führt dann zu Adress-Kollisionen.

The ffwizard-berlin tries to configure freifunk-p2pblock but we do not build the package. Should we build this package? Should the package make it into the default package set?

Das Profile für den WDR4900 enthält zur Zeit den wpad als Abhängigkeit. Eigentlich wäre der wpad-mini zu erwarten. Da wir den WPAD nicht explizit bauen, failed der Imagebuilder, wenn wir wpad nicht entfernen.

OpenWrt sollten das Profile des WDR4900 anpassen.

at the moment the wizard reads settings for olsrd (ipv4) config from community profile
do we want to do the same for olsrd6 config?
I don't think all options are valid for ipv6 f.e Ip4Broadcast ... what about the rest?

(this is related to #30)

At some point (release) we should describe the features of the firmware e.g. in the README.

Mentioned here freifunk/firmware-berlin#34
bssids could be removed from profile

Ein erster Release candidate sollte vorbereitet werden, sobald die Zeit reif ist.

Die feed-Repositories enthalten teilweise einen alpha branch. Die feeds.conf sollte diese Branches oder ähnliche enthalten.

Do omit confusion we should move all repositories to this new organizaion ( https://github.com/freifunk-berlin ) and delete no longer needed ones. This would includes the following ones:

• https://github.com/freifunk/berlin-buildbot
• https://github.com/freifunk/berlin-configs
• https://github.com/freifunk/berlin.freifunk.net
• https://github.com/freifunk/berlin-puppet-files
• https://github.com/freifunk/berlin-puppet
• https://github.com/freifunk/packages_berlin
• https://github.com/freifunk/firmware-berlin
• https://github.com/freifunk/berlin-netzplan
• https://github.com/freifunk/berlin-regip

If we want to provide open infrastructure for other communities we could rename buildbot-berlin to buildbot and encourage others to use this continuous integration setup.