RTL8125 not working even with os-realtek-re - any hope/help?

[Linwood]

I decided to buy a GMKTec M5, which despite some internet words saying it had intel drivers arrived with dual RTL8125's.

So I plugged in a USB Ethernet so I could get the os-realtek-re package downloaded and all good.... except the LAN doesn't work.

Oddly the WAN does.

The LAN is up, but cannot communicate except very, very rarely will respond to one ping).  If I ping from it it complains about lack of buffer space, though netstat -m shows plenty available.

The LAN is connected to a trunked port, but I removed the taggeed vlan's and still have the issue.

There's lots of memory (16gb and it only needs about 2gb), nothing unusual in my setup otherwise that I know of. The configuration is one running fine on a BeeLink with dual 1g NIC's, but I needed to upgrade to 2.5g.

To be clear, before adding the plugin the NIC's did not show up at all.   With the plugin they show up, but the LAN side does not work.

Yes... mea culpa, I should have somehow figured out it was Realtek and avoided it, but honestly I might have bought anyway as numerous postings say just install this plugin and it worked.  Live and learn.

Do I just throw this away and start over with a new box?  (or maybe see if I can return it)

Or is there something I may be missing?

Oh... there is one thing odd.  I started this with a clean install, installed the plugin (with a USB ethernet), then restored my config from the other machine (which happens to use the same interface names).  When it comes back up the plugin says "misconfigured" which I think is purely a cosmetic issue.  I've removed and reinstalled it and it shows fine, but will go back to misconfigured if I restore the config again.  I assume because the Beelink doesn't have that plug?  Should I install the plugin (even though not needed) on the Beelink?

[Patrick M. Hausen]

Realtek is bad, USB Ethernet is bad. I'd return the thing if possible.

[pfry]

The RTL8125 may not be ideal, but it's not that bad... normally. I'm working through one right now, and it hasn't given me a single problem. Caveats, though: I've only used it at 1Gb (connection from this station's RTL8111 to the firewall, either direct or through a switch), and my Internet link is 500Mb. And I don't have an explanation for the original poster's issue. If troubleshooting is the goal, I'd start with "What's the LAN side plugged into?" If returning the unit is the goal, no need to waste the time.

[Linwood]

Yeah, the USB was just because I had one and needed to get the plugin downloaded.

The Realtek was because I didn't do my diligence and/or was fooled (I wonder if they used to be intel on that one, or maybe some variant of that one).

So... I should not really be surprised the plugin doesn't work? 

---- just saw the most recent posting....

The LAN side is good, in the sense it's the same setup as the 1g Beelink setup I have.  And all cables and ports are tested and right.

I just rebooted with no VLAN's on the port (i.e. changed it to untagged/access) or in the interface assignment, that NIC still fails, the other works.

Now it gets interesting.... I definitely thought the beelink had intel, but it does not.  I just looked.  It has RTL8111. But before realizing that, I decided to try to fix the "misconfigured" issue by installing the plugin on the Beelink (thinking no realtek it would not care).

Guess what -- it failed, and gave the same errors except on the WAN side.  And it's at 1g only.

I removed the plugin and it's now working again (after a reboot).

So the plugin on the RTL8111 breaks re1, and on the RTL8125 breaks re0.  But the RTL8111 works out of the box, the RTL8125 does not even see the adapters without the plugin.

Weird.  And definitely need to research more carefully for the next one.

I have a big monster old desktop I put OPNsense on with a intel X550-T2 which worked fine out of the install, it's just too big a box to run as a firewall (power plus physical size).  So I at least have a fallback if the Beelink fails, but it has been working for a few months.  I'm trying to upgrade because I think I can get 2g fiber now from T-Mobile at the same price as my 1g.   Maybe.

But... the plugin to me has a real problem, it doesn't work for either one properly, and in fact breaks the RTL8111.

Realtek is bad. I get it.   I don't know if Amazon will take this back having used it and overwritten the drive.

[Linwood]

Hmmm... I had not followed the instructions in the plugin to change /etc/rc.conf because I couldn't find it.  I realized that it was really the interface/settings option, so I tried setting those all to disable (the first three -- the fourth was already set).

And at the moment it seems to be working.

Not that this is exactly reassuring.   But it's progress.

[Patrick M. Hausen]

I had not followed the instructions in the plugin to change /etc/rc.conf because I couldn't find it.

Which instructions?

[Linwood]

Which instructions?

When you install the plugin it says a bunch of stuff but at the end is this section:

Code Select Expand

If you experience network hangs with IPv6 enabled,
you might need to disable the checksum offloading
by adding the following parameters to the related
ifconfig line in your /etc/rc.conf file:

-rxcsum -txcsum -rxcsum6 -txcsum6
Checking integrity... done (0 conflicting)
Nothing to do.

The problem is there's no /etc/rc.conf file, and while there is a /etc/default/rc.conf file it doesn't have any obvious "related ifconfig line". 

I freely admit this is likely my lack of familiarity with BSDLinux. 

What I think this should recommend is go to interfaces, settings and turn off the first three items there, which is what I think this really is (but did not realize those lines existed at the time). 

[Patrick M. Hausen]

When you install the plugin it says a bunch of stuff but at the end is this section:

And underneath that text box it very prominently and explicitly reads:

Output shown here for diagnostic purposes. There is no general need for manual system intervention.

Please please please folks, stop following whatever is shown in there. This is from the FreeBSD package management and in 100% of all cases irrelevant or even bad in the OPNsense context. FreeBSD packages when installed show instructions for a stock FreeBSD system, not for OPNsense. OPNsense software takes care of all of that.

How can this be improved? How large does the disclaimer at the bottom need to be? Stronger wording perhaps?

[Linwood]

How can this be improved? How large does the disclaimer at the bottom need to be? Stronger wording perhaps?

OK, let's take it in context.  The plugin did not work, so I started trying to figure out why.

The why (many hours later) was that intervention was needed inside of OPNsense to turn off those settings in interfaces.

So possibly noting that may help, but also please keep in mind that when drowning, people grab onto anything floating, even if it's not helpful.

Those comments were the solution but needed to be implemented in opnsense, and at least this dumb stupid ignorant user (did I miss any?  Please be sure to pile on some more if so) did not connect them to the interface options.

[Patrick M. Hausen]

OPNsense sets all of these offloading functions to disabled by default, though. A "factory new" OPNsense will have all the correct settings. You must have changed them at some time.

[Linwood]

OPNsense sets all of these offloading functions to disabled by default, though. A "factory new" OPNsense will have all the correct settings. You must have changed them at some time.

I've been through numerous hardware and software upgrades; I'm surprised I changed those, but certainly could have. Maybe even was guided there for some other reason (with different hardware).  Restoring a configuration does restore that setting.

It's a problem with tools that work well, we tend to leave them alone for years, then when we need to change something it's a bit like starting over.

[Patrick M. Hausen]

Also did not intend to diss on you, but this is a common problem so I would be really interested in how the dialog could be improved. So many plugins, e.g. the Intel or AMD microcode updates, display specific instructions for plain FreeBSD that are wrong for OPNsense. And then users go out and try to follow them.

Completely hiding the package install log in favour of a progress bar would not be helpful, either, in my opinion. Because if things break and people come to the forum we can at least ask for a copy of that log.

But really none of these messages calls for any action on the user's part. That is all handled by OPNsense and in case it isn't, that's a bug.

Similarly when some YT video or blog post tells you to edit /boot/loader.conf.local - don't. All tunables can be set in the UI and then they will be included in a config backup.

Kind regards,
Patrick

[Linwood]

Thanks.

I would be really interested in how the dialog could be improved. So many plugins, e.g. the Intel or AMD microcode updates, display specific instructions for plain FreeBSD that are wrong for OPNsense. And then users go out and try to follow them.

I'm not sure if that output is specific to this one plugin or is something put up generally, but if you want one reader's suggestion something that implies a break and makes it more obvious to question what's written and why, e.g. maybe a line and:

-----------------------------
Above may not apply to OPNsense, and is from the driver and for reference/diagnostic purposes, generally OPNsense needs no direct system intervention.

Wording would change if that output is just on every such plugin of course.

But for this particular one I wonder how many people end up where I did -- a prior configuration with hardware offloading turned on?  If I'm really unusual no matter, but if you've heard that one before maybe also:

Note that the offloading disables in OPNsense are on the Interfaces, Settings page at the top, not in the OS.

Of course, I also realize that people read selectively and it is absolutely impossible to make instructions foolproof -- fools are very ingenious.

[Linwood]

I reran the install of the plugin, and I see there is a line in the UI between that message and the output from the plugin, so please ignore that aspect of the above.  In looking with fresh eyes, I think the main thing that may have helped me was sort of a disclaimer to clearly state it may not be about OPNsense.