The download mirrors intentionally don't redirect from http to https, to retain the option of using plain http downloads (just drop the 's' from the protocol).
Now this looks promising.
1 Like
Thanks to the post from Art on June23, I was able to follow and get OpenWRT installed on this router. You will need to be savy enough to understand how to get the .bin files from the openwrt page for this router, get the dualboot file from github, use WinSCP to transfer the file from pc to /tmp directory on router, log into router using ssh, then run the linux command according to Art in the /tmp directory. Took me about an hour to do all this, but I had already spent several hours googling to find an easier way to install openwrt, but couldn't find anything. If you are not savy you'll have problems. For example, I couldn't get wget to pull the dualboot file fron github, but simple went directly to github.com and searched and downloaded directly to pc and scp'd to router. Thanks again Art!
http://raw.githubusercontent.com/pkgadd/nbg6817/master/nbg6817-dualboot "should" work (github defaults to https, which probably isn't supported by the OEM wget implementation (busybox))
...and real factory images for the nbg6817 are basically working now, thanks to
http://lists.infradead.org/pipermail/openwrt-devel/2018-August/013670.html with these preliminary results http://lists.infradead.org/pipermail/openwrt-devel/2018-August/013763.html
1 Like
The corresponding patches have been merged today, that means current snapshots now provide a openwrt-ipq806x-zyxel_nbg6817-squashfs-factory.bin image, which can be flashed directly from the stock vendor firmware (like an original ZyXEL firmware update) or used for recovering via tftp.
openwrt-ipq806x-zyxel_nbg6817-squashfs-mmcblk0p4-kernel.bin and openwrt-ipq806x-zyxel_nbg6817-squashfs-mmcblk0p5-rootfs.bin are no longer needed and will probably be removed in a subsequent cleanup patch soon.
3 Likes
I've worked on the nbg6817's wiki device page over the last couple of days, it would be nice if my changes (flash layout in particular) could be reviewed by a another set of eyes - and missing bits and pieces added as needed. It certainly could be a little more verbose in a few places.
2 Likes
Looks great -- between all the work on making flashing easy and stable and the lower price on these, I'm considering buying one.
Would one one of you be able to post the output of iw phy so I can see if the wireless will do what I'd like? I'm also curious about the power output achievable on 2.4 GHz, which sometimes is lower than what iw phy reports for capabilities.
regdom configured to DE: DFS-ETSI.
# iw phy
Wiphy phy1
max # scan SSIDs: 16
max scan IEs length: 209 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 1:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-31
Frequencies:
* 2412 MHz [1] (20.0 dBm)
* 2417 MHz [2] (20.0 dBm)
* 2422 MHz [3] (20.0 dBm)
* 2427 MHz [4] (20.0 dBm)
* 2432 MHz [5] (20.0 dBm)
* 2437 MHz [6] (20.0 dBm)
* 2442 MHz [7] (20.0 dBm)
* 2447 MHz [8] (20.0 dBm)
* 2452 MHz [9] (20.0 dBm)
* 2457 MHz [10] (20.0 dBm)
* 2462 MHz [11] (20.0 dBm)
* 2467 MHz [12] (20.0 dBm)
* 2472 MHz [13] (20.0 dBm)
* 2484 MHz [14] (disabled)
valid interface combinations:
* #{ managed } <= 1, #{ AP, mesh point } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports VHT-IBSS.
Wiphy phy0
max # scan SSIDs: 16
max scan IEs length: 199 bytes
max # sched scan SSIDs: 0
max # match sets: 0
max # scan plans: 1
max scan plan interval: -1
max scan plan iterations: 0
Retry short limit: 7
Retry long limit: 4
Coverage class: 0 (up to 0m)
Device supports AP-side u-APSD.
Available Antennas: TX 0xf RX 0xf
Configured Antennas: TX 0xf RX 0xf
Supported interface modes:
* managed
* AP
* AP/VLAN
* monitor
* mesh point
Band 2:
Capabilities: 0x19ef
RX LDPC
HT20/HT40
SM Power Save disabled
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 7935 bytes
DSSS/CCK HT40
Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
Minimum RX AMPDU time spacing: 8 usec (0x06)
HT TX/RX MCS rate indexes supported: 0-31
VHT Capabilities (0x339b79fa):
Max MPDU length: 11454
Supported Channel Width: 160 MHz, 80+80 MHz
RX LDPC
short GI (80 MHz)
short GI (160/80+80 MHz)
TX STBC
SU Beamformer
SU Beamformee
MU Beamformer
MU Beamformee
RX antenna pattern consistency
TX antenna pattern consistency
VHT RX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT RX highest supported: 1560 Mbps
VHT TX MCS set:
1 streams: MCS 0-9
2 streams: MCS 0-9
3 streams: MCS 0-9
4 streams: MCS 0-9
5 streams: not supported
6 streams: not supported
7 streams: not supported
8 streams: not supported
VHT TX highest supported: 1560 Mbps
Frequencies:
* 5180 MHz [36] (20.0 dBm)
* 5200 MHz [40] (20.0 dBm)
* 5220 MHz [44] (20.0 dBm)
* 5240 MHz [48] (20.0 dBm)
* 5260 MHz [52] (20.0 dBm) (radar detection)
* 5280 MHz [56] (20.0 dBm) (radar detection)
* 5300 MHz [60] (20.0 dBm) (radar detection)
* 5320 MHz [64] (20.0 dBm) (radar detection)
* 5500 MHz [100] (26.0 dBm) (radar detection)
* 5520 MHz [104] (26.0 dBm) (radar detection)
* 5540 MHz [108] (26.0 dBm) (radar detection)
* 5560 MHz [112] (26.0 dBm) (radar detection)
* 5580 MHz [116] (26.0 dBm) (radar detection)
* 5600 MHz [120] (26.0 dBm) (radar detection)
* 5620 MHz [124] (26.0 dBm) (radar detection)
* 5640 MHz [128] (26.0 dBm) (radar detection)
* 5660 MHz [132] (26.0 dBm) (radar detection)
* 5680 MHz [136] (26.0 dBm) (radar detection)
* 5700 MHz [140] (26.0 dBm) (radar detection)
* 5720 MHz [144] (disabled)
* 5745 MHz [149] (13.0 dBm)
* 5765 MHz [153] (13.0 dBm)
* 5785 MHz [157] (13.0 dBm)
* 5805 MHz [161] (13.0 dBm)
* 5825 MHz [165] (13.0 dBm)
* 5845 MHz [169] (13.0 dBm)
* 5865 MHz [173] (13.0 dBm)
valid interface combinations:
* #{ managed } <= 1, #{ AP, mesh point } <= 16,
total <= 16, #channels <= 1, STA/AP BI must match, radar detect widths: { 20 MHz (no HT), 20 MHz, 40 MHz, 80 MHz }
HT Capability overrides:
* MCS: ff ff ff ff ff ff ff ff ff ff
* maximum A-MSDU length
* supported channel width
* short GI for 40 MHz
* max A-MPDU length exponent
* min MPDU start spacing
Device supports VHT-IBSS.
# iw dev wlan0 info
Interface wlan0
ifindex 22
wdev 0x2
addr 60:31:97:XX:XX:X5
ssid XXX
type AP
wiphy 0
channel 100 (5500 MHz), width: 80 MHz, center1: 5530 MHz
txpower 26.00 dBm
# iw dev wlan1 info
Interface wlan1
ifindex 21
wdev 0x100000002
addr 60:31:97:XX:XX:X4
ssid XXX
type AP
wiphy 1
channel 13 (2472 MHz), width: 20 MHz, center1: 2472 MHz
txpower 20.00 dBm
1 Like
Wow! Thanks for the great work! I will try it out on my NBG6817 aswell.
I've read the mailing list. Just a few thoughts, no big deal: afaik, the stock firmware allows either flashing the same version or a higher version. I think going with RAS_VERSION := "V1.00(ABCS.9)C0"RAS_VERSION := "V1.00(ABCS.8)C0" would be a wiser solution, as this will also prevent people from flashing from a possible and untested ABCS.9. Once ABCS.9 has been officially released and confirmed not bricking your device after flashing the make-ras image, RAS_VERSION could be increased.
Many, many thanks to anyone involved! Incredible work!
//Edit: I meant ABCS.8, not ABCS.9.
Flashing via tftp doesn't do any version checks, so reverting to stock firmware is unaffected by an inflated OpenWrt version number. Using the expected next OEM version would be a problem for OpenWrt releases, as it's likely to be reached by OEM during the life cycle of an OpenWrt release.
I've added quite a few new features to nbg6817-dualboot and refactored the usage description to make it a bit easier to read (all existing parameters remain unchanged). Combined with the factory images in master, this should be mostly feature complete.
I've flashed OpenWRT from Zyxel ABCS.8 Web-Interface. Worked flawless! Thanks for all the efforts, this is really helpful! A bit sad, it didn't make it into OpenWRT 18.06.1. However you can easily use the SNAPSHOT release for easy installation and install 18.06.1 via sysupgrade afterwards.
Please note, SNAPSHOT releases don't have a GUI; you will need to SSH, wget the 18.06.1 image and do sysupgrade via cli, but I think this is still safer / less of a hassle than the original method. And from 19.01 onwards, this will be child's play.
Very pleased by 18.06.1, incredible how much this project improved in such a short time.
After 12 days of flawless uptime, my NBG6817 randomly rebooted today. My R7800, which I setup at the same time, still runs. NBG6817 is facing WAN though, therefore handles PPPoE and has a few extras installed, like SQM, UPnP and DDNS. I have OpenWRT 18.06.1 installed on both devices.
Unfortunately, kernel logs are per default written to /tmp (or am I wrong?), so I couldn't reveal anything afterwards. I will setup logging to syslog server, so I will have proper kernel logs next time.
Anyone else experienced crashes?
Just to extend my previous remark, while testing flow-offloading I did notice several spontaneous reboots (also on lantiq, not just the nbg6817) - since disabling flow-offloading the nbg6817 has been rock stable for me. As I don't really need flow-offloading for my maximum WAN speed, I didn't investigate this any further and just kept it disabled (as per default).
Oh okay. I assumed it was a non-issue, as OP didn't had flow-offload enabled. I have disabled it now. I'll report back.
I had 20 days uptime, until our oven malfunctioned and caused a power outtage. However, I had no issues within those 20 days and the Zyxel happily runs again. I think disabling flow-offload indeed fixed my issue. Thanks!
1 Like
Thanks for confirming my hunch.
@slh quick question for you.
polishing the rt2600ac stuff off here... before delving in for a day or two to polish....
-
Is there a shared "target" script ( target -> basefiles -> bin -> ? ) the BOOTTOGGLE can be done in ( or should there be )?
-will it help if the uboot variables have commonality -
Likewise, with advanced reboot ( does it hook in somewhere or is it's config static )?
Cheers!
( got factory today, very happy indeed 
)