Announcement

Collapse
No announcement yet.

Linux 5.15 Staging Replaces Its Realtek RTL8188EU WiFi Driver

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

  • Linux 5.15 Staging Replaces Its Realtek RTL8188EU WiFi Driver

    Phoronix: Linux 5.15 Staging Replaces Its Realtek RTL8188EU WiFi Driver

    The staging updates for Linux 5.15 continue to have a lot of code churn including some drivers being promoted while one Realtek WiFi driver has been replaced...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I find it amazing that realtek is still a trash company in 2021. It has to be a government front. That's the only way they could have survived so long with windows 95 only drivers on a isdn connected website.

    Comment


    • #3
      I find it funny there's an uostream rtl81xxxu driver that seems to be abandoned, that is, no new features. It still only does monitor and client mode only.

      Comment


      • #4
        I have a rtl8153b usb-to-ethernet nic..
        The driver(rtl8152) is awful..

        The hardware itself, only has hardware receiving buffers, transmitting buffers are not present, they should maybe consider a buffer on the usb side..
        If the device if pushed above 50% of bandwidth, like executing a iperf3 test to try to saturate the port, passing through it several gigabytes of Data... is a mess..

        The kernel driver resets the device, several times, and at each reset is generate..guess what..yeah a random mac address for it..
        I went to realtek site,
        Downloaded the last version of the kernel module, at the time, and mitigated the problem, on reset for the driver to maintain the same mac address..

        I didn't pursued a more longer investigation on why, it resets so frequently, and for what I know a lot of devices have this usb-to-ethernet converters, which are a mess.. plagued with resets.. only if you don't saturate the ports there behaviour is a lot better, resetting with a lot less frequency..

        I suspect the same behaviour of pcie-to-ethernet adaptors..

        Comment


        • #5
          I'd like to see some love towards a proper RTL88x2BU driver in the kernel. Been using a 3rd-party driver for way too long.

          Comment


          • #6
            Honestly why does anyone use realtek in Linux... I have it built into my mobo and bought a Intel nice for like $20 never had an issue

            Comment


            • #7
              Originally posted by cytomax55 View Post
              Honestly why does anyone use realtek in Linux...
              Try finding any modern USB wifi device supporting 802.11ac that is not made by Realtek or Mediatek.
              Otherwise keep quiet.

              Comment


              • #8
                From the development repo of Larry Finger:
                > please create /etc/NetworkManager/conf.d/80-wifi.conf with content:
                Code:
                [device]
                wifi.scan-rand-mac-address=no
                It is [device], not [device XXX]. Seems a confirmation that NM really does not consider the case of having multiple wifi adaptors (which is not so uncommon if you have a malfunctioning or poorly supported or obsolete internal adaptor in a laptop, for instance). If you do something for an adaptor you do it for all. Seems to go hand in hand with the fact that if you rfkill one device and you have more than one, NM disables wireless altogether.
                Any clue on whether this will ever be addressed?

                Comment


                • #9
                  Originally posted by cytomax55 View Post
                  Honestly why does anyone use realtek in Linux... I have it built into my mobo and bought a Intel nice for like $20 never had an issue
                  I remember some board maker representative once noting that these Realtek chips are so cheap if bought in bulk, that they put them on every board. they are cheaper than just putting a phy for the amd and intel integrated macs on a board. the windows drivers are good enough, the majority of people doesn't care that they can't saturate a gbit link.

                  Comment


                  • #10
                    Originally posted by callegar View Post
                    From the development repo of Larry Finger:
                    > please create /etc/NetworkManager/conf.d/80-wifi.conf with content:
                    Code:
                    [device]
                    wifi.scan-rand-mac-address=no
                    It is [device], not [device XXX]. Seems a confirmation that NM really does not consider the case of having multiple wifi adaptors (which is not so uncommon if you have a malfunctioning or poorly supported or obsolete internal adaptor in a laptop, for instance). If you do something for an adaptor you do it for all. Seems to go hand in hand with the fact that if you rfkill one device and you have more than one, NM disables wireless altogether.
                    Any clue on whether this will ever be addressed?
                    At the exact time when you look at the NetworkManager.conf man page

                    Code:
                    DEVICE SECTION
                    Contains per-device persistent configuration.
                    
                    Example:
                    
                    [device]
                    match-device=interface-name:eth3
                    managed=1
                    
                    Supported Properties
                    The following properties can be configured per-device.
                    
                    <...>
                    
                           wifi.scan-rand-mac-address
                    That's the problem with tutorials and howtos — they insinuate that the described way is the only one, or the best one, or the recommended one. Which is often not the case.

                    Comment

                    Working...
                    X