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

Topics - MartB

#1
Hey there,

the test-upgrade worked fine but as soon as the network interfaces get some traffic the system crashes.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x4
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff80e74823
stack pointer         = 0x0:0xfffffe00c6179cb0
frame pointer         = 0x0:0xfffffe00c6179d60
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 12 (swi1: netisr 0)
trap number = 12
panic: page fault
cpuid = 0
time = 1636661506
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c6179950
vpanic() at vpanic+0x187/frame 0xfffffe00c61799b0
panic() at panic+0x43/frame 0xfffffe00c6179a10
trap_fatal() at trap_fatal+0x387/frame 0xfffffe00c6179a70
trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00c6179ad0
trap() at trap+0x26a/frame 0xfffffe00c6179be0
calltrap() at calltrap+0x8/frame 0xfffffe00c6179be0
--- trap 0xc, rip = 0xffffffff80e74823, rsp = 0xfffffe00c6179cb0, rbp = 0xfffffe00c6179d60 ---
ip_tryforward() at ip_tryforward+0x213/frame 0xfffffe00c6179d60
ip_input() at ip_input+0x382/frame 0xfffffe00c6179df0
swi_net() at swi_net+0x12b/frame 0xfffffe00c6179e60
ithread_loop() at ithread_loop+0x25a/frame 0xfffffe00c6179ef0
fork_exit() at fork_exit+0x8a/frame 0xfffffe00c6179f30
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c6179f30
--- trap 0x80386000, rip = 0xffffffff80c4944f, rsp = 0, rbp = 0x2475000 ---
mi_startup() at mi_startup+0xdf/frame 0x2475000
KDB: enter: panic


Was the realtek-vendor-kmod if_re.ko compiled with the correct kernel sources or is there any incompatible changes?

If i use any other usb network interface it works just fine.
Nevermind it just happened with an USB network interface too, something else must be broken here.

I first though its related to me having RSS enabled but i disabled the sysctl in the config.xml and it still happens.

The textdump.tar file is attached to this post.

HWPROBE for 22.1 on odroid-h2+: https://bsd-hardware.info/?probe=9268d91d01
#2
Edit: Beware, this happens when trying to switch to the development version aka 22.1, it alters the url incorrectly.

Hey there, not sure how and why this happened but i just wanted to report it, in case it happens to someone else.

pkg-static: Error parsing: '/usr/local/etc/pkg/repos//OPNsense.conf': error while parsing <unknown>: line: 3, column: 55 - 'unexpected newline', character: '0x0a'


OPNsense: {
  fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
  url: "pkg+https://pkg.opnsense.org/${ABI}/21.7/latest
  signature_type: "fingerprints",
  mirror_type: "srv",
  priority: 11,
  enabled: yes
}


Its obviously missing an ", but im not sure if that happened bcs i searched for updates and then switched to Development before installing 21.7.5.
#3
21.7 Legacy Series / NTPd: Unreliable replies
September 08, 2021, 12:10:35 PM
Hey there,
i am troubleshooting slow ntp replies on my local network and i wonder if anyone could help me here.

10.0.1.1 wird verfolgt [10.0.1.1:123].
Es ist 08.09.2021 12:04:08.
12:04:08, d:+00.0001919s o:+00.7763822s  [                           | *                         ]
12:04:10, d:+00.0001735s o:+00.7764153s  [                           | *                         ]
12:04:12, d:+00.0001587s o:+00.7764470s  [                           | *                         ]
12:04:14, d:+00.0002067s o:+00.7764750s  [                           | *                         ]
12:04:16, d:+00.0008436s o:+00.7762094s  [                           | *                         ]
12:04:18, d:+00.0008367s o:+00.7762080s  [                           | *                         ]
12:04:20, d:+00.0001780s o:+00.7765668s  [                           | *                         ]
12:04:22, d:+00.0001812s o:+00.7765997s  [                           | *                         ]
12:04:24, d:+00.0001821s o:+00.7766274s  [                           | *                         ]
12:04:26, d:+00.0001996s o:+00.7766657s  [                           | *                         ]
12:04:28, d:+00.0002470s o:+00.7766922s  [                           | *                         ]
12:04:30, d:+00.0010592s o:+00.7763176s  [                           | *                         ]
12:04:32, d:+00.0002674s o:-00.0001337s  [                           *                           ]
12:04:34, Fehler: 0x800705B4
12:04:37, Fehler: 0x800705B4
12:04:40, Fehler: 0x800705B4
12:04:43, d:+00.0002189s o:-00.0001094s  [                           *                           ]
12:04:45, Fehler: 0x800705B4
12:04:48, Fehler: 0x800705B4
12:04:51, Fehler: 0x800705B4
12:04:54, d:+00.0002664s o:-00.0001332s  [                           *                           ]
12:04:56, Fehler: 0x800705B4
12:04:59, Fehler: 0x800705B4
12:05:02, Fehler: 0x800705B4
12:05:05, d:+00.0001802s o:-00.0000901s  [                           *                           ]
12:05:07, Fehler: 0x800705B4
12:05:10, Fehler: 0x800705B4
12:05:13, Fehler: 0x800705B4
12:05:16, Fehler: 0x800705B4
12:05:19, Fehler: 0x800705B4
12:05:22, Fehler: 0x800705B4
12:05:25, d:+00.0009073s o:-00.0004536s  [                           *                           ]


Not sure whats going on here, but ntpd does not seem to reply in the required manner.
No errors are logged in the ntpd syslog.

Command used to test:
w32tm /stripchart /computer:10.0.1.1
#4
Hey there,

after switching to 21.7 my freeradius stopped working with the following message:

Error: /usr/local/etc/raddb/clients.conf[2]: secret must be at least 1 character long

This was caused by missing quotes around the secret and possibly due to my secret starting with #@.

We need to add the quotation signs around the secrets when writing the config to prevent this.
#5
error: outgoing tcp: connect: Permission denied for 193.194.133.1 port 53

Getting this on a recursive unbound resolver when i visit renault.de, what is causing the permission denied?
#6
Hey there, whenever i start an upstream speed test (LAN->WAN with 200 Mbit/s) my ipv6 upstream gateway just proceeds to stop passing packets and does not respond to pings anymore for some time, even after the load dropped to 0. How do i troubleshoot this?

I tried capturing packets but i did not find anything.
The ipv6 default gateway just stops replying, is anyone experiencing something similar with 20.7.4?
Could this be network interface related? (realtek)

Throw any cool troubleshooting commands at me that you have.

Edit:
After disabling my upstream FQ Codel Pipe the issue stopped.
Im currently trying to figure out if a specific rule is causing it.

Edit2: solved
I added Interface2 and fixed the directions on my rules and it now seems to work correctly, im a bit confused here, how can the traffic shaper cause these kind of issues?
#7
SOLVED
My ubiquiti APS arp spoofed the gateway because of a broken proxy arp implementation.
This had nothing to do with opnsense, sorry for the noise!


Original report below:
Hello there,

i have been using 20.7.3 with the updated realtek drivers for some months and it never gave me any issues.
After upgrading to 20.7.4 my firewall/gateway is starting to not process packets from time to time.
The following symptoms appear when this happens:

- My 4 unifi aps cant "inform" the controller hosted on the firewall box.
- Some windows clients are able to get an DHCP Address but replies to DNS / ICMP pings dont work and i dont have any sort of internet connection.
- The firewall webinterface cant be accessed from the devices exhibiting these symptoms.

This randomly fixes itself after some time.
On windows i found the following hotfix: ipconfig /release & ipconfig /renew seems to somehow make traffic flow again.

I can verify that there are no faults logged inside opnsense, a traffic capture on the firewall system does *not* show the ICMP packets that are supposedly being sent by my clients when i test.

When i ping an affected device from opnsense, i can see the packet reach my client (traffic capture) but of course the reply from the client wont reach the firewall.

Im kinda lost here, this all started after the 20.7.4 upgrade.
Is there any way to rollback without setting up the entire device again?

Edit: I also get Loopback adapter Default Deny messages in my firewall, is this normal?

Edit2:
I attached an image of a ping test that ran from all 4 APs at the same time (slightly different start times).

As you can see the ping recovers after some time.

Kind regards & help appreciated,
MartB