Project

General

Profile

Actions

Bug #11339

closed

Odd console output when WireGuard is running

Added by Marcos M almost 4 years ago. Updated over 3 years ago.

Status:
Not a Bug
Priority:
Very Low
Assignee:
-
Category:
WireGuard
Target version:
-
Start date:
01/29/2021
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
2.5.0
Affected Architecture:

Description

I'm not sure what triggers the output (see image attached), and I'm not completely certain that it's WireGuard to begin with. I have multiple pfSense VMs on ESXi, and the only common denominator I find when I see this output is that Wireguard is running. The text shows up on the system logs as well:

Jan 29 23:18:47 kernel calculated: e3d390f6a689613e6e8f19d3a168a868
Jan 29 23:18:47 kernel sent : 85c1f7b46486a309823acc2a341c86c7

As far as I can tell, there's no issue and it doesn't happen so often as to spam the logs. Hence this redmine entry is more-so to document the behavior.


Files

image.png (42 KB) image.png Marcos M, 01/29/2021 06:19 PM
Actions #1

Updated by Jim Pingle almost 4 years ago

When Steve saw it, I think he had a routing loop of sorts -- the outer WireGuard traffic was attempting to go over the WireGuard tunnel, which was set as his default gateway accidentally at the time. Was that also the case for you?

Actions #2

Updated by Marcos M almost 4 years ago

That was not the case here, though I did have the gateway selection set to automatic. However, given that the WAN gateway is another pfSense firewall's LAN IP and given there were no gateway events, I don't believe the gateway ever changed to the WG interface. The only somewhat odd configuration I have is that it's a VM with only one interface (WAN).

Actions #3

Updated by Jim Pingle almost 4 years ago

If your gateway was set to automatic there is a high chance that wireguard took over as the default gateway. At least in my testing it's prone to doing that, which is why in all the docs I mention setting a specific gateway as default before assigning.

Actions #4

Updated by Marcos M almost 4 years ago

For completeness sake, this is confirmed to be WireGuard.

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir printf module/crypto/zinc/chacha20poly1305.c 
        printf("src_len too short\n");
        printf("calculated: %16D\n", b.mac, "");
        printf("sent      : %16D\n", src + dst_len, "");

root@banshee:~/macy-freebsd-wg/sys/dev/if_wg# grep -ir -A3 -B3 'printf("calc' module/crypto/zinc/chacha20poly1305.c 
    if (likely(!ret))
        chacha20(&chacha20_state, dst, src, dst_len, simd_context);
    else {
        printf("calculated: %16D\n", b.mac, "");
        printf("sent      : %16D\n", src + dst_len, "");
    }
    memzero_explicit(&chacha20_state, sizeof(chacha20_state));

Actions #5

Updated by Christian McDonald over 3 years ago

Not seeing this on the latest kmod code

Actions #6

Updated by Renato Botelho over 3 years ago

  • Status changed from New to Not a Bug
Actions #7

Updated by Jim Pingle over 3 years ago

  • Target version deleted (Future)
Actions

Also available in: Atom PDF