"Recent posts
#71
Q-Feeds (Threat intelligence) / Re: Help fixing 'erroneous' Q-...
Last post by lmoore - August 09, 2026, 07:42:33 PMQuote from: Taunt9930 on August 08, 2026, 02:17:29 PMEDIT: If I go to firewall > Diagnostics > aliases and select the qfeeds malware alias in the dropdown, and search for the IP, it does not appear to be in the list. Why is it being blocked? What can I do to work out why this is suddenly being blocked. If I disable the qfeeds rule, all is well.
The IP in question is 43.131.7.8
It is in there and caught by a CIDR entry - search for 43.131.0.0.
#72
Tutorials and FAQs / Re: Tutorial: Caddy (Reverse P...
Last post by Stinger0674 - August 09, 2026, 07:41:11 PMI thought it might be bad practice to make a separate post, so I'm putting my request for help under this thread.
So I tried to follow the tutorial, but I'm still having issues with setting up a reverse proxy for my internal services. I don't need ACME and Let's Encrypt since I'm running everything locally and I'm lazy, so I tried to skip that stuff.
My desired domain for my Docker services is homelab.internal, so like jellyfin.homelab.internal, immich.homelab.internal, etc. They're all running in Docker on a Debian VM in Proxmox; the VM IP is 192.168.10.247 and I can access these services at the IP + port number (i.e. 192.168.10.247:2283 for Immich). I'm not sure if I had to make an override or not, but I did anyway with Unbound and made it like this:
Host = *
Domain = homelab.internal
Type = IPv4
IP = 192.168.10.247
nslookup resolves in both OPNsense shell and on my laptop (connected to the same VLAN Network that Proxmox is on), I can ping the domain name in terminal
I have the firewall rules set up to allow http and https traffic from any source to destination This Firewall. The direction is "In" and it's set on my LANs/VLANs, not my WAN. Do I need to enable this on WAN too?
You cannot view this attachment.
After that I did the suggested defaults in Caddy general settings (ACME email, auto HTTPS). I then followed the Reverse Proxy steps to get this:
You cannot view this attachment.
You cannot view this attachment.
Here's my Caddyfile too:
I can't resolve to the website whether I put http, https, the port number, anything. What else am I missing?
So I tried to follow the tutorial, but I'm still having issues with setting up a reverse proxy for my internal services. I don't need ACME and Let's Encrypt since I'm running everything locally and I'm lazy, so I tried to skip that stuff.
My desired domain for my Docker services is homelab.internal, so like jellyfin.homelab.internal, immich.homelab.internal, etc. They're all running in Docker on a Debian VM in Proxmox; the VM IP is 192.168.10.247 and I can access these services at the IP + port number (i.e. 192.168.10.247:2283 for Immich). I'm not sure if I had to make an override or not, but I did anyway with Unbound and made it like this:
Host = *
Domain = homelab.internal
Type = IPv4
IP = 192.168.10.247
nslookup resolves in both OPNsense shell and on my laptop (connected to the same VLAN Network that Proxmox is on), I can ping the domain name in terminal
I have the firewall rules set up to allow http and https traffic from any source to destination This Firewall. The direction is "In" and it's set on my LANs/VLANs, not my WAN. Do I need to enable this on WAN too?
You cannot view this attachment.
After that I did the suggested defaults in Caddy general settings (ACME email, auto HTTPS). I then followed the Reverse Proxy steps to get this:
You cannot view this attachment.
You cannot view this attachment.
Here's my Caddyfile too:
Code Select
# DO NOT EDIT THIS FILE -- OPNsense auto-generated file
# caddy_user=root
# Global Options
{
log {
output net unixgram//var/run/caddy/log.sock {
}
format json {
time_format rfc3339
}
}
servers {
protocols h1 h2
}
email [redacted]
grace_period 10s
skip_install_trust
import /usr/local/etc/caddy/caddy.d/*.global
}
# Reverse Proxy Configuration
immich.homelab.internal {
handle {
reverse_proxy 192.168.10.247:2283 {
}
}
}
import /usr/local/etc/caddy/caddy.d/*.conf
I can't resolve to the website whether I put http, https, the port number, anything. What else am I missing?
#73
Q-Feeds (Threat intelligence) / Re: Help fixing 'erroneous' Q-...
Last post by vpx23 - August 09, 2026, 07:16:44 PMAre you using Q-Feeds Plus or Premium? That would explain why you have the IP in the list but vk2him doesn't.
I noticed that the IP is on the Spamhaus ZEN blacklist, you can check it here: https://mxtoolbox.com/blacklists.aspx
I noticed that the IP is on the Spamhaus ZEN blacklist, you can check it here: https://mxtoolbox.com/blacklists.aspx
#74
Q-Feeds (Threat intelligence) / Re: New Login Location Alert -...
Last post by vpx23 - August 09, 2026, 07:08:58 PMThanks, it seems to be working, I didn't get an alert on the last login.
#75
Hardware and Performance / Re: AX88179B USB NIC: 57 -> 97...
Last post by web - August 09, 2026, 07:04:55 PMfollow up to my own post. i think the flapping isnt the adapter at all, its a **locking bug in freebsds mii layer**. patch at the bottom
quick recap for anyone finding this fresh. tp-link ue306 (ax88179b) as wan on opnsense 26.7, vlan 10, spark fibre 930/500. stock axge did 57-73 mbps. i found four bugs in `if_axge.c` (rx aggregation timer way too short, two read helpers handing back uninitialised stack memory, `AXGE_PADDING` defined but never set, one rx transfer in flight) and that got it to **979 mbps**
but it still flapped. `ue0: link state changed` a few hundred times a minute, and the wan lease went with it every time. and it was weirdly all or nothing. it once ran 2 hours 18 minutes completely clean at 979, then i power cycled the box for an unrelated reason and it went straight back to flapping constantly. same kernel, same cable, same everything. that bistable thing is what made it so hard to pin down, i kept thinking id fixed it when id just got a good run
so heres what i think is happening. the mii layer keeps the current media (speed, duplex, link up or down) in a couple of shared variables, and it assumes that while its updating them its holding the driver lock so nothing else can look. thats fine on a normal pci nic, reading a phy register there is a register poke and a short poll, all of it under the lock, never sleeping
but on usb its different. every phy register read is a control transfer, and `usbd_do_request_flags()` **drops the mutex you hand it while it waits**. thats what passing it in is for. so the driver lock gets released and retaken on every single register read. `mii_tick()` (the once a second poll) and `mii_pollstat()` (anything asking the interface what its media is) end up running straight through each other, and one of them reads the media variables while the other is halfway through writing them
the code reads as correct, which is part of why it took me so long. `axge_ifmedia_sts()` does hold `AXGE_LOCK` across `mii_pollstat()`, and `axge_tick()` runs with it held. they still arent serialised, because the lock doesnt survive the transfer
went back through the logs and it was the media value that pointed somewhere. every DOWN event carried `0x20`, which is a bare `IFM_ETHER` with no speed and no duplex in it. the media word gets built in stages and `0x20` is what it holds for a few microseconds at the very start, before the speed goes in. `ukphy_status()` sets exactly that at the top, and every single exit path out of it fills in either a real speed or `IFM_NONE`, so a finished pass cant leave `0x20` behind. seeing it arrive looks like catching the other pass mid write
also every DOWN was followed by an UP microseconds later, and every one of those UPs said `0x100030`, which is 1000baseT full duplex. hundreds of events and it never once came back at 100baseTX or half duplex. that doesnt feel like a link genuinely renegotiating to me, though if theres a reason it would look like that id be glad to hear it
and it feeds itself, which id say is why it looked so random. a torn read makes `mii_linkchg()` fire off a link state change. whatever reacts to that goes and asks the interface what its media is, and that question is another mii pass, which tears again. so once it starts it doesnt stop on its own
stuff i chased that turned out to be nothing, in case it saves someone else the time:
- thought autoneg was restarting by itself, so i counted every BMCR write. two resets in an entire run. not it
- thought it was usb errors. tx errors 0, rx errors 0, the usb layer is completely healthy the whole time
- thought the driver was resetting the phy. init 1, mediaupd 1, reset 1, while statchg hit 659, so something was reacting to a link change the phy doesnt look like it made
- built a driver that lied and always reported link up in BMSR. that one was my favourite dead end, i was certain. changed nothing at all, which fits the corruption happening between the reads rather than in the bit
- thought it was load. it flaps at idle too, 426 events in 2.5 minutes at about 13 packets a second
the fix i went with is to make whole mii passes exclusive. a busy flag in the drivers per device struct, slept on with `msleep()` and the existing `sc_mtx`, wrapped around `mii_tick()`, `mii_pollstat()` and `mii_mediachg()`. i couldnt use a second mutex for this, the transfer sleeps and a normal mutex held across a sleep panics. the flag works where the lock doesnt, because it survives the lock getting dropped
40 second windows, before and after:
```
link state changes 186 / 313 / 139 -> 0 / 0 / 0
miibus_statchg 659 -> 4
phy register reads 57010 -> 4536
torn media words 170 -> 0
```
the 4 statchg calls left are just the transitions at startup, and it stays at 4. i also added a counter for how many passes had to wait on another one and it hit 254, then 538 on a longer run, so theyre landing on each other constantly, i was expecting a much narrower window than that. interface counters after: 0 input errors, 0 drops, 0 output errors across 1.89 GB in and 1.05 GB out
**979 down, 465 up, best single run 983** on a 930/500 plan. the 465 upload comes from a tx queue depth change (1 to 4) i havent submitted yet, without that expect about 250 up
i dont think this is an axge problem specifically. i grepped the tree and `if_axe`, `if_muge`, `if_smsc` and `if_ure` all call `mii_attach`, `mii_tick` and `mii_pollstat` exactly the same way axge does, and they all reach the phy over the same control transfers that drop the mutex. whether they actually hit it in practice i cant say, i only have the one adapter. so if youve got a usb nic on freebsd that flaps for no reason and youve just lived with it, might be worth a look. someone who actually knows the mii layer should probably say whether the proper fix belongs in there rather than being redone in every driver. i do wonder if some of usb ethernets reputation on freebsd comes from this, though thats one adapter and a lot of extrapolating
patch attached, 100 lines, touches `if_axge.c` and `if_axgereg.h`. applies on its own, no dependency on the earlier four. compiles clean against stable/26.7. going on the freebsd bug alongside this. its just the one module so applying it means building `if_axge.ko`, not a whole kernel
if youre on the cdce workaround (the usb quirk forcing config 1) none of this should touch you, youre stable at around 350/500 already. patched axge is doing 979/465 here against that, so its there if you fancy a swap. if anyone else with a usb nic gives it a go id be keen to hear how it went
quick recap for anyone finding this fresh. tp-link ue306 (ax88179b) as wan on opnsense 26.7, vlan 10, spark fibre 930/500. stock axge did 57-73 mbps. i found four bugs in `if_axge.c` (rx aggregation timer way too short, two read helpers handing back uninitialised stack memory, `AXGE_PADDING` defined but never set, one rx transfer in flight) and that got it to **979 mbps**
but it still flapped. `ue0: link state changed` a few hundred times a minute, and the wan lease went with it every time. and it was weirdly all or nothing. it once ran 2 hours 18 minutes completely clean at 979, then i power cycled the box for an unrelated reason and it went straight back to flapping constantly. same kernel, same cable, same everything. that bistable thing is what made it so hard to pin down, i kept thinking id fixed it when id just got a good run
so heres what i think is happening. the mii layer keeps the current media (speed, duplex, link up or down) in a couple of shared variables, and it assumes that while its updating them its holding the driver lock so nothing else can look. thats fine on a normal pci nic, reading a phy register there is a register poke and a short poll, all of it under the lock, never sleeping
but on usb its different. every phy register read is a control transfer, and `usbd_do_request_flags()` **drops the mutex you hand it while it waits**. thats what passing it in is for. so the driver lock gets released and retaken on every single register read. `mii_tick()` (the once a second poll) and `mii_pollstat()` (anything asking the interface what its media is) end up running straight through each other, and one of them reads the media variables while the other is halfway through writing them
the code reads as correct, which is part of why it took me so long. `axge_ifmedia_sts()` does hold `AXGE_LOCK` across `mii_pollstat()`, and `axge_tick()` runs with it held. they still arent serialised, because the lock doesnt survive the transfer
went back through the logs and it was the media value that pointed somewhere. every DOWN event carried `0x20`, which is a bare `IFM_ETHER` with no speed and no duplex in it. the media word gets built in stages and `0x20` is what it holds for a few microseconds at the very start, before the speed goes in. `ukphy_status()` sets exactly that at the top, and every single exit path out of it fills in either a real speed or `IFM_NONE`, so a finished pass cant leave `0x20` behind. seeing it arrive looks like catching the other pass mid write
also every DOWN was followed by an UP microseconds later, and every one of those UPs said `0x100030`, which is 1000baseT full duplex. hundreds of events and it never once came back at 100baseTX or half duplex. that doesnt feel like a link genuinely renegotiating to me, though if theres a reason it would look like that id be glad to hear it
and it feeds itself, which id say is why it looked so random. a torn read makes `mii_linkchg()` fire off a link state change. whatever reacts to that goes and asks the interface what its media is, and that question is another mii pass, which tears again. so once it starts it doesnt stop on its own
stuff i chased that turned out to be nothing, in case it saves someone else the time:
- thought autoneg was restarting by itself, so i counted every BMCR write. two resets in an entire run. not it
- thought it was usb errors. tx errors 0, rx errors 0, the usb layer is completely healthy the whole time
- thought the driver was resetting the phy. init 1, mediaupd 1, reset 1, while statchg hit 659, so something was reacting to a link change the phy doesnt look like it made
- built a driver that lied and always reported link up in BMSR. that one was my favourite dead end, i was certain. changed nothing at all, which fits the corruption happening between the reads rather than in the bit
- thought it was load. it flaps at idle too, 426 events in 2.5 minutes at about 13 packets a second
the fix i went with is to make whole mii passes exclusive. a busy flag in the drivers per device struct, slept on with `msleep()` and the existing `sc_mtx`, wrapped around `mii_tick()`, `mii_pollstat()` and `mii_mediachg()`. i couldnt use a second mutex for this, the transfer sleeps and a normal mutex held across a sleep panics. the flag works where the lock doesnt, because it survives the lock getting dropped
40 second windows, before and after:
```
link state changes 186 / 313 / 139 -> 0 / 0 / 0
miibus_statchg 659 -> 4
phy register reads 57010 -> 4536
torn media words 170 -> 0
```
the 4 statchg calls left are just the transitions at startup, and it stays at 4. i also added a counter for how many passes had to wait on another one and it hit 254, then 538 on a longer run, so theyre landing on each other constantly, i was expecting a much narrower window than that. interface counters after: 0 input errors, 0 drops, 0 output errors across 1.89 GB in and 1.05 GB out
**979 down, 465 up, best single run 983** on a 930/500 plan. the 465 upload comes from a tx queue depth change (1 to 4) i havent submitted yet, without that expect about 250 up
i dont think this is an axge problem specifically. i grepped the tree and `if_axe`, `if_muge`, `if_smsc` and `if_ure` all call `mii_attach`, `mii_tick` and `mii_pollstat` exactly the same way axge does, and they all reach the phy over the same control transfers that drop the mutex. whether they actually hit it in practice i cant say, i only have the one adapter. so if youve got a usb nic on freebsd that flaps for no reason and youve just lived with it, might be worth a look. someone who actually knows the mii layer should probably say whether the proper fix belongs in there rather than being redone in every driver. i do wonder if some of usb ethernets reputation on freebsd comes from this, though thats one adapter and a lot of extrapolating
patch attached, 100 lines, touches `if_axge.c` and `if_axgereg.h`. applies on its own, no dependency on the earlier four. compiles clean against stable/26.7. going on the freebsd bug alongside this. its just the one module so applying it means building `if_axge.ko`, not a whole kernel
if youre on the cdce workaround (the usb quirk forcing config 1) none of this should touch you, youre stable at around 350/500 already. patched axge is doing 979/465 here against that, so its there if you fancy a swap. if anyone else with a usb nic gives it a go id be keen to hear how it went
#76
General Discussion / Re: Help needed to update boot...
Last post by hushcoden - August 09, 2026, 06:55:09 PM #77
26.1, 26,4 Series / Re: 26.1 upgrade chaos, Realte...
Last post by computer_freak_8 - August 09, 2026, 06:55:07 PMQuote from: nero355 on July 25, 2026, 07:39:02 PMAFAIK that's a very old RealTek NIC Chip used as Onboard NIC for a lot of devices and might be declared as EOL by the people who build the FreeBSD Kernel so you could check that and see if there is a solution available for those who want to use it anyway ?
Yes, it's old - that's why I'm using this machine as a firewall box rather than a general-purpose computer.
I suppose it's *possible* that the upstream devs went to the work of removing support for some RTL8111 flavors while leaving other RTL8111 flavors supported, but that seems implausible.
Also, that wouldn't (shouldn't) affect the proprietary driver package, which as noted, also doesn't work, even though Realtek says it's the same driver for both the working and non-working chipset flavors.
#78
General Discussion / Re: Minimum Supported Refresh ...
Last post by yourfriendarmando - August 09, 2026, 06:23:01 PMI think these fields appeared more recently in recent production releases.
It should give more granularity. This could be useful, perhaps download one copy often, and distribute to client firewalls via an internal web server.
Classically, I update all aliases with a Cron Job on a weekly basis. It's only to make sure my URL sources do not ban me for getting too often.
It should give more granularity. This could be useful, perhaps download one copy often, and distribute to client firewalls via an internal web server.
Classically, I update all aliases with a Cron Job on a weekly basis. It's only to make sure my URL sources do not ban me for getting too often.
#79
General Discussion / Re: Help needed to update boot...
Last post by Patrick M. Hausen - August 09, 2026, 06:19:35 PMYou would need to take a deep dive into Intel's or AMD's documentation, find what exactly the update does to your CPU, then assess if this is something that is necessary to be done before the FreeBSD kernel initialises.
Microcode updates are bug fixes for your CPU. I have no idea how I would find that information.
So probably early loading is somehow "better"?
But I run ~100 servers which all load late without any ill side effects.
🤷, sorry.
Microcode updates are bug fixes for your CPU. I have no idea how I would find that information.
So probably early loading is somehow "better"?
But I run ~100 servers which all load late without any ill side effects.
🤷, sorry.
#80
General Discussion / Re: Help needed to update boot...
Last post by hushcoden - August 09, 2026, 06:12:49 PMOne more question: I'm reading about whether early or late loading of the cpu microcode is better and considering I'm not experiencing any issues with the recently installed v26.7.1, I'd say there's nothing I need to do. Is that the case, or should I create the file
I just want to understand whether the early loading is strictly necessary or if it's simply recommended.
Code Select
/boot/loader.conf.local and add those two lines? Code Select
cpu_microcode_load="YES"
cpu_microcode_name="/boot/firmware/intel-ucode.bin"I just want to understand whether the early loading is strictly necessary or if it's simply recommended.
