What's new

[ 386.10 Alpha Build(s) ] Testing available build(s) for AC models

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I wonder how ChatGPT would do if provided a git shortlog and asked to generate a readable changelog out of it
I can already guess how it will market Merlin, send us to Mars!
I grew up on C64 BBSes, not mobile texting or typing in WhatsApp :)
That's why this project is so great, and without the great you, there would be no such great project.
countless thanks!!!

Edit: typo
 
Last edited:
I can already guess how it will market Merlin, send us to Mars!

Prompt:

Code:
Can you format the following git log into a human-readable changelog, categorizing fixes and additions?

(followed here with the output from git log 386.9..HEAD)

And the result:

Here is a human-readable changelog for the given Git log, categorized by fixes and additions:

Fixes​

dropbear​

  • Fix so DROPBEAR_DSS is only forced for fuzzing (commit 8defc268c93e0bcd4abff59a778012e347b60ecb)

libcap-ng​

  • libdrop_ambient.so only exists for kernel 4.3.0 and newer, so check before installing it (commit b0390cf07051d2a16af32a45f8e471196f3f48ac)

Additions​

openssl​

  • updated to 1.1.1t (commit 70b7c1b9e625440cb1bd96a7657c06e695269b5d)

miniupnpd​

  • updated to 2.3.2 (commit ece84b1a6878b8b4c5e764c68b7b05e4c49d6783)

dnsmasq​

  • updated to 2.89 (commit 8c6f44c37cb29a41abdc0d9339a125e38572b84a)

libcap-ng​

  • added libcap-ng 0.8.3, required by OpenVPN 2.6 (commit ba2843cc8d27602d48f3a4db441deb59340cf631)

openvpn​

  • updated to 2.6.0 (commit 093f6b6a75e1c53832f8aecd97e9e00bfcaac913)

asd​

  • updated to ASD 2.0 engine (patch from Asus) (commit e8f0cde5dcb65afb7d45e1141e9e9b3719f29ca1)

documentation​

  • Updated documentation (commits b222da8f8626c98e9b56810f053216b92682519f, 1bf7e305bac9399814502b80b5705132cd42ea04, 7aeb08b0de3aa0d4b80587b303d43ec586311a07)
  • Documented the difference between regular and _rog firmware images (commit b0390cf07051d2a16af32a45f8e471196f3f48ac)
  • update default cipher lists for OpenVPN 2.6 (commit ba2843cc8d27602d48f3a4db441deb59340cf631)

rc​

  • link with frs_service.o, need read_asd_enc_file() from it (commit 3f3a270efdffb3c3f26a8baa708f6dc7374c0e71)

That still looks tons better than the changelog of a lot of things out there...
 
Prompt:

Code:
Can you format the following git log into a human-readable changelog, categorizing fixes and additions?

(followed here with the output from git log 386.9..HEAD)

And the result:

Here is a human-readable changelog for the given Git log, categorized by fixes and additions:

Fixes​

dropbear​

  • Fix so DROPBEAR_DSS is only forced for fuzzing (commit 8defc268c93e0bcd4abff59a778012e347b60ecb)

libcap-ng​

  • libdrop_ambient.so only exists for kernel 4.3.0 and newer, so check before installing it (commit b0390cf07051d2a16af32a45f8e471196f3f48ac)

Additions​

openssl​

  • updated to 1.1.1t (commit 70b7c1b9e625440cb1bd96a7657c06e695269b5d)

miniupnpd​

  • updated to 2.3.2 (commit ece84b1a6878b8b4c5e764c68b7b05e4c49d6783)

dnsmasq​

  • updated to 2.89 (commit 8c6f44c37cb29a41abdc0d9339a125e38572b84a)

libcap-ng​

  • added libcap-ng 0.8.3, required by OpenVPN 2.6 (commit ba2843cc8d27602d48f3a4db441deb59340cf631)

openvpn​

  • updated to 2.6.0 (commit 093f6b6a75e1c53832f8aecd97e9e00bfcaac913)

asd​

  • updated to ASD 2.0 engine (patch from Asus) (commit e8f0cde5dcb65afb7d45e1141e9e9b3719f29ca1)

documentation​

  • Updated documentation (commits b222da8f8626c98e9b56810f053216b92682519f, 1bf7e305bac9399814502b80b5705132cd42ea04, 7aeb08b0de3aa0d4b80587b303d43ec586311a07)
  • Documented the difference between regular and _rog firmware images (commit b0390cf07051d2a16af32a45f8e471196f3f48ac)
  • update default cipher lists for OpenVPN 2.6 (commit ba2843cc8d27602d48f3a4db441deb59340cf631)

rc​

  • link with frs_service.o, need read_asd_enc_file() from it (commit 3f3a270efdffb3c3f26a8baa708f6dc7374c0e71)
It looks like a typesetting format prepared for markdown.


only exists for kernel 4.3.0 and newer, so check before installing it (commit b0390cf07051d2a16af32a45f8e471196f3f48ac)
Is this made up by chatGPT itself? Well, I thought it was written by chatGPT itself.

But it seems to mess up the commit hash.
https://github.com/RMerl/asuswrt-merlin.ng/commit/a135fa6bf7354a9c9855c494052f3fa51c590c89
https://github.com/RMerl/asuswrt-merlin.ng/commit/b0390cf07051d2a16af32a45f8e471196f3f48ac


That still looks tons better than the changelog of a lot of things out there...
Yes, if it's a markdown-formatted log, it looks like it can be copied directly. But in the terminal, it will look bad, lacking proper indentation, newlines.


EDIT:
I would think that there is no problem with its typesetting under markdown, but there are too many errors, including incorrect classification and wrong hash.

Hopefully Google's Bard will be an improvement over it, at least there used to be someone there who thought they were talking to real people.
 
Last edited:
Last edited:
Installed on a main/AP AC86U combo this morning. A fairly minimal set of features enabled. The main router acts as a VPN server, and it does have 5 HDDs hooked up to it. Everything is working fine after ~12 hours, but I'm seeing entries like the following in the system log of the main router:

Code:
Feb 19 18:12:54 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x4
Feb 19 18:12:54 kernel: bcm63xx_nand ff801800.nand: intfc status c80000e0

I've never had those errors with any of my AC86Us.

Interestingly, I saw a stuck wl error on the AP. This was the first time I've seen this on any of my four AC86Us since I started monitoring a few weeks ago.

I read somewhere that this firmware is based on the same GPL, but something sure seems different, and it looks like its related to the GPL.
 
RT-AC-66U_B1. Dirty upgrade from 386.9 without issues. Using a USB stick with Diversion, Unbound, and YazFi. Thank you @RMerlin.
 
Is 386.10 expected to fix the nvram issue that folks have been seeing? I posted over yonder, but I'm unsure of the best place to discuss it. I'm running ASUSWRT-Merlin RT-AC68U 386.9_0, and my usual workarounds to clear up NVRAM space aren't working.

First, I review nvram show, and try to shorten settings where possible, making changes such as...

A. Remove all but one cipher for each of the OpenVPN connections:

Diff:
-vpn_server2_ncp_ciphers=CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
+vpn_server2_ncp_ciphers=AES-256-CBC

B. Use ssh-ed25519 instead of ssh-rsa for SSH access (566 bytes -> 94 bytes)

Second, I can clear up ~10kB by removing all unused settings; however, after a reboot, all/most of those empty settings are re-created. I don't recall whether that behavior was the same prior to my upgrade to 389.9. Here's the

Bash:
❯ for line in `nvram show | grep -Eo '^[^=]+\=$' | cut -d"=" -f 1`; do nvram unset $line; done
size: 62231 bytes (3305 left)

❯ nvram show | wc -c
size: 52779 bytes (12757 left)
52759

❯ nvram commit

#
# reboot router and reconnect
#

❯ nvram show | wc -c
size: 62124 bytes (3412 left)
62104

If I have to reset to factory settings and reinstall Merlin, that's enough of a pain that I would consider switching to something else. I've been happy with Merlin for many years now, but it seems like things are in flux or something? Maybe I'm supposed to be using the "gnuton" fork?
 
Is 386.10 expected to fix the nvram issue that folks have been seeing? I posted over yonder, but I'm unsure of the best place to discuss it. I'm running ASUSWRT-Merlin RT-AC68U 386.9_0, and my usual workarounds to clear up NVRAM space aren't working.
RMerlin explained the reasons why older AC routers are seeing these low NVRAM errors crop up, see this link:
Low nvram notification is nothing new, and is becoming increasingly common for that old model as it's running out of nvram space with every new firmware adding new nvram settings. It's part of why Asus is leaving it on the 386 branch most likely, as 388 probably adds even more nvram settings.

This 9 years old model is starting to show its age, with Asus having added lots of new features to it since its initial launch in 2013.

I might have to start considering removing some things from the RT-AC68U to save some nvram space. Reducing the number of OpenVPN clients would be such a thing, as each client consumes around 1 KB of nvram even while not in use.
The solution for now seems to be, do a hard factory reset after flashing 386.9 and manually reconfigure the router (don't restore from a backed up config file). Or try some of the suggestions in this thread, like this from SSH:
Code:
for line in `nvram show | grep ^[^=]*=$ `; do var=${line%*=}; nvram unset $var; done; nvram commit

Lots of people have complained about the NVRAM warning or NVRAM being low on the older AC routers recently with the more recent Asus-Merlin firmware releases. See here, here, and here. I ran into it on the Alpha 386.9, see here.
 
...
A. Remove all but one cipher for each of the OpenVPN connections:

Diff:
-vpn_server2_ncp_ciphers=CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-128-CBC:AES-256-CBC
+vpn_server2_ncp_ciphers=AES-256-CBC
I assume you've done the same for the following VPN client settings:
Code:
vpn_client_ncp_ciphers=
vpn_client1_ncp_ciphers=
vpn_client2_ncp_ciphers=
vpn_client3_ncp_ciphers=
vpn_client4_ncp_ciphers=
vpn_client5_ncp_ciphers=
Perhaps you can even set to empty strings those VPN clients that you're not using at all.

Here's a script I wrote in 2020 based on posts about some deprecated NVRAM variables that were still left behind after changes were made to the location of some VPN settings. I don't know if those NVRAM vars are still found on your router, but you might as well double-check.

EDIT:
Updated the script to include 3 OpenVPN clients for possible removal from NVRAM storage. For more details see my subsequent post following @RMerlin suggestion (post #31).

Bash:
#!/bin/sh
####################################################################
# CleanupNVRAMvars.sh
# To remove deprecated NVRAM entries for VPN & SSH keys.
# Last Modified: Martinski W. [2023-Feb-23]
####################################################################
set -u

_UnsetNVRAMvars_()
{
   if [ $# -eq 0 ] || [ -z "$1" ] ; then return 1 ; fi

   local Count="$(nvram show 2>/dev/null | grep -c "^$1")"
   if [ $Count -gt 0 ]
   then
       if [ $# -eq 2 ] && [ -n "$2" ] && \
          $doNVRAM_unset && echo && ! _PromptForYesOrNo_ "$2"
       then return 10 ; fi

       if "$firstRun" ; then firstRun=false ; echo "$SEPstr1" ; fi

       for KeyStr in $(nvram show 2>/dev/null | grep "^$1")
       do
           if ! echo "$KeyStr" | grep -qE ".*[=]+.*"
           then Count=$((--Count)); continue ; fi
           echo "KeyName: [${KeyStr%%=*}]"
           $doNVRAM_unset && nvram unset "${KeyStr%%=*}"
       done

       echo "VARs COUNT: [$Count]"
       $doNVRAM_unset && \
       echo "COUNT AFTER: [$(nvram show 2>/dev/null | grep -c "^$1")]"
       echo "$SEPstr1"
       doNVRAM_commit=$doNVRAM_unset
       return 0
   else
       echo "NVRAM variables [${1}.*] NOT FOUND."
       return 1
   fi
}

_PromptForYesOrNo_()
{
   read -n 1 -p "$1 [Y|N] N?" YESorNO
   if [ -z "$YESorNO" ] ; then return 1 ; fi
   echo
   if [ "$YESorNO" = "Y" ] ; then return 0 ; fi
   return 1
}

firstRun=true
doNVRAM_unset=false
doNVRAM_commit=false
SEPstr0="=================================================="
SEPstr1="--------------------------------------------------"

if [ $# -gt 0 ]
then
   if [ "$1" = "-unset" ]
   then doNVRAM_unset=true
   else echo "*UNKNOWN* Parameter [$1]." ; exit 1
   fi
fi

echo -n "NVRAM " ; nvram show | grep "^size: "
echo "$SEPstr0"
_UnsetNVRAMvars_ "vpn_crt_client"
_UnsetNVRAMvars_ "vpn_crt_server"
_UnsetNVRAMvars_ "sshd_.*.key="

for VPNnum in 5 4 3
do
   _UnsetNVRAMvars_ "vpn_client${VPNnum}_" "Remove ALL OpenVPN Client${VPNnum} variables?"
   [ $? -eq 10 ] && echo "Skipping OpenVPN Client${VPNnum} variables."
done
echo "$SEPstr0"
echo -n "NVRAM " ; nvram show | grep "^size: "

if ! "$doNVRAM_commit"
then echo "NOTHING to commit."
else nvram commit ; echo "Completed successfully." 
fi

#EOF#

If you run the script manually without any arguments, it will show you if the variables are found. If so, you can remove them all with the following cmd:
Bash:
./CleanupNVRAMvars.sh -unset

HTH.
 
Last edited:
You most likely don`t need five OpenVPN clients, so I would suggest clearing all the vpn_client5_* settings completely (unset them).
 
You most likely don`t need five OpenVPN clients, so I would suggest clearing all the vpn_client5_* settings completely (unset them).
That's a very good point, in particular for lower-powered routers such as the RT-AC68U.

Given your above suggestion, I went ahead and modified my script to include 3 of the OpenVPN clients for possible removal. When the script is run without arguments, it will also list all 3 sets of NVRAM variables that are found on the router *without* making any changes.

If you decide to remove one or more of the OpenVPN clients, type the following command as before:
Bash:
./CleanupNVRAMvars.sh -unset
The script will prompt you for confirmation before completely removing (i.e. nvram unset *) each set of OpenVPN client NVRAM vars. To avoid, or at least minimize, accidental confirmations the only accepted character that confirms removal is the upper-case letter Y. This way, you need a 2-key combination to really go ahead with the removal steps.

I've just run the modified script on an RT-AC68U router and found that one set of OpenVPN Client settings consists of 33 NVRAM variables and was taking 774 bytes of storage (this was for a never configured/used client). That's 165 NVRAM variables for a total of 3,870 bytes when you add up all 5 OpenVPN clients.

After talking with my relative (who owns the RT-AC68U router) and discussing the pros & cons, it was decided to remove only 3 of the OpenVPN clients. The router has now gained 2,336 bytes. That's fairly significant for a router that was already starving for NVRAM space.

I've already updated my previous post #30 with the newly-modified version of the script in case anyone is interested or wants to try it out.

My 2 cents.
 
Last edited:
Installed on a main/AP AC86U combo this morning. A fairly minimal set of features enabled. The main router acts as a VPN server, and it does have 5 HDDs hooked up to it. Everything is working fine after ~12 hours, but I'm seeing entries like the following in the system log of the main router:

Code:
Feb 19 18:12:54 kernel: bcm63xx_nand ff801800.nand: timeout waiting for command 0x4
Feb 19 18:12:54 kernel: bcm63xx_nand ff801800.nand: intfc status c80000e0

I've never had those errors with any of my AC86Us.

Interestingly, I saw a stuck wl error on the AP. This was the first time I've seen this on any of my four AC86Us since I started monitoring a few weeks ago.

I read somewhere that this firmware is based on the same GPL, but something sure seems different, and it looks like its related to the GPL.

As a follow-up, these errors go away when no one is at the location. However, there are ~15 wifi devices associated with the router even when no one is there.
 
I assume you've done the same for the following VPN client settings:
Code:
vpn_client_ncp_ciphers=
vpn_client1_ncp_ciphers=
vpn_client2_ncp_ciphers=
vpn_client3_ncp_ciphers=
vpn_client4_ncp_ciphers=
vpn_client5_ncp_ciphers=
Perhaps you can even set to empty strings those VPN clients that you're not using at all.

Here's a script I wrote in 2020 based on posts about some deprecated NVRAM variables that were still left behind after changes were made to the location of some VPN settings. I don't know if those NVRAM vars are still found on your router, but you might as well double-check.

EDIT:
Updated the script to include 3 OpenVPN clients for possible removal from NVRAM storage. For more details see my subsequent post following @RMerlin suggestion (post #31).

Bash:
#!/bin/sh
####################################################################
# CleanupNVRAMvars.sh
# To remove deprecated NVRAM entries for VPN & SSH keys.
# Last Modified: Martinski W. [2023-Feb-23]
####################################################################
set -u

_UnsetNVRAMvars_()
{
   if [ $# -eq 0 ] || [ -z "$1" ] ; then return 1 ; fi

   local Count="$(nvram show 2>/dev/null | grep -c "^$1")"
   if [ $Count -gt 0 ]
   then
       if [ $# -eq 2 ] && [ -n "$2" ] && \
          $doNVRAM_unset && echo && ! _PromptForYesOrNo_ "$2"
       then return 10 ; fi

       if "$firstRun" ; then firstRun=false ; echo "$SEPstr1" ; fi

       for KeyStr in $(nvram show 2>/dev/null | grep "^$1")
       do
           if ! echo "$KeyStr" | grep -qE ".*[=]+.*"
           then Count=$((--Count)); continue ; fi
           echo "KeyName: [${KeyStr%%=*}]"
           $doNVRAM_unset && nvram unset "${KeyStr%%=*}"
       done

       echo "VARs COUNT: [$Count]"
       $doNVRAM_unset && \
       echo "COUNT AFTER: [$(nvram show 2>/dev/null | grep -c "^$1")]"
       echo "$SEPstr1"
       doNVRAM_commit=$doNVRAM_unset
       return 0
   else
       echo "NVRAM variables [${1}.*] NOT FOUND."
       return 1
   fi
}

_PromptForYesOrNo_()
{
   read -n 1 -p "$1 [Y|N] N?" YESorNO
   if [ -z "$YESorNO" ] ; then return 1 ; fi
   echo
   if [ "$YESorNO" = "Y" ] ; then return 0 ; fi
   return 1
}

firstRun=true
doNVRAM_unset=false
doNVRAM_commit=false
SEPstr0="=================================================="
SEPstr1="--------------------------------------------------"

if [ $# -gt 0 ]
then
   if [ "$1" = "-unset" ]
   then doNVRAM_unset=true
   else echo "*UNKNOWN* Parameter [$1]." ; exit 1
   fi
fi

echo -n "NVRAM " ; nvram show | grep "^size: "
echo "$SEPstr0"
_UnsetNVRAMvars_ "vpn_crt_client"
_UnsetNVRAMvars_ "vpn_crt_server"
_UnsetNVRAMvars_ "sshd_.*.key="

for VPNnum in 5 4 3
do
   _UnsetNVRAMvars_ "vpn_client${VPNnum}_" "Remove ALL OpenVPN Client${VPNnum} variables?"
   [ $? -eq 10 ] && echo "Skipping OpenVPN Client${VPNnum} variables."
done
echo "$SEPstr0"
echo -n "NVRAM " ; nvram show | grep "^size: "

if ! "$doNVRAM_commit"
then echo "NOTHING to commit."
else nvram commit ; echo "Completed successfully."
fi

#EOF#

If you run the script manually without any arguments, it will show you if the variables are found. If so, you can remove them all with the following cmd:
Bash:
./CleanupNVRAMvars.sh -unset

HTH.
I have found this works until reboot. The keys will reappear.
 
I have found this works until reboot. The keys will reappear.
Yes, you're absolutely right. I had forgotten that back in 2020, for the RT-AC68U routers, I had set up the "old" 2020 version of the script to run during every reboot from the "/jffs/scripts/init-start" script. That's why since then, whenever I checked the free NVRAM space, the router always appeared to have just enough, and we never saw the "Low NVRAM" warning message.

I have now an updated version of the new script which can be run during reboot (*without* any prompts or console messages) from the "/jffs/scripts/init-start" script as before, but the key is that now you have to provide the list of OpenVPN client numbers as one argument (i.e. enclosed in double quotes).

For example, to only show the list of the corresponding NVRAM vars:
Bash:
./CleanupNVRAMvars.sh  "5 4 3 2 1"

To actually force the removal of only the unwanted/unused NVRAM vars:
Bash:
./CleanupNVRAMvars.sh  "5 4 3"  -forceunset

A log file "/tmp/var/tmp/CleanupNVRAMvars.LOG" is also generated so you can review it & verify the results after a reboot.

The latest script file is now available in PasteBin:
Bash:
mkdir -m 755 -p /jffs/scripts
curl -kLSs --retry 3 --retry-delay 5 --retry-connrefused pastebin.com/raw/VhqMzBtt | tr -d '\r' > /jffs/scripts/CleanupNVRAMvars.sh
chmod 755 /jffs/scripts/*.sh
 
Last edited:
Dirty upgrade from 386.9, all seems okay.

Lots of these messages in the log:
Code:
Feb 15 20:35:33 RT-AC86U kernel: br0: port 4(eth4) entered learning state
Feb 15 20:35:35 RT-AC86U kernel: br0: topology change detected, propagating
Feb 15 20:35:35 RT-AC86U kernel: br0: port 4(eth4) entered forwarding state
Feb 15 20:35:37 RT-AC86U kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link DOWN.
Feb 15 20:35:37 RT-AC86U kernel: br0: port 4(eth4) entered disabled state
Feb 15 20:35:37 RT-AC86U kernel: br1: port 5(eth4.501) entered disabled state
Feb 15 20:35:37 RT-AC86U kernel: br2: port 5(eth4.502) entered disabled state
Feb 15 20:35:39 RT-AC86U kernel: eth4 (Ext switch port: 3) (Logical Port: 11) Link UP 10 mbps full duplex
Feb 15 20:35:39 RT-AC86U kernel: br0: port 4(eth4) entered listening state
Feb 15 20:35:39 RT-AC86U kernel: br0: port 4(eth4) entered listening state
Feb 15 20:35:39 RT-AC86U kernel: br1: port 5(eth4.501) entered listening state
Feb 15 20:35:39 RT-AC86U kernel: br1: port 5(eth4.501) entered listening state
Feb 15 20:35:39 RT-AC86U kernel: br2: port 5(eth4.502) entered listening state
Feb 15 20:35:39 RT-AC86U kernel: br2: port 5(eth4.502) entered listening state
Feb 15 20:35:41 RT-AC86U kernel: br0: port 4(eth4) entered learning state
Feb 15 20:35:43 RT-AC86U kernel: br0: topology change detected, propagating
Feb 15 20:35:43 RT-AC86U kernel: br0: port 4(eth4) entered forwarding state
Feb 15 20:35:54 RT-AC86U kernel: br1: port 5(eth4.501) entered learning state
Feb 15 20:35:54 RT-AC86U kernel: br2: port 5(eth4.502) entered learning state
Feb 15 20:36:09 RT-AC86U kernel: br1: topology change detected, propagating
Feb 15 20:36:09 RT-AC86U kernel: br1: port 5(eth4.501) entered forwarding state
Feb 15 20:36:09 RT-AC86U kernel: br2: topology change detected, propagating
Feb 15 20:36:09 RT-AC86U kernel: br2: port 5(eth4.502) entered forwarding state
Also, temperatures on this 86U are 3C lower.

Those are spanning tree (STP) messages. You sure you don't have a loop somewhere in your topology? Or maybe it is just more verbose in its logging now. Generally you should only get those messages when an interface comes up or goes down.
 
Change Log:
386.10 (x-xxx-2023)
- NOTE: 386_xx releases are only for Wifi 5 (AC) models.

- CHANGED: Reduced EDNS packet size from 1280 to 1232
bytes in dnsmasq, to better work with some
upstream servers not fully supporting EDNS0.
Ahhh, that explains “Feb 24 12:05:16 dnsmasq[2237]: reducing DNS packet size for nameserver 8.8.4.4 to 1232” in my SysLog. Excellent
 
Last edited:
Those are spanning tree (STP) messages. You sure you don't have a loop somewhere in your topology? Or maybe it is just more verbose in its logging now. Generally you should only get those messages when an interface comes up or goes down.
Why would these log entries appear of spanning tree protocol is disabled?
 
Why would these log entries appear of spanning tree protocol is disabled?

The spanning tree control you can turn on and off is just for the switch ports as far as I know. Those messages are for the internal bridge interfaces. Or maybe that's the bug, STP is enabled even when you turn it off. It should really always be enabled though.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Top