Announcement

Collapse
No announcement yet.

Intel's IWD 2.0 Released For Modern Linux Wireless Daemon

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by tildearrow View Post
    due to a quirk called LAR - card must be aware of other 5GHz stations prior to being able to broadcast on 5GHz.
    Yes that´s true.. It´s controlled by a flag "NO-IR" (no initial radiation) on the channels reported by the driver.. The driver receives this info from the firmware running on the card, which is loaded by the driver beforehand.. So the regulatory database is acutally embeeded in the cards firmware / updated with it..
    I tried to enable 6GHz (WiFi 6E) on my AX210, but it´s pretty much locked down in firmware.. Things i tried:

    - Just patch the driver to report all channels as "active" to the kernel and with no NO-IR flag. -> wpa_supplicant or IWD let´s you select the channel, but setting in in firmware fails with and error code.
    - Patch the regulatory database in the firmware image -> Nah thing is signed and the signature is checked in Firmware
    - There is a way for a device manufacturer to load their own regulatory database during boot, but it has to be signed as well.. If such a DB is loaded the location/regulatory zone might be overriden by the BIOS / UEFI, for example if the device has a 4G/5G modem and determines the country by the MCC of the received mobile network
    - Sending fake beacon frames from the only AP the card sees put´s it into the regulatory zone advertised in the beacon frame (not practical, as you typically receive multiple networks and the majority wins) -> this "LAR" mechanism is completly implemented in firmware, there is even a patent for that (which describes the method with MCC from a mobile network as well)
    There is a function though which put´s the card into "test-mode", the firmware command has 1 32bit input called "key" in the driver..
    As far as i understand it this is the way how OEMs working with intel will validate their designs during R&D and get certification, it should "unlock" the card´s firmware, so you can set whatever TX-power and Channel you want.. However the firmware seems to crash / lockdown till you power-cycle the card when you enter an invalid key.. Otherwise iterating over all 4294967296 possibilities wouldn´t be out of this world. Rebooting the card and re-uploading the firmware takes too long for this to be viable unfortunately..

    Guess someone has to rever-engineer the firmware and find some buffer overflow?!

    Otherwise i am counting on other manufacturers releasing similar 802.11ax cards which arent´t that restricted (looking at your HiSilicon / Huawei)...

    I don´t like the choices intel made lately to verndor-lock their customers into their platform. Like for example the versions of the AX2*1 or AX4*1 which only work with their platforms, the "Intel VMD / RST" crap (used for Optane Cache, but implemented in the Chipset not in software -> Why the fuck not implement it in software / a driver), the ARC-GPUs which can only be Firmware-updated via their platforms. and especially their "Software Defined Silicon" DRM crap.

    Comment


    • #12
      Originally posted by timofonic View Post

      What are the advantages of it? Could you please elaborate on it?

      Also, it would be nice to make a collaborative project with own governance, not just Intel branding everywhere.

      Is this so better compared to alternatives? What's left to implement?
      this video gives a good overview of why they built iwd and its advantages. basically, designed for linux, clean code base, proper abstractions, nice command line tool. also, since wpa_supplicant (the alternative) had lots of architectural issues, iwd was able to correct kernel driver issues that wpa_supplicant never exposed. https://www.youtube.com/watch?v=QIqT2obSPDk

      Comment


      • #13
        Originally posted by Danny3 View Post
        I see that right before the release there is this change:


        I wonder what this means for privacy.
        If the IPv6 address is derived from the MAC address and if the IPv6 support can be disabled.
        If not, I'm not interested into using such garbage software that doesn't care about my privacy!
        Obviously you can disable ipv6. If not with iwd, in the kernel. Anyway, you should generate a new MAC address if you really care.

        Comment


        • #14
          Originally posted by Danny3 View Post
          I see that right before the release there is this change:


          I wonder what this means for privacy.
          If the IPv6 address is derived from the MAC address and if the IPv6 support can be disabled.
          If not, I'm not interested into using such garbage software that doesn't care about my privacy!
          IPv6 privacy extensions (i.e. randomized addresses) are enabled by default on all desktop Linux distributions. This is a non-issue!

          Comment


          • #15
            I've been using iwd instead of wpa_supplicant just for fun now for several months on my Debian machine and it was completely problem-free, in fact, I did not really experience a difference, the replacement was transparent. NetworkManager has to get set a flag to enable iwd support and once done, it requested the passwords again, when connecting for the first time. That's all.

            Comment


            • #16
              Can IWD handle predictable interface names yet? I haven't had a look at it for a while, but last time I got some race with udev...

              Comment


              • #17
                Originally posted by loganj View Post
                so softap on 5ghz is available? or are they still following microsoft example of only 2ghz softap?
                i know they block their own cards on 5ghz softap but they should not block other cards too
                I can't get it to work even on 2GHz. It's even worse than wpa_supplicant where only WPA3 is broken.

                Comment


                • #18
                  Originally posted by fitzie View Post

                  this video gives a good overview of why they built iwd and its advantages. basically, designed for linux, clean code base, proper abstractions, nice command line tool. also, since wpa_supplicant (the alternative) had lots of architectural issues, iwd was able to correct kernel driver issues that wpa_supplicant never exposed. https://www.youtube.com/watch?v=QIqT2obSPDk
                  Thanks for the share, watching it now. Its quite sad how left behind some parts of Linux are, so happy that iwd exists and can't wait till its fully stable and default on distro's.

                  Comment


                  • #19
                    Originally posted by tildearrow View Post

                    You mean on Intel cards? I doubt they are following Microsoft's example.
                    The lack of support for 5GHz is due to a quirk called LAR - card must be aware of other 5GHz stations prior to being able to broadcast on 5GHz.

                    It is possible to work around this issue by patching hostapd to scan (so that the card finds out there is a 5GHz station nearby) before initiating the access point.
                    the microsoft part was just sarcasm. microsoft does not allow softap if my wifi card is set to use only 5ghz

                    also does iwd use hostapd?

                    Comment


                    • #20
                      Being on Arch I've had iwd+networkd setup running for a few months now without issues. Just sharing.

                      Comment

                      Working...
                      X