USB-ethernet adapter only works sometimes...

B

BillyJoePiano

I purchased a few NewerTech USB-Ethernet adapters recently, and have had some difficulties getting them to work correctly with FreeBSD. I am told by the manufactuers' support tech that it uses a USB 3.0 Type-A (Realtek RTL8153) chipset, and the only driver they can provide is for MacOS (the Windows driver is installed by default, I guess)

I am running FreeBSD on an older (...but beefier...) MacBook Pro. When I plug in the USB-ethernet adapter, it works fine at first. However, certain types of network activity cause it to suddenly stop working. It seems that larger data transfers and literally anything SMB-related (even just browsing/listing directory contents) causes the interface to go down. The only way to get it working again is to unplug it and then plug it back in.

When I type "ifconfig" on the command line, the working adapter shows this output:

Code: 
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:50:b6:17:f2:76
        inet 192.168.241.1 netmask 0xffffff00 broadcast 192.168.241.255
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


After it stops working, ifconfig shows the following output for the not working adapter:

Code: 
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:50:b6:17:f2:76
        inet 192.168.241.1 netmask 0xffffff00 broadcast 192.168.241.255
        media: Ethernet autoselect (none <half-duplex>)
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>


....The notable difference being the change in the 'media' and 'status' lines.

Do you have any idea what is going on here or what can be done to solve it?

Note that I was using this exact same adapter recently on a MacBook Air running Ubuntu Linux with no issues. I did have some issues getting the adapter to work with a different MacBook Air running Windows 10, but was able to solve this by resetting SMC and PRAM (at the support-tech's suggestion). I already did the SMC & PRAM reset for the MacBook Pro running FreeBSD, but it hasn't had any effect on the issue.


EDIT:

Here are the outputs of two usbconfig commands. Maybe this info will help identify the issues? Not sure?

Code: 
# usbconfig
ugen1.1: <Intel EHCI root HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen2.1: <Intel EHCI root HUB> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen2.2: <vendor 0x8087 product 0x0024> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.2: <vendor 0x8087 product 0x0024> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (0mA)
ugen1.3: <Apple Inc. FaceTime HD Camera (Built-in)> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen2.3: <vendor 0x0424 product 0x2513> at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (2mA)
ugen2.4: <Apple Inc. BRCM20702 Hub> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=SAVE (94mA)
ugen2.7: <Apple Inc. Bluetooth USB Host Controller> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA)
ugen2.8: <Apple Computer, Inc. IR Receiver> at usbus2, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON (100mA)
ugen2.9: <Apple Inc. Apple Internal Keyboard / Trackpad> at usbus2, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (40mA)
ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (64mA)


Code: 
# usbconfig -u 0 -a 2 dump_device_desc
ugen0.2: <Realtek USB 10/100/1000 LAN> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (64mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0300
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0009
  idVendor = 0x0bda
  idProduct = 0x8153
  bcdDevice = 0x3000
  iManufacturer = 0x0001  <Realtek>
  iProduct = 0x0002  <USB 10/100/1000 LAN>
  iSerialNumber = 0x0006  <000001000000>
  bNumConfigurations = 0x0002
 
Also, kldstat shows that if_ure.ko is loaded into the kernel. Not entirely sure why it's loading as ue and not ure...

EDIT:

I noticed that when I unplug and plug back in the adapter, the message on the native terminal screen says things about ure0 ... so I'm assuming it is using the correct driver ... ???
 
So figured out how to "reset" the usb device in-software (disconnect and reconnect), using this command

Code: 
usbconfig -u 0 set_config 1    # disconnects the device
# wait a bit, then...
usbconfig -u 0 set_config 0    # reconnects the device


EDIT: See the final version of this script down-thread

I wrote a script "daemon" that checks on the status of the interface, and does this automatically. It is far from an ideal solution, and pretty hacky obviously... but it at least keeps the interface running, and so far seems to restore it fast enough that TCP sessions don't time out (though anything more than a few KB will transfer in fits and spurts... which ends up being excruciatingly slow)


Bash: 
#!/bin/bash

(
while true
do
    if ! ifconfig ue0 | grep "no carrier"
    then
        sleep 0.5
        continue
    fi

    echo > /dev/ttyv0
    echo "ue0 lost carrier ... resetting" > /dev/ttyv0

    usbconfig -u 0 set_config 1

    # wait for interface to disappear
    for i in {1..100}        # max of ~10 seconds
    do
        if ! ifconfig ue0
        then
            echo "ue0 DOWN" > /dev/ttyv0
            break
        fi
        sleep 0.1
    done

    usbconfig -u 0 set_config 0

    # wait for interface to come back
    for i in {1..100}        # max of ~10 seconds
    do
        if ifconfig ue0
        then
            echo "ue0 UP" > /dev/ttyv0
            break
        fi
        sleep 0.1
    done

    # wait for interface to become active
    for i in {1..100}        # max of ~10 seconds
    do
        if ifconfig ue0 | grep "active"
        then
            echo "ue0 ACTIVE" > /dev/ttyv0
            break      
        fi
        sleep 0.1
    done
done
) > /dev/null 2>&1 &
 
Long shot hint: This COULD be caused by a hardware problem, which then triggers bad error handling, causing your adapter to get "locked up", namely locked in a mode where it can not auto-detect the media. Why do I suspect that? Because the only real difference in the ifconfig output is the media, and the "no carrier" is probably nothing but an effect from the "autoselect (none...)". And because re-initializing the adapter (the physical hardware) and the driver causes the lock to get fixed, without pulling power.

A few things to try. Do you know that this adapter works with different software? I know it's hard to test, you'd have to install Windows or Linux. Can you change some of the wiring? For example, use a different cable to connect it to a different switch? And if all else fails, can you try using the "media" and "mediaopt" options on ifconfig to hand-selected 100baseTX full-duplex? Perhaps if you don't allow the adapter to try autoselect, it will just work.

And by the way, ure is the correct driver for that RealTek chip. Matter-of-fact, to figure out how to use those two options, you need to read the man pages for ifconfig and ure.
 
In my experience USB ethernet adapters just suck and completely stop working after a few weeks
 
Thanks ralphbsz !

So... I'm absolutely positive the USB-Eth adapter works with other operating systems. I have 4 of the adapters, and have switched them out between various different machines running both Windows and Ubuntu. The only issue I ran into there was having to reset the SCM & PRAM when using it on Mac hardware. It took a call to the manufacturers' tech support to figure out that one, but their suggestion did the trick for my Mac laptop/desktop which dual-boots into Windows 10. I also use them as an extra ethernet port on a Lenovo ThinkPad with Win10 (via a USB multi-dock there!) with zero issues, and used one on an old MacBook Air running Ubuntu server also with no issues. I haven't actually tried the adapters in MacOS proper (I don't use it much, and would need to install the driver), but given the experiences in the other OS's it seems this is a problem specific to FreeBSD. I have tried all 4 of the adapters on this machine, on different networks with different ethernet cables, and also did the SCM/PRAM reset (since it is a MacBook Pro) ... always with the same results.

I will give your suggestion about statically configuring the mediaopt in ifconfig a shot! That sounds like a possibility...

I suppose it is also possible there is a problem with the USB port on the machine itself. I have an Ubuntu-desktop boot stick I might try booting the machine with, to see if the problem goes away there.

I also have been digging into the information about ure, ifconfig, and usbconfig, but haven't had much luck other than the software reset in that script above. Any suggestions are always welcome. Thanks again!
 
Alright, so I can report back that booting into Ubuntu did make the problem go away -- Same machine & usb port, same adapter, same network/cables/switch. I could transfer a continuous massive stream of data without breaking the interface. This seems to suggest that the problem is specific to FreeBSD

Also, I did try the static media config for the interface with ifconfig and that unfortunately didn't seem to solve the problem. Next I am going to see if substituting that tactic into the "resetting" script will work... might be faster than complete software-disconnect and then reconnect of the USB device. I'll report back in a bit
 
This problem gets even weirder.

After restarting into FreeBSD, everything is working totally fine... for now! I've seen it do this before. It works well for part of a day, but then breaks again. I would honestly be surprised if it is still working tomorrow, but I'll wait and report back then.

NOTE: I did make one change in the loader.conf file while I was working on this before the restart, to include if_ure_load="YES" . I'm not sure that is what's making it work now, because even before that when I ran kldstat I saw if_ure.ko in the list of kernel modules (apparently it loaded itself???) I suppose its' possible that loading it at boot time (as opposed to ad hoc ??) could make it work correctly, but hard to say... this is not something I know a lot about!
 
YEP, I was right! It started having problems again after about 2 hours of use.

Fortunately the "reset daemon" seems to be working reasonably well. As it turns out, the daemon doesn't need to do a full reset of the USB device. Just running:

ifconfig ue0 media 100baseTX mediaopt full-duplex

...fixes the problem every time so far... PLUS much more quickly than completely shutting down the USB device and restarting it. I did keep the USB reset in the script as a contingency for when ifconfig fails to fix the problem, but hopefully that is not necessary very often.

Still not a great solution, but it seems like it is working well enough for now. Wish I could figure out a root-cause solution, but that is probably something on the driver/kernel level that would be a bit over my head!!
 
In case anyone is interested interested, here is the final (I think!?) version of my script.

Also, thanks to this other thread for some tips on trouble-shooting USB ethernet adapters:
forums.freebsd.org

RTL8153 USB NIC help.

Hello all, So I have been running FreeBSD and OPNsense as a VM's for some time now but due to changes I need to make internally I decided to repurpose an old portable to be the ONSense box, now I know this isn't the OPNsense forum but I believe my issue and question is more of a base system...
forums.freebsd.org forums.freebsd.org

(edit: SCRIPT UPDATED 2-23-22 , 7:20PM US Central Time)

Code: 
#!/bin/bash
#NOTE: I have a symlink at /bin/bash to its actual path in FreeBSD -- /usr/local/bin/bash

inactiveSleep=10
# seconds to sleep between check-ins when there haven't been any recent issues.
# the script becomes more vigilant the more recently there were issues

(

sleepTime=$inactiveSleep

while true
do
        if ! ifconfig ue0 | grep "(none <half-duplex>)"
        then
                sleep $sleepTime
                if (( $(bc <<< "$sleepTime < $inactiveSleep") ))
                then
                        sleepTime=$( bc <<< "$sleepTime + 0.1" )

                        if (( $(bc <<< "$sleepTime >= $inactiveSleep") ))
                        then
                                sleepTime=$inactiveSleep
                        fi
                fi

                continue
        fi

        sleepTime=0



        echo > /dev/ttyv0
        echo -n "ue0 lost full-duplex   ...     " > /dev/ttyv0
        date > /dev/ttyv0

        echo "  Trying ifconfig static media options configuration..." > /dev/ttyv0
        echo "ifconfig ue0 media 100baseTX mediaopt full-duplex" > /dev/ttyv0

        if ifconfig ue0 media 100baseTX mediaopt full-duplex > /dev/ttyv0 2>&1
        then
                success=0
                start=$(date +%s)
                for i in {0..50} # wait 5 seconds
                do
                        if ! ifconfig ue0 | grep "(none <half-duplex>)"
                        then
                                echo "  ifconfig media opts fixed the problem!" > /dev/ttyv0 2>&1
                                success=1
                                break
                        fi

                        timePassed=$(date +%s)
                        [ $(( $timePassed - $start )) -gt 6 ] && break # seems that ifconfig output gets held-up searching for media & carrier

                        sleep 0.1
                done

                [ $success -eq 1 ] && continue
                echo "  ifconfig exited with success but was unable to fix the problem ... trying USB device hard-reset"  > /dev/ttyv0 2>&1

        else
                echo "  ifconfig exited with failure code $? ... trying USB device hard-reset" > /dev/ttyv0 2>&1
        fi

        usbconfig -u 0 set_config 1

        # wait for interface to disappear
        for i in {0..100}               # max of ~10 seconds
        do
                if ! ifconfig ue0
                then
                        echo "ue0 OFF" > /dev/ttyv0
                        break
                fi
                sleep 0.1
        done

        usbconfig -u 0 set_config 0

        # wait for interface to come back
        for i in {0..100}               # max of ~10 seconds
        do
                if ifconfig ue0
                then
                        echo "ue0 ON" > /dev/ttyv0
                        break
                fi
                sleep 0.1
        done

        ifconfig ue0 media 100baseTX mediaopt full-duplex > /dev/ttyv0 2>&1

        # wait for interface to become active
        for i in {0..100}               # max of ~10 seconds
        do
                if ifconfig ue0 | grep "active"
                then
                        echo "ue0 ACTIVE" > /dev/ttyv0
                        break
                fi
                sleep 0.1
        done

        (
                if service samba_server status
                then
                        service samba_server restart
                fi
        ) &

        ifconfig ue0 media 100baseTX mediaopt full-duplex > /dev/ttyv0 2>&1

done

) > /dev/null 2>&1 &
 
Last edited:
Very odd. So with Ubuntu Linux it works perfect, with FreeBSD it works pretty well right now, but not perfect. That seems to indicate a rare and unusual bug in the FreeBSD driver.

One question, to help debug the problem further:

BillyJoePiano said:
I have 4 of the adapters, ...
Click to expand...
Can you switch between these on FreeBSD, and see whether the problem affects all 4?

I still suspect that the real problem is a rare (or bizarre) hardware problem, which is usually fixed in software, but the error handling on the FreeBSD side has a bug. If the problem only affects one of the four, that would be an indication that it is partially a hardware problem. It might also allow you to avoid the problem (label the one with "do not use with FreeBSD").
 
ralphbsz thanks again for the tips!

So I had tried switching out adapters before with no luck ... tried again this afternoon at your suggestion ... also no luck :-(

RE: Ubuntu ... to be fair, I didn't spend hours on Ubuntu testing the interface. Only a few minutes running a ton of data through it (what was causing it to break on FreeBSD). It took FreeBSD a few hours after boot before the problems showed up again.

Today the problem got worse again. Even trivial things (like browsing file listings with SMB) were causing it to break. And the script was often having to resort to the "contigency" section -- taking down the entire USB device and resetting it.

covacat -- how do I do a devd message?
 
Also wondering if this is something that might be worth bringing to the attention of developer for the "ure" driver? Given that the interface is hardly working right now, I'd be happy to be the guinea pig for any attempts to fix the driver... and provide whatever logs he/she/they need?
 
Almost "did you try to turn it off and on again" advice for that bug.

Buggy driver; I don't think you'll have much luck beside implementing workaround (or trying to buy device with different chipset).
 
BillyJoePiano said:
Also wondering if this is something that might be worth bringing to the attention of developer for the "ure" driver? Given that the interface is hardly working right now, I'd be happy to be the guinea pig for any attempts to fix the driver... and provide whatever logs he/she/they need?
Click to expand...
You can certainly open a PR. If the developer has time, they might contact you to tell you how to collect debugging information. Because at this point, there is no actionable information here, other than "it doesn't work". I have a nasty suspicion though: The developer will simply tell you that it works great for him (which is probably true). At that point, what to do next? One suggestion: You send them your specific adapter by mail, and they test it. Now I have to likely possibilities: (a) They tell you that what you have is a crappy Chinese clone of the chip, throw it in the trash and get a real one. This is actually quite common for USB adapter (FTDI has had massive problems with Chinese clones that sort of work). (b) They test with your adapter, and it works great for them. At that point, they need to look at your upstream configuration. Perhaps your cables or upstream switch are suspect?

But the first step of opening a PR can't hurt.
 
You must log in or register to reply here.
Back
Top