Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - moonman

#1
Thank you for trying to help. However 8125b (2.5Gb/s, pcie) is very different from 8153 (Gigabit,USB).

realtek-re-kmod package is for PCI-E only adapters.
Realtek PCIe FE / GBE / 2.5G / 5G Ethernet Family Controller
kernel driver.


Also I am not sure if it's exactly the same driver, but you can also install a package from within the GUI from under System -> Firmware -> Plugins -> os-realtek-re

I know 8153b is supported by "ure" driver in Freebsd, implementation is pretty good, it's just the driver doesn't recognise my hardware because there are a ton of different vendor/device ids for the same chip and the Surface adapter may not be on the list. I know in linux I can force a driver to start using a certain vendor/device id through configuration file/at boot. I am not that familiar with *bsd so I was hoping there is a similar mechanism
#2
Hi, I need to add 2 extra ethernet ports to my firewall (a little Intel N100 fanless box with 4 ethernet ports) for low bandwidth-ish devices (PiKVM and a printer). I have 2 MS Surface USB3 gigabit adapters with realtek 8153b chips in them and got them to work with cdc generic driver by settings them to mode 1. The problem is that this driver is pretty bad in terms of maximum bandwidth (250Mbit/s) and latency. realtek 8153b is supposed to be decently supported with the "ure" driver which I am hoping will improve the latency at high load. I suspect that ure driver doesn't get loaded because the device id is just not in the driver code. Is there any way to make the driver load for my device passing device id at runtime (which is possible on linux).

I had these nics running under linux before and they were rock solid with months uptime.

ugen0.3: <RTL8153B GigE [Surface Ethernet Adapter] Microsoft Corp.> at usbus0, cfg=1 md=HOST spd=SUPER (5.0Gbps) pwr=ON (72mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0300
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0009
  idVendor = 0x045e
  idProduct = 0x0927
  bcdDevice = 0x3100
  iManufacturer = 0x0001  <Microsoft>
  iProduct = 0x0002  <Ethernet Adapter>
  iSerialNumber = 0x0006  <001008A1A>
  bNumConfigurations = 0x0002
#3
Thanks everyone. Running
pkg add -f /var/cache/pkg/pkg-1.19.2.pkg
fixed it for me
#4
So this update pkg to 1.20.x and it now gives an error checking for new packages/update. Does anyone know how to rollback to the previous version of pkg. I have the package itself locally from a different system, just can't figure out how to properly downgrade.

Quote from: meyergru on September 25, 2023, 12:28:17 PM
4. (Optional) If you want to verify that the updates are working, you can install the package x86info. This is not contained in OpnSense, therefore you have to edit /usr/local/etc/pkg/repos/FreeBSD.conf to enable FreeBSD repositories temporarily. You can use these commands:

echo "FreeBSD: { enabled: yes }" > /usr/local/etc/pkg/repos/FreeBSD.conf
echo y | pkg install x86info"
echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
rehash
kldload -q cpuctl
x86info -a | fgrep -i microcode


This is the log
root@OPNsense:~ # echo y | pkg install x86info
Updating FreeBSD repository catalogue...
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
Fetching packagesite.pkg: 100%    7 MiB   6.9MB/s    00:01
Processing entries: 100%
FreeBSD repository update completed. 34062 packages processed.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
New version of pkg detected; it needs to be installed first.
The following 1 package(s) will be affected (of 0 checked):

Installed packages to be UPGRADED:
        pkg: 1.19.2 -> 1.20.7 [FreeBSD]

Number of packages to be upgraded: 1

The process will require 21 MiB more space.
9 MiB to be downloaded.

[1/1] Fetching pkg-1.20.7.pkg: 100%    9 MiB   9.0MB/s    00:01    %
Checking integrity... done (0 conflicting)
[1/1] Upgrading pkg from 1.19.2 to 1.20.7...
[1/1] Extracting pkg-1.20.7: 100%
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
Updating OPNsense repository catalogue...
pkg: No SRV record found for the repo 'OPNsense'
pkg: packagesite URL error for pkg+http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.txz -- pkg+:// implies SRV mirror type
Unable to update repository OPNsense
Error updating repositories!
root@OPNsense:~ # echo "FreeBSD: { enabled: no }" > /usr/local/etc/pkg/repos/FreeBSD.conf
root@OPNsense:~ # rehash
root@OPNsense:~ # kldload -q cpuctl
root@OPNsense:~ # pkg update
Updating OPNsense repository catalogue...
pkg: No SRV record found for the repo 'OPNsense'
Fetching meta.conf: 100%    163 B   0.2kB/s    00:01
pkg: packagesite URL error for pkg+http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.pkg -- pkg+:// implies SRV mirror type
pkg: packagesite URL error for pkg+http://mirror.sfo12.us.leaseweb.net/opnsense/FreeBSD:13:amd64/23.7/latest/packagesite.txz -- pkg+:// implies SRV mirror type
Unable to update repository OPNsense
Error updating repositories!


@meyergru I would delete that part before someone else stumbles upon it.
#5
Just ran into the same issues. I had specifically checked all the rules and logging is disabled for every one of them, yet the space was still getting filled up. Thank you for the solution. I limited the logs to 7 days.
#6
22.1 Legacy Series / Re: phase 2 ipsec bug?
April 24, 2022, 11:09:02 PM
I agree, it's a little confusing, but to add phase 2 entry there is a + button on the same line with your phase 1 entry.
#7
Removing "Description" from all Dynamic DNS entries seems to fix this problem.
#8
Here you go.

I have no problem with my upload shaping by the way, but it is only 15Mbit/s pipe.
#9
Quote from: mimugmail on March 08, 2020, 07:12:59 AM
Where is the link in the Wiki with wrong explanation?
https://docs.opnsense.org/manual/how-tos/shaper.html
I suppose after reading those two topics on the forum + github and none of them were marked solved and I was seeing similar behavior I just assumed it wasn't fixed. After reading the help text for masks I realized mask behaves differently for "Pipe" and for "Queue".
QuoteDid you read the Help Text of masks?
I did, as I stated in the second post.

Quote from: franco on March 08, 2020, 08:32:53 AM
Whenever possible avoid generalisation of "it's broken" assessments. It can keep help away from your thread.
Apologies, duly noted. Topic subject edited.

I'm still having issue with only half of bandwidth available to me. I've now tested with 3 clients at the same time, and when the pipe bandwidth is set to 300, I only can get ~150 (+/- 10) Mbit/s cumulatively on all clients
#10
So after reading the comments, one does not need to set the mask. Somebody needs to edit the wiki to get rid of that. Once mask is unset, it limits the bandwidth for the whole pipe.

The other problem is still there though.

Here's the list of corresponding values that I got from testing.

It is value set under Shaper -> Pipe (downpipe) vs actual value I get from speedtest.
Something is really off, and the results are consistent after many runs.

Pipe  - actual
150 -  80
300 -  150
320 -  200
330 -  250
340 -  ~310 My max connection speed is 300 with initial burst of up to 320

#11
There are 2 issues with it:
- It halves the total bandwidth for every user
- It limits the bandwidth per user, instead of per pipe. Given enough users, the cumulative bandwidth will exceed that of the maximum bandwidth of the pipe.

There are at least 2 topics on this on this forum. One from 2016 and one from 2018. Github issue was closed in 2019 with no resolution (and 1 more problem added while trying to fix the initial one).

Is anyone working on this at all?

https://forum.opnsense.org/index.php?topic=7235.0
https://forum.opnsense.org/index.php?topic=3966.0
https://github.com/opnsense/core/issues/2191


#12
19.7 Legacy Series / Re: Constant PHP errors with DYNDNS
December 13, 2019, 11:39:14 PM
There is an issue report on github: https://github.com/opnsense/plugins/issues/1564
#13
19.7 Legacy Series / Re: Constant PHP errors with DYNDNS
November 28, 2019, 02:26:26 AM
Yup. Same problem here.
#14
Found out why after inspecting unbound.conf

Custom options are put into the config after domain overrides and unbound doesn't like it.

The solution is to remove all of your overrides and stck them manually between
private-domain: "example.lan"
domain-insecure: "example.lan"
do-not-query-localhost: no

and
forward-zone:
        name: "."
        forward-addr: 127.0.0.1@5353


For example:

private-domain: "example.lan"
domain-insecure: "example.lan"
do-not-query-localhost: no
forward-zone:
        name: "example.lan"
        forward-addr: 192.168.1.1
forward-zone:
        name: "."
        forward-addr: 127.0.0.1@5353
#15
Hello everyone,

I was just following https://docs.opnsense.org/manual/how-tos/dnscrypt-proxy.html to setup dnscrypt-proxy.
In the first paragraph the guide says to "just set this in your Unbound Advanced settings:"
do-not-query-localhost: no
forward-zone:
name: "."
forward-addr: 127.0.0.1@5353


There is no option to use custom options under Unbound --> Advanced, so I assume the author meant Unbound --> General --> Custom options.

Well, inserting the above into Custom Options, saving and applying settings kills Unbound and it won't start again until do-not-query-localhost: no is removed (and the rest kept), with the only issue that no address resolves without this option. I assume it just won't forward to 127.0.0.1:5151 because it's localhost and it is disallowed.

Any help would be appreciated.