Wireguard Session Manager (4th) thread
- Thread starter Martineau
- Start date
Thanks for the update, I had assumed that it would apply to all 388.2 devices. Probably a foolish question, but do you expect to receive updated SDKs for the RT-AX88U or GT-AX11000 which will allow the blog bypass or is this it?
Broadcom didn't implement it for these models. I could try backporting it, but there's no guarantee it will work (it depends if the kernel patches would be compatible with the rest of the SDK used by these two models). That's something that will have to wait later during the 388.2 development cycle if I decide to try it out.
ZebMcKayhan
Very Senior Member
Wg_manager adds packet marks in firewall to bypass flowcache for Wireguard communication already. There have been no reported issue with running Wireguard with flowcache enabled on AC86U and AX88U (to my knowledge). So if you ever decide to kick out qos then flowcache would be enabled again and you will be able to reach Gb speed on devices not going out Wireguard.
The problem is mainly with the newer AX routers that these marks dont work on them, probably because of the newer sdk so Asus/Broadcom developed this new methode.
But as you are running on AX88U then this would not be an issue for you.
if I enable flowcache and disable qos then this happens
Code:
Mar 1 16:25:47 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:47 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:47 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:47 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:57 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:57 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:58 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:58 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:59 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:25:59 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:09 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:09 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:10 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:10 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:19 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:19 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:20 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:20 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:21 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:21 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:31 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:31 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:32 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:32 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:42 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:42 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:43 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:43 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:43 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:43 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:53 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:53 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:54 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:26:54 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:00 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:00 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:04 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:04 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:05 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:05 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:15 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:15 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:16 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:16 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:20 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:20 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:27 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:27 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:27 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:27 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:38 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:38 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:38 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:38 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:41 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Mar 1 16:27:41 Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
etc...ZebMcKayhan
Very Senior Member
Yea thos are the usual msg from this incompatibility
Did you turn off pkg marks in wgm?
Could you check the firewall for them?
Have you had this in prior fw too?
ZebMcKayhan
Very Senior Member
Check command v or vx in cmd to look at your config for:
Code:
#NOSETXMARKSo marking is happening in mangle table, like:
Code:
admin@RT-AC86U-D7D8:/tmp/home/root# iptables -nvL PREROUTING -t mangle
Chain PREROUTING (policy ACCEPT 2516K packets, 2936M bytes)
pkts bytes target prot opt in out source destinati
on
0 0 MARK all -- wg12 * 0.0.0.0/0 0.0.0.0/0
/* WireGuard 'client' */ MARK xset 0x1/0x7
615K 763M MARK all -- wg11 * 0.0.0.0/0 0.0.0.0/0
/* WireGuard 'client' */ MARK xset 0x1/0x7
Code:
admin@Router:/tmp/home/root# iptables -nvL PREROUTING -t mangle
Chain PREROUTING (policy ACCEPT 205M packets, 165G bytes)
pkts bytes target prot opt in out source destination
66M 46G MARK all -- wg11 * 0.0.0.0/0 0.0.0.0/0 /* WireGuard 'client' */ MARK xset 0x1/0x7
53882 5102K MARK all -- wg21 * 0.0.0.0/0 0.0.0.0/0 /* WireGuard 'server' */ MARK xset 0x1/0x7
52M 55G MARK all -- * * 0.0.0.0/0 0.0.0.0/0 match-set wg11-mac src /* WireGuard 'client' */ MARK or 0x1000
Code:
admin@Router:/tmp/home/root# ip6tables -nvL PREROUTING -t mangle
Chain PREROUTING (policy ACCEPT 21M packets, 18G bytes)
pkts bytes target prot opt in out source destination
4645K 1752M MARK all wg11 * ::/0 ::/0 /* WireGuard 'client' */ MARK xset 0x1/0x7
9929 2221K MARK all wg21 * ::/0 ::/0 /* WireGuard 'server' */ MARK xset 0x1/0x7
5391K 6022M MARK all * * ::/0 ::/0 match-set wg11-mac src /* WireGuard 'client' */ MARK or 0x1000
Code:
# Override setting of the -t mangle FORWARD/PREROUTING '-j MARK --set-xmark 0x01/0x7' fwmarks
39 # (NOT the user Selective Routing fwmarks for Ports/IPSETs etc.)
40 # Use command 'vx' to edit this setting.
41 #NOSETXMARKZebMcKayhan
Very Senior Member
Either there is something in your setup that makes these marks ineffective. Or there is something in the firewall that changes them.
The marks are also in the forward table:
Code:
iptables -nvL FORWARD -t mangleyour ipsets are also using fw marks but it is OR:ed in so I didnt think it would be an issue
Do you have any suggestions on where to look, how to troubleshoot? if it helps
Code:
admin@Router:/tmp/home/root# iptables -nvL FORWARD -t mangle
Chain FORWARD (policy ACCEPT 188M packets, 156G bytes)
pkts bytes target prot opt in out source destination
70M 68G MARK all -- * wg11 0.0.0.0/0 0.0.0.0/0 /* WireGuard 'client' */ MARK xset 0x1/0x7
32265 1858K TCPMSS tcp -- wg11 * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
242K 15M TCPMSS tcp -- * wg11 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
221K 275M MARK all -- * wg21 0.0.0.0/0 0.0.0.0/0 /* WireGuard 'server' */ MARK xset 0x1/0x7
696 41760 TCPMSS tcp -- wg21 * 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU
768 43724 TCPMSS tcp -- * wg21 0.0.0.0/0 0.0.0.0/0 tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU
Code:
admin@Router:/tmp/home/root# ip6tables -nvL FORWARD -t mangle
Chain FORWARD (policy ACCEPT 27M packets, 24G bytes)
pkts bytes target prot opt in out source destination
6174K 6742M MARK all * wg11 ::/0 ::/0 /* WireGuard 'client' */ MARK xset 0x1/0x7
4068 321K TCPMSS tcp wg11 * ::/0 ::/0 tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
26334 2107K TCPMSS tcp * wg11 ::/0 ::/0 tcpflags: 0x06/0x02 /* WireGuard 'client' */ TCPMSS clamp to PMTU
11524 8478K MARK all * wg21 ::/0 ::/0 /* WireGuard 'server' */ MARK xset 0x1/0x7
377 30160 TCPMSS tcp wg21 * ::/0 ::/0 tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU
501 38980 TCPMSS tcp * wg21 ::/0 ::/0 tcpflags: 0x06/0x02 /* WireGuard 'server' */ TCPMSS clamp to PMTU
30373 2970K DNSFILTERF udp br+ * ::/0 ::/0 udp dpt:53
0 0 DNSFILTERF tcp br+ * ::/0 ::/0 tcp dpt:53ZebMcKayhan
Very Senior Member
Maybee confirm first that it is Wireguard generating these messages by stopping peers and see if they are gone.
Start only client
Start only server
Good call, but now to work out where to look. I stopped the WG clients and server and disabled Cake (to re-enable flow cache) and the 'bcm_mcast_blog_process' errors reappeared.
As I was routing the Unbound DNS via wireguard, I also removed
from unbound.conf; these are the ipv4 and ipv6 aliases set in wan-event which are also attached to wg11 and wg12 as policy rules
I am working through various settings, but as the errors normally take an hour or so before appearing and the rest of the family do not want to constantly hear 'just restarting the router' this may take a while. I also note that even after setting each peer to auto=n (to prevent restarting on a reboot) I can see that wgm itself is starting.
Should #'ing out
in post-mount be sufficient and/or is there a better way to stop wgm from starting on reboot, without uninstalling.
As I was routing the Unbound DNS via wireguard, I also removed
Code:
# outgoing-interface: 192.168.3.1 # routing to wan-event + wgm policy rules
# outgoing-interface: fd36:7ef1:2add:aa88:100::1 # routing to wan-event + wgm policy rulesI am working through various settings, but as the errors normally take an hour or so before appearing and the rest of the family do not want to constantly hear 'just restarting the router' this may take a while. I also note that even after setting each peer to auto=n (to prevent restarting on a reboot) I can see that wgm itself is starting.
Should #'ing out
Code:
/jffs/addons/wireguard/wg_manager.sh init "" & # WireGuard ManagerAn update: - with my setup - 388.2 alpha 2 and no flow cache WGM was unstable and unusable
I tried just using wg11 (client) and just server (wg21) and sometimes I would get the
Code:
Router kernel: [0;33;41m[ERROR mcast] bcm_mcast_blog_process,819: blog allocation failure[0m
Code:
Router kernel: potentially unexpected fatal signal 11.
Router kernel: CPU: 1 PID: 1237 Comm: httpd Tainted: P O 4.1.51 #2
Router kernel: Hardware name: Broadcom-v8A (DT)
Router kernel: task: ffffffc03dc04b00 ti: ffffffc02e18c000 task.ti: ffffffc02e18c000
Router kernel: PC is at 0xf6ac8b10
Router kernel: LR is at 0x4fdac
Router kernel: pc : [<00000000f6ac8b10>] lr : [<000000000004fdac>] pstate: 20010010
Router kernel: sp : 00000000ffd11c28
Router kernel: x12: 00000000000c3184
Router kernel: x11: 00000000f663c08a x10: 00000000ffd11dac
Router kernel: x9 : 00000000000b04fc x8 : 0000000000000000
Router kernel: x7 : 00000000ffd11d08 x6 : 00000000ffd11d14
Router kernel: x5 : 00000000004773d8 x4 : 000000000048b2a8
Router kernel: x3 : 00000000f68977f4 x2 : 0000000000000000
Router kernel: x1 : 0000000000000000 x0 : 000000000048b2a8In each case I could not finds any other syslog events concurrent with the failures.
I also think my initial thoughts on the mcast errors being unconnected to Wireguard were mistaken, as it seems that they will persist until a reboot. Running with WGM off I did not get any recurrence.
At this point I do not know whether it was a result of enabling flow cache, using alpha 2 or that I have not done a full reset and clean install since moving from 384 to 386 in January 2021. For now I have reverted to 388.1 and disabled flow cache. The next step will be a reset, manual rebuild and then start testing again (on 388.1), but that will need to wait until I have a suitable window.
Okay, next step done, full reset and manual rebuild. Enabling flow cache is definitely an issue (I had forgotten that Cake only disables runner, so was very surprised the first time the errors recurred). Comparing pre and post rebuild I no longer have a bunch of extraneous scripts installed over the last couple of years for testing 'stuff' so once I have some free time (no one else around to complain) I can start testing to see if the errors are client only, server only or both only. Only challenge is that the errors can take quite a long time to appear (over 24 hours) and I cannot find anything else in the logs (I am using scribe) that precede them.
ZebMcKayhan
Very Senior Member
So is it really an issue? I remember some of us using ac86u with flowcache enabled have got some occational blog mcast errors in the logs. I think you will find it if you trace these threads backwards. In my case it seemed linked to specific firmware and only times when my daughter was home so linked to some type of communication I guess. There were never any real issue reported and the errors were just a couple each hour. After checking a month or so later the errors were gone. Never did get to find out if firmware upgrade changed anything or if my daughter stopped using some app / playing some game.
Im using dual stack, same as you but Im running on self-assigned AA addresses and only over wireguard as I dont have ipv6 wan. And Im behind cgnat so not running any server. Still curious if your ipv6 and/or ipsets pkg marks are involved in giving you these errors?
So, except from syslog messages, do you actually experience errors, and how?
Definitely experience errors. I only started looking through the syslog because of all web connections (across all connected devices) becoming very sluggish and complaints from the family along the lines of 'what's wrong with the internet'. Symptoms do not appear to start until the mcast errors have been running for a couple of hours or more. Will not have any time to test for a few days, but when I do I will take proper notes on environment (connected devices, etc) and symptoms.
heysoundude
Part of the Furniture
quick query for those in the know - will/does netplan make using/config-ing Wireguard any easier/simpler/better?
Martineau
Part of the Furniture
A bit late..........RT-AX86U Pro v388.2_beta1 @ZebMcKayhan / @RMerlin but when I try to manually modify the 'blog' files
Code:
ll /proc/blog/
-r--r--r-- 1 admin root 0 Mar 22 20:55 skip_wireguard_network
-r--r--r-- 1 admin root 0 Mar 22 18:12 skip_wireguard_porte.g.
Code:
echo "1234 either" >> /proc/blog/skip_wireguard_port
echo: write error: Invalid argument
echo "172.16.1.1/32" >> /proc/blog/skip_wireguard_network
echo: write error: Invalid argument
Last edited:
ZebMcKayhan
Very Senior Member
Great that you pick this up and start trying!!
Could it be that fc are using this file and need to be turned off while changing them?
As I said before, I dont have the skills needed to understand the firmware code, Im more of a "try again and again untill the firmware gives up and let me do what I want" kind of guy.
Similar threads
Similar threads
Similar threads
-
New Addon - ChatAI - have a chat session with Googles Gemini AI Bot- Started by JGrana
- Replies: 2
-
Solved How do I remove WG Manager from amtm without resetting amtm?
- Started by DJones
- Replies: 2
Latest threads
-
-
Upgrading from wifi 5 to wifi 6 and looking for suggestions
- Started by Listedguru2
- Replies: 2
-
RT AX88u pro | 2.4GHz Band Disconnecting Clients Until the Network Fails
- Started by zuzuzu
- Replies: 2
-
-
RT-AX86U_PRO_3004_388.8_4 firmware MD5 checksum mismatch- Started by inakaya
- Replies: 4
Support SNBForums w/ Amazon
If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!
Sign Up For SNBForums Daily Digest
Get an update of what's new every day delivered to your mailbox. Sign up here!