Suggestion 1: Silence AP Login Attempt Failures by ExtremeFiretop · Pull Request #484 · ExtremeFiretop/MerlinAutoUpdate-Router

ExtremeFiretop · 2025-06-06T03:30:03Z

For AiMesh nodes, the password is always the same as the primary with no options to change, so we don't need the passwordloginchecker helper for those.

And for an AP, they can be set to any password that doesn't match the primary, so displaying invalid password for those seems incorrect.

Addresses this report:

Post in thread 'MerlinAU v1.4.7 - The Ultimate Firmware Auto-Updater (WEBUI + GNUTON SUPPORT!)' https://www.snbforums.com/threads/merlinau-v1-4-7-the-ultimate-firmware-auto-updater-webui-gnuton-support.91326/post-957855

For AiMesh nodes, the password is always the same as the primary with no options to change, so we don't need the passwordloginchecker helper for those. And for an AP, they can be set to any password that doesn't match the primary, so displaying invalid password for those seems incorrect.

Whoops

ExtremeFiretop · 2025-06-06T03:32:37Z

@Martinski4GitHub

Alternative is we stop detecting when to do this automatically all together and make it a switch in the settings, or we completely remove any of the AiMesh related code. Not sure how much value it provides to people, I don't mind it, I think others like @TheS1R probably don't mind it, but I don't think there's an easy way from the primary router to detect of one of the entries is an AiMesh node or an AP.

Luckily the current solution doesn't care and continues to work for the primary even if it can't login to the node, it's not a show stopper, so we just need to make it less visible and less of an annoyance to users.

Double Whoops. I was right the first time

Martinski4GitHub · 2025-06-06T09:21:22Z

@Martinski4GitHub

Alternative is we stop detecting when to do this automatically all together and make it a switch in the settings, or we completely remove any of the AiMesh related code. Not sure how much value it provides to people, I don't mind it, I think others like @TheS1R probably don't mind it, but I don't think there's an easy way from the primary router to detect of one of the entries is an AiMesh node or an AP.

Ah, so the root cause is that currently we cannot reliably detect whether the main router has an AP or an AiMesh node attached to it based on the NVRAM values being used at this point. This is very unfortunate because it means that the MerlinAU AiMesh menus showing the list of nodes is also unreliable and could be misleading if it's showing an AP that has been misidentified as an AiMesh node.

I wonder how the ASUS code correctly detects any APs vs AiMesh nodes (I assume that it does).

Luckily the current solution doesn't care and continues to work for the primary even if it can't login to the node, it's not a show stopper, so we just need to make it less visible and less of an annoyance to users.

I think another annoyance would be to have an AP wrongly listed as an AiMesh node.

I don't use AiMesh at all so I can't really check the issues myself, so I'll leave it up to you whether to remove/disable the AiMesh-related menus, or leave the functionality there knowing that it's unreliable and possibly showing misleading information. If it's left "as is" now, I'd suggest letting users know the current limitations and possible "AiMesh mode vs AP" misidentification issues.

Martinski4GitHub · 2025-06-06T09:27:06Z

MerlinAU.sh

    if [ $? -ne 0 ]
    then
-        _UpdateLoginPswdCheckHelper_ FAILURE
-        printf "\n${REDct}Login failed for AiMesh Node [$NodeIP_Address].${NOct}\n"


I think at least some kind of warning may be useful here just in case it IS an AiMesh node that's having a problem with the login attempt (for some reason).

ExtremeFiretop · 2025-06-06T11:38:42Z

@Martinski4GitHub
Alternative is we stop detecting when to do this automatically all together and make it a switch in the settings, or we completely remove any of the AiMesh related code. Not sure how much value it provides to people, I don't mind it, I think others like @TheS1R probably don't mind it, but I don't think there's an easy way from the primary router to detect of one of the entries is an AiMesh node or an AP.

Ah, so the root cause is that currently we cannot reliably detect whether the main router has an AP or an AiMesh node attached to it based on the NVRAM values being used at this point. This is very unfortunate because it means that the MerlinAU AiMesh menus showing the list of nodes is also unreliable and could be misleading if it's showing an AP that has been misidentified as an AiMesh node.

I wonder how the ASUS code correctly detects any APs vs AiMesh nodes (I assume that it does).

Luckily the current solution doesn't care and continues to work for the primary even if it can't login to the node, it's not a show stopper, so we just need to make it less visible and less of an annoyance to users.

I think another annoyance would be to have an AP wrongly listed as an AiMesh node.

I don't use AiMesh at all so I can't really check the issues myself, so I'll leave it up to you whether to remove/disable the AiMesh-related menus, or leave the functionality there knowing that it's unreliable and possibly showing misleading information. If it's left "as is" now, I'd suggest letting users know the current limitations and possible "AiMesh mode vs AP" misidentification issues.

I would keep it exactly as is, but just make the failures less annoying.
Otherwise I'd rip everything AiMesh related out for it's limited value.

ExtremeFiretop · 2025-06-06T11:40:21Z

Understanding you don't use aiMesh at all, what about APs? I think one of your cousins or family members had one setup as an AP right? When we did our most recent change regarding APs?

Any way that primary router can identify the AP instead of an AiMesh node? Any nvram values maybe? Otherwise we can also make it a switch for on and off in the settings.

TheS1R · 2025-06-06T12:33:26Z

Understanding you don't use aiMesh at all, what about APs? I think one of your cousins or family members had one setup as an AP right? When we did our most recent change regarding APs?

Any way that primary router can identify the AP instead of an AiMesh node? Any nvram values maybe? Otherwise we can also make it a switch for on and off in the settings.

In the string returned by nvram get cfg_device_list, there is a value within delimiters for each node following the MAC address. For mine, it is >1< for the primary router and >0< for each AiMesh node.

Likewise, in the string returned by nvram get asus_device_list, there is a value within delimiters for each node following the MAC address. For mine, it is >1< for the primary router and >2< for each AiMesh node.

Is it possible that these values are different for an AP? I have another router (RT-AX68U) in the spares bin that I could test with, but that won't happen until at least this afternoon.

ExtremeFiretop · 2025-06-06T12:54:06Z

Understanding you don't use aiMesh at all, what about APs? I think one of your cousins or family members had one setup as an AP right? When we did our most recent change regarding APs?
Any way that primary router can identify the AP instead of an AiMesh node? Any nvram values maybe? Otherwise we can also make it a switch for on and off in the settings.

In the string returned by nvram get cfg_device_list, there is a value within delimiters for each node following the MAC address. For mine, it is >1< for the primary router and >0< for each AiMesh node.

Likewise, in the string returned by nvram get asus_device_list, there is a value within delimiters for each node following the MAC address. For mine, it is >1< for the primary router and >2< for each AiMesh node.

Is it possible that these values are different for an AP? I have another router (RT-AX68U) in the spares bin that I could test with, but that won't happen until at least this afternoon.

The only reference I have is this from Martinski: #426 (comment)

ExtremeFiretop · 2025-06-06T12:56:36Z

Actually; thats a lie.

I also have this from the user that reported the issue initially:

nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3

TheS1R · 2025-06-06T13:07:55Z

Actually; thats a lie.

I also have this from the user that reported the issue initially:

nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3

Check your forum DM (I didn't want to publicly post MAC addresses).

ExtremeFiretop · 2025-06-06T13:13:07Z

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).

So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay

ExtremeFiretop · 2025-06-06T13:14:35Z

Unless I'm misunderstanding the readings from Martinski, maybe that was taken from the AP itself instead of the parent router?
If so that could clear up lots of my confusion.

TheS1R · 2025-06-06T13:26:38Z

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).
So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay

No, just the AP. There is a 3 to start next device string, so you are seeing 3 -- look at x in >x<.

ExtremeFiretop · 2025-06-06T13:27:46Z

@TheS1R

Can you run a test for me?

Copy and paste this function:

_GetNodeIPv4List_()
{
    # Get the value of asus_device_list #
    local ip_addresses
    local device_list="$(nvram get asus_device_list)"

    # Check if asus_device_list is not empty #
    if [ -n "$device_list" ]
    then
        # Split the device list into records and extract the IP addresses, excluding Main Router LAN IP address #
        ip_addresses="$(echo "$device_list" | tr '<' '\n' | awk -v exclude="$mainLAN_IPaddr" -F'>' '{if (NF>=4 && $3 != exclude) print $3}')"

        # Check if IP addresses are not empty #
        if [ -n "$ip_addresses" ]; then
            # Print each IP address on a separate line
            printf "%s\n" "$ip_addresses"
        else
            return 1
        fi
    else
        Say "NVRAM asus_device_list is NOT populated. No Mesh Nodes were found."
        return 1
    fi
    return 0
}

And then run it by doing:_GetNodeIPv4List_

You should get an IP output of all your nodes, including the AP

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).
So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay
No, just the AP. There is a 3 to start next device string, so you are seeing 3 -- look at x in >x<.

Exactly what I am looking at, yes. No confusion here.

ExtremeFiretop · 2025-06-06T14:20:45Z

@TheS1R

Can you run a test for me?

Copy and paste this function:

_GetNodeIPv4List_()
{
    # Get the value of asus_device_list #
    local ip_addresses
    local device_list="$(nvram get asus_device_list)"

    # Check if asus_device_list is not empty #
    if [ -n "$device_list" ]
    then
        # Split the device list into records and extract the IP addresses, excluding Main Router LAN IP address #
        ip_addresses="$(echo "$device_list" | tr '<' '\n' | awk -v exclude="$mainLAN_IPaddr" -F'>' '{if (NF>=4 && $3 != exclude) print $3}')"

        # Check if IP addresses are not empty #
        if [ -n "$ip_addresses" ]; then
            # Print each IP address on a separate line
            printf "%s\n" "$ip_addresses"
        else
            return 1
        fi
    else
        Say "NVRAM asus_device_list is NOT populated. No Mesh Nodes were found."
        return 1
    fi
    return 0
}

And then run it by doing:_GetNodeIPv4List_

You should get an IP output of all your nodes, including the AP

@TheS1R

Once you have the output and confirm it includes the AP.

Try this function instead:

_GetNodeIPv4List_()
{
    local NODE_ROLE="2"                   # keep only nodes whose last field == 2
    local device_list ip_addresses

    device_list="$(nvram get asus_device_list)"

    if [ -z "$device_list" ]; then
        Say "NVRAM asus_device_list is NOT populated. No Mesh Nodes were found."
        return 1
    fi

    ip_addresses="$(
        printf '%s\n' "$device_list" |         
        tr '<' '\n'            |               
        awk -F'>' \
            -v role="$NODE_ROLE" \
            -v exclude="$mainLAN_IPaddr" '
            NF >= 4 && $3 != exclude && $NF == role { print $3 }
        '
    )"

    if [ -n "$ip_addresses" ]; then
        printf '%s\n' "$ip_addresses"
        return 0
    fi

    # nothing matched
    return 1
}

And run it again with: _GetNodeIPv4List_

Let me know if it excludes the AP that time! :)

ExtremeFiretop · 2025-06-06T15:38:41Z

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).
So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay
No, just the AP. There is a 3 to start next device string, so you are seeing 3 -- look at x in >x<.

Ah I understand, you thought because I said lots of devices, I was talking about the 3 at the start of the nodes, but no I meant is that from all devices you have, the >3 at the end is of the test_ap is what we care about to exclude. That means that >2 is from the nodes

TheS1R · 2025-06-06T15:53:31Z

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).
So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay
No, just the AP. There is a 3 to start next device string, so you are seeing 3 -- look at x in >x<.
Ah I understand, you thought because I said lots of devices, I was talking about the 3 at the start of the nodes, but no I meant is that from all devices you have, the >3 at the end is of the test_ap is what we care about to exclude. That means that >2 is from the nodes

EXACTLY!

I just now returned home, and I will run your test shortly.

ExtremeFiretop · 2025-06-06T16:07:09Z

Actually; thats a lie.
I also have this from the user that reported the issue initially:
nvram get cfg_device_list
<RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>1<RT-AC86U>192.168.42.6>04:D9:xx:xx:xx:xx>1

nvram get asus_device_list
<3>RT-AX86U_Pro>192.168.42.5>A0:36:xx:xx:xx:xx>0>ASUS-HomeHub_42>255.255.x.x>1<3>RT-AC86U>192.168.42.6>04:D9xx:xx:xx:xx>0>2.4_Repeat>255.255.x.x>3
Check your forum DM (I didn't want to publicly post MAC addresses).
So based on your data, which is ALOT of devices, the delimiters of value would be >3< within asus_device_list?
But that does not seem to line up with the screenshot from Martinski's comment. But it does seem to line up with the output from Jimbobjay
No, just the AP. There is a 3 to start next device string, so you are seeing 3 -- look at x in >x<.
Ah I understand, you thought because I said lots of devices, I was talking about the 3 at the start of the nodes, but no I meant is that from all devices you have, the >3 at the end is of the test_ap is what we care about to exclude. That means that >2 is from the nodes
EXACTLY!

I just now returned home, and I will run your test shortly.

Once I had my second coffee and gave it some thought I understood where my communication went wrong. But I think as long as the theory holds that solution should hold. I think my confusion can be ignored since Martinskis results were from the AP itself

TheS1R · 2025-06-06T16:09:30Z

Exactly as you predicted, I think — the first run includes primary router, four (4) AiMesh nodes, and the AP. The second run includes ONLY the four (4) AiMesh nodes, removing both the primary router and the AP.

TheS1R@routS1R:/tmp/home/root# GetNodeIPv4List()

{
# Get the value of asus_device_list #
local ip_addresses
local device_list="$(nvram get asus_device_list)"
# Check if asus_device_list is not empty #
if [ -n "$device_list" ]
then
    # Split the device list into records and extract the IP addresses, excluding Main Router LAN IP address #
    ip_addresses="$(echo "$device_list" | tr '<' '\n' | awk -v exclude="$mainLAN_IPaddr" -F'>' '{if (NF>=4 && $3 != exclude) print $3}')"

    # Check if IP addresses are not empty #
    if [ -n "$ip_addresses" ]; then
        # Print each IP address on a separate line
        printf "%s\n" "$ip_addresses"
    else
        return 1
    fi
else
    Say "NVRAM asus_device_list is NOT populated. No Mesh Nodes were found."
    return 1
fi
return 0
}
TheS1R@routS1R:/tmp/home/root# GetNodeIPv4List
192.168.222.253
192.168.222.254
192.168.222.250
192.168.222.242
192.168.222.1
192.168.222.252
TheS1R@routS1R:/tmp/home/root# GetNodeIPv4List()
{
local NODE_ROLE="2" # keep only nodes whose last field == 2
local device_list ip_addresses
device_list="$(nvram get asus_device_list)"

if [ -z "$device_list" ]; then
    Say "NVRAM asus_device_list is NOT populated. No Mesh Nodes were found."
    return 1
fi

ip_addresses="$(
    printf '%s\n' "$device_list" |         
    tr '<' '\n'            |               
    awk -F'>' \
        -v role="$NODE_ROLE" \
        -v exclude="$mainLAN_IPaddr" '
        NF >= 4 && $3 != exclude && $NF == role { print $3 }
    '
)"

if [ -n "$ip_addresses" ]; then
    printf '%s\n' "$ip_addresses"
    return 0
fi

# nothing matched
return 1
}
TheS1R@routS1R:/tmp/home/root# GetNodeIPv4List
192.168.222.253
192.168.222.254
192.168.222.250
192.168.222.252
TheS1R@routS1R:/tmp/home/root#

TheS1R · 2025-06-06T16:12:11Z

Yes, it made it much more obvious when I had both AiMesh nodes AND an AP on the network!

ExtremeFiretop · 2025-06-06T16:15:08Z

@TheS1R

The finale question I have for you is how much value does this feature hold to you?
When I was working on the Second PR suggestion (removing it completely) I basically realized it's some 500 lines of code only to save... Some email spamming?

Like... What's the difference between this feature and just installing it on the nodes themselves and letting them handle it all?

Well with this feature, you get one email with a summary of all the nodes and their updates. As for without it, each node would send its own email "spamming" your inbox.

So the question is, is that worth while maintaining for the value it provides?
I don't mind the feature, but I'm not sure how much support we should provide for it before we just say it's not worth it.

TheS1R · 2025-06-06T16:19:53Z

@TheS1R

The finale question I have for you is how much value does this feature hold to you? When I was working on the Second PR suggestion (removing it completely) I basically realized it's some 500 lines of code only to save... Some email spamming?

Like... What's the difference between this feature and just installing it on the nodes themselves and letting them handle it all?

Well with this feature, you get one email with a summary of all the nodes and their updates. As for without it, each node would send its own email "spamming" your inbox.

So the question is, is that worth while maintaining for the value it provides? I don't mind the feature, but I'm not sure how much support we should provide for it before we just say it's not worth it.

I can go either way on this. I waffle back and forth between running Merlin and stock firmware on the nodes, based upon where the two baselines stand. I don't always have MerlinAU installed on the nodes, which is why the feature is helpful.

ExtremeFiretop · 2025-06-06T16:27:36Z

@TheS1R
The finale question I have for you is how much value does this feature hold to you? When I was working on the Second PR suggestion (removing it completely) I basically realized it's some 500 lines of code only to save... Some email spamming?
Like... What's the difference between this feature and just installing it on the nodes themselves and letting them handle it all?
Well with this feature, you get one email with a summary of all the nodes and their updates. As for without it, each node would send its own email "spamming" your inbox.
So the question is, is that worth while maintaining for the value it provides? I don't mind the feature, but I'm not sure how much support we should provide for it before we just say it's not worth it.

I can go either way on this. I waffle back and forth between running Merlin and stock firmware on the nodes, based upon where the two baselines stand. I don't always have MerlinAU installed on the nodes, which is why the feature is helpful.

Valid point, it can be a good way to check the firmware version on the nodes without installing MerlinAU, as well as saving the spamming.

I think considering we have a better solution (in theory for now) I'll park this idea of removing it and instead work on implementating this new function

ExtremeFiretop · 2025-06-06T16:37:07Z

@TheS1R

Thank you for the data points; this helped us better design a solution to detect the APs over the AiMesh nodes, for now I've opened a new PR and will close this one.

ExtremeFiretop added 2 commits June 5, 2025 23:28

Whoops

5cecd66

Whoops

ExtremeFiretop assigned ExtremeFiretop and Martinski4GitHub Jun 6, 2025

ExtremeFiretop added the bug Something isn't working label Jun 6, 2025

ExtremeFiretop marked this pull request as ready for review June 6, 2025 03:32

ExtremeFiretop requested a review from Martinski4GitHub as a code owner June 6, 2025 03:32

Double Whoops. I was right the first time

5e92d3e

Double Whoops. I was right the first time

Martinski4GitHub reviewed Jun 6, 2025

View reviewed changes

Martinski4GitHub changed the title ~~Silcence ap warnings~~ Silence AP Login Attempt Failures Jun 6, 2025

ExtremeFiretop changed the title ~~Silence AP Login Attempt Failures~~ Suggestion 1: Silence AP Login Attempt Failures Jun 6, 2025

ExtremeFiretop closed this Jun 6, 2025

ExtremeFiretop deleted the Silcence-AP-Warnings branch June 6, 2025 16:46

Conversation

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

Martinski4GitHub commented Jun 6, 2025

Uh oh!

Martinski4GitHub Jun 6, 2025

Choose a reason for hiding this comment

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

TheS1R commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TheS1R commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

ExtremeFiretop commented Jun 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading

TheS1R commented Jun 6, 2025 •

edited

Loading

ExtremeFiretop commented Jun 6, 2025 •

edited

Loading