freifunkmuc / site-ffm Goto Github PK

Hallo,

ntp geht im umland nicht:

root@zzzuml-60e327576e28:~# /usr/sbin/ntpd -n -w -d -p 0.ntp.ffmuc.net -p 1.ntp.ffmuc.net
ntpd: resolved peer 1.ntp.ffmuc.net to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: resolved peer 0.ntp.ffmuc.net to fdef:ffc0:4fff::131
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 1s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 1s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 1s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 2s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 1s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 1s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 2s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 1s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 1s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 2s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 2s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 2s
ntpd: sending query to fdef:ffc0:4fff::3
ntpd: sending query to fdef:ffc0:4fff::131
ntpd: timed out waiting for fdef:ffc0:4fff::3, reach 0x00, next query in 1s
ntpd: timed out waiting for fdef:ffc0:4fff::131, reach 0x00, next query in 1s
.
.
.

Servus
Christian

The current mechanism to setup the wireguard connection and to switch to a different gateway in case of connection failure is unsatisfactory. The script is run once a minute and then uses a random delay of up to 60 seconds until it is started. So initially it may take up to two minutes, until a connection is established.

In case of a gateway failure, e.g. temporary loss of internet connection to one of our server locations, it is even worse - due to the random gateway selections, several tries to unavailable gateways can occur, before a working gateway is selected. Clients which are currently connected, will not automatically get a new IP address or use the new gateway, but rather try to use the old gateway. The DHCP lease time is set to 10 minutes, so it will take another 8 minutes, until clients will send a new DHCP request and eventually get a new IP address and gateway, which works again.

I would suggest using the Projects tab to list the current ToDos and Issues and see which ones are being worked on by whom.

Is it really necessary to do a full rebuild of an image on every change to site.conf? If not, separate the build processes of the base image and the injection of site.conf.

All VXLAN based mesh on lan links are not displayed.

instead of broadcasts for mesh-on-lan

der Wizard zeigt manchmal (in meinen Tests nicht, aber bei anderen schon?) die Keys auf der letzten Seite an: http://imgur.com/NXMCHFg

Aktuell wird im Webinterface nach dem Upload ein MD5 hash angezeigt.
Ist etwas unpraktisch da im .manifest File ein SHA(256?) steht ;)

To not route private networks to the broad network.

Doc: https://gluon.readthedocs.io/en/v2018.1.x/package/gluon-ebtables-source-filter.html

See #17

Due to the custom config mode plugin we used for wireguard in the past, there are nodes with a configuration mismatch, where

gluon.mesh_vpn.enabled=0

and

wireguard.mesh_vpn.enabled=1

To address this issue the update script for wireguards currently sets gluon.mesh_vpn.enabled, in case wireguard.mesh_vpn.enabled is 1. This is causing an issue in the config UI - it is currently not possible to disable Mesh-VPN.

In theory all nodes should now be consistent again, as the firmware update containing the migration script has been rolled out, and it can be removed with the next release. In practice there are some routers that still show the mismatch (NanoPi R2S) for reasons yet to be analyzed, and would disable Mesh-VPN (thus causing nodes to get offline), if the script is removed.

https://github.com/freifunkMUC/community-packages/blob/995c77ec03dc54942abb1bca7870fb9d458a7387/gluon-mesh-vpn-wireguard-vxlan/luasrc/lib/gluon/upgrade/400-mesh-vpn-wireguard#L22

Ein Hinweistext, der erklärt, das die eingegebenen Kontaktadressen für alle im Internet auf der Map sichtbar sein werden. Siehe auch https://lqfb.freifunk-muenchen.de/lf/initiative/show/126.html

While node shows correct transfer rate the offloader shows a much lower traffic as can be seen in the following images:

Checked out a fresh, clean copy of tag v2019.0.4, then tried to build from scratch, but build fails almost at the beginning:

[user@node001 site-ffm.test2]$ make

#########################
# FFMUC Firmware build
# Building release v2019.0.4 for branch stable

make manifest
make[1]: Entering directory `/home/user/site-ffm.test2'
rm -rf output
(cd gluon-build \
        && git remote set-url origin https://github.com/freifunk-gluon/gluon.git \
        && git fetch origin \
        && git checkout -q v2018.2.1)
ln -sfT .. gluon-build/site
make gluon-patch
make[2]: Entering directory `/home/user/site-ffm.test2'
echo "Applying Patches ..."
Applying Patches ...
(cd gluon-build; git branch -D patched)
error: branch 'patched' not found.
make[2]: *** [gluon-patch] Error 1
make[2]: Leaving directory `/home/user/site-ffm.test2'
make[1]: *** [gluon-prepare] Error 2
make[1]: Leaving directory `/home/user/site-ffm.test2'
make: *** [all] Error 2

Manually creating a branch called "patched" in the repo inside the gluon-build directory works around the issue and allows the build to move forward.

See i113.

We have 3 domains:

• ffmuc
• ffmuc_umland
• ffmuc_welcome

When running v2019.0-exp~15 only ffmuc is shown on map although the node is correctly configured and working.

As the only change seems to be the firmware we will check this first. When needed this will be shifted to the correct place

This is a draft idea how we could switch FFMUC to a routed approach without losing functionality of B.A.T.M.A.N. for local meshes.

Problem statement

We want to switch Freifunk Munich to a routed approach towards the gateways, because large layer2 domains pose too many problems. Also we want to get rid of the overhead of VXLAN and B.A.T.M.A.N. towards the gateways.

Idea

• Use wireguard to connect to the Freifunk Munich gateways

• Inside wireguard use a calculated link-local address which is derived from the public key

• v6

  • Run radvd on nodes which have an established wireguard tunnel to announce the v6 /64 inside the local network
  • the local /64 is assigned via wgkex
  • Default route via the wireguard tunnel

• v4

  • Use a fixed /20 per segment and set the next-hop to the v6 address of the gateway, also NAT on the node itself.
  • The node runs DHCP thus it becomes the default gateway for the local network. Also set B.A.T.M.A.N. GW Mode to server.
  • We need a transfer network between gateway and node

• Meshing

  • The node runs B.A.T.M.A.N. for local meshing just the same as on "normal" Gluon

• Why not babel?

  • We want to stay compatible to old nodes, which can just mesh like before.
  • A routing protocol is not needed in this approach, thus we avoid another failure domain.

What needs to be done?

• Test setup with that approach (two raspberry PIs or smth)
• Changes to gluon (dhcp-server, radvd, nat)
• wgkex needs to get a backend database from which transfer v4 addresses are picked
• wgkex also needs to have an database for v6 /64

Possible issues

• Kernel of OpenWRT is too old and doesn't support v6 next-hops for v4
• Meshing freaks out
• IP address conflicts while roaming

Known Issues

• No IPv4 Connectivity between clients which are not in the same local mesh
• Potential IPv4 collisions in spontaneous meshes

Glossar

• Nodes => Freifunk Router
• Gateway => Supernode

Discussion

https://chat.ffmuc.net/freifunk/channels/firmware

Comments welcome! 🚀

quote from freifunk-gluon/gluon#1210
"It is known that a fastd MTU of 1280 bytes will cause excessive fragmentation for full packets on networks that advertise to transport payloads of 1280 bytes, because it neglects the headers that are being added by the batman-adv encapsulation."
see this link for more info.
we discovered an increase of around 30% in maximum possible speed on each node when we migrated in summer 2017

Device: WR841ND v10
Migration from v2019.0-beta1 => v2019-exp~13

Further data:
https://chat.ffmuc.net/freifunk/pl/7p795dzwmpnbpdz4x3rub77ezy

winzerer meldet über chat.ffmuc.net:
"Beim Abspeichern der Konfig vor dem reboot kommt:"

Fehlermeldung: XML-Verarbeitungsfehler: Nicht übereinstimmendes Tag. Erwartet: </div>. Adresse: http://192.168.1.1/cgi-bin/config/wizard Zeile Nr. 36, Spalte 421: <p>Dein Knoten <em>freifunk-asdf</em> startet gerade neu und wird anschließend versuchen, sich mit anderen Freifunk-Knoten in seiner Nähe zu verbinden. [...]

Firmware: v2019-beta1
Gerät: TP-Link TL-WDR4300 v1

Vmlt. bereits seit 2015.7-37, aber erst mit -39 aufgefallen:

Bei vmtl hoherer Last starten meine Router neu. Teilweise alle 2-5min.

841v9: Bei einer VPN-Last von ca. 3-4MBit erfolgt ein Neustart.
Grafna: https://ffmuc.net/stats/dashboard/db/node?var-node_id=e8de27588810 (mittlerweile abgeschaltet, siehe v.a. 24.11.-25.11.)

NanostationM2Loco: Bei mehr als 10 Clients mit etwas Durchsatz (kein VPN!) erfolgt ein Neustart.
Grafna: https://ffmuc.net/stats/dashboard/db/node?var-node_id=24a43ca6c785 (siehe v.a. seit 16.11.)

1043v2.1: Auch hier erfolgt ein Neustart sobald gefuehlt ein bisschen Last aufkommt. Kommt dann Teilweise nichtmal bis zum aufbau der VPN Verbindung vor dem Neustart
Grafna: https://ffmuc.net/stats/dashboard/db/node?var-node_id=30b5c23e9d34 (Siehe v.a. die vielen Luecken seit 20.11. hier bleibt der Router quasi in einer Boot-Loop)

Kann ich irgendwelche Spezifischen Tests durchfuehren?

Anbei ein Ausschnitt aus Grafna von meinem 841 (andznet_01) über einen Zeitraum von ca. 1:15h (24.11. 23:30 - 25.11. 0:45). Man sieht deutlich die häufigen Neustarts sowie die recht hohe Last.

For some reason after a DSL disconnect, B.A.T.M.A.N. on the node sees the gateways but not vice versa which leads to no client network at all.

This started for me with v2020.3.4

Maybe it's related to #96.

See discussion in freifunkMUC/freifunkmuc.github.io#65.

Easier Way to set location on a node:

• Select location on map instead of finding the GPS location somehow.

Available since gluon 2018.2 and setup via module and site.conf:
https://gluon.readthedocs.io/en/v2018.2.x/user/site.html#user-site-config-mode

(migrated from https://tickets.ffmuc.net - 58028)

@goligo I think you already did some work here?

Maybe you already have some stuff in your next branch

1. provide coordinates in meshviewer (on right click) in '$LAT; $LON' format
2. allow pasting coordinates in the above format into luci, alternatively to using two fields. If first field contains semicolon and second field is empty the string will be split. This should be documented on the wizard page

Ein Hinweistext, der auf die Beteiligungsmöglichkeit und vorhandene Dokumentation im lqfb hinweist.

Useful links:
Freifunk-Franken reports sth similar: Node on BATMAN_V cannot measure throughput and always reports 1Mb/s

This is currently observed on vxlan but it seems it is related to BATMAN_V support.

This will probably be fixed when freifunk-gluon/gluon#1726 gets closed

We may want to broadcast an additional SSID for OWE (owe.muenchen.freifunk.net). This ensures that traffic between the node and the client is encrypted, making sniffing of muenchen.freifunk.net's wireless traffic between the node and the client useless

https://gluon.readthedocs.io/en/v2021.1.x/releases/v2020.2.html?highlight=owe#owe-on-client-network

"Opportunistic Wireless Encryption (OWE) is a Wi-Fi standard which ensures that the communication between each pair of endpoints is protected from other endpoints. Unlike conventional Wi-Fi, it provides "Individualized Data Protection" such that data traffic between a client and access point is "individualized". Other clients can still sniff and record this traffic, but they can't decrypt it. " (https://en.wikipedia.org/wiki/Opportunistic_Wireless_Encryption)

2 branches with ssid regensburg.freifunk.net / schwandorf.freifunk.net

Aktuell werden 3000 kbit/s down und 200 kbit/s up als Limits vorgeschlagen.

Die wenigsten werden diesen Wert von sich aus veraendern, daher wuerde ich vorschlagen, diese Werte hochzudrehen auf
6000/600
oder sogar
12000/1200

Bei 50.000er Anschluessen sollten die 12.000 nicht weh tun...und fuer Leute mit 16.000ern kann man ja in die FAQ schreiben dass man eher 6.000 nehmen sollte.
Vielleicht hat jemand von euch noch ne durchdachtere Wahl der Werte am Start :) 🎱

Since both the OpenWrt upstream and the Gluon upstream migrate the ar71xx target to ath79, we should also consider this here.
https://github.com/freifunk-gluon/gluon/blob/master/targets/ath79-generic

https://openwrt.org/releases/21.02/notes-21.02.0-rc2#dropped_hardware_targets
https://openwrt.org/docs/techref/targets/ar71xx-ath79

hallo,

sollte nicht die site.conf der 3 Segmente jeweils so sein?:

#####
ffmuc:
#####

  prefix4 = '10.80.32.0/19',
  prefix6 = 'fdef:ffc0:4fff:0::/64',

  wifi24 = {
    ssid = 'muenchen.freifunk.net',
    channel = 6,
    htmode = 'HT20',
    mesh_ssid = 'mesh.ffmuc',
    mesh_bssid = '02:0E:8E:1E:61:17',
    mesh_mcast_rate = 12000,
  },

  wifi5 = {
    ssid = 'muenchen.freifunk.net',
    channel = 44,
    htmode = 'HT40+',
    mesh_ssid = 'mesh.ffmuc',
    mesh_bssid = '02:0E:8E:1E:61:17',
    mesh_mcast_rate = 12000,
  },

  next_node = {
    ip4 = '10.80.32.1',
    ip6 = 'fdef:ffc0:4fff:0::1',
    mac = '16:41:95:40:f7:dc',
  },



#####
ffmuc-welcome:
#####

  prefix4 = '10.80.64.0/19',
  prefix6 = 'fdef:ffc0:4fff:1::/64',

  wifi24 = {
    ssid = 'muenchen.freifunk.net',
    channel = 6,
    htmode = 'HT20',
    mesh_ssid = 'mesh.ffmuc.welcome',
    mesh_bssid = '02:0E:8E:1E:61:18',
    mesh_mcast_rate = 12000,
  },

  wifi5 = {
    ssid = 'muenchen.freifunk.net',
    channel = 44,
    htmode = 'HT40+',
    mesh_ssid = 'mesh.ffmuc.welcome',
    mesh_bssid = '02:0E:8E:1E:61:18',
    mesh_mcast_rate = 12000,
  },

  next_node = {
    ip4 = '10.80.64.1',
    ip6 = 'fdef:ffc0:4fff:1::1',
    mac = '16:41:95:40:f7:dc',
  },



#####
ffmuc-umland:
#####

  prefix4 = '10.80.96.0/19',
  prefix6 = 'fdef:ffc0:4fff:2::/64',

  wifi24 = {
    ssid = 'muenchen.freifunk.net',
    channel = 6,
    htmode = 'HT20',
    mesh_ssid = 'mesh.ffmuc.umland',
    mesh_bssid = '02:0E:8E:1E:61:19',
    mesh_mcast_rate = 12000,
  },

  wifi5 = {
    ssid = 'muenchen.freifunk.net',
    channel = 44,
    htmode = 'HT40+',
    mesh_ssid = 'mesh.ffmuc.umland',
    mesh_bssid = '02:0E:8E:1E:61:19',
    mesh_mcast_rate = 12000,
  },

  next_node = {
    ip4 = '10.80.96.1',
    ip6 = 'fdef:ffc0:4fff:2::1',
    mac = '16:41:95:40:f7:dc',
  },

Servus
Christian

In case the internet connection is not available, checkuplink tries to setup the tunnel again. When adding the wireguard peer, wireguard retries for about two minutes, to establish the tunnel, before it is giving up. As checkuplink is run once per minute, it will run up to three times in parallel. When the connection comes online again, all three will continue, causing all kind of strange setups, like multiple wireguard tunnels in parallel.

# ps w | grep checkuplink
30280 root      1104 S    /bin/sh /lib/gluon/gluon-mesh-wireguard-vxlan/checkuplink
30897 root      1104 S    /bin/sh /lib/gluon/gluon-mesh-wireguard-vxlan/checkuplink
31520 root      1104 S    /bin/sh /lib/gluon/gluon-mesh-wireguard-vxlan/checkuplink

Mon May 17 21:45:54 2021 daemon.err micrond[1772]: Try again: `gw06.ext.ffmuc.net:40008'. Trying again in 12.84 seconds...
Mon May 17 21:45:54 2021 daemon.err micrond[1772]: Try again: `gw06.ext.ffmuc.net:40008'. Trying again in 7.43 seconds...
Mon May 17 21:45:55 2021 daemon.err micrond[1772]: Try again: `gw07.ext.ffmuc.net:40008'. Trying again in 1.00 seconds...
Mon May 17 21:46:01 2021 daemon.err micrond[1772]: Try again: `gw07.ext.ffmuc.net:40008'. Trying again in 1.20 seconds...
Mon May 17 21:46:07 2021 daemon.err micrond[1772]: Try again: `gw06.ext.ffmuc.net:40008'. Trying again in 8.92 seconds...
Mon May 17 21:46:07 2021 daemon.err micrond[1772]: Try again: `gw07.ext.ffmuc.net:40008'. Trying again in 1.44 seconds...
Mon May 17 21:46:12 2021 daemon.err micrond[1772]: Try again: `gw06.ext.ffmuc.net:40008'
Mon May 17 21:46:14 2021 daemon.err micrond[1772]: Try again: `gw07.ext.ffmuc.net:40008'. Trying again in 1.73 seconds...

In case the setup is broken afterwards, the next run of checkuplink will usually fix it again.

Hier muss die 102 rein :).

As decided in i124, we will not require users to send us their public keys. We will blacklist them on the gateways. Therefore, the notice to the key form and possibly all notices to public/private keys needs to be removed from the web interface.

One should be able to configure the VLAN that should be used for mesh on LAN.

This should also be integrated into upstream Gluon.

Habe mal das gluon-config-mode-site-select Paket (https://github.com/freifunk-gcp/v2015.1) in unseren aktuellen Master gebaut.

Damit kann man mehrere site.confs in eine Firmware integrieren und sie im Gluon Luci und per Kommandozeile umschalten.

Bis auf die bekannte Bindestrich-Allergie von lua gab es keine Probleme, allerdings musste ich den site-code von ffmuc-umland in ffmuc_umland aendern damit es reibungslos funktioniert.
Ausserdem gibt es Probleme beim kompilieren, wenn unsere custom gluon-ebtables-filter-... Pakete eingebaut werden sollen.
Es gibt allerdings noch einiges zu testen und fixen bevor man daran denken koennte das zu verwenden:

• Upgrade von aktueller gluon-ffmuc-v2015.5 Firmware auf Firmware mit site-select (site.conf muss nach Upgrade identisch mit ffmuc.conf sein)

👍 Funktioniert. Die alte site.conf wird mit neuer site.conf mit entsprechendem site-code ersetzt (ffmuc -> ffmuc).

• Upgrade von aktueller gluon-ffmuc-umland-v2015.6 Firmware auf Firmware mit site-select (site.conf muss nach Upgrade trotz Aenderung von des site-codes von "ffmuc-umland" auf "ffmuc_umland" identisch mit ffmuc_umland.conf sein)

👎 Funktioniert nicht. Landet bei ffmuc.

• Was passiert bei einem Upgrade auf eine Firmware, bei der der aktuell ausgewaehlte site-code nicht mehr verfuegbar ist?

Ist der alte site-code nicht mehr in der neuen Firmware, wird auf den default site-code zurueckgefallen. -> Das hilft beim zweiten Testcase! Um von ffmuc-umland auf ffmuc_umland zu kommen, muss dort einfach eine Firmware mit ffmuc_umland als default site.conf verteilt werden.

• Herausfinden, warum unsere gluon-ebtables-filter Pakete nicht mit eingebaut werden koennen und fixen

🍻

Hinweis: "Default site.conf" ist die site.conf, die nicht nur als ./site-ffm/extras/.conf existiert, sondern auch nochmal explizit als ./site-ffm/site.conf.

Hallo,

da wir nun auch IPv6 Adressen bei den gwtest*.ffmuc.net zurückliefern, sollten wir dann aber auch die MTU für IPv6 anpassen. Der Wert 1426 ist für IPv6 zu hoch. Es dürfen maximal 1406 sein.

Servus
Christian

with current gluon release build with this site config fails with follwoing error:

mode-site-select/ipkg-mips_24kc/gluon-config-mode-site-select/lib/gluon/site-select/ffmuc.json
lua: site_config.lua:9: site_config.lua:5: attempt to index a nil value
stack traceback:
        [C]: ?
        [C]: in function 'load'
        site_config.lua:9: in main chunk
        (command line):1: in main chunk
        [C]: ?
stack traceback:
        [C]: in function 'assert'
        site_config.lua:9: in main chunk
        (command line):1: in main chunk
        [C]: ?

de.pool.ntp.org anstelle interner services

Take a look at https://gitlab.com/FreifunkChemnitz/site-ffc/-/commit/fecab42d198685ae15f924c5e61aa1af22b9487c and https://gitlab.com/FreifunkChemnitz/site-ffc/-/commit/9bf94c4cc002c497ddac733cea861c892e746075

Just to give you ideas to get a shorter and more readable site.mk

https://github.com/DanielAdolfsson/ndppd

In the wifi settings in expert mode, the user should be able to configure the wifi channels for 2.4GHz and 5GHz. This should either be set to "default" (= site.conf setting) or "auto" and all available channels. The underlying wifi settings in uci (/etc/config/network) should be persistent and not be touched after sysupgrades if not set to "default".

Use Cases

• For installations with meshing over wired connections and many access points in close proximity (due to many clients), it would make sense to disable wireless meshing and use the full wifi spectrum to increase usability.
• Exclusive mesh nodes without client wifi can be established to bridge distances where no cables can be installed and wouldn't impact regular users on the default channel.

Implementation

A bit of research is needed if this can be achieved with a new package or if the existing gluon-luci-wifi-config package needs adjustments.

Working around currently open issue #62 with tag v2019.0.4, the build otherwise seems mostly successful, i.e. image files are generated. However, it seems build process tries to create a directory "output" inside the top level "site-ffm" directory, and to populate it with the images created in some lower level subdirectories. And this fails as a botched path with some extraneous backslash "\" is being used in the attempt, e.g. (same symptom also for other build targets) "openwrt/bin/targets/x86\/generic/openwrt-x86-generic-combined-ext4.img.gz":

 make[6] -C /home/user/site-ffm.test/gluon-build/packages/packages/net/xtables-addons compile
 make[5] package/install
 make[5] target/install
 make[6] -C target/linux install
 make[5] package/index
 make[5] checksum
make[3]: Leaving directory `/home/user/site-ffm.test/gluon-build/openwrt'
cp: cannot stat 'openwrt/bin/targets/x86\\/generic/openwrt-x86-generic-combined-ext4.img.gz': No such file or directory
make[2]: *** [all] Error 1
make[2]: Leaving directory `/home/user/site-ffm.test/gluon-build'
Building target x86-geode
make[2]: Entering directory `/home/user/site-ffm.test/gluon-build'
make[3]: Entering directory `/home/user/site-ffm.test/gluon-build/openwrt'

It seems the script copy_output.sh in site-ffm/gluon-build/scripts is the one trying to use the bad path, so might be an upstream issue. But I am currently not sufficiently familiar with the entire process to track down why the script is using a botched path, whether the script itself is at fault, or whether something else is feeding it bad data.

Port needs to be 30008!