Gluon: raspberry pi 3 broken status

[miyuuli]

I'm running gluon on a rpi3 for a while and everything seems to be good so far:
http://mgmt.saar.freifunk.net/hopglass/#!v:m;n:b827eb0b08a9

It does only support one wifi interface and according to iw no 11s. Client AP works fine, though, and so does meshing over Ethernet. VLANs are also supported.

What's required to mark this as unbroken?

[kpanic23]

All WiFi interfaces working, with 11s. Sorry...

[bobcanthelpyou]

@miyuuli

A pull request with the following device checklist is required.
https://github.com/freifunk-gluon/gluon/wiki/Device-Integration-checklist

Raspberry pi 3 is already supported as BROKEN by Gluon.
https://github.com/freifunk-gluon/gluon/blob/master/targets/brcm2708-bcm2710

But marked as # BROKEN: Untested in targets.mk
https://github.com/freifunk-gluon/gluon/blob/master/targets/targets.mk

Test the device by filling out the checklist and move the target to a different place in targets.mk.

[rotanid]

@bobcanthelpyou you pointed out the process correctly, but as @kpanic23 already wrote, this won't happen here because 11s is not working.
therefore, the only possible change could be to change the reason for it being broken.

[bobcanthelpyou]

@rotanid sorry, i was confused, cause @miyuuli wrote "no 11s" and @kpanic23 wrote "All WiFi interfaces working, with 11s" which i might misinterpreted as everything is fine. Maybe a "need" / "must" / "should" / ., is missing to work with my build-in interpreter. Sorry again.

Could someone at least update the target file with "11s not working / unsupported / .." or something like that for the raspberry pi 3? It seems to be tested somehow.

Adding something like ifneq ($(GLUON_WLAN_MESH_ibss)$(BROKEN),) for the target doesn't make sense?

[blocktrron]

@bobcanthelpyou I highly doubt the WiFi driver of the Raspberry Pi 3 supports anything else than the simple AP or Client case (It's Broadcom after all). It uses the brcmfmac driver and the WiFi chip itself is attached via SDIO. The fact it is attached via SDIO alone makes meshing a big nono in terms of practicability.

[mweinelt]

For reference

Wiphy phy0
    max # scan SSIDs: 10
    max scan IEs length: 2048 bytes
    max # sched scan SSIDs: 16
    max # match sets: 16
    max # scan plans: 1
    max scan plan interval: 508
    max scan plan iterations: 0
    Retry short limit: 7
    Retry long limit: 4
    Coverage class: 0 (up to 0m)
    Device supports roaming.
    Supported Ciphers:
        * WEP40 (00-0f-ac:1)
        * WEP104 (00-0f-ac:5)
        * TKIP (00-0f-ac:2)
        * CCMP-128 (00-0f-ac:4)
    Available Antennas: TX 0 RX 0
    Supported interface modes:
         * IBSS
         * managed
         * AP
         * P2P-client
         * P2P-GO
         * P2P-device
    Band 1:
        Capabilities: 0x1020
            HT20
            Static SM Power Save
            RX HT20 SGI
            No RX STBC
            Max AMSDU length: 3839 bytes
            DSSS/CCK HT40
        Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
        Minimum RX AMPDU time spacing: 16 usec (0x07)
        HT TX/RX MCS rate indexes supported: 0-7
        Bitrates (non-HT):
            * 1.0 Mbps
            * 2.0 Mbps (short preamble supported)
            * 5.5 Mbps (short preamble supported)
            * 11.0 Mbps (short preamble supported)
            * 6.0 Mbps
            * 9.0 Mbps
            * 12.0 Mbps
            * 18.0 Mbps
            * 24.0 Mbps
            * 36.0 Mbps
            * 48.0 Mbps
            * 54.0 Mbps
        Frequencies:
            * 2412 MHz [1] (20.0 dBm)
            * 2417 MHz [2] (20.0 dBm)
            * 2422 MHz [3] (20.0 dBm)
            * 2427 MHz [4] (20.0 dBm)
            * 2432 MHz [5] (20.0 dBm)
            * 2437 MHz [6] (20.0 dBm)
            * 2442 MHz [7] (20.0 dBm)
            * 2447 MHz [8] (20.0 dBm)
            * 2452 MHz [9] (20.0 dBm)
            * 2457 MHz [10] (20.0 dBm)
            * 2462 MHz [11] (20.0 dBm)
            * 2467 MHz [12] (20.0 dBm)
            * 2472 MHz [13] (20.0 dBm)
            * 2484 MHz [14] (disabled)
    Supported commands:
         * new_interface
         * set_interface
         * new_key
         * start_ap
         * join_ibss
         * set_pmksa
         * del_pmksa
         * flush_pmksa
         * remain_on_channel
         * frame
         * set_wiphy_netns
         * set_channel
         * start_sched_scan
         * start_p2p_device
         * connect
         * disconnect
         * crit_protocol_start
         * crit_protocol_stop
         * update_connect_params
    Supported TX frame types:
         * managed: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-client: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-GO: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
         * P2P-device: 0x00 0x10 0x20 0x30 0x40 0x50 0x60 0x70 0x80 0x90 0xa0 0xb0 0xc0 0xd0 0xe0 0xf0
    Supported RX frame types:
         * managed: 0x40 0xd0
         * P2P-client: 0x40 0xd0
         * P2P-GO: 0x00 0x20 0x40 0xa0 0xb0 0xc0 0xd0
         * P2P-device: 0x40 0xd0
    software interface modes (can always be added):
    valid interface combinations:
         * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
           total <= 3, #channels <= 2
         * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
           total <= 4, #channels <= 1
    Device supports scan flush.
    Device supports randomizing MAC-addr in sched scans.
    Supported extended features:
        * [ 4WAY_HANDSHAKE_STA_PSK ]: 4-way handshake with PSK in station mode
        * [ 4WAY_HANDSHAKE_STA_1X ]: 4-way handshake with 802.1X in station mode

[NeoRaider]

The RPi3 is a difficult case, because it is unclear what the expected feature set is:

• Everything that worked on the RPi 1 and 2 is working on the RPi 3
• WLAN on RPi 3 will never "work" for Gluon (with mesh support)

At the very least we would need to ensure that Gluon doesn't even attempt to use the built-in WLAN for meshing.

In any case, I'm not sure why we even support RPis at all - they aren't good offloaders and don't support WLAN meshing... there should be no reason to use Gluon on one at all? Or am I underestimating the VPN offloading capabilities of modern RPis?

[yanosz]

That's difficult.

IMHO the RaPi won't be the flash'n'play node people are looking for, when installing gluon. For the VPN-performance: My model 3 (non +) can easily saturate the 100MBit/s LAN-Port using wireguard while having approx. 12% CPU load when doing iperf3 tcp testing. The 3+ has 1000MBit/s. It should be faster.
IMHO that somehwat qualifies a RaPi to work as an offloader.

The built-in radio can gor for IBSS. This makes it possible to play with mesh setups using RaPi devices. Due to its widespread use as a tinkering device, people are wondering how to use it for Freifunk and related tinkering.

From that perspective, a RaPi running Gluon isn't absurd, but it's also not a device that can be used to build build a mature wifi mesh network. It won't hurt to integrate that OpenWRT target into Gluon.

Since this point is often addresses in Freifunk communities and by people around here. I guess, that this is due to missing documentation on Raspberry Pi devices.

Personally, I'm not motivated to contribute to Gluons documentation at the momtent. My last attempt was quite frustrating.

[mweinelt]

If #1947 works as planned we could actually make some use of all the RPi lying around, and if driving them with a USB radio becomes a common practice I could imagine unbreaking them.

[rotanid]

If #1947 works as planned we could actually make some use of all the RPi lying around, and if driving them with a USB radio becomes a common practice I could imagine unbreaking them.

many USB radios don't support meshing though

[mweinelt]

We are checking mt7610/7612 based radios right now, stay tuned.