Nope. You tried to run tftpd64 using "Tftp Client" tab. However, you're supposed to run it in "Tftp Server" tab.
Whooohooo.. yes tolga9009.. Amazing.. works like a charm.. So thankful for the help I've got here..
It was the tftp server instead of the client.. Duhhhh.. And I use ESET for security so needed to turn of firewallprotection and then it worked.. Had already opened the router up and was about to order serial to usb cable and a converter..Many many thanks
If your router is still open, please take some high-res pictures from the PCB for the wiki.
@HammerFall you're welcome ;)!
@slh maybe we should work on an install script making use of nbg6817-dualboot
for an easier install experience? Something, which checks current active partition, installs LEDE on the other, sets flag accordingly and then reboots. Also, do you have any idea why the LEDE flash process could've failed? Maybe wrong active partition during flash?
@tolga9009 I've been considering that for quite a while already, but I'm not sure if the OEM firmware provides the basic dependencies for dealing with the sysupgrade image (needs losetup/ mkfs, as the sysupgrade images aren't padded, thereby missing the signature for mtdsplit), expecting the user to supply the two images (kernel & rootfs) feels risky - and downloading it automatically is a can of worms I'd rather avoid to open. The other alternative would be to work on a real factory image, which doesn't seem to be that difficult - I'm just not sure which hash algorithm is actually used by genImgHdr.
It's hard to guess what might have failed, recent- and current master are fine, the mtd/ eMMC partitioning hasn't changed in 1.00(ABCS.8)C0 either, so the printf and cat calls are fine as well. The only thing that might have happened, albeit unlikely, is that the OEM firmware was booted from /dev/mmcblk0p5 and some running process of the OEM firmware clobbered data on /dev/mmcblk0p5 while writing the new image/ before rebooting. ...or simple finger trouble.
Hi,,I made 3 pics from the header pins.. its al I've got.. opening btw is quite simple. 4 screws hidden under the rubber pads in the corner. And I used a broad table knife to open it up from the corners where the screws where and sliding the table knife to the sides. open up the sides then the back and then you can lit the front off..!!! (restricted to just 1 image to a post: some limitations for noobs).. Thanks again...!!
@slh and @simplexion thanks both for your advice and additional directions. Just reporting in that I have the latest snapshot up (6-21-2018) running on my device. Very helpful advice for a linux/OpenWRT novice!
I followed @slh instructions to pull dualboot code from github rather than running "# printf "\xff" >/dev/mtdblock6". Then I just used the last four lines of OEM Easy Install. I had to use WinSCP as my router didn't have open-ssl, so I couldn't wget from HTTPS.
@slh, I know this is repetitive, but posting up my process anyways for others checking out the thread.
Step 1: Enable SSH on ZyXel NBG6817 and internet connectivity
Step 2: Download appropriate OpenWRT Versions
i.e. ....mmcblk0p4-kernel.bin and mmcblk0p5-rootfs.bin
http://downloads.openwrt.org/releases/18.06-SNAPSHOT/targets/ipq806x/generic/
Step 3: Transfer kernel.bin and rootfs.bin files to /tmp directory on router
- You can use WinSCP and navigate to /tmp for drag and drop transfer
Step 4: Dual Boot Protection
-
Don't use the first line of the default commands outlined here for OEM Easy Installation:
https://openwrt.org/toh/zyxel/nbg6817#oem_easy_installation
Line 1 from OEM Easy Installation: "# printf "\xff" >/dev/mtdblock6 #warning, only do this from the OEM firmware!" -
Use DualBoot protection code instead of Line 1 from above:
https://github.com/pkgadd/nbg6817/blob/master/nbg6817-dualboot -
To do this, run these commands via SSH (putty)
root@NBG6817:~# cd /tmp/
root@NBG6817:/tmp# wget https://github.com/pkgadd/nbg6817/raw/master/nbg6817-dualboot
root@NBG6817:/tmp# chmod +x /tmp/nbg6817-dualboot
root@NBG6817:/tmp# /tmp/nbg6817-dualboot --set-rootfs /dev/mmcblk0p5
Step 5: complete installation (as @simplexion said, change .bin filenames to ones you downloaded)
root@NBG6817: # cat /tmp/openwrt-18.06-snapshot-r7018-18f18a2-ipq806x-zyxel_nbg6817-squashfs-mmcblk0p4-kernel.bin >/dev/mmcblk0p4
root@NBG6817: # cat /tmp/openwrt-18.06-snapshot-r7018-18f18a2-ipq806x-zyxel_nbg6817-squashfs-mmcblk0p5-rootfs.bin >/dev/mmcblk0p5
root@NBG6817: # sync
root@NBG6817: # reboot -f
Also, any type of streamlined install with dualboot I am sure would be very helpful for other users, especially novices like myself! Not necessarily automated, as @slh your concerns certainly make sense, but I think it would be great to include additional info on the wiki possible.
Thanks again to everyone! Especially @slh for work on supporting the router and being super helpful on the forums!
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.
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
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.
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.
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
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.