Re: [PATCH v3 0/3] mac80211/ath11k: HE mesh support

[Sven Eckelmann <sven@narfation.org>]

[-- Attachment #1: Type: text/plain, Size: 5279 bytes --]

Hi,

Thanks for clarifying your statement regarding ie_len. I think I should have 
been able to guess what you meant but for some reason my brain wasn't able to 
understand the phrase at that time.

On Friday, 14 June 2019 16:10:46 CEST Johannes Berg wrote:
> Two comments:
> 
> 1) It seems to me that patches 1/2 really should be in opposite order,
>    since you can't really claim HE mesh support in hwsim when you don't
>    have it in mac80211?
>    Or maybe I misunderstand?

I personally didn't have an opinion regarding the patch order. It was just the 
order how I committed the stuff. And it was just committed in this order 
because I could easier amend changes to mac80211.

But yes, (in retrospective) it is a lot better to have first the mac80211 
change and then the driver changes for meshpoint.

> 2) This series breaks the wpas_mesh_max_peering wpa_supplicant/hwsim
>    test, and I'm not sure why. Perhaps some length calculations are bad?

I just went through all tests and saw following failed ones before the 
patches:

   failed tests: tnc_peap_soh tnc_peap_soh_errors tnc_ttls tnc_ttls_fragmentation tnc_fast ap_ft_ptk_rekey p2p_go_move_reg_change p2ps_connect_adv_go_persistent p2ps_channel_both_connected_different ap_wps_conf_5ghz ap_wps_upnp_http_proto wpas_mesh_gate_forwarding olbc proxyarp_open_ebtables p2p_device_persistent_group2 dpp_ap_config_p521_p521 wnm_bss_tm_reject

and following after the patches:

   failed tests: tnc_peap_soh tnc_peap_soh_errors tnc_ttls tnc_ttls_fragmentation tnc_fast ap_ft_ptk_rekey ap_acs_vht discovery_group_client p2p_go_move_reg_change p2ps_stale_group_removal2 ap_wps_conf_5ghz ap_wps_upnp_http_proto radius_acct_interim_unreachable mesh_secure_ocv_mix_legacy mesh_secure_ocv_mix_ht wpas_mesh_max_peering wpas_mesh_open_ht40 wpas_mesh_gate_forwarding rrm_neighbor_rep_oom rrm_beacon_req_passive_scan_vht ap_vht160b ap_vht160_no_dfs_112_minus proxyarp_open_ebtables

So as you can see, even more stuff failed which I haven't touched. And other 
stuff which I haven't touched now work. The interesting ones were:

* mesh_secure_ocv_mix_legacy
* mesh_secure_ocv_mix_ht
* wpas_mesh_open_ht40
* wpas_mesh_max_peering

The last one (mentioned by you) is interesting - because I can see the 
accepting additional peers == No for the beacons in the dump. But it is not 
recognized as such by the script. With new tshark:

    ~/tmp/wireshark/build/run/tshark -r /tmp/hwsim-test-logs/latest/wpas_mesh_max_peering.hwsim0.pcapng  -T fields -e wlan.sa -e wlan.mesh.config.cap 'wlan.fc.type_subtype == 8' 
    02:00:00:00:01:00       0x00000009
    02:00:00:00:00:00       0x00000009
    02:00:00:00:01:00       0x00000009
    02:00:00:00:02:00       0x00000009
    02:00:00:00:00:00       0x00000008
    02:00:00:00:01:00       0x00000009
    02:00:00:00:02:00       0x00000009
    02:00:00:00:00:00       0x00000008

With wireshark 3.0.0:

    tshark -r /tmp/hwsim-test-logs/latest/wpas_mesh_max_peering.hwsim0.pcapng  -T fields -e wlan.sa -e wlan.mesh.config.cap 'wlan.fc.type_subtype == 8' 
    02:00:00:00:01:00       0x00000001
    02:00:00:00:00:00       0x00000001
    02:00:00:00:01:00       0x00000001
    02:00:00:00:00:00       0x00000001
    02:00:00:00:02:00       0x00000001
    02:00:00:00:01:00       0x00000001
    02:00:00:00:02:00       0x00000001
    02:00:00:00:00:00       0x00000001

So I had to change the wireshark version (see below) which is used by hostapd.
(just to document for me what I have forced it to a different version)

    diff --git a/tests/hwsim/tshark.py b/tests/hwsim/tshark.py
    index 019df781a760c657b8854acfcee94dc83e30575f..ecf83a7a97dde0e52b54e994d2dd4d46bddaa9df 100644
    --- a/tests/hwsim/tshark.py
    +++ b/tests/hwsim/tshark.py
    @@ -28,7 +28,7 @@ def _run_tshark(filename, filter, display=None, wait=True):
             time.sleep(0.1)
     
         try:
    -        arg = ["tshark", "-r", filename,
    +        arg = ["/home/sven/tmp/wireshark/build/run/tshark", "-r", filename,
                    _tshark_filter_arg, filter]
             if display:
                 arg.append('-Tfields')
    @@ -102,7 +102,7 @@ def run_tshark(filename, filter, display=None, wait=True):
                                wait)
     
     def run_tshark_json(filename, filter):
    -    arg = ["tshark", "-r", filename,
    +    arg = ["/home/sven/tmp/wireshark/build/run/tshark", "-r", filename,
                _tshark_filter_arg, filter]
         arg.append('-Tjson')
         arg.append('-x')
    
The first three things looks like wpa_supplicant problems. Seems to be 
caused by the way HE forces VHT to be enabled and now the tests fail 
which try to disable VHT. There was already a patch [0] for that but it
wasn't considered a good solution.

But beside these three things there are various other problems in 
wpa_supplicant regarding HE with pending patches. So I've used 
wpa_supplicant 91b6eba7732354ed3dfe0aa9715dc4c0746e3336 with two 
additional patches [1,2] and increased the VM memory to 1024 MB. Also 
wireshark (tshark to be more precise) had to be updated to 
v3.1.0rc0-1192-gf64990438c

Kind regards,
	Sven

[0] https://patchwork.ozlabs.org/patch/1125305/
[1] https://patchwork.ozlabs.org/patch/1125314/
[2] https://patchwork.ozlabs.org/patch/1125322/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]