gluon-core: add outdoor channel support for 5 ghz radios #1329

mweinelt · 2018-02-12T00:25:14Z

    Add the `wifi5.outdoor_chanlist` site configuration that
    allows specifying an outdoor channel range that can be
    switched to for regulatory compliance.
    
    Upon enabling the outdoor option the device will
     - configure the `outdoor_chanlist` on all 5 GHz radios
     - which may enable DFS/TPC, based on the regulatory domain
     - disable ibss/mesh on the 5 GHz radio, as DFS *will*
       break mesh connections
     - allow for htmode reconfiguration on 5 GHz radios
    
    The outdoor option can be toggled from
     - Advanced Settings
       - W-LAN
         - Outdoor Installation
    
    The `preserve_channel` flag overrules the outdoor channel
    selection.

Configuring from Config Mode

Configuring from CLI

Outdoor disabled

root@64xxx-f81a67a5f222:~# uci set gluon.wireless.outdoor='0'
root@64xxx-f81a67a5f222:~# /lib/gluon/upgrade/200-wireless 
root@64xxx-f81a67a5f222:~# uci show wireless.radio0.channel; uci show wireless.radio1.channel; uci show wireless.mesh_radio0.disabled
wireless.radio0.channel='44'
wireless.radio1.channel='1'
wireless.mesh_radio0.disabled='0'
root@64xxx-f81a67a5f222:~# wifi
root@64xxx-f81a67a5f222:~# iw dev
phy#1
	Interface client1
		ifindex 18
		wdev 0x100000003
		addr f8:1a:67:a5:f2:21
		ssid darmstadt.freifunk.net
		type AP
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
	Interface mesh1
		ifindex 17
		wdev 0x100000002
		addr ae:02:43:9d:a4:05
		type mesh point
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
phy#0
	Interface client0
		ifindex 16
		wdev 0x3
		addr ae:02:43:9d:a4:00
		ssid darmstadt.freifunk.net
		type AP
		channel 44 (5220 MHz), width: 20 MHz, center1: 5220 MHz
		txpower 20.00 dBm
	Interface mesh0
		ifindex 15
		wdev 0x2
		addr ae:02:43:9d:a4:01
		type mesh point
		channel 44 (5220 MHz), width: 20 MHz, center1: 5220 MHz
		txpower 20.00 dBm

Outdoor enabled

root@64xxx-f81a67a5f222:~# uci set gluon.wireless.outdoor='1'
root@64xxx-f81a67a5f222:~# /lib/gluon/upgrade/200-wireless 
root@64xxx-f81a67a5f222:~# uci show wireless.radio0.channel; uci show wireless.radio1.channel; uci show wireless.mesh_radio0.disabled
wireless.radio0.channel='100'
wireless.radio1.channel='1'
wireless.mesh_radio0.disabled='1'
root@64xxx-f81a67a5f222:~# wifi
root@64xxx-f81a67a5f222:~# iw dev
phy#1
	Interface client1
		ifindex 21
		wdev 0x100000005
		addr f8:1a:67:a5:f2:21
		ssid darmstadt.freifunk.net
		type AP
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
	Interface mesh1
		ifindex 20
		wdev 0x100000004
		addr ae:02:43:9d:a4:05
		type mesh point
		channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
		txpower 20.00 dBm
phy#0
	Interface client0
		ifindex 19
		wdev 0x4
		addr ae:02:43:9d:a4:00
		type AP
		channel 100 (5500 MHz), width: 20 MHz, center1: 5500 MHz
		txpower 22.00 dBm
root@64xxx-f81a67a5f222:~# logread | grep DFS
Mon Feb 12 01:22:49 2018 daemon.notice hostapd: client0: interface state COUNTRY_UPDATE->DFS
Mon Feb 12 01:22:49 2018 daemon.notice hostapd: client0: DFS-CAC-START freq=5500 chan=100 sec_chan=0, width=0, seg0=0, seg1=0, cac_time=60s
Mon Feb 12 01:23:49 2018 daemon.notice hostapd: client0: DFS-CAC-COMPLETED success=1 freq=5500 ht_enabled=1 chan_offset=0 chan_width=1 cf1=5500 cf2=0
Mon Feb 12 01:23:49 2018 daemon.notice hostapd: client0: interface state DFS->ENABLED

TODO

blocktrron · 2018-02-12T11:48:18Z

In addition to this, it would be great to have some devices pre-configured to use outdoor channels. Devices such as Nanostation M5, CPE510, UniFi AP AC Mesh (probably impossible atm. due to wrong board detection).

mweinelt · 2018-02-13T01:21:05Z

If we're doing client only on 5 GHz we could aim for other htmodes as well, no?

mweinelt · 2018-02-15T22:57:35Z

Simon Wunderlich's slides on "Dynamic Frequency Selection in 5 GHz mesh networks"
https://www.battlemesh.org/BattleMeshV7/Agenda?action=AttachFile&do=get&target=2014-05-17_wbmv7_DFS.pdf

Intelligent handling of mesh connections is out of scope for this issue.

MPW1412 · 2018-02-15T23:05:12Z

As comments were requested in the gluon developer mumble meeting tonight: I would like to see this merged, as we have a lot of Ubiquity AC Mesh Pro devices here in Münsterland, which are running with original firmware so far and could be flashed with Gluon then. For now we install the rocket m2 for mesh and use a dual band access point at the same place. This could be reduced to one dual band device and by this simplifies setups.

Vote fore merge. :)

mweinelt · 2018-02-16T23:29:00Z

config mode lets you configure htmode per radio now.
config only shows up when you actually have a 11a/11na/11ac radio

looking for more people willing to test now! set wifi5.outdoor_chanlist to 100-140 for example.

also the section description and field labels could need some polishing, please start here: https://md.darmstadt.ccc.de/gluon-outdoor-config-mode

mweinelt · 2018-02-27T23:10:46Z

I tested this for the DFS-ETSI regdom, the 5 GHz radio automatically uses a txpower setting according to {regdom, device capability}.

The global regulatory domain seems to be what's used, the per phy value apparently is not.

# iw reg get
global
country DE: DFS-ETSI
	(2400 - 2483 @ 40), (N/A, 20), (N/A)
	(5150 - 5250 @ 80), (N/A, 20), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
	(5470 - 5725 @ 160), (N/A, 27), (0 ms), DFS
	(5725 - 5875 @ 80), (N/A, 14), (N/A)
	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#1
country US: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
	(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
	(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
	(5735 - 5835 @ 80), (N/A, 30), (N/A)
	(57240 - 63720 @ 2160), (N/A, 40), (N/A)

phy#0
country US: DFS-FCC
	(2402 - 2472 @ 40), (N/A, 30), (N/A)
	(5170 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
	(5250 - 5330 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
	(5490 - 5730 @ 160), (N/A, 23), (0 ms), DFS
	(5735 - 5835 @ 80), (N/A, 30), (N/A)
	(57240 - 63720 @ 2160), (N/A, 40), (N/A)

UAP-AC-Mesh

# iw dev
[...]
phy#0
	Interface client0
		ifindex 20
		wdev 0x6
		addr ba:f5:60:dd:39:70
		ssid darmstadt.freifunk.net
		type AP
		channel 140 (5700 MHz), width: 20 MHz, center1: 5700 MHz
		txpower 27.00 dBm

WDR4900v1 (didn't find a radar-free channel … weird)

# iw dev
[...]
phy#0
	Interface client0
		ifindex 28
		wdev 0x5
		addr ae:02:43:9d:a4:00
		type AP
		channel 120 (5600 MHz), width: 20 MHz, center1: 5600 MHz
		txpower 22.00 dBm

mweinelt · 2018-02-28T02:54:48Z

The last commit adds an improved channel and chanlist validation:

wifi24.channel and wifi5.channel now check against an array of valid channels:

*** site.conf error: expected wifi24/channel to be one of the given array [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14], but it is 0

*** site.conf error: expected wifi5/channel to be one of the given array [34, 36, 38, 40, 42, 44, 46, 48, 50, 52, 54, 56, 58, 60, 62, 64, 100, 102, 104, 106, 108, 110, 112, 114, 116, 118, 120, 122, 124, 126, 128, 132, 134, 136, 138, 140, 142, 144, 149, 151, 153, 155, 157, 159, 161, 165, 169, 173], but it is 45

Also chanlist validation implements what hostapd describes to be a valid chanlist:

# Channel list restriction. This option allows hostapd to select one of the
# provided channels when a channel should be automatically selected.
# Channel list can be provided as range using hyphen ('-') or individual
# channels can be specified by space (' ') separated values
# Default: all channels allowed in selected hw_mode
#chanlist=100 104 108 112 116
#chanlist=1 6 11-13

mweinelt · 2018-03-26T21:22:16Z

And the language strings for de and en are in. Next up is testing, testing and testing. Anybody willing to chime in?

mweinelt · 2018-03-27T00:11:11Z

~~I currently see a 500 Bad Gateway after clicking Save & Restart. I don't get an error message and haven't found the error yet.~~

This issue was unrelated to this PR.

mweinelt · 2018-04-04T18:24:43Z

Model detection for UAP-AC-M is stuck in the openwrt pull request queue (openwrt/openwrt#767) and OpenWrt 18.5 is supposed to be branched in 3 days.

IMO this is the most interesting device for this PR, but the review/merge isn't happening.

MPW1412 · 2018-04-06T20:10:12Z

It's merged now.

openwrt/openwrt#767

CodeFetch · 2018-07-22T16:54:22Z

There was a talk on the last battlemesh where they said that DFS in ath9k is broken as it has far too many false-positives (maybe it was a lightning talk as it is not on the schedule).
They said they have implemented DFS in hostapd which works reliable and it was tested in a certified environment. Maybe it was „Opennet Initiative“. I don't know... https://wiki.opennet-initiative.de/wiki/OpenWrt_DFS/Experiment

I oppose merging this unless we are either sure that DFS works correctly (which I doubt) or whoever did that talk releases their work and we confirmed it's working.
It is not okay to merge something into Gluon that makes communities think they can switch to outdoor channels now while there is evidence that it is broken.

Adorfer · 2018-07-22T20:54:38Z

"false positives" are better than "no 5G outdoor at all".
If somebody can improve the DFS later: why not.
But at least it's start.
Or do you assume that "not merging" will improve the reliability of dectection significantly/instantly?

CodeFetch · 2018-07-24T23:32:17Z

@Adorfer You are right. I misunderstood what the PR does. As it falls back to indoor channels when no radar-free channel was detected, it is safe to merge this and I didn't see that one can define devices for which outdoor channels can be used before.
Only the DFS detection in ath9k is broken. Ath10k should be fine.
As far as I remember it can happen that a node continuously detects radar without any radar at all.
~~Markus~~Martin said „WDR4900v1 (didn't find a radar-free channel … weird)“. It seems to be the case for this device as mine does not find a radar free channel, too.
Nonetheless I've written an e-mail to the Opennet people hoping that we can fix DFS completely soon.

@mweinelt We have a very strong CW radar in our city. It uses channels 116-132. Can you please change the outdoor channel siteconf definition to be a list instead so that one can define e.g. outdoor_chanlist = {'100-112', '136', '140'}, add a siteconf check to make sure that the default channel is always an indoor channel and mention this in the docs?

The only problem I still see is when radar was detected once and the node switches to the indoor channel it is unlikely that it ever switches to an outdoor channel again or am I missing something?

mweinelt · 2018-07-24T23:37:42Z

@CodeFetch:

outdoor_chanlist = '100-112 136 140',

see #1329 (comment)

It shouldn't switch to an indoor channel if that's not in the chanlist.

(also I'm Martin, not Markus)

CodeFetch · 2018-07-24T23:58:47Z

@mweinelt Oh sorry Martin... Did I get it right the first time that when I activate outdoor channels it does not use the default (indoor) channel anymore?
Are you sure that it can't happen that a node detects radar on all outdoor channels hence not being reachable for some time at all?
In the talk they said some ath9k devices detect radar very often and some even always. I don't know if it only differs per location, device or chipset, but I'd like to be sure beforehand...

mweinelt · 2018-07-25T00:18:58Z

When you activate outdoor mode it sets:

channel=auto

That removes the indoor channel from the hostapd configuration

As I described in #1329 (comment) I indeed had the situation that a WDR4900v1 didn't find a radar-free channel and therefore didn't set up the radio. I didn't research this any further.

I've tried this on ath9k/ath10k/mt76, all seem to be working (to some degree?).

CodeFetch · 2019-03-18T20:30:20Z

@blocktrron Merging with LibreMesh is on the plan for more than 3 years now. We've talked about that with the LibreMesh developers on the last BattleMesh and last consent was that after we've successfully modularized the packages to be independent from Batman and Babel integration is fine, we should have a look at how to support BMX7. That AREDN-Mesh wants to have a look at switching to Gluon is new. I have the names of devices in #94 corresponding to vendor device IDs from their firmware and extracted the other power offsets from the UBNT firmware. They want to get rid of their Perl-Scripts and switch to a cleaner solution.

Edit: BTW description of Gluon is "a modular framework for creating OpenWrt-based firmwares for wireless mesh nodes" and not "Freifunk firmware build environment"

neocturne · 2019-03-23T16:42:19Z

"Merging with LibreMesh" is unrealistic, and I don't even consider it desirable, as it will further reduce the diversity in mesh firmware frameworks. We can work together and try to create modules that are usable by both projects, but I don't think either project will disappear.

neocturne · 2019-03-23T16:51:00Z

@CodeFetch Modularization can be achieved in a later refactoring.

CodeFetch · 2019-03-23T23:11:39Z

@NeoRaider Yes, it can be done later. I wasn't clear about that. "Merging" was the wrong word. They'd use Gluon as their base system when it's modular enough and as you say merging efforts of common packet development and system stability, device support patching etc.

package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

scripts/check_site.lua

package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless

package/gluon-core/luasrc/lib/gluon/upgrade/180-outdoor-preset

neocturne · 2019-04-23T11:57:41Z

package/gluon-core/luasrc/lib/gluon/upgrade/180-outdoor-preset

+
+uci:section('gluon', 'wireless', 'wireless', {
+    outdoor = platform_info.is_outdoor_device()
+})


I think it is unexpected that the outdoor mode may be enabled on a sysupgrade. When this is not a fresh configuration (sysconfig.gluon_version is set), outdoor should always be set to false.

Fixed in 492c22e

Rather than doing nothing when sysconfig.gluon_version is set, outdoor should be set to false in this case

I think it would make sense to have a site.conf option that can force the default to on or off

Wow, I didn't properly read what you wrote earlier, sorry. Fixed in f6b9feb.

TODO.

package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless

package/gluon-web-wifi-config/luasrc/lib/gluon/config-mode/model/admin/wifi-config.lua

package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless

neocturne · 2019-04-28T14:49:03Z

#1716 caused a few merge conflicts...

docs/site-example/site.conf

Add the `wifi5.outdoor_chanlist` site configuration that allows specifying an outdoor channel range that can be switched to for regulatory compliance. Upon enabling the outdoor option the device will - configure the `outdoor_chanlist` on all 5 GHz radios - which may enable DFS/TPC, based on the regulatory domain - disable ibss/mesh on the 5 GHz radio, as DFS *will* break mesh connections - allow for htmode reconfiguration on 5 GHz radios The outdoor option can be toggled from - Advanced Settings - W-LAN - Outdoor Installation The `preserve_channel` flag overrules the outdoor channel selection.

adds a section to the wizard for outdoor capable devices that informs the user of of the regulatory situation and allows a quick toggle of the outdoor mode.

belzebub40k · 2019-04-29T08:36:02Z

I just looked into the feature after it got merged but it looks like there is a mismatch between what is checked in check_site.lua ...

gluon/package/gluon-core/check_site.lua

Line 47 in ddb11dd

need_one_of({config, 'outdoors'}, {true, false, 'preset'}, false)

... and what is read in 180-outdoors.

gluon/package/gluon-core/luasrc/lib/gluon/upgrade/180-outdoors

Line 17 in ddb11dd

local config = site.wifi5.outdoor_preset('preset')

Also the documentation says:

The outdoors option in turn allows to configure when outdoor mode will be enabled.

mweinelt · 2019-04-29T14:08:55Z

Thanks, fixed in ad1a190.

neocturne · 2019-04-29T15:24:58Z

Hmm, should the site.conf setting really be placed under wifi5? While it doesn't matter for 2.4GHz, other frequency bands that may be added in the future will likely have similar restrictions, so I'd see the outdoor mode more as a global (toplevel) flag.

neocturne · 2019-04-29T22:29:40Z

Hmm, should the site.conf setting really be placed under wifi5? While it doesn't matter for 2.4GHz, other frequency bands that may be added in the future will likely have similar restrictions, so I'd see the outdoor mode more as a global (toplevel) flag.

@mweinelt Opinions on this?

mweinelt · 2019-04-29T23:35:43Z

Yes, long-term you are correct.

Short-term (still several years) we're not going to see another frequency band for outdoor usage, are we?

We can certainly change this now, I'm not sure we need to.

mweinelt changed the title ~~RFC: gluon-core, gluon-web-wifi-config: add outdoor option~~ RFC, WIP: gluon-core, gluon-web-wifi-config: add outdoor option Feb 12, 2018

rotanid added 0. type: enhancement The changeset is an enhancement 2. status: rfc request for comments labels Feb 15, 2018

mweinelt changed the title ~~RFC, WIP: gluon-core, gluon-web-wifi-config: add outdoor option~~ RFC, WIP: gluon-core: add outdoor regulatory compliance support for 5 ghz radios Feb 16, 2018

mweinelt changed the title ~~RFC, WIP: gluon-core: add outdoor regulatory compliance support for 5 ghz radios~~ RFC, WIP: gluon-core: add outdoor channel support for 5 ghz radios Feb 16, 2018

mweinelt changed the title ~~RFC, WIP: gluon-core: add outdoor channel support for 5 ghz radios~~ RFC: gluon-core: add outdoor channel support for 5 ghz radios Feb 16, 2018

mweinelt changed the title ~~RFC: gluon-core: add outdoor channel support for 5 ghz radios~~ gluon-core: add outdoor channel support for 5 ghz radios Feb 28, 2018

neocturne mentioned this pull request Mar 25, 2018

CPE 510 still low tx power #1023

Closed

rotanid added 5. needs: testing Testing of the changes is necessary and removed 2. status: rfc request for comments labels Mar 27, 2018

neocturne added this to the next milestone May 5, 2018

rotanid modified the milestones: next, 2018.2 Jul 9, 2018

neocturne mentioned this pull request Mar 24, 2019

[RFC] gluon-web-model: Make model-maps extensible #1662

Closed

rotanid requested a review from neocturne April 8, 2019 22:16

mweinelt added the 2. status: waiting-on-author Waiting on some action from the author label Apr 10, 2019

mweinelt added 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. and removed 2. status: waiting-on-author Waiting on some action from the author labels Apr 22, 2019

neocturne requested changes Apr 23, 2019

View reviewed changes

neocturne reviewed Apr 24, 2019

View reviewed changes

package/gluon-web-wifi-config/luasrc/lib/gluon/config-mode/model/admin/wifi-config.lua Outdated Show resolved Hide resolved

rotanid added the 2. status: waiting-on-author Waiting on some action from the author label Apr 25, 2019

TobleMiner reviewed Apr 25, 2019

View reviewed changes

package/gluon-core/luasrc/lib/gluon/upgrade/200-wireless Outdated Show resolved Hide resolved

rotanid requested a review from neocturne April 27, 2019 15:24

rotanid removed the 2. status: waiting-on-author Waiting on some action from the author label Apr 27, 2019

neocturne reviewed Apr 28, 2019

View reviewed changes

docs/site-example/site.conf Outdated Show resolved Hide resolved

mweinelt added 4 commits April 28, 2019 18:17

gluon-core: improve channel and add chanlist validation

423aafb

gluon-core: allow presetting the outdoor mode for new installations

e20d5b0

add gluon-config-mode-outdoor package

501c3b3

adds a section to the wizard for outdoor capable devices that informs the user of of the regulatory situation and allows a quick toggle of the outdoor mode.

neocturne merged commit ddb11dd into freifunk-gluon:master Apr 28, 2019

rotanid removed the 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. label Apr 30, 2019

This comment has been minimized.

Sign in to view

mweinelt deleted the outdoor_mode branch June 9, 2021 23:07

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

gluon-core: add outdoor channel support for 5 ghz radios #1329

gluon-core: add outdoor channel support for 5 ghz radios #1329

mweinelt commented Feb 12, 2018 •

edited

Loading

blocktrron commented Feb 12, 2018

mweinelt commented Feb 13, 2018

mweinelt commented Feb 15, 2018

MPW1412 commented Feb 15, 2018

mweinelt commented Feb 16, 2018 •

edited

Loading

mweinelt commented Feb 27, 2018 •

edited

Loading

mweinelt commented Feb 28, 2018

mweinelt commented Mar 26, 2018

mweinelt commented Mar 27, 2018 •

edited

Loading

mweinelt commented Apr 4, 2018

MPW1412 commented Apr 6, 2018 •

edited

Loading

CodeFetch commented Jul 22, 2018 •

edited

Loading

Adorfer commented Jul 22, 2018

CodeFetch commented Jul 24, 2018 •

edited

Loading

mweinelt commented Jul 24, 2018 •

edited

Loading

CodeFetch commented Jul 24, 2018

mweinelt commented Jul 25, 2018

CodeFetch commented Mar 18, 2019 •

edited

Loading

neocturne commented Mar 23, 2019

neocturne commented Mar 23, 2019

CodeFetch commented Mar 23, 2019

neocturne Apr 23, 2019

mweinelt Apr 24, 2019

neocturne Apr 25, 2019

mweinelt Apr 25, 2019

mweinelt Apr 26, 2019

neocturne commented Apr 28, 2019

belzebub40k commented Apr 29, 2019

mweinelt commented Apr 29, 2019

neocturne commented Apr 29, 2019

neocturne commented Apr 29, 2019

mweinelt commented Apr 29, 2019

This comment has been minimized.

gluon-core: add outdoor channel support for 5 ghz radios #1329

gluon-core: add outdoor channel support for 5 ghz radios #1329

Conversation

mweinelt commented Feb 12, 2018 • edited Loading

Configuring from Config Mode

Configuring from CLI

TODO

blocktrron commented Feb 12, 2018

mweinelt commented Feb 13, 2018

mweinelt commented Feb 15, 2018

MPW1412 commented Feb 15, 2018

mweinelt commented Feb 16, 2018 • edited Loading

mweinelt commented Feb 27, 2018 • edited Loading

mweinelt commented Feb 28, 2018

mweinelt commented Mar 26, 2018

mweinelt commented Mar 27, 2018 • edited Loading

mweinelt commented Apr 4, 2018

MPW1412 commented Apr 6, 2018 • edited Loading

CodeFetch commented Jul 22, 2018 • edited Loading

Adorfer commented Jul 22, 2018

CodeFetch commented Jul 24, 2018 • edited Loading

mweinelt commented Jul 24, 2018 • edited Loading

CodeFetch commented Jul 24, 2018

mweinelt commented Jul 25, 2018

CodeFetch commented Mar 18, 2019 • edited Loading

neocturne commented Mar 23, 2019

neocturne commented Mar 23, 2019

CodeFetch commented Mar 23, 2019

neocturne Apr 23, 2019

Choose a reason for hiding this comment

mweinelt Apr 24, 2019

Choose a reason for hiding this comment

neocturne Apr 25, 2019

Choose a reason for hiding this comment

mweinelt Apr 25, 2019

Choose a reason for hiding this comment

mweinelt Apr 26, 2019

Choose a reason for hiding this comment

neocturne commented Apr 28, 2019

belzebub40k commented Apr 29, 2019

mweinelt commented Apr 29, 2019

neocturne commented Apr 29, 2019

neocturne commented Apr 29, 2019

mweinelt commented Apr 29, 2019

This comment has been minimized.

mweinelt commented Feb 12, 2018 •

edited

Loading

mweinelt commented Feb 16, 2018 •

edited

Loading

mweinelt commented Feb 27, 2018 •

edited

Loading

mweinelt commented Mar 27, 2018 •

edited

Loading

MPW1412 commented Apr 6, 2018 •

edited

Loading

CodeFetch commented Jul 22, 2018 •

edited

Loading

CodeFetch commented Jul 24, 2018 •

edited

Loading

mweinelt commented Jul 24, 2018 •

edited

Loading

CodeFetch commented Mar 18, 2019 •

edited

Loading