Buffalo WZR-HP-G300NH Model Codes

Talk about Documentation
1

The Buffalo WZR-HP-G300NH page in the ToH currently recommends using "the specific model code from the label on the back of your device in order to choose the right firmware":

  • A0D0: Use “wzr-hp-g300nh-rb”-type images. (“wzr-hp-g300nh-s”-type images will boot, but will enter failsafe mode without network support. If you did that, you will have to use serial terminal to flash firmware and recover).
  • B0B0: Use “wzr-hp-g300nh-s”-type images. (“wzr-hp-g300nh-rb”-type images will boot, but will constantly enter failsafe mode).
  • B0C0: Use “wzr-hp-g300nh-s”-type images.

However, I don't think this correct. Here are the information sources I've collected:

  1. I have two A0D0 devices (purchased in 2010) which both have rtl8366s.
  2. @josteink states in Buffalo WZR-300hp and 21.02 - #8 by josteink that B0B0 uses rtl8366s. (The log shows MIPS: machine is Buffalo WZR-HP-G302H A1A0? Is this from the firmware image?)
  3. @musashino states in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #89 by musashino that A0A1 has rtl8366s.
  4. @alfredganz states in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #90 by alfredganz that A0D0 has rtl8366s and A2F0B (corrected in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #116 by alfredganz and confirmed in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #170 by alfredganz ) has rtl8366s.
  5. @fabio70mi states in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #92 by fabio70mi that B0B0G has rtl8366s.
  6. @FIN_PPX states in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #106 by FIN_PPX that B0B0 has rtl8366s.
  7. @foop states in Impossible to install/update any packages on WZR-HP-G300NH 18.06.1 - #112 by foop that B0C0 uses rtl8366s.
  8. @tomyan112 states in Which firmware should I choose for Buffalo WZR-HP-G300NH? - #5 by tomyan112 that A0D0 is rtl8366s, B0B0 is rtl8366s, and B0C0 is rtl8366rb. (From what source?)
  9. @batmreload mentions having A0A3 in Migrating from DD-WRT v3 on Buffalo WZR-HP-G300NH but it's unclear which switch it has.

Tracing the wiki edits:

  1. jostein added B0B0 as rtl8366s in https://openwrt.org/toh/buffalo/wzr-hp-g300h?do=diff&rev2[0]=1634672672&rev2[1]=1638531959&difftype=sidebyside
  2. @user_1 added A0D0 as rtl8366rb in https://openwrt.org/toh/buffalo/wzr-hp-g300h?do=diff&rev2[0]=1650296174&rev2[1]=1669092323&difftype=sidebyside
  3. hazuki added B0C0 to rtl8366s the wiki in https://openwrt.org/toh/buffalo/wzr-hp-g300h?do=diff&rev2[0]=1725988279&rev2[1]=1771128795&difftype=sidebyside

Is there any way to contact those wiki authors to have them confirm their findings? @user_1, I hope you are the same user as on the wiki and can confirm A0D0 as rtl8366rb, because everyone else (myself included) has rtl8366s and it would be great to have clarity here. Are newer models with the same code different?

Based on the above, I propose the following edit:

  • A0A1 Use “wzr-hp-g300nh-s”-type images.
  • A0D0: likely uses “wzr-hp-g300nh-s”-type images, but may use “wzr-hp-g300nh-rb”-type on newer devices. Check dmesg in stock firmware to confirm before installing. (“wzr-hp-g300nh-s”-type images will boot on rb-type devices, but will enter failsafe mode without network support. If you did that, you will have to use serial terminal to flash firmware and recover).
  • A2F0B Use “wzr-hp-g300nh-s”-type images.
  • B0B0: Use “wzr-hp-g300nh-s”-type images. (“wzr-hp-g300nh-rb”-type images will boot, but will constantly enter failsafe mode).
  • B0B0G Use “wzr-hp-g300nh-s”-type images.
  • B0C0: Use “wzr-hp-g300nh-s”-type images.

Any objections or suggestions? I'd appreciate any thoughts, confirmations, refutations, or additional information.

2

I can add that I have
WZR-HP-G300NH2 build A1A0 (https://openwrt.org/toh/buffalo/wzr-hp-g300nh2)
that works with image built for
WZR-HP-G302H build A1A0 image (https://openwrt.org/toh/hwdata/buffalo/buffalo_wzr-hp-g302h_a1a0)

It seems this whole model range naming is a complete mess...

3

Hey @kevinoid .

Namedropping is a good way to get attention :wink:

In my model B0B0 I run what imagebuilder calls "buffalo_wzr-hp-g300nh-s". In the main Luci UI it is shown as "Buffalo WZR-HP-G300NH (rtl8366s)".

Here's an excerpt from the boot-logs:

root@buffalo:~# dmesg
[    0.000000] Linux version 6.12.91 (builder@buildhost) (mips-openwrt-linux-musl-gcc (OpenWrt GCC 14.3.0 r34704-c9406df918) 14.3.0, GNU ld (GNU Binutils) 2.44) #0 Sat May 30 21:00:12 2026
[    0.000000] printk: legacy bootconsole [early0] enabled
[    0.000000] CPU0 revision is: 00019374 (MIPS 24Kc)
[    0.000000] MIPS: machine is Buffalo WZR-HP-G300NH (rtl8366s)

Hope this helps. :slight_smile:

4

It didn't use to be that bad before - but after the ath79 device-tree rewrite/port (which I on overall consider a good thing), it seems that things have gotten a wee bit messier for this device-family - and nobody really seems to have cared because this device is now 20 years old and probably very few people depend on it for any serious internet business :wink:

5

@kevinoid Oh yeah, big mess! I have 2 of these devices, 1 ea A0A3 and A0D0.

I did some mildly successful work on these earlier this year. See this post. I thought about doing some updates at the time, but it was in such bad shape, I was at a loss to figure out how to update it other than stuffing a new section with "as of this date..." and I also needed to figure out how to "wiki". As no "owners" replied to my post I figured it was not value added, I am sorry.

I did a fair amount of research, but my notes are a mess. In general you are right that the HW versions do not correctly align with suggested chips inside as written in the wiki. I used this link which is just above the section "OEM installation using TFTP method" and built this table, but do not know it to be correct other than the 2 I own which are highlighted. Just above that is instructions on how to use dmesg to query the device for it's version.

A0A0 RTL8366S
A0A1 RTL8366S
A0A3 RTL8366S
A0D0 RTL8366S
A0F0B RTL8366RB
A1A3 RTL8366RB
A2A0 RTL8366RB
B0B0G RTL8366S

My A0D0 is an "S" and is working fine on 24.10.5 which I think was the current version at the time.

The A0A3 which is also "S" works fine on the pre-DSA builds (19.07 I think), but when I installed the same 24.10.5 the router would not save any settings. I brought the thing back to Buffalo DD-WRT and did it again, same results.

My post was specifically about the first device, none of the issues with the second was written up. I just put it aside. I think I will dust them off.

The Buffalo images are still alive and I recovered both devices back to there and upgraded. I think I need to redo the A0A3 and go version by version. IIRC, I went from 19.07 to 24.10.3 (at least those are the files I have). Even my post is not now clear to myself (HA!)

Do you have a specific version question, or just global cleanup?

FWIW, I did all my work in Windows.

6

I'm glad it got the attention and useful comments that it has! I hope the namedrops weren't rude or excessive.

That's good info! The process of Factory -> DD-WRT -> OpenWrt sounds painful. Was it necessary, or just how you managed to make it work? I've successfully flashed OpenWrt via TFTP in the past, and would expect it to work with current images. If it doesn't work anymore, we may want to investigate.

No worries! That's a lot of effort to invest in documenting 20 year old hardware. I have also known about the wiki issues for a while and never taken the time to improve it, until now. I appreciate what you've already shared here in the forum. Hopefully these posts and the wiki updates will be helpful to future users.

That's odd and frustrating. It might be interesting to try intermediate versions to bisect the issue and confirm that the switch to ath79 is the cause. (Using 19.07 and 21.02.) However, my initial suspicion is that the NAND has bad blocks where writes fail, causing the changes to be lost, and image size/layout changes may be triggering the issue. I'd keep an eye out for bad blocks and write errors in dmesg/mtdinfo/ubinfo.

I was just planning a bit of wiki cleanup and hoped to get input from other users to confirm the code/switch mapping. I appreciate all the input so far!

Since I'm unable to edit my original post, here's my updated proposal for the wiki:

For OpenWrt 21.02 and up, please make sure you choose the right image for your device. To do so, lookup the specific model code from the label on the back of your device in the table below. The model code is 4 or 5 characters, often separated by a space, located in the top right corner of the label with the SSID on the back of the device.

Model Code Switch Image
A0A0 RTL8366S wzr-hp-g300nh-s
A0A1 RTL8366S wzr-hp-g300nh-s
A0A3 RTL8366S wzr-hp-g300nh-s
A0D0 RTL8366S wzr-hp-g300nh-s
A0F0B RTL8366RB wzr-hp-g300nh-rb
A1A3 RTL8366RB wzr-hp-g300nh-rb
A2A0 RTL8366RB wzr-hp-g300nh-rb
A2F0B RTL8366S wzr-hp-g300nh-s
B0B0 RTL8366S wzr-hp-g300nh-s
B0B0G RTL8366S wzr-hp-g300nh-s
B0C0 RTL8366S wzr-hp-g300nh-s

If your model code is not listed above, you may be able to determine your switch hardware by running dmesg | grep -i rtl8366 in the "Buffalo Professional Firmware" (DD-WRT) or after temporarily installing OpenWrt 19.07. If so, please consider adding your code to the table above, or posting in the model code thread on the forum to assist future users.

Installing the wrong firmware image is likely to cause the device to boot into failsafe mode without network support. Recovery may require using a serial terminal to flash the proper firmware. See this thread for more details: Buffalo WZR-300hp and 21.02 - #8 by josteink

@josteink Is it true that the only way to recover from flashing the wrong image is via serial terminal? Or is it possible to TFTP the correct image? My read of your post is that you used the serial terminal to see output, but that flashing was done via TFTP. Is that correct?

7

I think this is fine. Indeed, some of the gurus here are quite busy and may miss a reply if you do not.

On the first unit it was stuck in some never, never gona boot land, so the re-flash of 19.07 did not fix it. So yes. As for painful, a bit, but I was always able to get to this point, so it was a clean starting point. Frankly, for those with "undiagnosed issues" I think it's a good thing to do.

What I do not know is if I can back flash the 24.10 to 19.07, but I can go to Buffalo DD-WRT.

So, yes this is my next plan, but...

After last night I was thinking of making a post on this issue and was wondering if there is some way to diagnose the HW\FW as it stands. Not smart enough to know about the NAND as you suggest, but am thinking it maybe MY hw in some way. And to reiterate 19.07 saved changes.

So, not a Linux guy and could use more detailed help with the specific commands. I am not sure I can do it before the weekend, but ya never know when ambition strikes.

Not quite a quote. While I think listing the table is important I think asking those few who travel this path to chime in. Bold the entire line for confirmed HW REVs

"this table is a list of known HW versions of the device, not all of which are user verified. If you own an unverified device, or have a missing HW version please update the table accordingly"

The thread title is excellent, but I think this stuff should not go here, but to the wiki page as this thread will likely close at some point (sooner than we may like)

So, I did revert my A0A3 to Buffalo, not sure I needed to. I think that my suggestion would be that if the user is on 19.x or lower with no issues that they should run dmesg to query the chip. I think this may require a package, but not sure.

If the device has any issues, revert to the Buffalo file, check the HW with dmesg and then install OpenWrt.

I'll get back to you on 19, 21 or 25 later, but the 19=>21=>25 path is 15 minutes of easy upgrades. There is no config to worry about. That said, these routers take a non trivial amount of time to FLASH, IIRC, it was about 5-7 minutes to complete and boot, maybe longer. Patience is required. The boot loop will be obvious.

At this point a have done a number of TFTP tests, and can firmly say, at least for my HW revs, the TFTP window opens at 12 seconds after the first LED comes on. I used a stop watch and could hit is reliably. Not sure how long it was open. .

Feel free to PM me any write ups you have and will try to review and test. Hopefully this weekend. Not sure we need to bury the tread in minutia of edits, but it's your call