Categories

  • 390
    Topics
    1.3k
    Posts

    GertjanG

    @vaan

    Isn't that a 32 bit processor ?
    Hummmm. Ancient processor needs ancient '32 bits' pfSense, and that doesn't exist anymore.

  • 118.8k
    Topics
    749.3k
    Posts

    stephenw10S

    And it's only the NIC you're trying to connect to that appears to stop passing traffic? I.e. a NIC/driver issue or soemthing in the network stack.

  • Discussions about pfSense software packages

    Cache/Proxy IDS/IPS Traffic Monitoring pfBlockerNG UPS Tools ACME FRR Tailscale WireGuard
    19.9k
    Topics
    125.7k
    Posts

    M

    These messages have appeared in the DNS Resolver logs since this morning:

    Jan 16 15:51:04 filterdns 27598 failed to resolve host acme-staging.api.letsencrypt.org will retry later again. Jan 16 15:51:04 filterdns 27598 failed to resolve host acme-staging.api.letsencrypt.org will retry later again.

    I'm currently using the ACME certificates for a lot of hosts via HAProxy. Is this something permanently broken with the package or something temporary?

    Is anyone else seeing this issue?

  • 42.4k
    Topics
    266.3k
    Posts

    T

    @micneu Bei einem großen Download sieht die Prozessliste so aus (der abgeschnitte Teil beinhaltet nur noch Prozesse im einstelligen Prozentbereich):

    last pid: 79545; load averages: 3.28, 2.75, 1.49 up 0+00:09:47 21:24:27 277 threads: 8 running, 248 sleeping, 21 waiting CPU: 13.9% user, 0.2% nice, 26.9% system, 18.5% interrupt, 40.4% idle Mem: 94M Active, 116M Inact, 438M Wired, 7054M Free ARC: 133M Total, 40M MFU, 88M MRU, 267K Anon, 785K Header, 3422K Other 104M Compressed, 228M Uncompressed, 2.20:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K RUN 3 4:23 88.67% [idle{idle: cpu3}] 0 root -60 - 0B 1328K CPU0 0 4:06 81.05% [kernel{if_io_tqg_0}] 11 root 187 ki31 0B 64K CPU1 1 4:38 77.10% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K CPU2 2 3:36 58.69% [idle{idle: cpu2}] 0 root -60 - 0B 1328K CPU2 2 1:48 34.08% [kernel{if_io_tqg_2}] 12 root -60 - 0B 272K WAIT 1 2:51 20.56% [intr{swi1: netisr 1}] 11 root 187 ki31 0B 64K RUN 0 3:32 19.38% [idle{idle: cpu0}] ...

    Der Trafficgraph dazu sieht so aus:

    112b5f3b-8407-4436-aeac-419c70c5e1a1-image.png

    Während einer der Einbrüche sieht die Prozessliste so aus:

    last pid: 92189; load averages: 2.87, 2.78, 1.70 up 0+00:12:13 21:26:53 284 threads: 12 running, 251 sleeping, 1 zombie, 20 waiting CPU: 12.2% user, 0.2% nice, 28.9% system, 18.3% interrupt, 40.4% idle Mem: 99M Active, 115M Inact, 439M Wired, 7051M Free ARC: 133M Total, 40M MFU, 88M MRU, 286K Anon, 787K Header, 3443K Other 104M Compressed, 228M Uncompressed, 2.20:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K RUN 3 5:29 91.55% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K RUN 2 4:38 86.28% [idle{idle: cpu2}] 11 root 187 ki31 0B 64K RUN 1 5:58 86.08% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K RUN 0 4:05 71.88% [idle{idle: cpu0}] 0 root -60 - 0B 1360K CPU0 0 5:35 27.20% [kernel{if_io_tqg_0}] 0 root -60 - 0B 1360K - 2 2:32 10.50% [kernel{if_io_tqg_2}] 12 root -60 - 0B 272K CPU1 1 3:49 6.79% [intr{swi1: netisr 1}] ...

    Also scheinbar "Weniger Pakete" -> "Weniger Load", stellt sich nur die Frage, warum weniger Pakete.

    Mein Setup sieht so aus:

    ┌───────────┐ PPPoE (VLAN7, ix0.7) ┌──────────────────────┐ ┌────────────────┐ │ pfSense ├───────────────────────►│ Glasfaser-Modem 2 ├─────►│ Anschlussdose │ └───────────┘ └──────────────────────┘ └────────────────┘

    Edit: Ich habe die Optionen Disable hardware TCP segmentation offload und Disable hardware large receive offload wieder aktiviert. Damit kriege ich das Sägezahnmuster aus dem Graph. Leider kommt es immer noch zu den Einbrüchen:

    Nicht während Einbruch:

    last pid: 71003; load averages: 4.50, 3.93, 2.10 up 0+00:08:06 21:46:22 277 threads: 8 running, 248 sleeping, 21 waiting CPU: 18.6% user, 0.2% nice, 28.8% system, 23.3% interrupt, 29.0% idle Mem: 93M Active, 116M Inact, 433M Wired, 7060M Free ARC: 133M Total, 40M MFU, 88M MRU, 263K Anon, 782K Header, 3432K Other 103M Compressed, 227M Uncompressed, 2.19:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 0 root -60 - 0B 1328K CPU0 0 3:31 71.29% [kernel{if_io_tqg_0}] 11 root 187 ki31 0B 64K RUN 1 2:37 69.58% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K RUN 3 2:32 64.79% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K RUN 2 1:59 47.66% [idle{idle: cpu2}] 12 root -60 - 0B 272K WAIT 3 3:27 31.79% [intr{swi1: netisr 2}] 11 root 187 ki31 0B 64K RUN 0 2:36 29.79% [idle{idle: cpu0}] 12 root -60 - 0B 272K WAIT 1 3:38 22.46% [intr{swi1: netisr 3}] 0 root -60 - 0B 1328K RUN 1 1:08 18.80% [kernel{if_io_tqg_1}] 0 root -60 - 0B 1328K RUN 3 0:54 16.55% [kernel{if_io_tqg_3}] ...

    Während Einbruch:

    last pid: 18392; load averages: 4.06, 3.93, 2.22 up 0+00:09:04 21:47:20 277 threads: 5 running, 251 sleeping, 21 waiting CPU: 17.3% user, 0.2% nice, 29.1% system, 23.7% interrupt, 29.7% idle Mem: 95M Active, 117M Inact, 433M Wired, 7058M Free ARC: 133M Total, 40M MFU, 88M MRU, 267K Anon, 782K Header, 3429K Other 103M Compressed, 227M Uncompressed, 2.19:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 11 root 187 ki31 0B 64K CPU1 1 3:04 77.59% [idle{idle: cpu1}] 11 root 187 ki31 0B 64K CPU3 3 2:55 77.49% [idle{idle: cpu3}] 11 root 187 ki31 0B 64K CPU2 2 2:16 68.55% [idle{idle: cpu2}] 11 root 187 ki31 0B 64K RUN 0 2:54 63.57% [idle{idle: cpu0}] 0 root -60 - 0B 1328K - 0 4:01 30.37% [kernel{if_io_tqg_0}] 12 root -60 - 0B 272K WAIT 1 3:57 11.96% [intr{swi1: netisr 2}] 12 root -60 - 0B 272K WAIT 3 4:10 9.57% [intr{swi1: netisr 3}] 0 root -60 - 0B 1328K - 1 1:18 8.15% [kernel{if_io_tqg_1}] 0 root -60 - 0B 1328K - 3 1:01 7.18% [kernel{if_io_tqg_3}] ...

    Graph dazu:
    de2b3885-37d1-4091-863f-4410562e3618-image.png

  • Information about hardware available from Netgate

    2.4k
    Topics
    19.5k
    Posts

    A

    Imagine you work for a busy company that is trying a different brand of delivery trucks for its fleet that operates 24/7. The delivery trucks work well and employees like them, so the company buys many more over the next few years. At first, there were no available options, but the brochure for recent models lists two axle options: BASE or MAX. The only difference mentioned is that the BASE axle is 6-lug and the MAX axle is 8-lug.

    Recently, the factory-equipped axles have begun failing much sooner than those of other truck brands and previous delivery trucks you have owned. Now, a sixth truck is stuck at the side of the road waiting for a tow, missing another important delivery and losing your customer's confidence.

    You begin researching axle failures and this truck model. You find that the BASE model tires are similar to the axles used on passenger vehicles. They are fine for driving around town with light loads, but highway driving, adding additional equipment, or carrying additional weight causes the axles to wear internally and fail prematurely. Changing to the MAX axle requires a truck to be out of service for 2 days. You find that other companies using these trucks are having the same problem, and the manufacturer even recommends removing the spare tire, jack, radio, passenger seat, bumpers, and mud flaps to reduce weight and extend the life of the BASE axle.

    You might think, "Ridiculous!" One of the main reasons we bought these trucks is that they support a wide variety of aftermarket accessories that allow the trucks to be customized to significantly improve their functionality, as shown in the glossy brochures.

    You wonder, "Since these are sold as delivery trucks, why would the manufacturer use inferior axles without making it clear that the BASE axle option is what most customers will need to use the trucks for anything but the lightest of tasks?"

    The MAX model was a $1000 option that seemed unnecessary at the time, but each premature axle failure costs you $10,000 in towing charges, labor, equipment rentals, customer goodwill, and vehicle repairs. Replacing the axles before they fail will cost $7000 of lost revenue, parts, and labor per truck. You look out your office at the 40 trucks in your loading yard and wonder how you will get through this situation.

  • Information about hardware available from Netgate

    44
    Topics
    211
    Posts

    AriKellyA

    It looks like unified web management could be coming soon. It would be great if it means easier control and management of all web services in one place. Let's see if any companies announce more details about it!

  • Feel free to talk about anything and everything here

    Forum Feedback Community Job Board
    3.4k
    Topics
    18.5k
    Posts

    stephenw10S

    Mmm, at one time, for example, I could look at https://forum.netgate.com/category/66/pfsense-software and see which subs had unread posts in by which were shown in bold text. However that hasn't worked for quite a while. For me at least.

Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.