Gluon: SSID is showing up late

[A-Kasper]

I think it was my own idea to save airtime and reduce the rate of the beacon frames.
I don't like the effect that the gluon ssid is showing up very very late in wlan lists. This leads to clients connecting to other networks.
I would like to discuss to increase it again

[NeoRaider]

We have never changed the beacon interval, it has always been 100ms (which is the default used by most WLANs).

[A-Kasper]

I'm not sure what we did.. but the Freifunk SSID is showing up very late
now. Context was saving of airtime. I'll search for the old ticket later.

>

[A-Kasper]

I can't find it. Maybe we discussed it in irc.

I would like to report this issue without knowing why it behaves like this

When I choose my wifi in android or windows the freifunk ssid is showing up very late. the private wlan is there instantly. in android it needs 3 to 4 list refresh cycles till freifunk is shown. The mesh showsup at about 2 refresh cycles.

Any Ideas?

[NeoRaider]

The Freifunk SSID always shows up instantaneously for me. It is likely a signal issue, e.g. high interference on the Freifunk channel.

[A-Kasper]

That doesn't make sense to me because the private wifi of gluon is there
instantaneously. with same channel and interference...

is something in site.conf that could be misconfigured and result in such
behavior?

>

[rotanid]

maybe it is broken behaviour of you Client device.
please also try another communities firmware.

[A-Kasper]

please reopen, the issue was spottet by someone else in irc

I investigated it a little bit. Setup:
2017.1.5, latest commit, 11s, privatewifi activated

The ssid is not shown, and disappears again.... Same in Android and Windows. I don't think it's a client issue.
If I give the ap a mesh neighbour, the ssid is shown. (I changed the ssid name in the meshneighbour to make sure, that it is not the neighbours SSID.

So there seems to be something wrong if there is no meshpartner available. I'll now check if deactivating private wifi has an effect

[A-Kasper]

okay... after some research I could identify, that the issue is related to txpower-settings. seems to be missconfiguration.

[rubo77]

I observed the same effect: the ff-ssid didn't show up in the list for some time (maybe 20s). Also on most IOS devices.

Maybe this doesn't show up in most developers-surrounding, because most of us have several Freifunk APs at home that send the same SSID.

Also I think it depends on the device, that is scanning for WIFI. I noticed this on Ubuntu 17.10 with Networkdamager ;)

[A-Kasper]

I noticed it at windows and android.
I'm not really sure if this is an issue or not. if i lower txpowersetting everything is fine.

but:
the private wifi works very fine with high tx power, that is why my Bauchgefühl saysthat there is something wrong in Freifunk part of gluon.

I can also report that there is an "Ausgeblendetes Netzwerk" without sended SSID under Windows that disappears when Freifunk SSID is shown.

I think there is a bug, but I've no idea where it comes from. How can I save wifi signals as beacons etc to analyze what is happening here. Maybe with some mac we could find something more

[rotanid]

@A-Kasper the tool "horst" can show you beacons etc. live

[A-Kasper]

Thank you. It looks like there is something wrong:

1 -30 6 42:84:29:b8:20:6b (42:84:29:b8:20:6b) PROBRP 'Claudi-IPv6' ddc21c8e
1 -29 6 42:84:29:b8:20:6b (42:84:29:b8:20:6b) BEACON 'Claudi-IPv6' ddc25180
1 -30 12 42:84:29:b8:20:69 (42:84:29:b8:20:69) BEACON '' ddf90180

69 ist the Freifunk SSID. There are becons send without BSSID. The Problem is only in Freifunk WLAN.
@rotanid Please reopen this Ticket. I'm sure this needs some more investigation....

After more tests I have to call back my reports:

• The issue also happens with mesh partner
• The issue also happens with correct tx settings

Environmend1043v3 with gluon 2017.1.5 latest commit

[SimJoSt]

I can observe this behavior on my Windows machine as well. On Android the problem is less drastic.

[mweinelt]

Are all devices affected by this issue running private wifi? More information would go a long way to reproduce and track down the issue.

Outputs of

• iwinfo,
• iw dev,
• hostapd configurations at /var/run/hostapd-* (remember to mask the password for private wifi configurations)

[A-Kasper]

The two nodes I'm using and reporting from have both private wifi activated. I can't say if this also apears in nodes without private-wifi

```root@FF-BO-aidshilfe-enJoy:~# iwinfo
client0 ESSID: "Freifunk"
Access Point: EE:0F:D9:4F:26:00
Mode: Master Channel: 1 (2.412 GHz)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0

mesh0 ESSID: unknown
Access Point: 00:00:00:00:00:00
Mode: Mesh Point Channel: 1 (2.412 GHz)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0

wlan0-1 ESSID: "ah-bochum-enjoy"
Access Point: EE:0F:D9:4F:26:03
Mode: Master Channel: 1 (2.412 GHz)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: -95 dBm
Bit Rate: unknown
Encryption: WPA2 PSK (CCMP)
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0

root@FF-BO-aidshilfe-enJoy:# iw dev
phy#0
Interface client0
ifindex 15
wdev 0x4
addr ee:0f:d9:4f:26:00
ssid Freifunk
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
Interface wlan0-1
ifindex 14
wdev 0x3
addr ee:0f:d9:4f:26:03
ssid ah-bochum-enjoy
type AP
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
Interface mesh0
ifindex 13
wdev 0x2
addr ee:0f:d9:4f:26:01
type mesh point
channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz
txpower 20.00 dBm
root@FF-BO-aidshilfe-enJoy:~# cat /var/run/hostapd-*
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=DE
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 90 120 180 240 360 480 540
beacon_int=100
channel=1

ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][DSSS_CCK-40]

interface=wlan0-1
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=masked
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=ah-bochum-enjoy
bridge=br-wan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=ee:0f:d9:4f:26:03

bss=client0
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
auth_algs=1
wpa=0
ssid=Freifunk
bridge=br-client
bssid=ee:0f:d9:4f:26:00

```

[NeoRaider]

@A-Kasper

1 -30 12 42:84:29:b8:20:69 (42:84:29:b8:20:69) BEACON '' ddf90180

42:84:29:b8:20:69 is the mesh SSID; 11s beacons are shown with empty SSID by horst. The client SSID either uses your device's primary address or 42:84:29:b8:20:68 (depending on the hardware).

I was able to reproduce the issue, and it seems it is caused by the basic_rate/supported_rates settings. It looks like the beacons produced with these settings are "weird" (for example, they are missing the "Extended Supported Rates" (50) tag). As a workaround, these settings can be removed from site.conf.

I will need to make further tests to find the root cause of this behaviour.

[NeoRaider]

Upon further analysis, the issue does not seem to be caused by the contents of the beacons (having no "Extended Supported Rates" is expected as the "Supported Rates" field is long enough to list all rates when the 11b rates are disabled), but by the fact that the beacons are sent at 6Mbit/s instead of 1MBit/s, which seems to lead to suboptimal client compatiblity.

[NeoRaider]

... but overall, I'm not much closer to a solution, as I also see other 11g APs using 6MBit/s including FritzBoxes, and I haven't heard of FritzBoxes having similar issues.

[A-Kasper]

the private wifi don't got these problems. are there different settings for supported rates etc. for private wifi?

The settings in site.conf example are missing some speeds is this okay?

[NeoRaider]

I can only reproduce this issue while connected to another network; as soon as I explicitly disconnect, all SSIDs appear. The cause might be the following:

WLAN drivers will only briefly scan other channels while there is an active connection to avoid degrading the performance of the connection. At 6MBit/s beacons are more likely to get lost due to interference or possibly other issues; this makes it easier to miss such networks during short scans. The issue disappears when a longer scan is run, i.e. there is no active connection.

The client and the private SSID use the same rate settings. FWIW, both show exactly the same behaviour here as long as I'm not connected to either of them: When I'm connected to a different network, they take a while to appear (and sometimes don't appear at all, even after minutes); when I'm not connected to anything, they appear instantaneously.

The behaviour makes sense, given that clients are usually only interested in connecting to any known network. Most clients do not implement prioritizing specific networks well, if at all...

[A-Kasper]

I can't confirm this. The devices are unconnected. Maybe you can reproduce by Saibling aber reenabling wifi

[A-Kasper]

De have an mcastrate of 12000 maybe this conflicts?

[NeoRaider]

No, each SSID can have its own rates, and I'm seeing the beacons with different rates just fine in Wireshark.

[bobcanthelpyou]

I also notice that issue. First with the Freifunk Hamburg firmware where 11b rates are disabled. Disabled the 11b rates in another firmware and the issue appears, too.