Solved Internet connection going up and down constantly

HI everyone,

My internet connection go trough an Ethernet cable plugged into the router 10gbits port and the other end to my computer usb-c port trough a usb ethernet adaptater from HELIX. I was wondering why I was loosing my VPN connection all the time like every hour or 30 minutes sometime every 15 minutes and less. I check everything and finally I saw in /var/log/messages the following :

Code:
Sep 23 16:54:37 nomonoru kernel: wg0: link state changed to UP
Sep 23 17:02:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:02:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:04:05 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:04:05 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:22:26 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:22:26 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:30:06 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:30:06 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:38:45 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:38:45 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:44:45 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:44:45 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:45:25 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:45:25 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:45:25 nomonoru kernel: ue0: 2 link states coalesced
Sep 23 17:45:25 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:45:25 nomonoru dhclient[2683]: New IP Address (ue0):
Sep 23 17:45:25 nomonoru dhclient[2687]: New Subnet Mask (ue0):
Sep 23 17:45:25 nomonoru dhclient[2691]: New Broadcast Address (ue0):
Sep 23 17:45:25 nomonoru dhclient[2695]: New Routers (ue0):
Sep 23 17:45:25 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:45:25 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:45:25 nomonoru kernel: wg0: loop detected
Sep 23 17:45:56 nomonoru syslogd: last message repeated 191 times
Sep 23 17:47:47 nomonoru syslogd: last message repeated 316 times
Sep 23 17:49:45 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:49:45 nomonoru kernel: ue0: link state changed to UP
Sep 23 17:55:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 17:55:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:07:34 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:07:34 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:07:45 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:07:45 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:17:06 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:17:06 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:17:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:17:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:17:45 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:17:45 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:22:54 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:22:54 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:22:57 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:22:57 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:23:17 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:23:17 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:30:25 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:30:25 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:34:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:34:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:38:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:38:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:41:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:41:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:46:15 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:46:15 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:50:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:50:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:57:04 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:57:04 nomonoru kernel: ue0: link state changed to UP
Sep 23 18:57:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 18:57:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:24:56 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:24:56 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:24:56 nomonoru kernel: ue0: 2 link states coalesced
Sep 23 19:24:56 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:24:56 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:24:56 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:24:57 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:24:57 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:25:07 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:25:07 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:25:37 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:25:37 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:26:05 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:26:05 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:26:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:26:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:30:47 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:30:47 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:31:15 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:31:15 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:32:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:32:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:35:46 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:35:46 nomonoru kernel: ue0: link state changed to UP
Sep 23 19:39:27 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 19:39:27 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:18:47 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:18:47 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:18:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:18:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:24:11 nomonoru kernel: wg0: link state changed to DOWN
Sep 23 20:24:15 nomonoru kernel: wg0: link state changed to UP
Sep 23 20:24:15 nomonoru kernel: wg0: loop detected
Sep 23 20:33:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:33:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:33:55 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:33:55 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:37:06 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:37:06 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:46:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:46:35 nomonoru kernel: ue0: link state changed to UP
Sep 23 20:46:35 nomonoru kernel: ue0: link state changed to DOWN
Sep 23 20:46:35 nomonoru kernel: ue0: link state changed to UP

so I understood that I have connection stability issue. My question is do other people experience issue like that, and is there something I can do about it.
The correct driver is loaded in the kernel: if_ur.
usbconfig : ugen1.4: <RTL8152...
kldstat : 30 1 0xffffffff83f20000 8560 if_ure.ko
also the Ethernet cable is brand-new.

And final here is my firewall config:

Code:
cat /etc/pf.conf
# --- Options ---
# Allow traffic on the loopback interface (localhost)
set skip on lo0

# Define external network interface (replace with your actual external interface)
ext_if = "ue0"  # Example: use your actual external interface like 'em0' or 'ue0'

# --- Translation (NAT) Rules ---
# NAT for OpenVPN interface (tun0)
nat on tun0 from <IP adress> to any -> (tun0)

# NAT for WireGuard interface (wg0)
nat on wg0 from <IP adresse> to any -> (wg0)

# --- Filtering Rules ---
# Block all traffic by default
block all

# Allow outgoing TCP traffic for services like browsing, email, etc.
pass out proto tcp to any port { 22, 25, 80, 110, 143, 443, 465, 587, 993, 995 } keep state

# Allow outgoing UDP traffic for DNS queries (port 53)
pass out proto udp to any port 53 keep state

# Allow incoming and outgoing traffic for qBittorrent P2P port (61202)
#pass in log proto { tcp, udp } from any to any port 61202 keep state
#pass out log proto { tcp, udp } to any port 61202 keep state

# Allow all outgoing TCP and UDP traffic for general purposes
pass out proto { tcp, udp } to any keep state

# Allow ICMP (ping) requests
pass proto icmp

# --- WireGuard VPN Filtering Rules ---
# Allow WireGuard UDP traffic on its port (51820 by default)
pass in proto udp from any to ($ext_if) port 51820 keep state
pass out proto udp from any to any port 51820 keep state

# --- OpenVPN VPN Filtering Rules ---
# Allow OpenVPN UDP traffic on its port (1194 by default)
pass in proto udp from any to ($ext_if) port 1194 keep state
pass out proto udp from any to any port 1194 keep state

# --- VPN Interface Rules ---
# Allow all traffic in and out on OpenVPN (tun0) and WireGuard (wg0) interfaces
pass in on tun0 all
pass out on tun0 all
pass in on wg0 all
pass out on wg0 all

# Allow outgoing traffic on the external interface
pass out on $ext_if keep state

Thanks for insight.
 
Ethernet cable plugged into the router 10gbits port
Maybe the usb ethernet adapter does not like the 10G auto negotiation feature of the router.

Does the link ever become stable? If so check ifconfig ue0 and see what it shows.

If you cannot do that see if you can force the router/switch 10G port to 1G. Not autonegotiate.

The up-down of interface is called FLAPPING. Your interface is flapping.
 
Maybe the usb ethernet adapter does not like the 10G auto negotiation feature of the router.

Does the link ever become stable? If so check ifconfig ue0 and see what it shows.

If you cannot do that see if you can force the router/switch 10G port to 1G. Not autonegotiate.

The up-down of interface is called FLAPPING. Your interface is flapping.
I also tried to change the cable from one switch to another. At the beginning it was in the 1G one, after I plugged it into the 10G. On the box of the Ethernet adapter it say Ethernet 100mbits/s
ifconfig ue0 say it's up and active.
 
Speed negotiation fouling between ethernet devices is just one of many possible causes for flapping.

It is the low-hanging-fruit that you start looking at.

That is if the driver is known to perform well.

What bothers me is USB3-C adapter (helix brand unknown) and the driver I am not familiar with RT8152.

What platform/box/mobo is using the USB-C for networking?
 
What platform is using the USB-C for networking?
Excuse me but I dont understand that question...

maybe that help:
Code:
em0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=4e524bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG>
        ether
        media: Ethernet autoselect
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet  netmask
        inet6 ::1 prefixlen 128
        inet6 %lo0 prefixlen 64 scopeid 0x2
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
pflog0: flags=1000141<UP,RUNNING,PROMISC,LOWER_UP> metric 0 mtu 33152
        options=0
        groups: pflog
ue0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
        options=68009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        ether
        inet  netmask  broadcast
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
        options=80000<LINKSTATE>
        inet  netmask
        inet6  prefixlen 128
        groups: wg
        nd6 options=101<PERFORMNUD,NO_DAD>
 
That Helix device looks like an issue. Multi-function USB-C devices are not well supported.

Plus our HDMI over USB-C support is not good. Have you seen any success stories with the Helix device?

Do you have USB2/3 - Tpye A connections on this PC? This is a tablet computer with limited ports correct?
 
That Helix device looks like an issue. Multi-function USB-C devices are not well supported.

Plus our HDMI over USB-C support is not good. Have you seen any success stories with the Helix device?

Do you have USB2/3 - Tpye A connections on this PC? This is a tablet computer with limited ports correct?
Yes this is a tablet computer with limited ports.

maybe that help:

Code:
usbconfig
ugen0.1: <Intel XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.1: <Intel XHCI root HUB> at usbus1, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA)
ugen1.2: <vendor 0x214b USB2.0 HUB> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=SAVE (100mA)
ugen0.2: <Bluetooth wireless interface Intel Corp.> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen0.3: <Integrated Camera Chicony Electronics Co., Ltd> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
ugen1.3: <USB C USB C Video Adaptor> at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (0mA)
ugen0.4: <vendor 0x138a product 0x0097> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA)
ugen1.4: <RTL8152 Fast Ethernet Adapter Realtek Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)
ugen0.5: <Wacom Co.,Ltd. Pen and multitouch sensor> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (400mA)
ugen0.6: <SanDisk Portable SSD> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=ON (224mA)

Have you seen any success stories with the Helix device?
Nope! a quick search return nothing.
 
I would ditch the multifunction USB3-C device and get USB3-C hub only with USB3-A jacks.

Then get the best network USB we have. Asix AX88179

I'll try it and report when done. thanks again.
 
Check an output from usbconfig -d X.Y dump_device_desc where X.Y is your usb device (1.4 as in your previos post). If bNumConfigurations > 0 then try to use another configuration:
usbconfig -d X.Y set_config 1
 
It's plugged into my lenovo yoga370 with FreeBSD 14 as OS. I have no choice to use an adapter because there no Ethernet switch on the laptop.
Why don't you use the onboard intel NIC (em0)?

I've never seen any USB-to-LAN dongle (especially multi-function devices) that I'd consider even halfway reliable enough to work with.
So I'd stick with the onboard NIC for actual work and if you absolutely must (to connect to a physically different network?) a plain-and-simple USB to "only LAN" dongle, ideally with a 'known working' chipset, but you might still have to verify via try&error if it works.
 
Check an output from usbconfig -d X.Y dump_device_desc where X.Y is your usb device (1.4 as in your previos post). If bNumConfigurations > 0 then try to use another configuration:
usbconfig -d X.Y set_config 1
bNumConfigurations = 0x0002

Code:
usbconfig -d 1.4 dump_device_desc
ugen1.4: <RTL8152 Fast Ethernet Adapter Realtek Semiconductor Corp.> at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (100mA)

  bLength = 0x0012
  bDescriptorType = 0x0001
  bcdUSB = 0x0200
  bDeviceClass = 0x0000  <Probed by interface class>
  bDeviceSubClass = 0x0000
  bDeviceProtocol = 0x0000
  bMaxPacketSize0 = 0x0040
  idVendor = 0x0bda
  idProduct = 0x8152
  bcdDevice = 0x2000
  iManufacturer = 0x0001  <Realtek>
  iProduct = 0x0002  <USB 10/100 LAN>
  iSerialNumber = 0x0003  <00E04CA21FF6>
  bNumConfigurations = 0x0002
 
I've never seen any USB-to-LAN dongle (especially multi-function devices) that I'd consider even halfway reliable enough to work with.
I have couple USB-to-LAN devices, which works without any issues. But, before using, I made some modifications to prevent main problem of devices this type: overheating. Even 100 mbit devices can get high temperatures.
 
Q: does your environment allow the OS to turn off the NIC for power management?

In the Windows world, this is enabled by default.
One must config the NIC and uncheck this feature.
 
I don't have any NIC on the board. the interface you see that is listed there is a rest of the installation process. also I don't use WiFi. I prefer to connect with cable.
em is not a wireless device, that's the driver for a intel gigabit NIC. Also network devices are not "left over" from installation - if the driver is loaded during boot, that means there is a device that needs it.
Also the specs for that laptop list a gbit network interface...
Please check/show the output of pciconf -lv | grep -A4 em0
 
Also the specs for that laptop list a gbit network interface
It has a mini-ethernet port:
csm_left_0b81cd0280.jpg

At this point a mini-ethernet to ethernet adapter like the one showed in the laptop manual couldn't be a valid solution?
 
em is not a wireless device, that's the driver for a intel gigabit NIC. Also network devices are not "left over" from installation - if the driver is loaded during boot, that means there is a device that needs it.
Also the specs for that laptop list a gbit network interface...
Please check/show the output of pciconf -lv | grep -A4 em0

It has a mini-ethernet port:
csm_left_0b81cd0280.jpg

At this point a mini-ethernet to ethernet adapter like the one showed in the laptop manual couldn't be a valid solution?

Yes you are rigth, it has a 1 x Intel® Thunderbolt™ 3. I just realize it. It's the first time I come across this kind of port. Should I use it and buy an adapter thunderbolt 3 to Ethernet? Or am I better to stick with the USB-c to Ethernet adapter?

Code:
pciconf -lv | grep -A4 em0
em0@pci0:0:31:6:        class=0x020000 rev=0x21 hdr=0x00 vendor=0x8086 device=0x15d7 subvendor=0x17aa subdevice=0x224f
    vendor     = 'Intel Corporation'
    device     = 'Ethernet Connection (4) I219-LM'
    class      = network
    subclass   = ethernet
 
Back
Top