Some routers look pretty similar. So should be better organized to finde the correct one.

Hi just wonder, if 9c2e258 has been deployed on the host?
It seems not, ad web still links to the router-wizard on https://config.berlin.freifunk.net/summary, even it should go to the root-page.

ipv6 ftw!

Neither config.berlin.freifunk.net nor ca.berlin.freifunk.net use mandatory HTTPS despite actual user data getting transmitted. Also, both should set HSTS and X-Frame-Options headers.

add_header Strict-Transport-Security max-age=31536000;
add_header X-Frame-Options "SAMEORIGIN";

Just to let everyone know, I changed the file /var/www/nipap-wizard on config.berlin.freifunk.net at line number 19 from
API_POOL_HNA = 'HNA IPv4'
to
API_POOL_HNA = 'Mesh IPv4'

Without the ipaddress in the requirements.txt I can't start the uwsgi instance because manage.py imports './scripts/legacy_importer/init.py' that imports ipaddress. Should I add the dependency or should I remove the legacy_importer?

Currently, when something goes wrong the app just responds with a generic error page.

We should at least create a custom one, or, better, one that also hints to what went wrong.

The PicoStation is not available in the list of supported Freifunk routers. The router can be flashed using the Bullet M firmware. Prebuilt firmware images already exist in the ar71xx directory.

There should be a possibilty to get an email with a summary of IPs assigned to me.

cosmetic issue only:
I would suggest to replace
config.berlin.freifunk.net/app/static/img/router/tl-cpe210.jpg
which is pointing to kathleen firmware within
config.berlin.freifunk.net/default.cfg
with an image clearly pointing out "v1" HW Revision

This will make the site more consistent and hopefully this will help newbies to avoid buying Hardware not already supported, or at least let them ask for matching builds for v1.1 via mailing list?!
See also here.

In the current deployment of the service one can't request an IPv6-net only.

Probably related to #68.

The user should configure a lat/lon in the freifunk assistent. If we provide an option to lookup the lat/lon coordinates in config.berlin.freifunk.net we can add this to the mail template with the ip information etc. and the user can copy this information into the assistant.

An automatic migration path from OLSR to babel requires a way to automatically determine IPv6 IPs assigned to nodes so they can be added to nodes that are currently IPv4 only. This issue depends on #76 and #75 .

in https://config.berlin.freifunk.net/summary sollte es keine Rolle spielenwelcher mix von Groß- und Kleinbuchstaben für eine EMail-Adresse genutzt wird. Es heute ja üblich, dass jede Schreibweise zum gleichen EMail-account führt.

"Freifunk@my-domain" gibt 1 registrierte Adresse zurück
"freifunk@my-domain" gibt >10 registrierte Adressen zurück

With both wizard and expert mode it is not possible to request a new IP.
The server responds with a "500 Internal Server Error" in the last step.

In hopefully extremely rare circumstances it is necessary to have more than a /24 DHCP network. It would be quite useful to be able to request a /23 or /22 network.

Currently it is possible to be lucky and to get two consecutive /24 addresses which can be combined into a larger /23. But this is impractical.

I think we should rename this repository to config.berlin.freifunk.net. This name is better understandable for newcomers.

We have a few helper scripts that are run by manage.py using flask-script

usage: manage.py [-?]
                  {db,resetdb,remove_unconfirmed_requests,remove_orphaned_prefixes,import_legacy,get_mails_for_legacy,mail_addresses_for_pools,mail,shell,runserver}
                  ...

 positional arguments:
   {db,resetdb,remove_unconfirmed_requests,remove_orphaned_prefixes,import_legacy,get_mails_for_legacy,mail_addresses_for_pools,mail,shell,runserver}
     db                  Perform database migrations
     resetdb
     remove_unconfirmed_requests
     remove_orphaned_prefixes
     import_legacy
     get_mails_for_legacy
     mail_addresses_for_pools
     mail

flask-script is deprectaed and we should use the flask cli

Requesting IPs from a pool that is exhausted results in an internal server error when using the expert form. We should handle this case properly and tell the user to e.g. request a smaller address range.

From the logs:

2020-01-09 14:09:59,477 ERROR: Exception on /expert/form [POST][in /usr/lib/python2.7/dist-packages/flask/app.py:1423]
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1817, in wsgi_app
    response = self.full_dispatch_request()
  File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1477, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1381, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1475, in full_dispatch_request
    rv = self.dispatch_request()
  File "/usr/lib/python2.7/dist-packages/flask/app.py", line 1461, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "./app/expert.py", line 40, in expert_form
    prefixes_v6)
  File "./app/utils.py", line 39, in request_create
    get_api().allocate_ips(pool, r.id, r.email, name, prefix_len, 4)
  File "./app/nipap.py", line 135, in allocate_ips
    family, data=data)
  File "./app/nipap.py", line 123, in create_prefix_from_pool
    prefix = self._create_prefix(pool, prefix_type, family, prefix_len, data=data)
  File "./app/nipap.py", line 107, in _create_prefix
    prefix.save(args)
  File "/usr/lib/python2.7/dist-packages/pynipap.py", line 1225, in save
    raise _fault_to_exception(xml_fault)
NipapNonExistentError: no free prefix found

when validations fail, we get the propper error message in the error log. (e.g.
File "./app/forms.py", line 38, in validate_email
raise ValueError('E-Mail stimmt nicht überein.')
)

but the user gets an 500 in return and therefore does not know what went wrong

We should update (at least these first images) our tutorial How to flash the firmware (http://berlin.freifunk.net/participate/howto/).

A user of the firmware told me that he successfully flashed a TL-WR841ND with the TL-WR841N firmware. The "D" usually simply indicates that the antenna is detachable. Maybe we can place a "(D)" to all TL-WR841N models?

When requesting an IPv6-Address for "Treptow/Köpenick" the server results in an internal server error.
This was seen in "expert Mode", even when requesting an IPv6-address only.

IP-Addresses can be optained from the wizard without validating the e-mail-address by this workflow:

1. Request IP-Address allocation (amateur mode)
2. do not validate the email address by not clicking on the link sent to you
3. request a list of all alloc'd IP-Addresses

In result, a user can get the addresses without validating the email address. The allocation will expire and the addresses will be alloc'd to another user and node. This leads to duplicate addresses, which is bad for the network.

mail service on config.berlin.freifunk.net is offline - please restart

We should move all time-consuming tasks like send an email or rpc calls to nipap into an task queue. I would tend to use celery (http://www.celeryproject.org/) for this.

The migration path from OLSR to babel requires to migrate IPv6 first. New nodes should get IPv6 subnets together with the IPv4 addresses.

The second IP should be marked optional on the last site, where the configuration for the router is shown.

for the new wizard we would like to register IPs during configuration (see freifunk-berlin/firmware-wizard-frontend#9)
is it possible to get a service for ip registration with the following spec?

method: reserveIPs
params: routername, mail, meships count, subnet (yes/no), v6prefix) that sends a mail with an confirmation key
function: reserve IPs and send mail to user with confirmation key
return: success / failure

method: confirmIPs
params: confirmation key, email
function: register ips for the user, send success mail
return: success (json with IPs) / failure

There should be link with a token in the activation email for deleting emails.

Maybe we want to notify users about changes or updates. Therefor it would be handy if we have an script to write everyone an email. This would be useful as well for #3.

The migration path from OLSR to babel requires to migrate IPv6 first. Existing nodes should get IPv6 subnets assigned so they can get migrated later on.

Hey, I don't become IP adresses at my E-Mail. Is there a failure in the system https://config.berlin.freifunk.net/?

Hey guys,

so this isn't much of an issue or feature request on this project in itself. Instead I would like to encourage that you open issues / PRs for improvements on pynipap.

I've skimmed through https://github.com/freifunk-berlin/config.berlin.freifunk.net/blob/master/app/nipap.py and find that are a few functions, like get_pool_by_name or get_vrf_by_name, that are wrapping around pynipap that shouldn't really need to be wrapped at all - it should be offered by pynipap straight away.

I would like your feedback on how we can enhance pynipap in such a way that you, and others, don't have to write as much wrapper code to get started with pynipap :)

//kll

There should be a script to delete all unconfirmed requests after x hours. This could then be executed daily as a cronjob.

At the moment there is much text with content like lorem ipsum .... We need to replace this with actual content.

Flashing of this model succeeds, BUT leaves no memory for configuration see [https://github.com/freifunk-berlin/firmware/issues/191#issuecomment-68630029 freifunk-firmware].

So it might be helpful to warn users before downloading and flashing until the mentioned issue is resolved.
Thanks.

On these Überlassungserklärung setups we do connect a TP-Link WDR3600 with for instance a Nanostation. Therefor we need an additional ip for LAN. For the moment a checkbox in our form should be sufficient.

We should give experienced users the possibilty to request custom networks like additional /32 ips or /26 for bigger setups.

We should provide a link to the NIPAP installation on config.berlin.freifunk.net for maintainers of larger sites. Also the procedure for obtaining a login should be described there.

There should be an howto for configuration of a router through the new wizard for beginners.

I just received a confirmation-mail for a freshly registered address:

Hey,

du hast folgende IPs bekommen:

Mesh-IPs:
 * a.f.f.e/27


Wenn du die IP-Adressen nicht mehr brauchst kannst du sie folgendem Link
löschen:



Grüße
Freifunk Berlin

This mail is missing the link to return the addresses, which should be printed after "folgendem Link
löschen:"

We do not want to use these 104.0.0.0/8 ips anymore but it would be good to have them in our system because there are many active devices still configured with them. Therefor we need a script to import data from our old ipam to nipap.

• Add hint to write down or keep the Mesh-IPs and DHCP-Network for later
  -- question rises regarding order of Mesh-IPs and are 3 display, while later only 2 are asked
  -- numbering and explanation needed
• display Download links as Buttons (I was close to miss them, the visibility was bad)
• explain difference between those two links for "unexperienced users"

Since 2025738 we have a contact-form to notify the owner of an IP-range via an anonymous-link.
What about an contact form where a requestor can enter an IP-address and a message can be sent to the assigned contact. This might helpfull to get a contact in case of Address-missuse / address configuration issues.

@booo mentioned in #44 that after a system update the service needs to be updated too

it seems there is no official way to request "Mesh"-only Ip-addresses from the reserved Mesh-addressrange 10.31.0.0/16.
Using the IP-Expert you will only get addresses from 10.230.0.0/16 (maybe 10.36.0.0/16) which are reserved for DHCP-clients. see http://lists.berlin.freifunk.net/pipermail/berlin/2015-November/030789.html .

Mesh-only hosts are usefull when Routers are connected via OLSR and using B.A.T.M.A.N. (via LAN) to have a singe DHCP-server.

Habe im Expertenmodus IPv4 /29 und "kein IPv6" ausgewählt, die Formularvalidierung schlägt fehl: "Please select an item in the list"

On 16. September we've met as Community and had a talk on the config wizard. We mostly agreed, that there should be a rewrite. Some requirements for this rewrite could be:

• handout json-file with node name and ip-addresses (works in conjunction with new FF-wizard)
• IPv6-assignments also in end user mode
• automatic ipv6-retrieval for falter-routers already in use
• change name / addresses of already registered leases, instead of handing back in and make new

To be discussed:

• provide a way to publicly see, which addresses are alloc'd to which node

@Noki Could you add some nodes, If I was missing something, please?