Chadster766 commented 4 years ago

McDebian 5.6.14 Beta

Updates:

Linux Kernel 5.6.14
Implementing nftables flowtable offload which increases the DSA switch wan to lan routing to gigabit speeds for single connections (didn't work in previous kernel versions I tried)

Notes:

I recommend that only users that have TTL access to their WRT routers do McDebian beta testing.

In the WRT1900AC V1 make sure you have the below u-boot envars set to to accommodate the increased kernel size.

#This is what I have my WRT1900AC V1 u-boot kernel size set for
root@MCDEBIAN:~# fw_printenv pri_kern_size
pri_kern_size=0x520000
root@MCDEBIAN:~# fw_printenv alt_kern_size
alt_kern_size=0x520000

Fixes kernel "oops in br_vlan_enabled" Update Testing has shown that the below point doesn't work for the WRT32000ACM V1 but works on the WRT3200ACM V2.
Kernel version brings up interfaces properly so "pre-up ifup --ignore-errors br0" is no longer required in wan config and br0 config can be set to "auto br0".

Edit file "/etc/nftables.conf" to implement nftables flowtable offload

create table inet x
add flowtable inet x f { hook ingress priority 0; devices = { wan, br0 }; }
add chain inet x y { type filter hook forward priority 0; policy accept; }
add rule inet x y ip protocol { udp, tcp } flow offload @f
add rule inet x y counter packets 0 bytes 0

Add "post-up nft -f /etc/nftables.conf" to br0 config to implement nftables flowtable offload (don't enable nftables.service since it fails due to starting before all DSA interfaces are up"

Firmware:

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_5.6.14.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Buster-WRT1900AC-V2-FW_VER1_kernel_5.6.14.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Buster-WRT1200AC-V1-FW_VER1_kernel_5.6.14.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Buster-WRT3200ACM-V1-FW_VER1_kernel_5.6.14.img

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/firmwares/McDebian-Buster-WRT32X-V1-FW_VER1_kernel_5.6.14.img

Root File System Update:

wget --user=mcdebian --password=mcdebian123 http://www.protechs-online.com/downloads/McDebian/rootfs-updates/mcdebian-rootfs-kernel-modules-firmwares-updates-v5.6.14-ver1.gz

rm -rf /lib/modules/*
rm -rf /lib/firmware

tar zxfk mcdebian-rootfs-kernel-modules-firmwares-updates-v5.6.14-ver1.gz

IPv6

To enable IPv6 in this beta release you need to enable radvd:

systemctl enable radvd

Then uncomment the IPv6 config lines in:

vim /etc/default/isc-dhcp-server

After that reboot the router.

sfrost commented 3 years ago

So, just a couple of notes-

Yes, setting the pri_kern_size and alt_kern_size to be 0x520000 worked for me (thought I had said that somewhere already, but don't see it now..)
I was able to build out another WRT3200ACM using the 0x520000 settings and with the 5.6.14 kernel and Buster and it all seems to be going well so far, though only did that this morning
With my 1900AC and the 5.6.14 and my 'fix_bridge.sh' script, the system would periodically lock up without any output on the serial console or anything else. Packets through the ethernet ports would still flow but everything else was dead. No idea what caused that, might have been an issue with the hardware itself (I've had that 1900 around for quite a while) or maybe some kind of race condition or something, not sure. Ultimately that's what made me go get a 3200ACM to replace it, so I've now got a spare 1900. I had another 3200ACM before this and it's been running great for over a month with the fix_bridge.sh script running all the time. Now I have two of them. :) Hopefully that'll address the wifi issues that I've been having of late with that 1900 locking up.

Thanks again for this awesome project! My other 1900 continues to run as my firewall, but I don't have any wifi enabled for it and therefore don't need the fix_brdige.sh script and it continues to hum along just fine, and now I've got a spare for it should it ever have issues.

Mark-GR73 commented 3 years ago

Unfortunately, The nvme m2 to usb3 converter is working ,but with slow speeds about 700 M read and 40M write. The classical sata to esata or nvme m2 to usb3 is about 700 M read and 400M writing. The system recognize the usb 3 adapter ,boot from it of course ,but we need more...

Is there any advice probably ?

Chadster766 commented 3 years ago

Sorry I don't have any suggestion on how to speed that up.

Mark-GR73 commented 3 years ago

Well , I try to play with btrfs partitions. By Debian way everything is perfect until now . The difficult part is to boot the system from btrfs

Untiil now : make install the btrfs, apt install some tools : zlib1g-dev zlibc btrfs-tools btrfsmaintenance btrfs-progs libncurses-dev libzstd-dev python3.7 bzip2

Some results:

btrfs version btrfs-progs v5.11

modprobe btrfs modprobe: FATAL: Module btrfs not found in directory /lib/modules/5.6.14

ls /lib/modules/$(uname -r)/kernel/fs//ko /lib/modules/5.6.14/kernel/fs/cifs/cifs.ko /lib/modules/5.6.14/kernel/fs/ext2/ext2.ko /lib/modules/5.6.14/kernel/fs/fscache/fscache.ko /lib/modules/5.6.14/kernel/fs/fuse/cuse.ko /lib/modules/5.6.14/kernel/fs/fuse/fuse.ko /lib/modules/5.6.14/kernel/fs/hfs/hfs.ko /lib/modules/5.6.14/kernel/fs/hfsplus/hfsplus.ko /lib/modules/5.6.14/kernel/fs/nfsd/nfsd.ko /lib/modules/5.6.14/kernel/fs/nfs/nfsv4.ko /lib/modules/5.6.14/kernel/fs/ntfs/ntfs.ko /lib/modules/5.6.14/kernel/fs/ubifs/ubifs.ko /lib/modules/5.6.14/kernel/fs/udf/udf.ko

cat /proc/filesystems nodev sysfs nodev tmpfs nodev bdev nodev proc nodev cgroup nodev cgroup2 nodev cpuset nodev devtmpfs nodev debugfs nodev tracefs nodev sockfs nodev pipefs nodev ramfs nodev rpc_pipefs nodev devpts ext3 ext4 vfat msdos iso9660 nodev nfs nodev nfs4 nodev autofs nodev cifs nodev smb3

It has relationship with kernel ? Any advice perhaps?

Chadster766 commented 3 years ago

I didn't built the kernel with CONFIG_BTRFS_FS option.

IMO btrf is an unstable file system.

Even if the kernel supports btrf I don't think WRT u-boot supports it as a boot partition.

Mark-GR73 commented 3 years ago

Btrfs has no finished with all of new futures to supported yet until now ,i believe it is enough stable, has alot of futures ,and every day growing up .it it is a very good point for playing...

I believe it is a good start point for research..

If uboot will boot from nand or other partition scheme it could be to load the root dirs?

If we have ready the kernel for this would be nice.. Or if i have the mustdo for kernel building ,would be pretty ..to compile it myown , of course it is your project and your decision...

Chadster766 commented 3 years ago

Yes btrfs would only need to be added to the kernel in that case.

Mark-GR73 commented 3 years ago

I,m waiting...

Chadster766 commented 3 years ago

I will add the btrfs kernel module to the next McDebian release but have not ETA on that at this time.

fakemanhk commented 3 years ago

Don't know if BTRFS inside kernel will be better than separate module? I have tried 5.x yet, but on my 4.19.91, I managed to compile the BTRFS module with dependencies, however after loading it and create partition with it the system became very unstable suddenly (and uptime showing system loading going up to 9.0, I needed to reboot), so even we compiled successfully, we shall test with actual usage.

One more thing, I hope we can include "veth" support virtual ethernet, so that we can run docker on top of it.

Chadster766 / McDebian