[SteveJenkins]

I reported this bug today:

http://svn.dd-wrt.com/ticket/4729#comment:1

BS closed it almost immediately saying "rc_startup is started before any wireless configuration. so your setting is likelly overwritten. its no bug. its your responsiblity to use it in a way that it works if you overwrite settings manually"

I appreciate everything BS has done, but with all due respect, that really sounds like a cop out.

Based on the testing I demonstrated in that bug report, I showed it's possible to set the interference mitigation mode on eth1 via rc_startup on a single radio unit (using a sleep command workaround).

I also showed it's possible to use rc_startup to set the interference mitigation mode on eth2 on a DUAL radio unit with the workaround -- but can't find any method to set automate setting the mode for eth1 on boot.

If I can do something for the eth2 antenna via rc_startup, but can't do the exact same thing for eth1 on the same device... that sure sounds like a bug to me.

Am I off my rocker here? I'd sure like to give BS the benefit of the doubt that he just doesn't understand the issue, and I'm certainly open to understanding how I may not understand the issue. But it feels like he's trying to sweep this issue under the rug.

Thoughts?

[JAMESMTL]

Try an ipup script as that should execute after all interfaces are up. Problem solved

http://www.dd-wrt.com/wiki/index.php/Script_Execution

Another approach would be with a cron keepalive style setup where you check the status every few minutes and if your conditional check fails execute script to setup your config as you like it.

You could also try adding a sleep 5 before your commands but I would go with either a or b or a combo of the two.

FWIW I do agree with BS in that you should ensure your own timings.

Cheers

[SteveJenkins]

Thanks, JAMESMTL. I really appreciate your reply.

I agree with you that one should certainly be responsible for one's own timings. But what chaps me is that:

1) Running this command (setting interference mitigation mode) from the startup script works with single radio units.

2) Running this command from the startup script works for the eth2 adapter on dual radio units.

3) But it breaks for the eth1 adapter on dual radio units.

BS seems to be trying to convince me that it's not possible to set these options from rc_startup. And yet my tests show that those commands are indeed having an effect: the default mode is 1, yet I'm able to set it to 3 in the two successful cases above. It's ONLY the eth1 on a dual radio unit that chokes.

That said, I'll look into an ipup script. However, the fact that you suggested adding a sleep 5 before my commands implies that you didn't look closely enough at my examples, because I did use a sleep command. Still, it's not enough to set the mode for eth1 on a dual radio unit.

The inconsistent behavior is why I still believe this is a bug. Also, the fact that the GUI Command box won't allow you to set the mode for eth1 on a dual radio unit supports the notion that something is wrong inside the firmware.

Works fine with sleep command on single radio, works fine for eth2 on dual radio, but won't set from rc_startup OR the GUI Command box (long after everything is finished booting) on a dual radio unit?

That sure smells like a bug to me...

[tmo1138]

It's not a bug.. it's a behavior based on your observations that you are trying to leverage for your needs. The problem is it's not consistent. Putting "sleep" in any code (regardless of the platform) is relying on a race condition in an attempt to leverage it in your favor. That's got "code smell" and "antipattern" written all over it.

[SteveJenkins]

Hi, tmo1138. I appreciate your insight, and would love to have you continue in this conversation to help me get to the bottom of this (and I'm certainly open to this being user error if you can help show that to me).

I've done some further testing, from the command line, without any user-created scripts running, without any sleep commands, etc. And I still believe there's something strange happening with interference mitigation on eth1 on dual radio devices.

I've tested it on three different units with the most current (as of yesterday) firmware. And until someone else who actually has a dual radio device runs these same tests and tells me they get different results, it will be hard to persuade me that there's no bug. This occurs even on a default install after a 30/30/30 reset.

As submitted in http://svn.dd-wrt.com/ticket/4732 :

The interference mitigation mode for eth1 on a dual band device seems to "reset" to NULL after a seemingly random number of seconds. This appears to only occur on DUAL radio devices (2.4Ghz + 5Ghz) and ONLY for eth1 (2.4GHz).

There doesn't seem to be any consistency in how long it takes, or at what time it happens.

No user-installed scripts are running on the unit:

[JAMESMTL]

@steeve

Correct I had not re-read your ticket after reading your first post about it. However like I stated in my original post, sleep would not be my first choice in dealing with the issue.

Following your last post I checked the same commands on my r7000 which is also a dual radio unit. The default on the r7000 is mode 7 (bitmask 1,2,4) for both radios. Making changes on either eth1 or eth2 do not reset even 30 minutes later.

Is this behavior your witnessing unique to that router model, chipset, driver? Is mode 3 supported by that radio in the first place? No idea but it is not strictly a dual radio issue.

[SteveJenkins]

[imranjamadar]

[SteveJenkins]

Hi, imranjamadar. You don't need to run any script to test this if you have a dual radio Broadcom unit.

All these can be done from the command line. Please let me know what you find? Thanks

It's also possible (though unlikely) that this could be limited to only the E4200.

[SirSilentBob]

SteveJenkins,

I have a R7000. Is there anything you want me to try on my unit? I've been trying to look up info what exactly the modes do, but haven't found anything. just wondering if you knew specifically and if it was something that you could BRIEFLY explain.

Here's the configuration options for an R7000: