I'm trying to figure out why the RT-AC folder isn't part of mips-master, seems like this doesn't make sense to me, but then again, having everything together can be counter-productive. The instructions on the main bitbucket page should be updated to include checking out the RT-AC branch.

...slightly less sure whether I can use these (I'd like to continue using the Max version):

freshtomato-K26USB-NVRAM32K_RT-N5x-MIPSR2-2018.4-IPv6-VPN

freshtomato-K26USB-NVRAM32K_RT-N5x-MIPSR2-2018.4-Max

...and fairly certain I can't use this, since it's too big:

freshtomato-K26USB-NVRAM32K_RT-N5x-MIPSR2-2018.4-Mega-VPN

Should I be okay installing the Max version listed above? I remember on the Shibby builds that the indicator LEDs were reversed on this model from similar N models, but not sure if there were other differences which would exclude using FreshTomato on the N10P. Thanks!

what conditions do u mean?
i set it up like ever the last years ... and it get's no time ... scheduled can not run without time
maybe i have to wait some hours ?!

Click to expand...

Was there anything in the syslogs that said ntpd time sync failed? I'm on 6 days+ uptime without any issue with this. Also, keep in mind, there is a space to enter your modem's local IP for your ISP hardware into, or 0.0.0.0. Otherwise, dns resolution doesn't seem to work AFAIK.

If that is the case, that they are not 2.4 kernel images, I think you'll have to build your own from source. @pedro311, can you clarify, please?

Click to expand...

You could always run a 2.6 kernel on a WRT-54G series but it's not as efficient, which is why people stayed on 2.4 builds. It's a hardware limitation but strictly performance related. The newer RT drivers may or may not work as well as the ND or... crap what did they use before ND? Original?... drivers, but something to do with packet forwarding doesn't run as efficiently on the 54G under 2.6. I kind of stopped paying attention 10 years ago when I retired my 54GL, but this much I remember, because I was curious about 2.4 vs. 2.6.

I've an issue with the connected wireless clients. Sometimes it happens that wireless clients are still shown as connected while they are already disconnected for a few hours:

I have a Asus RT-N66U running Freshtomato 2018.4 MIPSR2 K26 USB AIO-64K (I've also seen this issue on 2018.3).
I recently switched from AdvancedTomato but I cleared the NVRAM and configured everything manually again. I applied the same settings as in AdvancedTomato where I didn't encounter this issue.
I'm using this in a script to do some presence detection for our home automation to detect our phones.
Some days it works and other times it doesn't work as expected.

Please let me know if you want some part of my configuration but I guess this is most unlikely caused by configuration.

I've an issue with the connected wireless clients. Sometimes it happens that wireless clients are still shown as connected while they are already disconnected for a few hours. {snipped for brevity} I have a Asus RT-N66U running Freshtomato 2018.4 MIPSR2 K26 USB AIO-64K (I've also seen this issue on 2018.3).
I recently switched from AdvancedTomato but I cleared the NVRAM and configured everything manually again. I applied the same settings as in AdvancedTomato where I didn't encounter this issue.

Click to expand...

This problem has been reported several times over the years. The data in Device List comes from several places aggregated together, and is, generally speaking, one of the more hairy/complicated parts of Tomato. These posts by me, or threads by others, may help you:

The reason I've given you these links: look at the post dates and you'll see this isn't a new thing.

The first link includes a thorough write-up from me on the subject. However, there is no "immediate/obvious cause" found, but Toastman suspected it's something from Shibby's work (which AdvancedTomato and FreshTomato are both based on). So there may be a bug somewhere, but it's hard to know for certain because nobody is sure how to reproduce the problem 100% reliably (so that devs can reproduce it). If this problem truly doesn't happen in AdvancedTomato (for anyone), then possibly they fixed the problem (maybe intentionally, maybe by accident?). But to make an already complicated matter worse, it's suspected that there are some models of routers that might not exhibit this issue, and that the issue might be specific to MIPS (e.g. fixed on ARM). If it's not present on ARM, then it could be something like a deep wireless driver behaviour/quirk, in which case we can't do anything about it because the wireless driver is closed-source and a binary blob provided by Broadcom.

First off, have to say that most of this discussion is way, way above my head, so please feel free to dumb this down. (E.g., I only just came across the term "libsodium"and have only the vaguest understanding that it is responsible for the encryption being used.)

Currently running Shibby Tomato 1.28.0000 MIPSR2-132 K26 Max on an Asus N12. Had been using dnscrypt-proxy to dnscrypt.eu-nl, which has recently stopped working. According to the developer who maintains that server, the libsodium version running on my Tomato (DNScrypt-proxy 1.4.1) is now outdated because of a recent dnscrypt.eu upgrade --the cause of the interruption of this service. He suggested getting a newer version of Tomato.

It has been suggested to me by someone knowledgeable in these matters that, for this Asus, I might try flashing either the freshtomato-K26_RT-N5x-MIPSR2-2018.4-MiniIPv6.zip or the freshtomato-K26_RT-N5x-MIPSR2-2018.4-Max.zip, if the first doesn't work out.

Basic question is do either of these have a more recent version of the dnscrypt-proxy, and/or a more recent version of the libsodium (it's possible that a newer version of the libsodium is all that's needed), which might work now to connect to the upgraded dnscrypt.eu? And do they have a similar drop down selection of the various dnscrypt-proxy resolvers available?

The caveat of dnscrypt is whether or not v1 or v2 protocols are being used by the resolvers, v2 requires golang from what I understand. I'm not sure if any of the wl drivers or anything you could borrow from any GPL sources would be newer, etc. or not. At least the devices are staying listed vice disappearing and reappearing randomly. Not that I am having that issue with FreshTomato, but it is a weird bug in another firmware.

Successfully flashed freshtomato-K26_RT-N5x-MIPSR2-2018.4-Max to the Asus N12D1 and am now able to connect to dnscrypt.eu. But wondering why there is no longer any entry for Static DNS in Basic->Network for this version of Tomato? Has it been moved somewhere else? Have searched exhaustively, but can't find it.

This problem has been reported several times over the years. The data in Device List comes from several places aggregated together, and is, generally speaking, one of the more hairy/complicated parts of Tomato.

<snip>

The first link includes a thorough write-up from me on the subject. However, there is no "immediate/obvious cause" found...
So there may be a bug somewhere, but it's hard to know for certain because nobody is sure how to reproduce the problem 100% reliably (so that devs can reproduce it). If this problem truly doesn't happen in AdvancedTomato (for anyone), then possibly they fixed the problem (maybe intentionally, maybe by accident?).
But to make an already complicated matter worse, it's suspected that there are some models of routers that might not exhibit this issue, and that the issue might be specific to MIPS (e.g. fixed on ARM).

Click to expand...

On the routers I've used Tomato on, this problem happens on all the MIPS devices with near 100% reproducibility, and never on any of the ARM devices. Thus, for over a year, Active/Fresh Tomato hasn't seen the bug (due to being ARM-only), and Shibby has had/not had the bug because both platforms are supported. Now that Fresh Tomato is being built for both platforms, we're seeing this again.
The issue stems from wl assoclist reporting the devices as active even though they are not. I've tried all three wl lists, and they all exhibit this issue. Occasionally, a device actually will drop off the list right away when disconnected, but most of the time old devices never drop off the list until wl is restarted. Not 100% sure, but it seems that a hard disconnect (like rebooting your phone, or turning off WiFi) seems to knock a device off the list, but a soft disconnect (like device roaming out of range as someone walks away with their phone) remains stuck on the list. One of the wl commands sees the "last active" timer count higher and higher on these inactive devices, but they never actually timeout and drop off the list. I imagine a script could be written that would monitor this list and kick devices that haven't been seen any packet for say, three minutes (the ARM firmware drops devices a lot quicker than that!).

I've an issue with the connected wireless clients. Sometimes it happens that wireless clients are still shown as connected while they are already disconnected for a few hours:

I have a Asus RT-N66U running Freshtomato 2018.4 MIPSR2 K26 USB AIO-64K (I've also seen this issue on 2018.3).
I recently switched from AdvancedTomato but I cleared the NVRAM and configured everything manually again. I applied the same settings as in AdvancedTomato where I didn't encounter this issue.
I'm using this in a script to do some presence detection for our home automation to detect our phones.
Some days it works and other times it doesn't work as expected.

Please let me know if you want some part of my configuration but I guess this is most unlikely caused by configuration.

Click to expand...

I'm not sure how fixable this bug is by the developers here. I've tried bringing it up without success, as I too have done the very same thing and run into the same issue. I would recommend upgrading to an ARM-based router. The feature you're trying to use works perfectly on ARM routers. The Asus RT-N66U is MIPS based. If you don't need 5 GHz WiFi, I would recommend the Tenda AC15 router as it is inexpensive, rock stable, and powerful (but has weak 5g on Tomato).

If you've tracked the problem down to wl assoclist -- meaning that command, from the command-line, continues to show associated devices long after they've disconnected -- then that would be a wl (command/binary) or wl.ko (wireless driver) bug. My gut feeling is that it's in the latter.

Both of those are closed-source, provided by Broadcom themselves. In other words: bugs/quirks in either of those are not something that can be fixed by anyone in the Tomato project. DD-WRT (as a counterexample) may have things like this fixed in MIPS because BrainSlayer has access to the Broadcom SDK that can build the latest wireless driver (from Broadcom's own binaries and code) that Broadcom provides him; he pays them money for this type of thing (we don't know how much, but it's suspected it's in the high 4 or 5-digit range in US dollars per year). Tomato doesn't have that. The wireless drivers and binaries used vary in where they come from (it varies per model of router), but usually they come from Asus, purely in a binary form. (If you're an SDK subscriber, you sign NDAs; you cannot distribute the SDK, only the compiled/resulting binaries)

As for a workaround: I would like to know how you "kick devices" from this list. To my knowledge, wl (nor the Broadcom C-based API for wireless) cannot do this. The workaround would be pretty crappy: we'd have to store, persistently, a list of MACs that should be excluded from the result list. This list would grow infinitely depending on how many devices were floating around doing this. Storing it in NVRAM might be required (for it to be persistent), which means more wasted NVRAM (this is a bigger problem with Shibby-multiWAN-based firmwares since NVRAM usage is much higher). Try to remember: some people (for whatever reason) are using Tomato in medium-sized businesses which have hundreds of wireless clients.

It's a crummy situation no matter what, one that should really be fixed at the source (wireless driver), except Broadcom probably doesn't care about MIPS much any more, and someone would have to beg/plead with Asus to try and get Broadcom to fix the problem in the MIPS driver -- except that Asus themselves is primarily doing ARM routers now too, so what reason/inclination would they have to do this for us?

Yes, definitely confirmed at wl assoclist; in fact, Fredric showed us a screenshot revealing the same thing for him. That's where I actually had problems with the issue with my script, and then later found out its output is what caused devices to stick in the devices list (not that I cared as much about that).
Don't know about kicking devices for sure; with all its commands, I just assumed wl had a command for deauthenticating a device from the network. Of course, as long as it's not banned or the password changed, such a device would just immediately reauthenticate--but that's just the behavior we would want in this case. I guess the same script we could've written to kick old devices based on the last activity could be used for generating an MAC list without the old devices on it instead if that capability is unavailable. But writing such a script is beyond my Linux coding skills, so I just upgraded to an ARM router.

Do you still have access to the MIPS router which exhibits the aforementioned problem? If so, I have an idea of where the problem may lie (yes, in the wireless driver) but an idea of something to try that may help fix it. Please let me know.

With freshtomato-K26_RT-N5x-MIPSR2-2018.4-Max/Asus N12D1, not finding anywhere to enter Static DNS. In earlier versions I've used was located at Basic->Network. Can't find it anywhere now. If this no longer exists, how do I enter Static DNS?

On a MIPS1 device (Buffalo WHR-HP-G54) where I had installed 2018.3 beta the web interface becomes inaccessible "sometimes" after the device has been booted. The device has intermittent access to Internet (e.g. Monday to Friday).

The wireless connections do NOT clear on my Asus RT-N16 as well. I have noticed this since updateing to 128.3 of fresh tomato. Also since updateing to 128.4 MEGA-VPN 32k version. MY network speed slowes down to nothing over a few days of uptime and i have to power cycle the router to get my speed back.

Do you still have access to the MIPS router which exhibits the aforementioned problem? If so, I have an idea of where the problem may lie (yes, in the wireless driver) but an idea of something to try that may help fix it. Please let me know.

Click to expand...

Sure. Any MIPS router running Tomato Shibby or Fresh does it. Right now, I've got access to a location running a Linksys E1500 with Shibby v140 K26 firmware. Currently waiting for a device to leave as all the connections+leases are active (the router had a scheduled reboot this morning, so the lists have been cleared). But it had a half dozen dead ones on it a few days ago. The command I was thinking of earlier that showed the idle time was wl sta_info <mac>.

Do you still have access to the MIPS router which exhibits the aforementioned problem? If so, I have an idea of where the problem may lie (yes, in the wireless driver) but an idea of something to try that may help fix it. Please let me know.

Click to expand...

I can of course also help.
While reading all the replies I realized that I was using the AC6X version of Shibby's firmware before but since FreshTomato I'm using the N5X version since it gives me better a better signal strength like mentioned here: http://www.linksysinfo.org/index.php?threads/shibby-k26rt-n-vs-k26rt-ac.73527/#post-288032
So it will indeed most likely be the a driver issue since I never encountered the issue on the AC6X builds of shibby.

Sure. Any MIPS router running Tomato Shibby or Fresh does it. Right now, I've got access to a location running a Linksys E1500 with Shibby v140 K26 firmware. Currently waiting for a device to leave as all the connections+leases are active (the router had a scheduled reboot this morning, so the lists have been cleared). But it had a half dozen dead ones on it a few days ago. The command I was thinking of earlier that showed the idle time was wl sta_info <mac>.

Click to expand...

I'm making some assumptions here (that these sub-commands work on MIPS as they do ARM), so bear with me:

1. Please run wl scb_timeout and provide the output. It should be a single line with a number.

2. Wait until the problem happens. Determine through whatever (GUI, etc.) the MAC of a client which should have expired but is still showing up in wl assoclist. Then please try the following, in this order:

wl sta_info {MAC} -- should provide some general info about the client (a.k.a. STA)wl deauthenticate {MAC} -- should potentially disassociate the client (a.k.a. STA)
Wait about 5-10 full secondswl assoclist -- now see if the client (a.k.a. STA) shows up in the list or not

NOTE: it's very important you include the {MAC} argument when using the deauthenticate sub-command! Omission of the argument will cause all clients to be deauthenticated: no I'm not kidding!

If you could provide the full output from that terminal session, that'd be great. It might shed some light on what's going on. Again, I have a strong feeling this is a wireless driver bug.

If this doesn't do anything or shed light on anything, I have one more wl command up my sleeve that's a bit... "complicated"... that might work as a crappy workaround but I'm not holding my breath. I'll save that one til later.

As soon as a client tries to connect the router reboot, Netgear and Tenda are the same result.
All times clean install. I try a new clean install, the same result. Tenda back to stable, no problem.

Click to expand...

Same issue wndr4500v1 WIFI 2.4ghz & 5ghz have visible SSID's but after submitting password or even connecting with no password set reboots the wndr4500v1.
Flashed:
WNDR4500-V1.0.1.20_1.0.40 to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-AIO-64K
WNDR4500-V1.0.1.20_1.0.40 to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-VPN-64K
WNDR4500-V1.0.1.46_1.0.76 to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-AIO-64K
WNDR4500-V1.0.1.46_1.0.76 to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-VPN-64K
WNDR4500-V1.0.1.46_1.0.76 to dd-wrt to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-AIO-64K
WNDR4500-V1.0.1.46_1.0.76 to dd-wrt to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-VPN-64K
freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-AIO-64K to freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-AIO-64K
freshtomato-Netgear-WNDR4500V1_RT-AC6x-2018.4-VPN-64K downgraded to 2018.3.106-beta
Tried multiple NVRAM clearing after each failure
Alternating 2.4 & 5ghz
Different SSIDs
Different Passwords & No passwords
no luck

stock & dd-wrt firmware ok

Hope any of this information helps.
As a long time user of Toastmans build thank you.

I haven't had the wireless issues with my E4200v1. Of course, I didn't do a reset when I upgraded from 2108.2.106 beta. Both radios have the random password. Do you have serial console access? Re-creating the event and having serial access might be beneficial for troubleshooting.

I have a RT-N16, and I had been using the most recent Toastman. With Fresh Tomato, the wireless speed is definitely slower - about 30mbps on Fresh Tomato vs. up to 50-60mbps on Toastman on a theoretical max of 75mbps.

freshtomato-K26USB-NVRAM32K_RT-N5x-MIPSR2-2018.4-Mega-VPN.trx - What I was using.

I tried to change a lot of Advanced settings to match that of Toastman, but the difference is definitely there. I reflashed to Toastman and then back to Fresh Tomato again just to be sure, and the results were consistent.

I noticed that the static DNS servers set are missing in DHCP server's lease if you select "disable internal DNS". Thus Internet is not working on clients. Could you please take a look?

Click to expand...

Do you have "Use received DNS with user-entered DNS" selected, and "Use internal DNS" de-selected? That seems to work, if I recall right. I am not using static or manual DNS server addresses, that is set to "Auto" and I am having no issues.

First and foremost, thanks kille72, pedro311 and others for continuing the Tomato work.
One question to save me time:
Being the E1000v2 only 4MB of flash, Is there a MultiWAN option on those builds?

Click to expand...

Alright, I answer myself: It does (only 2WAN because it's 32KB).

Now I'm testing its behavior with 2018.4, starting with what I already figured out on a wnr3500Lv2 with 140 (which, turning off all optional features, works with MultiWAN). First things I notice:

I have my LAN cable on port3, WAN on WAN, and WAN2 on LAN4. The port order is not right, and if I choose to invert the ports order, it don't respect WAN2 is port4 (i.e. shows it unplugged). The same happens on my 140 with the other router

I did the VLAN and WAN settings exactly as it's working on the other router. But the WAN2 port (LAN4) is still acting like a LAN port. On the Status page states "Renewing...", but if I connect my Wireshark to that port, I see it serves me a LAN IP address, instead of requesting for a WAN one

I've noticed the throughput is reduced on the 5ghz band with Fast-NAT enabled through the script. Speedtests drop from 72mbps to 28mbps. Also, it seems that enabling PPTP Server slows things down too. I tried erasing the NVRAM and starting from scratch to no avail. I guess it is what it is.

I haven't had the wireless issues with my E4200v1. Of course, I didn't do a reset when I upgraded from 2108.2.106 beta. Both radios have the random password. Do you have serial console access? Re-creating the event and having serial access might be beneficial for troubleshooting.

Click to expand...

While I do own a Linksys E4200v1 running FreshTomato flawlessly. My question was regarding a Netgear wndr4500v1. Unfortunately I don't have serial access.

Not sure if any version of Tomato logs information to the syslog that would be of use, but that is also something to check, preferably via ssh or telnet access (tail -f /var/log/messages). Looks like that device already has the headers, whereas the E4200v1 doesn't, as I've had the fun first hand of de-bricking one of mine. Entirely your call if you want to crack it open and hook up the serial adapter and all, but I can understand not wanting to (unless absolutely necessary to de-brick).

2. I did the VLAN and WAN settings exactly as it's working on the other router. But the WAN2 port (LAN4) is still acting like a LAN port. On the Status page states "Renewing...", but if I connect my Wireshark to that port, I see it serves me a LAN IP address, instead of requesting for a WAN one

Click to expand...

3. I also tried to piggyback WAN2 of this router to another, with an static IP address. No joy, it can't even ping the main router, nor the other way around.

Attached Files:

So, I just got a Linksys e4200 for $3 and loaded freshtomato-E4200USB-NVRAM60K_RT-N5x-MIPSR2-2018.4-Nocat-VPN.bin This is working well. A spot of research later, I found out that there's a checkbox to disable multiwan display--It is the config link by the port pictures, and then clear a checkbox. Also disabled bandwith monitoring, ip monitoring and logging, because the point of this exercise is not needing to use router config screens often.

Very relevant for today is your mdns performance: The HP wifi multifunction, achieved both printing and scanning too; And, the Google Home Mini can play nonstop, uninterrupted the whole day through. As expected, I gave the googles a static dhcp, put those ip addresses into the qos "media" classification, and moved them up the list to just under voip.

FreshTomato has some nicer QOS refinements. It was easier to configure.

A spot of research later, I found out that there's a checkbox to disable multiwan bs--It is the config link by the port pictures, and then clear a checkbox. Classic mode engaged! Wish I'd found that much, ever so much, sooner.

Click to expand...

I'd love to know what it is you're talking about here. Screenshot, please?

I'd love to know what it is you're talking about here. Screenshot, please?

Click to expand...

Sure.
locale is basic/network
Seems to turn off only a display; however, speed-test did slightly faster ramp-up. I'd found it on old tomato documentation from ~2010~2012. I did not investigate this thoroughly.

Attached Files:

That's just disabling the ports state display, not Multi-WAN, I thought. Good to see someone else with an old E4200v1 (I have 3). I, too, stumbled across Advanced and FreshTomato, figured I would opt to give Fresh a whirl on one to help test, etc.

Sure.
locale is basic/network
Seems to turn off only a display; however, speed-test did slightly faster ramp-up. I'd found it on old tomato documentation from ~2010~2012. I did not investigate this thoroughly.

That's just disabling the ports state display, not Multi-WAN, I thought.

Click to expand...

Thanks. I was wondering if there was cause-effect reversal on my part. Apparently, multi-wan wasn't bad--just a possibility that the port monitor may do some unnecessary busy work? I don't know how to test for this very well.
Just in case I was off, I re-ran speed test and yes, slightly faster ramp-up persists and is reproducible.

Seems that this group: syslog, bandwidth monitor, ip monitor, port monitor, is enabled with the assumption of end-users spending much time staring at router config screens. That may need revised, since real use is opposite.

I'm making some assumptions here (that these sub-commands work on MIPS as they do ARM), so bear with me:

1. Please run wl scb_timeout and provide the output. It should be a single line with a number.

2. Wait until the problem happens. Determine through whatever (GUI, etc.) the MAC of a client which should have expired but is still showing up in wl assoclist. Then please try the following, in this order:

wl sta_info {MAC} -- should provide some general info about the client (a.k.a. STA)wl deauthenticate {MAC} -- should potentially disassociate the client (a.k.a. STA)
Wait about 5-10 full secondswl assoclist -- now see if the client (a.k.a. STA) shows up in the list or not

NOTE: it's very important you include the {MAC} argument when using the deauthenticate sub-command! Omission of the argument will cause all clients to be deauthenticated: no I'm not kidding!

If you could provide the full output from that terminal session, that'd be great. It might shed some light on what's going on. Again, I have a strong feeling this is a wireless driver bug.

If this doesn't do anything or shed light on anything, I have one more wl command up my sleeve that's a bit... "complicated"... that might work as a crappy workaround but I'm not holding my breath. I'll save that one til later.

Sorry it took so long to get back with you guys, but this was the first opportunity I saw where someone not usually at the location showed up and left with a phone, leaving a stuck device on the list. Here's what the Device List looks like:

So the first two devices are laptops. Tomato MIPS usually has no problem when a device's WiFi is turned off or disconnected (by toggling the switch or by the device shutting down), and you can see that both laptops show as disconnected, on the list only because of DHCP. These laptops have come and gone all week no problem.
However, devices 3 - 5 are phones. Device 3 is not preset but shows as connected anyway. It should show up just like the first two, with no RSSI, Interface, etc. Device 3 is an example of what we mean when we say that old devices are getting "stuck" on the assoclist. Below is a log of the commands I ran and the results:

None of the above commands made it go away. At the end, you can still see it on the assoclist, even though it has been inactive for 73000+ seconds (20.3 hours). The Device List page remained unchanged throughout. At this point, I didn't run any further commands, as I'm sure any of the radio resetting commands would've immediately removed it (and then I'd have to wait all over again!).

Thank you for this. This acts, more or less, that it's a wireless driver-level bug, and the workaround possibilities are getting very slim. That said, can you please provide output from just the below 3 commands?

Code:

wl sta_info {MAC}
wl deauthenticate {MAC}
wl sta_info {MAC}

Where {MAC} would be, in your above example, the 30:6A:**:**:**:F8 client.

And yes, I still have one more command up my sleeve that I haven't disclosed yet, but I want to see the above first.

What about wifi power saving modes? Phones likely impliment them, would the wl driver possibly hold on to last known values if the phone told it it was going into a low power state, and while in that state moved out of range? I'd try pinging the phone IP or initiate some sort or traffic to it, as that would prompt wl to send a wakeup if it is a low power state.. and upon not receiving a response may get it to timeout off the list.

This is normal. In UNIX, generally speaking, operative commands that do something tend to not output anything.

wl sta_info MAC
/tmp/.wxyXOihe: line 5: sta_info: not found

Click to expand...

This doesn't make any sense. You literally just ran the same command above, re: wl sta_info on the same MAC, and it worked. There's no reason it would behave like this when it just worked. Furthermore, there's no /tmp file involved that I can tell *and* in addition, there's no "line 5" -- wl is a binary program (provided by Broadcom), not a script or interpreted PL, so the output makes absolutely no sense.

In other words: something very anomalous happened in some way with regards to the last wl sta_info command you ran. And that's a bummer, because that exact output is what I need. It's the only way I can determine if wl deauthenticate is working.

These commands should be done through telnet or SSH and not Tools -> System Commands, just for the record. The latter has weird problems due to use of JavaScript and other whatnots that I do not care to deal with.

I don't have a MIPS router set up right now, only ARM, and I wireless is entirely disabled on my ARM router, so there's no way I can test this.

I will disclose my final idea/command once I get someone in this situation who can do the above 3 commands and get what I need to see.

Well, I think my theory of wifi power save may be worth investigating. Note that the sta_info from @Techie007 and @danielhaden both have the PS flag set. :

During association, an STA uses the Listen Interval parameter to indicate to the AP how many beacon intervals it shall sleep before it retrieves the queued frames from the AP. The AP shall not drop any queued frames until the STA's Listen Interval elapses.

In this scheme, an STA enters power-save mode by sending a Null frame to the AP with the Power Management bit set. From then on, the AP stores all packets destined to the STA in a per-STA queue and sets the TIM field in the beacon frame to indicate that packets destined for the STA have been queued at the AP. An STA wakes up from sleep every Listen Interval to receive the beacon frame and when it detects that the TIM field for it has been set, it sends a PS-Poll frame to the AP. In response, the AP sends the first queued frame to the STA. The STA receives the queued data frame and if the More Data field in this frame is set, it sends another PS-Poll frame to the AP. The STA continues to send PS-Poll frames to receive all the queued frames and when none are left, it goes back to sleep until the next Listen Interva

Click to expand...

Possible explanation for inability to manually de-authenticate the STA:

The AP shall not drop any queued frames until the STA's Listen Interval elapses.

Click to expand...

Possible spot for a bug or incompatibility between versions of PS mode on STA and AP causing STA to never timeout if frame is never received ( STA out of range or disconnected ) :

If folks think it's PM-related, then they can try wl PM 0 (this disables all PM) and then have the client reconnect + see what wl sta_info MAC says. They can alternately try wl PM 2 (this uses something called "FAST PM mode" -- don't ask me about the difference). I don't know what Tomato picks for this by default; I'm not sure if wl -i interface PM will actually return the current selected mode/value, or if it's a set-only command.

There is another related information command (pertaining to PM) that might shed some light on this too, but again, I'm reluctant to give them until some existing data is available. The syntax also looks a bit hairy, and I'm not even sure I'd understand the information it shows.

Also, TPC should not be relevant/involved here, just in case someone tries going down that road. That's a setting that allows the AP to dictate to the slight what its maximum transmit power should be -- different than PM.

Conversely, one could set " wl PM 1" and see if the issue duplicates using an Android phone ( while no one stated Android phones were used, this has Android written all over it with the way it handles WiFi ).

If I'm reading this right, the deauthenticate command works only while the phone is present and powered on. Also, I don't have any non-essentials enabled, such as ssh, telnet, syslog, port monitor, bandwidth monitor, ip monitor, ipv6, 5ghz. So, the command was issued from the gui.

Thank you for this. This acts, more or less, that it's a wireless driver-level bug, and the workaround possibilities are getting very slim. That said, can you please provide output from just the below 3 commands?

Code:

wl sta_info {MAC}
wl deauthenticate {MAC}
wl sta_info {MAC}

Where {MAC} would be, in your above example, the 30:6A:**:**:**:F8 client.

And yes, I still have one more command up my sleeve that I haven't disclosed yet, but I want to see the above first.

Click to expand...

That's essentially what I did in the log earlier, just with other commands in between. Anyway, here it is, with a few other commands tacked on afterwards:

@Sean B., thank you for your input as well. Pinging the IP address and ARPing the MAC address doesn't affect the sticking issue. Yes, all the phones on the network at this point are Android phones. I believe iPhones do it too, but I don't have live proof of that currently. You might be onto something with the power save function of a phone/tablet over a laptop. Wouldn't this be more of an APSD function, not the PM feature on the router's radio?
This particular router is a Linksys E1500.

Makes me wonder what's going on there. Is wl PM simply lying? Is PS actually used/honoured? Is it a different/unrelated thing (we do know there are a couple forms of "power management" involved in wireless, and so a simple abbreviation may be referring to one kind but not another; ex. APSD vs. something else). The information here is conflicting (that's not your fault @Techie007 -- I'm saying it's more the fault of Broadcom). Sean may want to poke more at this stuff (the PS-related stuff).

As for the "one more command... but it's complicated..." I mentioned back in this post: what I was looking at was wl wowl_pkt. "WoWL" stands for "Wake on Wireless LAN". Quoting the subcommand usage:

Just hear me out: the problem seems to be a driver-level bug where the wl.ko driver in the AP isn't actually honouring disassociation of the STA (client), and not honouring what scb_timeout configures. (I see scb_probe mentioned above, but that command isn't in wl's usage syntax, so possibly it's undocumented). From the driver's perspective, the client is still alive (see state of sta_info). What if having the AP send a wakeup frame would get it to, at the driver level, somehow "work itself out" about the STA in question? We know that the packet would go off into lala land (the STA isn't in range, is turned off, whatever), but maybe it would tickle something internal to the driver?

I understand the difference between a bcast (broadcast) and ucast (unicast) magic frame for wakeup. It's similar to the classic Ethernet-based WOL methodology. I don't think the final example, EAPOL (Extensible Authentication Protocol over LAN) is relevant -- this involves some RADIUS nonsense -- but the former examples might be worth trying.

Give the below a shot please. Be careful about the last wowl_pkt subcommand (look very carefully!). These are the values/fields and what they mean:

interface = wireless interface on AP (ex. eth1 (2.4GHz), eth2 (5GHz))
AA:BB:CCD:EE:FF = MAC of the STA in question
0xAABBCCDDEEFF = Hexadecimal version of the STA MAC, but without colons, and needs the 0x prefix

If this doesn't help, then other than power-saving stuff and The Really Crappy Workaround(tm), I'm literally out of ideas.

I did a write-up of The Really Crappy Workaround(tm) for this problem by excluding such devices from the Device List GUI only. I've saved it to a file so that if we get to that point I can paste the details of the work/code that needs to be done and how hairy it is. The downsides to workaround, other than the complexity, are:

1. It will not solve the problem of the clients showing up in wl assoclist (via command line) or similar tools,

2. It will not solve the problem of Tomato (specifically the wireless driver) thinking there are too many connected WiFi clients. I mention this because it comes up more and more these days, especially when people start trying to use these consumer routers in things like medium-sized companies (stop that, get yourself decent equipment! These are for homes with small numbers of people! )

Edit: I really wish there was a way to turn off emoticons when posting.

I could've sworn *.ko modules were 3.x and up kernels (sorry, couldn't resist!). I believe the wireless drivers are compiled into the kernel on Tomato and not in /lib/modules. Just kind of following along here. I'm not entirely sure if any of the Broadcom proprietary code I have in any of my GPL stuff is newer than what is in the repository, but it could be just a problematic outdated driver without any fixes for this? I really wished Broadcom wasn't such a pain in the a** to get updated / fixed drivers from.

Makes me wonder what's going on there. Is wl PM simply lying? Is PS actually used/honoured? Is it a different/unrelated thing (we do know there are a couple forms of "power management" involved in wireless, and so a simple abbreviation may be referring to one kind but not another; ex. APSD vs. something else). The information here is conflicting (that's not your fault @Techie007 -- I'm saying it's more the fault of Broadcom). Sean may want to poke more at this stuff (the PS-related stuff).

As for the "one more command... but it's complicated..." I mentioned back in this post: what I was looking at was wl wowl_pkt. "WoWL" stands for "Wake on Wireless LAN". Quoting the subcommand usage:

Just hear me out: the problem seems to be a driver-level bug where the wl.ko driver in the AP isn't actually honouring disassociation of the STA (client), and not honouring what scb_timeout configures. (I see scb_probe mentioned above, but that command isn't in wl's usage syntax, so possibly it's undocumented). From the driver's perspective, the client is still alive (see state of sta_info). What if having the AP send a wakeup frame would get it to, at the driver level, somehow "work itself out" about the STA in question? We know that the packet would go off into lala land (the STA isn't in range, is turned off, whatever), but maybe it would tickle something internal to the driver?

I understand the difference between a bcast (broadcast) and ucast (unicast) magic frame for wakeup. It's similar to the classic Ethernet-based WOL methodology. I don't think the final example, EAPOL (Extensible Authentication Protocol over LAN) is relevant -- this involves some RADIUS nonsense -- but the former examples might be worth trying.

Give the below a shot please. Be careful about the last wowl_pkt subcommand (look very carefully!). These are the values/fields and what they mean:

interface = wireless interface on AP (ex. eth1 (2.4GHz), eth2 (5GHz))
AA:BB:CCD:EE:FF = MAC of the STA in question
0xAABBCCDDEEFF = Hexadecimal version of the STA MAC, but without colons, and needs the 0x prefix

If this doesn't help, then other than power-saving stuff and The Really Crappy Workaround(tm), I'm literally out of ideas.

I did a write-up of The Really Crappy Workaround(tm) for this problem by excluding such devices from the Device List GUI only. I've saved it to a file so that if we get to that point I can paste the details of the work/code that needs to be done and how hairy it is. The downsides to workaround, other than the complexity, are:

1. It will not solve the problem of the clients showing up in wl assoclist (via command line) or similar tools,

2. It will not solve the problem of Tomato (specifically the wireless driver) thinking there are too many connected WiFi clients. I mention this because it comes up more and more these days, especially when people start trying to use these consumer routers in things like medium-sized companies (stop that, get yourself decent equipment! These are for homes with small numbers of people! )

Edit: I really wish there was a way to turn off emoticons when posting.

Shouldn't tx pkts and tx failures be counting up with some of the commands we sent?

Click to expand...

Not when the STA is in power saving mode. Remember, the AP will buffer all packets destined for the STA until it receives the PS-Poll frame from the STA. Any command you execute that would cause data to be sent to the STA will not actually transmit at this time.

I can confirm the PS flag is indeed a power save mode. With my own phone ( Android ) if I check the sta_info while the phone is actively being used, flags show as:

Code:

flags 0x1e13b: BRCM WME N_CAP AMPDU AMSDU

But once I leave the phone idle with screen off for a short time, sta_info now shows flags as:

Code:

flags 0x1e13b: BRCM WME PS N_CAP AMPDU AMSDU

@Techie007 , under Advanced->Wireless do you have APSD mode enabled or disabled?

Disable it. I have a feeling that may eliminate your issue. APSD = Automatic Power Save Delivery. This is the function that enables buffering of packets by the AP when an STA goes into sleep mode. You will have to wait until the next time one of these devices associates and leaves to determine results, as changing the wireless settings will clear the assoc list.

P.S.
It seems that a similar approach may clear the phone error, but with 2 chron jobs, such as 4:00 wl down and then 4:00 sleep 2 ; wl up
possibly

Click to expand...

It will clear the assoc list so the stuck devices no longer show, but it doesn't address the fact they get stuck. I suggest trying APSD mode disabled first, as I believe it has a chance of preventing them from getting stuck in the first place.

Also, wl down + wl up will impact every single wireless client on your network, either a full outage or a very strange outage. Two seconds of outage is enough to make people scream at IT in the region I live at. I've intentionally been avoiding discussing that "workaround" because I don't see it being feasible.

Trying Sean's APSD disable approach sounds more feasible.

Again, just to continue to remind folks, this is all because of what appears to be a MIPS Broadcom wireless driver bug. We're fighting against something we have virtually no control over.

Disable it. I have a feeling that may eliminate your issue. APSD = Automatic Power Save Delivery. This is the function that enables buffering of packets by the AP when an STA goes into sleep mode. You will have to wait until the next time one of these devices associates and leaves to determine results, as changing the wireless settings will clear the assoc list.

Click to expand...

Thanks!
I'll also give this a try. In my case it was also enabled.
I've disabled it now so let's wait and see.

@koitsu , would you have any interest in/use for the GNU project debugger ( gdb ) 7.10.1 built for ARM? I managed to get it compiled and functional, but didn't realize how in-depth of a program it is. Will take me awhile of fiddling with it to make it of any use. Thought perhaps you may have experience with it.

Note: Not trying to random post this thread, but find it fitting as almost everything discussed is diagnostic related.

Disable it. I have a feeling that may eliminate your issue. APSD = Automatic Power Save Delivery. This is the function that enables buffering of packets by the AP when an STA goes into sleep mode. You will have to wait until the next time one of these devices associates and leaves to determine results, as changing the wireless settings will clear the assoc list.

Click to expand...

I disabled it yesterday and today I have noticed that my phone is still in the assoc list while I'm not at home.
So it doesn't seem to fix the problem.
Any info I can fetch to debug?

@Sean B. Thanks for the offer. I actually use Entware on ARM, which offers gdb 8.1.1 as of present. And yeah, I'm quite familiar with gdb (been doing C since the very late 90s). While I still prefer printf()-based debugging, it depends on what the situation is.

gdb's particularly helpful if binaries/libraries built with debugging symbols (and sometimes with optimisations disabled (-O0)) + things not stripped, but most everything on Tomato is optimised and stripped to conserve space. I think some packages are built with -Os (optimise for size). So unless you're good with ARM assembly and enjoy really digging deep at that level on Tomato, I kinda stick to other methodologies. (I myself still do 65xxx assembly on a regular basis -- done quite a lot the past several days, actually -- and I did x86 back in the early 90s, but today's x86/x64 is a whole other mess. I don't have familiarity with ARM or other RISC-arch CPUs -- my brain feels full already! )

But for building your own programs, cross-compiled or via Tomatoware, where you can use something like gcc -O0 -g3 -- yes, absolutely helpful.

I disabled it yesterday and today I have noticed that my phone is still in the assoc list while I'm not at home.
So it doesn't seem to fix the problem.
Any info I can fetch to debug?

Click to expand...

In the list as in it shows an active signal with RSSI value? This is an important distinguishing factor of the issue, as a device still showing in the device list after disconnection is completely normal. It will drop off after other things expire/timeout such as DHCP lease etc. However, still showing an active connection complete with RSSI value when client is far off site is abnormal.

In the list as in it shows an active signal with RSSI value? This is an important distinguishing factor of the issue, as a device still showing in the device list after disconnection is completely normal. It will drop off after other things expire/timeout such as DHCP lease etc. However, still showing an active connection complete with RSSI value when client is far off site is abnormal.

Click to expand...

Yes, it still has an RSSI value (-85).
The output of the wl sta_info command is:

For example, on my ASUS RT-N66U...
Using shibby's tomato-K26USB-1.28.RT-N5x-MIPSR2-140-AIO-64K, a network device signal quality would be around 45.
Using freshtomato-K26USB_RT-N5x-MIPSR2-2018.4-AIO-64K, the same network device signal quality is now 100.

Is the signal quality really that much better, or is FreshTomato using a more lenient calculation for it than shibby's version?
The signal strength for all network devices are around the same values, though.

From what I recall, the older builds reported the signal quality as the difference of the RSSI value and noise floor. For example, if the RSSI is -60 dBm and noise floor -90 dBm, the signal quality would be reported as 30. Newer builds now report the quality as a percentage, which uses an internal calculation to convert the (RSSI - noise floor) value to a percentage.

Edit: I just took a look at the percentage calculation again; it doesn't use the noise floor value at all, just the RSSI value. Any value of -50 dBm or greater is considered to be 100% quality.

And that may be linked to the other issue with connected devices, perhaps. The change between using noise floor and not using it. It's quite possible to not only be a driver-related issue, but another function contributing to the issue. Probably worth testing for giggles?

I discovered that my throughput problem was an Intel client hogging the wifi. So, I went to enable the Airtime Fairness feature (wl0_atf=1) and discovered that it is missing. It seems that we're using an elder driver, not the new driver with the security updates, patches, and features like airtime fairness? Does this matter need investigated or did I do more typos while trying to make settings?

I have the Ubuntu / Debian / generic tarball source packages for the latest STA driver, but not sure if that could be conjured up easily to use to replace the current wl driver. But that looks like where the problem(s) are related to wi-fi and what needs to be looked into, perhaps.