At the risk of seeming really stupid....lol....I must ask again, is there a way to reset to defaults? I think I've messed around too much and just want to start over. Does the hardware reset button work?

At the risk of seeming really stupid....lol....I must ask again, is there a way to reset to defaults? I think I've messed around too much and just want to start over. Does the hardware reset button work?

Chadster766 wrote:

nyt wrote:

Sorry, the whole situation is frustrating.  Every build I've tried has the problem

Are you still using the mrvl_wlan_v7drv package with the binary hostapd, or are you building that from source?

Custom build from source.

Woops, was just looking in my BB build tree, seems in AA hostapd is built from source...

Are you doing anything special with mcwrt for the wireless?  I didn't notice anything.

nyt wrote:

Chadster766 wrote:

Custom build from source.

Woops, was just looking in my BB build tree, seems in AA hostapd is built from source...

Are you doing anything special with mcwrt for the wireless?  I didn't notice anything.

There is quite a bit different and the whole wireless driver is built from source. No wireless binary blobs remain in OpenWRT McWRT.

Chadster766 wrote:

nyt wrote:

Woops, was just looking in my BB build tree, seems in AA hostapd is built from source...

Are you doing anything special with mcwrt for the wireless?  I didn't notice anything.

There is quite a bit different and the whole wireless driver is built from source. No wireless binary blobs remain in OpenWRT McWRT.

Yes, I'm doing the same using wlan-v7_drv_7.2.5.4_fw_7.2.5.2 driver source from the GPL tree.  What else are you doing different for wireless aside from that I mean.

fcs001fcs wrote:

There are still a number of listed interfaces that would be nice to remove. Is it safe to remove "wdev0ap1" to "wdev0ap7" and "wdev0sta0" along with the matching wdev1 series?

Yeah, its safe to blacklist them. The interface blacklist is more or less a filter to decide which interfaces to display in the ui and which not. If you ever need to work with a blacklisted iface in the ui you can still enter it manually in the physical interface settings.

jow wrote:

fcs001fcs wrote:

There are still a number of listed interfaces that would be nice to remove. Is it safe to remove "wdev0ap1" to "wdev0ap7" and "wdev0sta0" along with the matching wdev1 series?

Yeah, its safe to blacklist them. The interface blacklist is more or less a filter to decide which interfaces to display in the ui and which not. If you ever need to work with a blacklisted iface in the ui you can still enter it manually in the physical interface settings.

I entered a couple of more filters to blacklist them and cleaned up the listing nicely.

For others who want to do it they are: "^wdev%dsta%d", "^wdev%dap[1-9]", "^wdev%dap%dwds%d"

FYI, [1-9] is since my setup uses "wdev0ap0" and "wdev1ap0" for lan.

nyt wrote:

Chadster766 wrote:

There is quite a bit different and the whole wireless driver is built from source. No wireless binary blobs remain in OpenWRT McWRT.

Yes, I'm doing the same using wlan-v7_drv_7.2.5.4_fw_7.2.5.2 driver source from the GPL tree.  What else are you doing different for wireless aside from that I mean.

I'm not sure of the all differences honestly. I was the first to figure out how to compile the source into a usable OpenWRT package AFAIK. You can verify that somewhere in this thread. Regardless I coded away until I got something usable

Chadster766 wrote:

nyt wrote:

Yes, I'm doing the same using wlan-v7_drv_7.2.5.4_fw_7.2.5.2 driver source from the GPL tree.  What else are you doing different for wireless aside from that I mean.

I'm not sure of the all differences honestly. I was the first to figure out how to compile the source into a usable OpenWRT package AFAIK. You can verify that somewhere in this thread. Regardless I coded away until I got something usable

I ran a diff, there are no changes to the wireless drivers or packages in your build compared to mine, aside from some fixes I added to the QoS and 6in4 packages (pasted earlier in this thread if you want to update your build so QoS will work on AA), and your build has a link to packages online...

I see some changes to patches as well, mainly wan monitor.  Nothing that should separate behavior between what I'm running and what you're running

nyt wrote:

Chadster766 wrote:

I'm not sure of the all differences honestly. I was the first to figure out how to compile the source into a usable OpenWRT package AFAIK. You can verify that somewhere in this thread. Regardless I coded away until I got something usable

I ran a diff, there are no changes to the wireless drivers or packages in your build compared to mine, aside from some fixes I added to the QoS and 6in4 packages (pasted earlier in this thread if you want to update your build so QoS will work on AA), and your build has a link to packages online...

I see some changes to patches as well, mainly wan monitor.  Nothing that should separate behavior between what I'm running and what you're running

Interesting, you could try running OpenWRT McWRT v1.0.1 binary release for a while for an apples to apples comparison. If you continue to have problems you can post it as an issue in the OpenWRT McWRT repo.

Chadster766 wrote:

nyt wrote:

I ran a diff, there are no changes to the wireless drivers or packages in your build compared to mine, aside from some fixes I added to the QoS and 6in4 packages (pasted earlier in this thread if you want to update your build so QoS will work on AA), and your build has a link to packages online...

I see some changes to patches as well, mainly wan monitor.  Nothing that should separate behavior between what I'm running and what you're running

Interesting, you could try running OpenWRT McWRT v1.0.1 binary release for a while for an apples to apples comparison. If you continue to have problems you can post it as an issue in the OpenWRT McWRT repo.

Will fire that up tonight when I can take the network down.  If you have time, can you try xferring a really large file, something to the tune of like 10 or more gigs over 5ghz and let me know if it completes without issues.  Might have to try a few times to get a lock up, but it seems to do the trick for me.

Running this config for 5ghz.  The issue was present before adding htmode, ht_capab options, noscan, and distance fields.  It still persists after as well.

config wifi-device  wdev1
    option type     marvell
    option hwmode       11anac
    option wmm          1
    option htbw         0
    option channel  157
    list ht_capab LDPC
    list ht_capab SHORT-GI-20
    list ht_capab SHORT-GI-40
    list ht_capab TX-STBC
    list ht_capab RX-STBC1
    list ht_capab DSSS_CCK-40
    option htmode HT40+
    option distance 50
    option noscan 1
    option disabled 0

dfarning wrote:

Package hosting?

I was wondering if anyone has thought about places for host McWrt binaries.

For example http://downloads.openwrt.org/barrier_br … s/generic/ hosts the full output of the bin/ directory . The install McWRT install image is currently hosted at github as part of the release page. The two most important missing pieces are the imagebuilder and packages/ directory.

It is not really a show stopper, but enabling users to install packages from a predefined repository as part of the base image would lower the barriers to entry for new users.

David

src/gz %n http://www.protechs-online.com/downloads/McWRT/packages

fcs001fcs wrote:

jow wrote:

Yeah, its safe to blacklist them. The interface blacklist is more or less a filter to decide which interfaces to display in the ui and which not. If you ever need to work with a blacklisted iface in the ui you can still enter it manually in the physical interface settings.

I entered a couple of more filters to blacklist them and cleaned up the listing nicely.

For others who want to do it they are: "^wdev%dsta%d", "^wdev%dap[1-9]", "^wdev%dap%dwds%d"

FYI, [1-9] is since my setup uses "wdev0ap0" and "wdev1ap0" for lan.

dfarning,

Could you add this procedure to the OpenWRT McWRT Wiki? We should incorporate a variation of it into the next release.

Chadster766 wrote:

fcs001fcs wrote:

I entered a couple of more filters to blacklist them and cleaned up the listing nicely.

For others who want to do it they are: "^wdev%dsta%d", "^wdev%dap[1-9]", "^wdev%dap%dwds%d"

FYI, [1-9] is since my setup uses "wdev0ap0" and "wdev1ap0" for lan.

dfarning,

Could you add this procedure to the OpenWRT McWRT Wiki? We should incorporate a variation of it into the next release.

Sure,

I am trying to visualize 'two paths' through the documentation. One for how a fully working McWrt should look... and a second path with kludges like this which will be necessary until all the kinks are worked out.

Hi,

first at all, I want to thank Chadster766 for the great work.

Second a little correction in https://github.com/Chadster766/McWRT/wiki/Building
Could someone correct the line
sudo apt-get install build-essential flex gettext git gwak libncurses5-dev make python pkg-config python unzip zlib1g-dev
                                                                                ^^^^                                                                ^^^^
It should be
sudo apt-get install build-essential flex gettext git gawk libncurses5-dev make python pkg-config unzip zlib1g-dev

Richard

I have some wifi improvements for the AA build, will post a diff shortly.

The top two are my router after boot.  Right before 1:56 I run the changes and you can see the power gain.  It's substantial.

Here goes.

It seems marvell.sh in AA does not load the power profile as it does in the BB build.  I've updated it to do so.

https://github.com/notnyt/Mamba/commit/ … 5f7b72e387

Next step is tweaking the power config

nyt wrote:

Here goes.

It seems marvell.sh in AA does not load the power profile as it does in the BB build.  I've updated it to do so.

https://github.com/notnyt/Mamba/commit/ … 5f7b72e387

Next step is tweaking the power config

I'm curious about what I'm assuming is assembly code in the Mamba_FCC_v1.2_5G4TX.ini file. How did you come up with it?

Chadster766 wrote:

nyt wrote:

Here goes.

It seems marvell.sh in AA does not load the power profile as it does in the BB build.  I've updated it to do so.

https://github.com/notnyt/Mamba/commit/ … 5f7b72e387

Next step is tweaking the power config

I'm curious about what I'm assuming is assembly code in the Mamba_FCC_v1.2_5G4TX.ini file. How did you come up with it?

Doesn't look like assembly.  First column is obviously channels, next are hex values, apparently for tx power levels.