Author Topic: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report  (Read 10746 times)

drmemory

  • Big Bull
  • *****
  • Posts: 1147
WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« on: June 14, 2011, 03:59:36 pm »

Spill your guts - tell us what you see, so we can get it fixed


buddee

  • Big Bull
  • *****
  • Posts: 547
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #1 on: June 14, 2011, 05:33:04 pm »

The only issue i have ever had with this unit using any dd-wrt build (14998 and 16783 both have this issue) is the transmit power being locked at 19dBm, when the FCC and smallnetbuilder both rate the unit @ 29dBm. And this issue has been brought to the attention of the dd-wrt dev team many times, and never gets any fix. Changing the dBm value in advanced wireless setting does nothing to change the power. Kinda sad when my WHR-HP-G54, which is a lesser model (and one buffalo is phasing out, which is a mistake IMHO), has way more power/range than my WZR-HP-G300NH. I feel the G300NH has much more potential, but for some reason its not being implemented into dd-wrt.

 

OpenWRT however does unlock its true power, but i got this unit because of dd-wrt, not because i wanted to use OpenWRT on it.


pranavsuvarna

  • Calf
  • *
  • Posts: 41
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #2 on: June 14, 2011, 05:47:53 pm »

Is it possible to install optware on the ddwrt pro firmware? And another problem i am facing is,the transmit power doesnot exceed 15dbm on my router.


mcg

  • Calf
  • *
  • Posts: 25
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #3 on: June 15, 2011, 09:47:44 am »

On 16783 I still get periodic wireless freeze. 

 

Usually I notice it when watching a netflix movie over wireless, but it happens at other times too.  Perhaps increased traffic increases the likelihood of encountering it.  The symptom is all wireless traffic stops (inbound/outboud packet counts cease to change), and the wireless light on the router goes solid and stays solid instead of slowly blinking on/off like normal.  It might happen twice in a day, or most recently it was up for 2.5 days before it froze. 

 

I'm running AP mode NG-mixed, 20MHz channel 10 with some N and some G clients.

 

The router itself does not freeze, and all gui status pages still work.  telnet in to down/up the radio will start the wireless working again without rebooting the router.

 

Automatic nightly reboot of router decreases likelihood of wireless freezes, but does not eliminate them.   Watchdog to ping an always-on wireless client will help automatically recover by rebooting router, but that watchdog detection time plus full reboot time is unacceptable for watching streaming movies.

 

This wireless freeze bug has existed since 14998 and continues to exist in 16783.

 

I would be happy to collect more information about the freeze if you can provide instructions on how to capture useful diagnostic information when the freeze occurs.

 


drmemory

  • Big Bull
  • *****
  • Posts: 1147
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #4 on: June 15, 2011, 01:04:54 pm »

Collecting data from the logs could be useful, the logs might catch the last activity immediately before the freeze. thank you for offering.


mcg

  • Calf
  • *
  • Posts: 25
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #5 on: June 15, 2011, 07:09:05 pm »

I will capture the log next time it freezes. 

 

Browsing DD-WRT's buglist, I believe this is the same issue as DD-WRT tickets #1500, #1571, #1636, etc.

 

 

 


mcg

  • Calf
  • *
  • Posts: 25
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #6 on: June 18, 2011, 12:56:37 pm »

Took a little longer to freeze -- 2 days this time. 

 

Jun 17 17:41:59 BUFFALO daemon.info hostapd: ath0: STA 00:11:xx:xx:xx:3a WPA: group key handshake completed (RSN)
Jun 17 17:41:59 BUFFALO daemon.info hostapd: ath0: STA 00:1e:xx:xx:xx:28 WPA: group key handshake completed (RSN)
Jun 17 18:41:59 BUFFALO daemon.info hostapd: ath0: STA 00:11:xx:xx:xx:3a WPA: group key handshake completed (RSN)
Jun 17 18:41:59 BUFFALO daemon.info hostapd: ath0: STA 00:1e:xx:xx:xx:28 WPA: group key handshake completed (RSN)
Jun 17 19:38:38 BUFFALO kern.warn kernel: [212221.660000] Sending cwmmode action frame to ff:ff:ff:ff:ff:ff
Jun 17 19:42:02 BUFFALO daemon.info hostapd: ath0: STA 00:11:xx:xx:xx:3a IEEE 802.11: deauthenticated due to local deauth request
Jun 17 19:42:02 BUFFALO daemon.info hostapd: ath0: STA 00:1e:xx:xx:xx:28 IEEE 802.11: deauthenticated due to local deauth request
Jun 17 19:42:02 BUFFALO daemon.info hostapd: ath0: STA 00:11:xx:xx:xx:3a IEEE 802.11: disassociated
Jun 17 19:42:02 BUFFALO daemon.info hostapd: ath0: STA 00:1e:xx:xx:xx:28 IEEE 802.11: disassociated

The bold line represents the time of the freeze.  All wireless clients disconnected, none could reconnect, router still works for wired clients.

 

During the freeze inSSIDer was showing the router with extremely low barely detectable power output, and only occasional blips at that.  Neighbors routers over 500ft away showed higher power than this one inside the house.

 

Also during the freeze, the wireless status page would show slowly increasing transmitted packets, as if router thinks it is still transmitting SSID.

 

iwlist ath0 txpower showed 19dBm as did the router's wireless status page, but it was definitely not spewing that much power.

 

iwconfig ath0 txpower 22 had no effect and subsequent iwlist txpower still showed 19, but inSSIDer showed it was almost nothing.

 

Now here comes the fun part.  I tried this command I found recently in dd-wrt forums:

 

80211n_wlanconfig ath0 set_txpowercap 00:xx:xx:xx:xx:AC 22

 

And magically the power came back up (iwlist txpower showed new 22dBm value) and all the clients instantly began reconnected after being disconnected for over 12 hours.   And inSSIDer showed a solid healthy signal coming from the router again.

 

Here is what the log shows just before and after the reconnect:

 

Jun 18 12:20:36 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:20:37 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:20:38 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: deauthenticated due to local deauth request
Jun 18 12:20:38 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: disassociated
Jun 18 12:20:42 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:20:45 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: deauthenticated due to local deauth request
Jun 18 12:20:45 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: disassociated
Jun 18 12:22:07 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:22:10 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: deauthenticated due to local deauth request
Jun 18 12:22:10 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: disassociated
Jun 18 12:23:16 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:23:19 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: deauthenticated due to local deauth request
Jun 18 12:23:19 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: disassociated
Jun 18 12:24:32 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:24:35 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: deauthenticated due to local deauth request
Jun 18 12:24:35 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: disassociated
Jun 18 12:25:14 BUFFALO kern.warn kernel: [272617.470000] ic->ic_cwm.cw_width :1, ic->ic_cwm.cw_extoffset: 0
Jun 18 12:25:15 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:28 IEEE 802.11: associated
Jun 18 12:25:15 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:28 RADIUS: starting accounting session 00000003-0000001A
Jun 18 12:25:15 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:28 WPA: pairwise key handshake completed (RSN)
Jun 18 12:25:59 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:3a IEEE 802.11: associated
Jun 18 12:25:59 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:3a RADIUS: starting accounting session 00000003-0000001B
Jun 18 12:25:59 BUFFALO daemon.info hostapd: ath0: STA 00:xx:xx:xx:xx:3a WPA: pairwise key handshake completed (RSN)
Jun 18 12:26:35 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 IEEE 802.11: associated
Jun 18 12:26:35 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 RADIUS: starting accounting session 00000003-0000001C
Jun 18 12:26:35 BUFFALO daemon.info hostapd: ath0: STA 4c:xx:xx:xx:xx:92 WPA: pairwise key handshake completed (RSN)
Jun 18 12:26:38 BUFFALO kern.warn kernel: [272701.490000] Sending cwmmode action frame to ff:ff:ff:ff:ff:ff

So it looks like the wireless freeze is related somehow to the real txpower being cut to near nothing, even though iwlist txpower and wireless status page still showed normal power output.  The new set_txpowercap command seemed to work where ifconfig txpower did not, and restored wireless connectivity.  At least that is what it looked like from my perspective.

 

I sure hope this can get fixed soon, whether it is a dd-wrt native problem or a hardware problem that dd-wrt needs to detect and workaround.

 

Oh, and while on the subject of set_txpowercap -- even after setting the value to 22dBm this way, it eventually falls back to 19dBm.  No idea why the set_txpowercap value is not sticky.  Perhaps that is related to the same problem.  Also, no idea why setting the GUI transmit power does not seem to use the set_txpowercap mechanism which seems to have a definite effect while iwconfig txpower does not.

 

Please let me know if you'd like me to collect any additional info from subsequent wireless freezes.

 

 


drmemory

  • Big Bull
  • *****
  • Posts: 1147
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #7 on: June 20, 2011, 03:11:02 pm »

I've relayed this to the engineers - thank you for the logs.

 

 


crabnebula

  • Calf
  • *
  • Posts: 7
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #8 on: June 26, 2011, 08:57:05 pm »

This is the exact issue I've been having with dd-wrt on this router, and boy am I excited that you might have found the cause.

 

To moderators: if you ever need testers for a beta firmware version intended to correct this, I would be happy to contribute.

 


mcg

  • Calf
  • *
  • Posts: 25
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #9 on: June 26, 2011, 09:54:09 pm »

I have had success with the following startup script -- up for 5 days now without a wireless dropout.

 

From the Status/Wireless page, write down the router's wireless MAC address shown, looks like this 00:24:xx:xx:xx:xx.

 

In Administration/Commands tab, type this line using your wireless MAC and then click "Save Startup". 

 

while sleep 3; do 80211n_wlanconfig ath0 set_txpowercap xx:xx:xx:xx:xx:xx 22;done

 

You can substitute a different power dbm up to 25, but I don't know if it really translates into higher power output.  It definitely helps prevent the wireless cut out, or at leasts recovers within 3 seconds.  I streamed a wireless netflix movie today with no problems.

 

After saving, reboot your router.

 

Still waiting for a real fix. 

 


BuffaloBrian

  • BLBeta
  • *
  • Posts: 26
  • <Insert car metaphor here>
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #10 on: June 27, 2011, 06:42:37 pm »

Please note that there are many variables here.  The legal limit set by the FCC is to never transmit OVER 30 dbm.  To accomplish that, the average power setting will be lower since the peaks must remain under 30 dbm.  The dbm being reported in DD-WRT firmware is NOT the peak power, but the average power setting.  It also doesn't include gain from antennae, etc.  So 20 dbm power setting gets close to peak power of 30 dbm.  It is similar to comparing audio amplifiers and comparing peak power to RMS/average power.

 

The FCC report logs the peak power measured out of the antennae, not the internal chipset setting.  As some have found, the performance is superior to competitors in real-world testing.  Of course, everyones' mileage may vary, but please also know that since Buffalo HP routers are flirting with the limits of FCC, certain channels have to be detuned additionally to keep peaks down.

 

Also, spurious emissions outside the band of 2400-2483 have different limits, so lower and higher channels (e.g. CH 1 and 11) have additional requirements for lower power to keep their spurious emissions below the cap.

 

Center channels will give optimized performance.  Additionally, the nature of Wi-Fi is that 20 MHz will transmit at higher power as well, so to accomplish max power, 20 MHz channels and center channels should be selected.

 

-Brian

?


mishax1

  • Calf
  • *
  • Posts: 1
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #11 on: June 28, 2011, 05:33:55 am »

Continueing here after contacting the support.

 

High latency and packet loss on WZR-HP-G300NH? with BrainSlayer's firmware now have the same issue with the new ALPHA build 16783 from Buffalo site. please read my post on DDWRT forum: http://www.dd-wrt.com/phpBB2/viewtopic.php?t=86413&highlight=latency

"Hi all,
After testing a few connection methods at www.pingtest.net with a local server I've got the following results:

-BrainSlayer ddwrt (15962/earlier) over l2tp/pptp connection got ~35ms + 0-2% packet loss.

-Buffalo ddwrt(14998) over l2tp/pptp connection got ~18ms without packet loss.

-When the router was set to DHCP + win7 l2tp got ~14ms without packet loss.

The HW was ARRIS(cable modem) > WZR-HP-G300NH > wired 1gbit connection to a laptop.
?"


With BrainSlayer's firmware AND with the new buffalo ddwrt build 16783 I am getting a 20ms increase in ping and sometimes a small packet loss, This doesn't happen with the windows l2tp / pptp connection nor with build 14998 from buffalo's website.
?

?NOTE: Tests made over an Israeli ISP (bezeqint).


guidows

  • Calf
  • *
  • Posts: 1
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #12 on: July 02, 2011, 07:28:23 pm »

two issues

1) The firmware has problems with Firefox (windows). By example, if I go to wireless, add a virtual interface in Firefox, I only receive a white screen. That happens in many other parts in DD-WRT.

2) I can't get a "client" wireless connection. I'm using the unofficial DD-WRT (BrainSlayer?) and I have no problems if I configure my Wireless as a client of another Wifi. It gets an WAN IP with no problem and serves as a NAT for my home. But when I try to do the same thing with the official Buffalo builds, it's not possible to connect with the other router. That's is very annoying because the main reason for me when I choosed the WZR was the wireless client function.

 

I'm coping the ifconfig from the buffalo firmware and from the BrainSlayer.

Buffalo's Firmware

root@DD-WRT:/tmp/var/log# ifconfigath0      Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:10324 errors:0 dropped:0 overruns:0 frame:0          TX packets:24 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:625983 (611.3 KiB)  TX bytes:7776 (7.5 KiB)br0       Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          inet addr:192.168.11.1  Bcast:192.168.11.255  Mask:255.255.255.0          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1          RX packets:2863 errors:0 dropped:0 overruns:0 frame:0          TX packets:2423 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:265924 (259.6 KiB)  TX bytes:1440832 (1.3 MiB)br0:0     Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1eth0      Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:2889 errors:0 dropped:0 overruns:0 frame:0          TX packets:2423 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000          RX bytes:311322 (304.0 KiB)  TX bytes:1440832 (1.3 MiB)eth1      Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST MULTICAST  MTU:1500  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)lo        Link encap:Local Loopback          inet addr:127.0.0.1  Mask:255.0.0.0          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1          RX packets:18 errors:0 dropped:0 overruns:0 frame:0          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:1056 (1.0 KiB)  TX bytes:1056 (1.0 KiB)wifi0     Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:11684 errors:0 dropped:0 overruns:0 frame:1819          TX packets:68 errors:6 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:499          RX bytes:1064015 (1.0 MiB)  TX bytes:11454 (11.1 KiB)          Interrupt:2 Memory:b80c0000-b8100000

 

BrainSlayer?'s

 

root@DD-WRT:~# ifconfigath0      Link encap:Ethernet  HWaddr 02:1D:73:91:46:AE          inet addr:201.215.5.172  Bcast:201.215.5.255  Mask:255.255.255.0          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:10426880 errors:0 dropped:0 overruns:0 frame:0          TX packets:3400147 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:163723255 (156.1 MiB)  TX bytes:262085938 (249.9 MiB)ath0.1    Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:1828511 errors:0 dropped:0 overruns:0 frame:0          TX packets:2766280 errors:0 dropped:35 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:159943968 (152.5 MiB)  TX bytes:3634493138 (3.3 GiB)br0       Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1          RX packets:3827148 errors:0 dropped:0 overruns:0 frame:0          TX packets:5847473 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:423204784 (403.5 MiB)  TX bytes:4179601455 (3.8 GiB)br0:0     Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1eth0      Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:2020268 errors:0 dropped:3 overruns:0 frame:0          TX packets:3595266 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000          RX bytes:321810468 (306.9 MiB)  TX bytes:774189740 (738.3 MiB)eth1      Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST MULTICAST  MTU:1500  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)lo        Link encap:Local Loopback          inet addr:127.0.0.1  Mask:255.0.0.0          UP LOOPBACK RUNNING MULTICAST  MTU:16436  Metric:1          RX packets:2 errors:0 dropped:0 overruns:0 frame:0          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:0          RX bytes:826 (826.0 B)  TX bytes:826 (826.0 B)wifi0     Link encap:Ethernet  HWaddr 00:1D:73:91:46:AE          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:14765683 errors:0 dropped:0 overruns:0 frame:2951311          TX packets:5765555 errors:27150 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:499          RX bytes:3318876021 (3.0 GiB)  TX bytes:3479801391 (3.2 GiB)          Interrupt:2 Memory:b80c0000-b8100000

 

 

 

 


dyelton

  • Calf
  • *
  • Posts: 1
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #13 on: July 07, 2011, 04:27:31 pm »

I tried adding a custom service under Services Priority for QoS (TCP/UDP port 4072) and clicked save and it locked me out of the router.  That's to say thatI could no longer access the router's setup page, it just gave me a 404.  The router appears to function at this point, I can ping it and all wireless and wired traffic flow normally.  QoS seems to even work, at least for the MAC address that I have listed.

 

I unplugged the router and plugged it back in and I was able to get to the router's setup again, but as soon as I clicked add/edit under Services Priority it does the same thing again...and again.  Unplugging the router and plugging it back in brings it back every time.  So now I'm stuck...I can't add/edit/remove this custom service, and it doesn't even show up in the list of services to add to QoS.

 

**EDIT**

It looks like this only happens when using Chrome (even though the 404 occurs with other browsers after it happens until a reboot is completed).  When editing via Safari everything is ok and I can actually commit the change(s).  Not as big of a deal for me as it was previously as now I know to just not use Chrome when making changes to settings on the router.

 


gahgah

  • Calf
  • *
  • Posts: 2
Re: WZR-HP-G300NH Official 16783 BT-Pro (DD-WRT) FW Bug Report
« Reply #14 on: July 07, 2011, 08:09:00 pm »

Changing settings in GoogleChrome made my router go crazy. No access the router's setup page, just a 404?, even wired. But i could see wireless signal...

Tried everything, simple reset, 30/30/30, etc. Thought it was bricked...Suddenly, it started working again..

Do you suggest go back to build 14998?? 

When it was running user friendly it did not occur.

 

Actually, it happens with IE too..if i change anything with this fw the router stops working, and has to be reboot...

canīt set static ip, canīt port foward manually, the pppoe drops constanstly etc