svoxel / orbi-rbk50 Goto Github PK

Hi I've added a #7 that adds a new user script path for V2 users where changes to the ntgr folder clear on reboot so instead we (V2 user's) can use the bitdefender mount

Hi.

I bought a RBK53 several years ago (one RBR50 with two RBS50) and I've been using just one RBS50 (the other was in the box until now).

I want to use the second RBS and performed a double firmware upgrade (2.5.2.4 -> reset -> 9.2.5.2.27.1SF-HW) but vol_ntgr is not being mounted.

What I've found so far is that the mtd partition scheme is different:

Working RBS

mtd23: 02e40000 00020000 "rootfs"
mtd24: 015e0000 00020000 "rootfs_data"
mtd25: 01b80000 00020000 "reserved"
mtd26: 01702000 0001f000 "vol_ntgr"
mtd27: 0009b000 0001f000 "vol_oopsdump"
mtd28: 0020f000 0001f000 "vol_rae"

UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:60
Present UBI devices:            ubi0

ubi0
Volumes count:                           3
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     240 (30474240 bytes, 29.1 MiB)
Amount of available logical eraseblocks: 4 (507904 bytes, 496.0 KiB)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  20
Current maximum erase counter value:     4
Minimum input/output unit size:          2048 bytes
Character device major/minor:            249:0
Present volumes:                         0, 1, 2

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        190 LEBs (24125440 bytes, 23.0 MiB)
State:       OK
Name:        vol_ntgr
Character device major/minor: 249:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        5 LEBs (634880 bytes, 620.0 KiB)
State:       OK
Name:        vol_oopsdump
Character device major/minor: 249:2
-----------------------------------
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        17 LEBs (2158592 bytes, 2.1 MiB)
State:       OK
Name:        vol_rae
Character device major/minor: 249:3

Failing RBS

mtd23: 02e40000 00020000 "rootfs"
mtd24: 015e0000 00020000 "rootfs_data"
mtd25: 01b80000 00020000 "reserved"
mtd26: 01303000 0001f000 "vol_ntgr"
mtd27: 0009b000 0001f000 "vol_oopsdump"
mtd28: 0020f000 0001f000 "vol_rae"
mtd29: 00307000 0001f000 "vol_ntgrcrydata"
mtd30: 00117000 0001f000 "vol_jdx"

UBI version:                    1
Count of UBI devices:           1
UBI control device major/minor: 10:60
Present UBI devices:            ubi0

ubi0
Volumes count:                           5
Logical eraseblock size:                 126976 bytes, 124.0 KiB
Total amount of logical eraseblocks:     240 (30474240 bytes, 29.1 MiB)
Amount of available logical eraseblocks: 3 (380928 bytes, 372.0 KiB)
Maximum count of volumes                 128
Count of bad physical eraseblocks:       0
Count of reserved physical eraseblocks:  20
Current maximum erase counter value:     4
Minimum input/output unit size:          2048 bytes
Character device major/minor:            249:0
Present volumes:                         0, 1, 2, 3, 4

Volume ID:   0 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        157 LEBs (19935232 bytes, 19.0 MiB)
State:       OK
Name:        vol_ntgr
Character device major/minor: 249:1
-----------------------------------
Volume ID:   1 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        5 LEBs (634880 bytes, 620.0 KiB)
State:       OK
Name:        vol_oopsdump
Character device major/minor: 249:2
-----------------------------------
Volume ID:   2 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        17 LEBs (2158592 bytes, 2.1 MiB)
State:       OK
Name:        vol_rae
Character device major/minor: 249:3
-----------------------------------
Volume ID:   3 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        25 LEBs (3174400 bytes, 3.0 MiB)
State:       OK
Name:        vol_ntgrcrydata
Character device major/minor: 249:4
-----------------------------------
Volume ID:   4 (on ubi0)
Type:        dynamic
Alignment:   1
Size:        9 LEBs (1142784 bytes, 1.1 MiB)
State:       OK
Name:        vol_jdx
Character device major/minor: 249:5

As you may see, the failing one has vol_ntgrcrydata and vol_jdx, resulting in a smaller vol_ntgr. Don't really know if there's an issue here but /etc/ntgrdata-rbs50.cfg expects only vol_ntgr and vol_oopsdump and I can't find any script in /etc where vol_ntgr is being mounted.

Any help is really welcome.

Thanks.

Hey there! So, I got myself an Orbi "Mini" at Costco last week, and while the hardware seems solid, well, lets just say there's a lot left to be desired with regards to usability (i.e., a functional dual stack IPv6 implementation would be a GREAT start...).

A bit of digging on what could be done brought your work to my attention; it looks like you've put a lot of time and effort into putting together this lovely alternate firmware package. So I thought I'd ask if you'd be so kind as to give me your thoughts on how feasible (in terms of time and effort) to fork and port your RBK50 firmware to the RBK20. My initial (probably naively optimistic) thought is that it might not be too much of a slog—while I'm not sure they use the exact same chipset, grepping around the libtool .la files in the filesystem leads me to believe they're at least both Cortex-A7 based, and they have the same amount of RAM storage.

I dumped (in the crudest tar c - / | nc ... sense) the filesystem of my device (stock firmware V2.3.5.30), in case poking around there might be helpful. (I do realize there may be some semi-sensitive data there as well as perhaps some gray-areas in re: copyright, so I don't leave that repo up for very long).

To be clear, I'm not asking you—unless, of course, you want to, in which case, fantastic ;) —to create and maintain support for yet another device, just for me—I'm more than willing to set up the build system and toolchain and do as much of the grunt work of producing and testing builds, etc. Its been a few years since I've done the Linux From Scratch thing, and it might be nice get a bit familiarized with today's embedded systems.

Of course What I would need help with most likely, would a bit of handholding/pointers on which scripts and config files I'd need to look at, problematic packages that might need a deeper dive/patching, etc. , f you'd be willing.

To tell the truth, it seems I'm jumping the gun again... my only real question at this point is whether a port is, in your opinion, workable and feasible. By which I mean, something that you think this could be something done in a matter of weeks, not months or years, and not a fools errand entirely, for some obvious reason I have missed).

Thank you for your hard work, and I appreciate your time and knowledge!

· Geoff

Hi,

Big fan of your firmware but I'm facing an issue where the mini UPnPd won't update after 4294967295 bytes has been reached on either download or upload.

This issue is present in the stock firmware. More on the issue, here and here.

Would it be possible for you to fix this?

Thanks.

I have reported this issue to NG support ... no comment ... (send us debug logs, network packets, pictures, writing more than 20 comments into support ticket tool ... but nothing, they don't understand where is the problem ...)

I think you will for sure understand what I 'm talking about just looking my pictures :-)

regards

Hi SVoxel

I'm sorry to trouble you that can you take your time to investigate below detail discussion thread ?
https://community.netgear.com/t5/Orbi/WiFi-Slow-after-2-3-days-until-reboot/td-p/1782582
BTW: that why i start another thread to report how to use crontab to setup schedule reboot to workaround wifi speed drop issues. But we need fundamental solutions.
Will you help to figure out what cause this issues?

Let me try to summary for you which is :

1. Many RBK50/53 users has WIFI slow down issues, most issue happen on Router (RBR50) but not Satellite (RBS50).
2. Most of them tried update to latest firmware or like me is using your RBK50-V9.2.5.1.11SF-HW also has same issues.
3. After reboot, 5G WIFI speed work fine as expect as 5G standard.
4. e.g every 2-3 days though, WiFi speeds drop from 180+ Mb/s down to to ~40 Mb/s
5. Most of cause has been eliminated, such like channel settings, wired or wireless backhaul, other device broadcasting issue.
6. Some person guessing is memory leak or similar cause.

FW: RBK50-V9.2.5.1.11SF-HW
first approach:
crontab -e and added below command
00 02 1,4,7,10,13,16,19,22,25,28 * * /sbin/reboot
crontab -l
command is there correctly.
nvram commit
reboot
crontab -l check again, GONE, nothing is there

workaround approach:
put below command in /etc/rc.local
echo "00 02 1,4,7,10,13,16,19,22,25,28 * * /sbin/reboot" >/var/spool/cron/crontabs/root && crond -c /var/spool/cron/crontabs -L /var/log/crontab.log
nvram commit
reboot

my command in rc.local is GONE.

anything that i missed or wrong?