OpenWrt Forum Archive

Topic: davidc502 1900ac 3200acm builds

The content of this topic has been archived between 26 Feb 2018 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

starcms wrote:
davidc502 wrote:
starcms wrote:

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

@david, have you modified mwlwifi (specifically mac80211.c) to keep amsdu disabled after the changes made in this commit?  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0

or is there a way for the user to now disable amsdu on their own after compilation because of that commit?

edit: Because I am currently running r5297 and amsdu is NOT disabled as it had been for months now in your builds.

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page....  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0


EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

davidc502 wrote:
starcms wrote:
davidc502 wrote:

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page....  https://github.com/kaloz/mwlwifi/commit … 3b24e78ba0


EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

By putting it in cron instead of in System-->Startup-->Local Startup (/etc/rc.local), will the 2 commands be initiated immediately upon boot instead of after all the init.d scripts?

I'll try it now and report back.

The reason I recommend disabling permanently in the driver is because there are absolutely zero side-effects from having it disabled, and it makes the router perform as it should in games (this only applies to the 1200/1900ac/acs models; the 3200acm handles AMSDU differently, isn't affected by these lines or edits, and works properly).

EDIT:

Entering:

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

in cron has no effect.  Amsdu stays enabled.  Just a guess but maybe the version of cron included doesn't support @reboot?

However, placing the two echo commands where I first mentioned works to execute them on boot.

Edit2: You can check the status with:

cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

It'll say "tx amsdu: enable" if you haven't entered the echo commands or "tx amsdu: disable" if you have entered the echo commands.  But remember, amsdu has to be disabled BEFORE any of your STAs (devices) connect or those that connected before it was changed from enabled to disabled will still have it enabled.  Hence another reason I hope @david chooses to permanently disable it as it had been for the last 6+ months approx until this commit came out.  The commit is nice because it allows AMSDU to be able to be disabled after compilation, but it doesn't give a good way of disabling it -- more like a temporary disable.

Edit3: Just curious, @david, how did you get the diff command working in busybox?  Something simple we had overlooked a couple months ago when trying it or something more complicated?

(Last edited by starcms on 20 Nov 2017, 03:54)

starcms wrote:
davidc502 wrote:
starcms wrote:

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

By putting it in cron instead of in System-->Startup-->Local Startup (/etc/rc.local), will the 2 commands be initiated immediately upon boot instead of after all the init.d scripts?

I'll try it now and report back.

The reason I recommend disabling permanently in the driver is because there are absolutely zero side-effects from having it disabled, and it makes the router perform as it should in games (this only applies to the 1200/1900ac/acs models; the 3200acm handles AMSDU differently, isn't affected by these lines or edits, and works properly).

EDIT:

Entering:

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

in cron has no effect.  Amsdu stays enabled.  Just a guess but maybe the version of cron included doesn't support @reboot?

However, placing the two echo commands where I first mentioned works to execute them on boot.

Edit2: You can check the status with:

cat /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu

It'll say "tx amsdu: enable" if you haven't entered the echo commands or "tx amsdu: disable" if you have entered the echo commands.  But remember, amsdu has to be disabled BEFORE any of your STAs (devices) connect or those that connected before it was changed from enabled to disabled will still have it enabled.  Hence another reason I hope @david chooses to permanently disable it as it had been for the last 6+ months approx until this commit came out.  The commit is nice because it allows AMSDU to be able to be disabled after compilation, but it doesn't give a good way of disabling it -- more like a temporary disable.

Edit3: Just curious, @david, how did you get the diff command working in busybox?  Something simple we had overlooked a couple months ago when trying it or something more complicated?

Appears @reboot isn't supported by busybox... Well, worth a shot anyway.

No problem making the needed changes.

Best Regards,

davidc502 wrote:
starcms wrote:
davidc502 wrote:

The code has changed to a if else statement ... When you get a chance, take a look at line 733 and tell me what ye thinks??

This commit here. Look at the bottom of the page.... 


EDIT ****   LOL  apparently you already have.

Is latency back up again with the new driver?

With the way it is now (with that commit added), AMSDU can be manually disabled by issuing the commands:

echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

However, it has to be entered after every boot, and it needs to be entered before any devices connect, or it won't disable AMSDU on them.

If you don't do that now on your latest build, the ping/high latency issue has returned by AMSDU being enabled by default.

If you want to put it back to how it was before (AMSDU always disabled), which I would highly recommend and appreciate, change/delete lines 733-737 of mac80211.c and replace with

sta_info->is_amsdu_allowed = false;

(which is most likely exactly how you had it before).

EDIT:  However, adding the two echo lines above to System-->Startup-->Local Startup (at the bottom of the page) seems to work perfectly fine with disabling AMSDU and getting rid of the ping/latency issue.  The only possible problem with doing it that way is if a device connects to the AP before those 2 lines are executed, the device won't have AMSDU disabled on it.

I have no issues doing that.

As a test... Please place the following in cron, and see if this works please.

@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy0/mwlwifi/tx_amsdu
@reboot  echo 0 > /sys/kernel/debug/ieee80211/phy1/mwlwifi/tx_amsdu

Thanks was not aware of this setting. Another option is to place a script in "/etc/hotplug.d/iface" this will run as soon as the interface is started. This should be early enough in the boot process. What is not clear to me is what would be the best directory to use (net, iface or ieee80211). I used the directory iface and this worked to disable amsdu.
See
wiki.openwrt.org/doc/techref/hotplug
for more details.

starcms wrote:
adri wrote:

@starcms

With the latest build r5389 of @davidc502, reghack2 doesn't seem to work anymore.
It patches only the world domain in /lib/modules/4.9.58/cfg80211.ko, but no longer the US domain!
As a result, the bad DFS detection still says enabled. sad
I have a WRT1900ACS v1 and previously reghack2 was able to patch both domain regulations.
Have you seen similar behaviour or a workaround?

Adri.

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

@starcms,

It seems Lede has made some changes, causing the internal regdb in cfg80211.ko to be removed.
An external regdb in /lib/firmware/regulatory.db is always used now.
See the following commit https://git.lede-project.org/?p=source. … 7e52a527c0
It seems reghack2 is no working or easily adapted.

I compiled netstat-nat and it works normally on the wrt1200ac. It would be realy kind if you could include it in your buildbot routine @davidc502 it is one of the most important tools like htop or iftop, dont really know why it is missing.

https://github.com/hnw/openwrt-packages-netstat-nat/

makedir wrote:

I compiled netstat-nat and it works normally on the wrt1200ac. It would be realy kind if you could include it in your buildbot routine @davidc502 it is one of the most important tools like htop or iftop, dont really know why it is missing.

https://github.com/hnw/openwrt-packages-netstat-nat/

This package source would need to be added to feeds prior to building. I am a bit concerned as to why this package has been around as long as it has, yet isn't a part of OpenWrt/LEDE... Meaning it isn't a part of either systems as you have to configure it separately to be included in the build.  To me, that's always a concerning red flag.

I'm familiar with netstat, but what does netstat-nat give you?  I'm assuming IPv4 nat related stats?

davidc502 wrote:
makedir wrote:

I compiled netstat-nat and it works normally on the wrt1200ac. It would be realy kind if you could include it in your buildbot routine @davidc502 it is one of the most important tools like htop or iftop, dont really know why it is missing.

https://github.com/hnw/openwrt-packages-netstat-nat/

This package source would need to be added to feeds prior to building. I am a bit concerned as to why this package has been around as long as it has, yet isn't a part of OpenWrt/LEDE... Meaning it isn't a part of either systems as you have to configure it separately to be included in the build.  To me, that's always a concerning red flag.

I'm familiar with netstat, but what does netstat-nat give you?  I'm assuming IPv4 nat related stats?

The only reason why it is not part of Lede/OpenWRT anymore is because the devs are morons and typical Linux geeks and sort everything out with "there is no maintainer for this package anymore" even if it still works fine. The same happened to murmur for example before until I asked them to put it back in.

netstat-nat is one of the most important tools in my oppinion for a router. It is also just 6kb in size. It shows all opened nat connections, with source, destination. So you can easily see and debug stuff, for example look for fishy connections. It is important if you want to see if sources and specific ports/apps go over the correct NAT connection. I have 3 routing paths and need to check this a lot, which go over tun0 tun1 or directly over wan.

example output would be for example:

root@wrtarm:~#  netstat-nat -N
Proto NATed Address                  NAT-host Address               Destination Address            State
icmp  10.0.0.145                     172.21.64.2                    google-public-dns-a.google.co
tcp   10.0.0.145:51791               172.21.64.2:51791              ec-in-x.x.net:https     ESTABLISHED
tcp   10.0.0.145:40071               172.21.64.2:40071              ams16s29-x.net:https ESTABLISHED
tcp   10.0.0.22:61735                10.0.1.199:61735               104.27.87.x:https             ESTABLISHED
tcp   10.0.0.22:61728                10.0.1.199:61728               91.123.100.x:www             ESTABLISHED
udp   10.0.0.145:53969               172.21.64.2:53969              google-public-dns-a.goo:domain ASSURED
udp   10.0.0.145:38407               172.21.64.2:38407              google-public-dns-a.goo:domain ASSURED
udp   10.0.0.2:58810                 172.21.64.2:58810              wn-in-x.net:https     ASSURED
udp   10.0.0.2:63172                 172.21.64.2:63172              prg03s06x.net:https ASSURED
udp   10.0.0.242:1900                10.0.1.199:1900                10.0.1.203:51668               UNREPLIED
makedir wrote:

The only reason why it is not part of Lede/OpenWRT anymore is because the devs are morons and typical Linux geeks and sort everything out with "there is no maintainer for this package anymore" even if it still works fine.

You are amazingly amazing. Use the fruits of their labour and insult at the same time, how boorish. It is volunteer undertaking, if there is no maintainer for packages, things get broken and orphaned, causing issues with support buildbots... Here's an idea, if you want it so bad, leap-in, take ownership with a PR, and support the package and the community; i.e. give something back.

hi
can you help in which version was "cmd 0x801d=MEMAddrAccess timed out" error fixed? i was running 4.9.20 from June with "bad" wifi driver but it was pretty stable, now i can't connect via wifi with build from 17nov (apparently, the previous one). I'd aso love to patch the system somehow directly, rather than going throught the lengthy upgrade procedure. Thanks!
UPDATE: copied 88W8964.bin and other changed files and got me /sys/kernel/debug/ieee80211/phy0/mwlwifi/info upgraded after reboot.. could be the fix (msg 368323)

(Last edited by wrtuser123 on 21 Nov 2017, 01:02)

wrtuser123 wrote:

hi
can you help in which version was "cmd 0x801d=MEMAddrAccess timed out" error fixed? i was running 4.9.20 from June with "bad" wifi driver but it was pretty stable, now i can't connect via wifi with build from 17nov (apparently, the previous one). I'd aso love to patch the system somehow directly, rather than going throught the lengthy upgrade procedure. Thanks!
UPDATE: copied 88W8964.bin and other changed files and got me /sys/kernel/debug/ieee80211/phy0/mwlwifi/info upgraded after reboot.. could be the fix (msg 368323)

From https://github.com/kaloz/mwlwifi/issues/232 it does not look like the issue was fixed.

davidc502 wrote:

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

mrm wrote:
davidc502 wrote:

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

(Last edited by davidc502 on 21 Nov 2017, 02:54)

davidc502 wrote:
mrm wrote:
davidc502 wrote:

New build is up r5389...  For ACM owners, the latest test wifi firmware has been included.

1. There was one wifi driver commit that was added.
2. mvebu: backport a kernel irq fix for setting IRQ affinity
3. There are other packages upgraded/changed... The list as usual is on the Github site.

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

Prior to reading your comment, I made a startup script change to redirect the logs to USB storage and rebooted... so I lost the "condition" that the 3200ACM was in.  I will keep an eye on the router and will investigate more when it recreates (normally 24-36 hours).  My issue looks very much like mwlwifi issue #232, so I agree with the post above... doesn't look like lede/mwlwifi have that fixed, yet.

Thank you for all the effort you put toward supporting the community; much appreciated.

Hi, thanks for all work, kernel problem in Linksys WRT1900AC is fixed (Random Reset) ? or need use old kernel versions?

Firmware Version    Lede Reboot SNAPSHOT r5113-2af10c30fe / LuCI Master (git-17.291.51172-a98548e)
Kernel Version    4.4.93
Local Time    Tue Nov 21 02:42:41 2017
Uptime    1d 15h 0m 46s

I still dont know whats causing the connection issues on my clients. I just turned on my Laptop, booted into Windows, and I had no internet connection. Chrome showed a ERR_TIMED_OUT for all pages, but after about 1 minute, all started working and is working since now. It seems some to be a weird issue with tcp and the firewall of the router. As if the router doesnt clear tcp connections properly and they time out and then are blocked. I immediately looked over ssh on the router of course and during the timeout phase on my client, no disconnects or drops happened, ping worked fine on the router itself.

edit:
I had just a random thought, and I disabled tcp/ipv6 on my Windows client, and I had no connectivity issue anymore since then so far (for the last 30 minutes). Could be coincidence, but also related. How do I disable ipv6 100% on lede? It always is such a pain and just leads to problems. Should I add a option ipv6 '0' to lan and wan in network is that the wrong way to go? I also added a net.ipv6.conf.all.disable_ipv6=1 to sysctl.conf and will monitor if this helps.

(Last edited by makedir on 21 Nov 2017, 12:53)

mrm wrote:

haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

go to LuCi web System->System,  "Logging' tab
Alter "Write system log to file" to the mounted usb location.

I've done this yesterday and it's work OK.

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

AddRemover wrote:

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

Well I guess this answers my question. I have been running DD-WRT, currently r33772 on WRT3200, without issues of any kind. Was running DD-WRT because of issues when using LEDE. Was hoping to come back as I really prefer LEDE, but with wife's health issues and a teen girl in house I need a reliable Internet connection. Reboots and loosing wireless connections are not an option for me right now and for me DD-WRT does not suffer from these.

bill1228 wrote:
AddRemover wrote:

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

Well I guess this answers my question. I have been running DD-WRT, currently r33772 on WRT3200, without issues of any kind. Was running DD-WRT because of issues when using LEDE. Was hoping to come back as I really prefer LEDE, but with wife's health issues and a teen girl in house I need a reliable Internet connection. Reboots and loosing wireless connections are not an option for me right now and for me DD-WRT does not suffer from these.

There have been conflicting stories from folks using dd-wrt as to if this problem exists or not on those systems.

zorrigas wrote:

Hi, thanks for all work, kernel problem in Linksys WRT1900AC is fixed (Random Reset) ? or need use old kernel versions?

Firmware Version    Lede Reboot SNAPSHOT r5113-2af10c30fe / LuCI Master (git-17.291.51172-a98548e)
Kernel Version    4.4.93
Local Time    Tue Nov 21 02:42:41 2017
Uptime    1d 15h 0m 46s

Just flashed into this version of the firmware:

Firmware Version    Lede Reboot SNAPSHOT r5389-358df5e4fc / LuCI Master (git-17.316.07773-4891dea)

Kernel Version    4.9.58

Uptime    0h 5m 14s   

So a little early to give an answer...however the r5113 on kernel 4.4.93 has been rock stable and has been my 'go to' firmware since released for us WRT1900AC v1 afficianados   smile

Edit "Upperdate":    Experienced a random reboot around 11min 30 sec after flashing.

Answer: Random reboot persists for those still on WRT1900AC v1  (mamba)



Cheers

Hans

(Last edited by hancor on 21 Nov 2017, 21:13)

adri wrote:
starcms wrote:
adri wrote:

@starcms

With the latest build r5389 of @davidc502, reghack2 doesn't seem to work anymore.
It patches only the world domain in /lib/modules/4.9.58/cfg80211.ko, but no longer the US domain!
As a result, the bad DFS detection still says enabled. sad
I have a WRT1900ACS v1 and previously reghack2 was able to patch both domain regulations.
Have you seen similar behaviour or a workaround?

Adri.

I haven't had a chance to try r5389 yet.  If reghack2 is only able to patch the world region on r5389, you should simply be able to change your router region to 00 (World) instead of US and get the same effect.

@starcms,

It seems Lede has made some changes, causing the internal regdb in cfg80211.ko to be removed.
An external regdb in /lib/firmware/regulatory.db is always used now.
See the following commit https://git.lede-project.org/?p=source. … 7e52a527c0
It seems reghack2 is no working or easily adapted.

It shouldn't be too difficult to recompile it to get it to work again assuming everything that was in cfg80211.ko is now in /lib/firmware/regulatory.db.  Where did you see regulatory.db mentioned in that commit?

davidc502 wrote:
bill1228 wrote:
AddRemover wrote:

damn... Rango with latest build died with the following in syslog:

Tue Nov 21 15:55:32 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK d8:6c:02:xx:xx:xx
Tue Nov 21 15:59:54 2017 kern.info kernel: [153410.780789] ieee80211 phy1: staid 2 deleted
Tue Nov 21 15:59:54 2017 daemon.info hostapd: wlan1: STA d8:6c:02:xx:xx:xx IEEE 802.11: associated (aid 2)
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.893710] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153410.936705] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.113909] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.303700] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:54 2017 kern.err kernel: [153411.503981] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.694830] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.737812] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153411.923409] ieee80211 phy1: buffer is NULL for tx done ring
Tue Nov 21 15:59:55 2017 kern.err kernel: [153412.114253] ieee80211 phy1: buffer is NULL for tx done ring

BTW, after reboot, I do not see syslog output, logread wasn't running, so I have to manually start it with /etc/init.d/log start.

Well I guess this answers my question. I have been running DD-WRT, currently r33772 on WRT3200, without issues of any kind. Was running DD-WRT because of issues when using LEDE. Was hoping to come back as I really prefer LEDE, but with wife's health issues and a teen girl in house I need a reliable Internet connection. Reboots and loosing wireless connections are not an option for me right now and for me DD-WRT does not suffer from these.

There have been conflicting stories from folks using dd-wrt as to if this problem exists or not on those systems.

ddwrt is starting to have 5ghz issues for me, on the 3200. it is unusable.the weird part is, the issue for me started when i upgraded the Linksys partition to the latest Linksys firmware.

your image is the best for me.

mrm wrote:
davidc502 wrote:
mrm wrote:

Flashed my 3200ACM with r5389 from Linksys partition a few days days ago.  From clean LEDE, I changed WAN to use PPPoE, defined a few static DHCP entries, configured the wireless, and enabled dnscrypt-proxy.  I have not noticed a reboot while using my devices, but the kernel log is full of these:

 ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
 ieee80211 phy0: return code: 0x001d
 ieee80211 phy0: timeout: 0x001d

I appear to still have "full performance" connectivity, but the LuCI interface seems abnormally sluggish.  I'd be happy to capture more logs, but haven't figured out a good way to get system logging directed to the USB storage... would need some help getting that set up.

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

This recreated for me again.  It appears to have been aligned with my returning home with my phone (Moto/Android) at 17:58:03 timestamp in the logs:

Tue Nov 21 17:52:30 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:52:36 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:52:38 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:33 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:39 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:57:41 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:02 2017 kern.info kernel: [61505.750462] ieee80211 phy1: staid 3 deleted
Tue Nov 21 17:58:02 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 17:58:03 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 17:58:11 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 17:58:17 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK b4:52:7e:3a:a4:04
Tue Nov 21 18:01:36 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.825738] ieee80211 phy1: staid 3 deleted
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.957752] ieee80211 phy0: staid 1 deleted
Tue Nov 21 18:01:36 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 1)
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.082449] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.088310] ieee80211 phy0: return code: 0x1111
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.092866] ieee80211 phy0: timeout: 0x1111
Tue Nov 21 18:01:45 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: deauthenticated due to local deauth request
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.110195] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.116080] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.120635] ieee80211 phy0: timeout: 0x001d

The last three lines repeat every 4-ish seconds, until...

Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 18:02:17 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.111803] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.117667] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.122224] ieee80211 phy0: timeout: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.125738] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.131604] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.136151] ieee80211 phy0: timeout: 0x001d

At the same time, the 3200ACM's CPU load gradually increased over 20 minutes until it plateaued at "1.87" average load.  Once there, it remained at that level.  The network connection was still usable by multiple devices (wired and wireless), but LuCI was noticeably slower.

mrm wrote:
mrm wrote:
davidc502 wrote:

If LuCi is sluggish, please go to Statistics -> Graphs -> Processor and look at the CPU %. Also take a look at load and see if it is high as well.

Thanks,

This recreated for me again.  It appears to have been aligned with my returning home with my phone (Moto/Android) at 17:58:03 timestamp in the logs:

Tue Nov 21 17:52:30 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:52:36 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:52:38 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:33 2017 daemon.notice hostapd: wlan1: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:57:39 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2b:96
Tue Nov 21 17:57:41 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:02 2017 kern.info kernel: [61505.750462] ieee80211 phy1: staid 3 deleted
Tue Nov 21 17:58:02 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 17:58:03 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:03 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:05 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 17:58:08 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 17:58:11 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 17:58:17 2017 daemon.notice hostapd: wlan0: AP-STA-POLL-OK b4:52:7e:3a:a4:04
Tue Nov 21 18:01:36 2017 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.825738] ieee80211 phy1: staid 3 deleted
Tue Nov 21 18:01:36 2017 kern.info kernel: [61719.957752] ieee80211 phy0: staid 1 deleted
Tue Nov 21 18:01:36 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 1)
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.082449] ieee80211 phy0: cmd 0x9111=SetNewStation timed out
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.088310] ieee80211 phy0: return code: 0x1111
Tue Nov 21 18:01:45 2017 kern.err kernel: [61729.092866] ieee80211 phy0: timeout: 0x1111
Tue Nov 21 18:01:45 2017 daemon.info hostapd: wlan0: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: deauthenticated due to local deauth request
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.110195] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.116080] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:01:53 2017 kern.err kernel: [61737.120635] ieee80211 phy0: timeout: 0x001d

The last three lines repeat every 4-ish seconds, until...

Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: associated (aid 3)
Tue Nov 21 18:02:16 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 IEEE 802.11: authenticated
Tue Nov 21 18:02:17 2017 daemon.notice hostapd: wlan1: AP-STA-CONNECTED f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info hostapd: wlan1: STA f0:d7:aa:c6:2e:b4 WPA: pairwise key handshake completed (RSN)
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPDISCOVER(br-lan) f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPOFFER(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPREQUEST(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4
Tue Nov 21 18:02:17 2017 daemon.info dnsmasq-dhcp[3162]: DHCPACK(br-lan) 192.168.1.10 f0:d7:aa:c6:2e:b4 Phone
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.111803] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.117667] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:23 2017 kern.err kernel: [61767.122224] ieee80211 phy0: timeout: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.125738] ieee80211 phy0: cmd 0x801d=MEMAddrAccess timed out
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.131604] ieee80211 phy0: return code: 0x001d
Tue Nov 21 18:02:27 2017 kern.err kernel: [61771.136151] ieee80211 phy0: timeout: 0x001d

At the same time, the 3200ACM's CPU load gradually increased over 20 minutes until it plateaued at "1.87" average load.  Once there, it remained at that level.  The network connection was still usable by multiple devices (wired and wireless), but LuCI was noticeably slower.

Looks like you have the problem others are having. Check this thread out:

github.com/kaloz/mwlwifi/issues/232

@yuhhaurlin is working on this problem. You may want to head on over to that  thread to post your logs and what devices you are using. I have tried to produce this bug without any results. PUT h t t ps  : // on the above link. I can't post links yet.

Later

Sorry, posts 4026 to 4025 are missing from our archive.