McDebian 5.6.14 Beta

[Chadster766]

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]

Very cool!!! Thanks for working on this. I'll see about testing it soon.

[Chadster766]

It's working awesome!

[sfrost]

Wasn't so good for me- got:

NAND read: device 0 offset 0xa00000, size 0x500000
5242880 bytes read: OK

Booting kernel from Legacy Image at 02000000 ...

Image Name: linux
Created: 2020-05-26 10:57:42 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 5324557 Bytes = 5.1 MiB
Load Address: 00200000
Entry Point: 00200000
Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
Marvell>>

[Chadster766]

Which WRT model do you have?

[sfrost]

It's a WRT1900AC v1

[sfrost]

-rw-r--r-- 1 root root 4935885 Feb 14 02:45 McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_4.19.91.img
-rw-r--r-- 1 root root 5324621 Jun 2 00:26 McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_5.6.14.img

are the two kernels I've tried, with the first working just fine, but the second throwing the above error.

root@nord:~# sha1sum McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_*
0c030806180cf8178666fd679f8afafc160f7b09 McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_4.19.91.img
434448cad51bc404b26498913a1721a34f0f4090 McDebian-Buster-WRT1900AC-V1-FW_VER1_kernel_5.6.14.img

[Chadster766]

Thanks I will start troubleshooting this on my WRT1900AC V1.

[Chadster766]

I checked the checksum and it matches your results.

The update loaded fine on my WRT1900AC V1.

Double check you have the below set in u-boot:

pri_kern_size=0x500000
alt_kern_size=0x500000

[ValCher1961]

Hello Chad!

I think it was #7 (comment)
The bottom line is that the value of pri_kern_size and alt_kern_size should be larger than the actual size of the kernel.

[Chadster766]

Hi @ValCher1961 😃

I've had issues with CRC before but it's been intermittent. It would be great if @sfrost could confirm that your solution works for him.

Strange though that 0x500000 works for me.

[sfrost]

I've had them set to 0x500000 for a long time.

root@nord:~# fw_printenv pri_kern_size
pri_kern_size=0x500000
root@nord:~# fw_printenv alt_kern_size
alt_kern_size=0x500000

I can certainly try increasing that... Not sure why it's working for you and not for me.

[Chadster766]

@sfrost did you try @ValCher1961 suggestion to calculate the kernel size?

[Mark-GR73]

Greetings ....from Greece
The McDebian 5.6.14 beta looks like very stable on
WRT 3200 acm.
I would like to help your team for this project.
The kernel edition looks like more racing and more flexible, i think.
Anyway at least 4 days this beta edition i believe for wrt 3200 acm pass the tests.
The log was clear without issues ,and of course the switching/routing is fast without conflits.

[Chadster766]

Hi @Mark-GR73,

I'm glad its working well for you.

Did you implement the nftables flowtable?

I'm not sure were to go with McDebian. At this point everything I wanted to accomplish with this project has been completed with the upcoming release. All I need to do going forward is kernel updates and Debian rootfs updates on a regular basis.

I would have liked to implemented McDebian on some other routers like the EA9500 but they use the Broadcom CFE boot loader which I'm not familiar enough with.

I have created a McDebian-Portable project (not uploaded to Github) which can be cloned to a USB Key or drive that boots Debian on UEFI, MBR, x32 and x64 systems (universal) with some built in IT utilities like Pogostick for resetting Windows user password for service. I've been experimenting with implementing Docker containers, KVM hypervisor and ZFS filesystem (or ZFS Raidz) for open source server deployments but it's a lot of work unless I opt for the unRaid approach which is good as well I suppose.

[Mark-GR73]

Thanks for your reply.
I did exactly as you write above,
But i have no rules yet or portforwarding or any myown firewall rules.

You make all this work ,i believe the cfe of broadcom it is a peace of cake for you.
You will need cfetool ,frhed (hex program to read/write cfe parameters) and of course the must clis ...if you would like i can send you some examples from Linksys EA 6900 to Asus rt u 68 or for older e3000.
It is very simple...

Your job is a wild horse.
My opinion if it was better with kali or parrot penetrate distros..we have router and no just a pc, we need dirty ways for solutions !

But you break the rules..
Bravo..

[Chadster766]

@Mark-GR73 I don't do penetration testing in my IT work. Its only when customers forget their new passwords or admin passwords that I use Pogostick to reset it for them.

Other than that I use McDebian-Portable to repair partitions and drives.

[Chadster766]

@Mark-GR73 CFE is complicated when it comes to configuring it to boot from usb. Especially since it also requires a initrd packed into the firmware.

[Chadster766]

@Mark-GR73 yes please send me those CFE samples.

[Mark-GR73]

On Weekend ,i hope to send you.
In other hand i have problem with nftables..
After restart where was not internet.
With many tries if remove from br0 the post-up nft -f /etc/nftables.conf
Everything OK.

My interface config:
################################################################
auto wan
iface wan inet dhcp
hwaddress ether 02:e0:96:70:5f:c3
pre-up iptables-restore < /etc/iptables.up.rules
pre-up ifup --ignore-errors br0

iface wan inet6 auto
pre-up ip6tables-restore < /etc/ip6tables.up.rules
auto br0
iface br0 inet static
bridge_hw 02:2d:50:bd:ca:13
bridge_ports lan1 lan2 lan3 lan4
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /etc/network/mcdebian-model-check

post-up nft -f /etc/nftables.conf

################################################################

propably something wrong with nftables.conf ,i think
-Of course i did not type systemctl enable nftables.service.

[Mark-GR73]

A typing wrong

################################################################
auto wan
iface wan inet dhcp
hwaddress ether 02:e0:96:70:5f:c3
pre-up iptables-restore < /etc/iptables.up.rules
pre-up ifup --ignore-errors br0

iface wan inet6 auto
pre-up ip6tables-restore < /etc/ip6tables.up.rules
auto br0
iface br0 inet static
bridge_hw 02:2d:50:bd:ca:13
bridge_ports lan1 lan2 lan3 lan4
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /etc/network/mcdebian-model-check
(#post-up nft -f /etc/nftables.conf) ----> without ()

[Chadster766]

Comment out line "pre-up ifup --ignore-errors br0"

Run nft commands to check if it works:

nft -f /etc/nftables.conf

root@MCDEBIAN:~# nft list tables
table ip filter
table ip mangle
table ip nat
table ip6 nat
table ip6 mangle
table ip6 filter
table inet x

If "table inet x" is listed then the flowtable is active.

[Chadster766]

If you have an older McDebian rootfs you may need to "apt-get install nftables".

[Mark-GR73]

-With this type of config ,the results for the wan side are OK ...

root@MCDEBIAN:~# apt list --installed | grep -i nftab
libnftables0/stable,now 0.9.0-2 armhf [installed,automatic]
nftables/stable,now 0.9.0-2 armhf [installed]

root@MCDEBIAN:~# nft list tables
table ip filter
table ip mangle
table ip nat
table ip6 nat
table ip6 mangle
table ip6 filter

root@MCDEBIAN:~# ls /etc/ | grep nfta
nftables.conf

Part-of etc/networks/interfaces file..
auto wan
iface wan inet dhcp
hwaddress ether 02:e0:96:70:5f:c3
pre-up iptables-restore < /etc/iptables.up.rules
(# pre-up ifup --ignore-errors br0)

iface wan inet6 auto
pre-up ip6tables-restore < /etc/ip6tables.up.rules

auto br0
iface br0 inet static
bridge_hw 02:2d:50:bd:ca:13
bridge_ports lan1 lan2 lan3 lan4
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /etc/network/mcdebian-model-check
(# post-up nft -f /etc/nftables.conf)

┌─[ote@parrot]─[~]
└──╼ $ping github.com
PING github.com (140.82.118.4) 56(84) bytes of data.
64 bytes from lb-140-82-118-4-ams.github.com (140.82.118.4): icmp_seq=1 ttl=56 time=54.4 ms
64 bytes from lb-140-82-118-4-ams.github.com (140.82.118.4): icmp_seq=2 ttl=56 time=54.7 ms
64 bytes from lb-140-82-118-4-ams.github.com (140.82.118.4): icmp_seq=3 ttl=56 time=54.8 ms

---

-But,
with /etc/networks/interfaces , like:

auto br0
iface br0 inet static
bridge_hw 02:2d:50:bd:ca:13
bridge_ports lan1 lan2 lan3 lan4
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /etc/network/mcdebian-model-check
post-up nft -f /etc/nftables.conf

root@MCDEBIAN:~# nft list tables
table ip filter
table ip mangle
table ip nat
table ip6 nat
table ip6 mangle
table ip6 filter
table inet x

root@MCDEBIAN:~# ip route
default dev ppp0 scope link
80.106.125.100 dev ppp0 proto kernel scope link src 94.65.238.202
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1

root@MCDEBIAN:~# ping github.com
PING github.com (140.82.118.3) 56(84) bytes of data.
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=1 ttl=57 time=59.9 ms
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=2 ttl=57 time=60.4 ms

┌─[ote@parrot]─[~]
└──╼ $ping github.com
ping: github.com: Temporary failure in name resolution

---

And of course if a remove the line
post-up nft -f /etc/nftables.conf

root@MCDEBIAN:~# ping github.com
PING github.com (140.82.118.3) 56(84) bytes of data.
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=1 ttl=58 time=51.10 ms
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=2 ttl=58 time=51.6 ms

┌─[✗]─[ote@parrot]─[~]
└──╼ $ping github.com
PING github.com (140.82.118.3) 56(84) bytes of data.
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=1 ttl=56 time=58.9 ms
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=2 ttl=56 time=58.9 ms

---

[Chadster766]

I think whats happening is you have a PPPoe internet connection and haven't updated the firewall files to work with that connection.

In McDebian the wan interface is the wan Ethernet port.

If you have a PPPoe connection you need to update the firewall files as described in this Wiki article:
https://github.com/Chadster766/McDebian/wiki/5.-Network-Configuration#configuration-for-a-pppoe-internet-connection

With this beta a third file will need to be updated for the ppp0 interface:

sed -i s/wan/ppp0/g /etc/iptables.up.rules
sed -i s/wan/ppp0/g /etc/ip6tables.up.rules
sed -i s/wan/ppp0/g /etc/nftables.conf

If you didn't do these changes the firewall wouldn't be working on the ppp0 interface.

[Chadster766]

You can check if the flowtable is working by listing the flowtable. If the counter is going up it's working:

root@MCDEBIAN:/etc# nft list table inet x
table inet x {
        flowtable f {
                hook ingress priority 0
                devices = { wan, br0 }
        }

        chain y {
                type filter hook forward priority 0; policy accept;
                ip protocol { tcp, udp } flow offload @f
                counter packets 587943 bytes 95268611
        }
}

[Chadster766]

@sfrost any luck getting the firmware running on your WRT1900AC V1?

[Mark-GR73]

The connection to wan is pppoe .

with
sed -i s/wan/ppp0/g /etc/nftables.conf

and wiith configured as must the conf fille
/etc/networks/interfaces

auto br0
iface br0 inet static
bridge_hw 02:2d:50:bd:ca:13
bridge_ports lan1 lan2 lan3 lan4
address 192.168.1.1
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
pre-up /etc/network/mcdebian-model-check
post-up nft -f /etc/nftables.conf

then

┌─[ote@parrot]─[~]
└──╼ $ping github.com
PING github.com (140.82.118.3) 56(84) bytes of data.
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=1 ttl=56 time=53.8 ms
64 bytes from lb-140-82-118-3-ams.github.com (140.82.118.3): icmp_seq=2 ttl=56 time=54.0 ms

success responce from client side.

But the results from flowtable are empty..

root@MCDEBIAN:~# /etc/ nft list table inet x
Error: No such file or directory; did you mean table ‘nat’ in family ip?
list table inet x
^

or,

root@MCDEBIAN:~#/etc/ nft list table inet nat
Error: No such file or directory; did you mean table ‘nat’ in family ip?
list table inet nat
^^^

and of course as we said before,the connectivity status

root@MCDEBIAN:~#/etc/ ping -c 2 google.com
PING google.com (172.217.22.78) 56(84) bytes of data.
64 bytes from fra15s17-in-f78.1e100.net (172.217.22.78): icmp_seq=1 ttl=119 time=52.7 ms
64 bytes from fra15s17-in-f78.1e100.net (172.217.22.78): icmp_seq=2 ttl=119 time=52.7 ms

and ipv6

root@MCDEBIAN:~#/etc/ ping6 -c 2 google.com
connect: Network is unreachable

---

Thanks ....

[Chadster766]

No the flowtable config is working fine for McDebian.

Did you change wan to ppp0 in the
Iptables restore files as described in that article?

[LeBrad]

Thanks for this McBeta, It's great to have nftables.

However, I'm hitting a wired speed bottleneck on my 1900AC. I'm getting gigabit link speed between computers connected to the wired LAN ports, but speed drops to around 250 megabits/second when I connect one of the computers to the WAN port and one to the LAN.

I tried this with local computers and various cables to make sure it wasn't an ISP or wire problem.

When I run an iperf3 speed test with a link between WAN and LAN the cpu usage of the 1900AC spikes to almost 100%, with lots of ksoftirqd usage.

I wonder if this is a firewall issue, because I assume that the 1900AC is fast enough to masquerade at gigabit speeds. Also it could be a kernel issue and maybe i should just wait for the next update.

Anyway, I thought I'd ask if you have any other hunches about how to remove the bottleneck.

[Chadster766]

@LeBrad you will need to follow the flow offloading instruction in the below post:
#69 (comment)

To see if it's offloading the counter values will increase with internet usages on the LAN side:

nft> quit
root@MCDEBIAN:~# nft list table inet x
table inet x {
        flowtable f {
                hook ingress priority 0
                devices = { wan, br0 }
        }

        chain y {
                type filter hook forward priority 0; policy accept;
                ip protocol { tcp, udp } flow offload @f
                counter packets 1334054 bytes 177538514
        }
}

[LeBrad]

Thanks, hopefully my flow offloading is correct. I installed it using your instructions when I updated to the beta, and it doesn't seem to help with the bottleneck. Here's my firewall:

brad@cinefile:~$ date && sudo nft list ruleset
Mon 21 Dec 2020 05:40:09 PM UTC
table ip filter {
	chain output {
		type filter hook output priority 0; policy accept;
	}

	chain input {
		type filter hook input priority 0; policy accept;
		tcp dport { ssh, http, https } accept
		meta l4proto { tcp, udp } @th,16,16 53 accept
		iifname "br0" accept
		iifname "wan" ct state established,related accept
		iifname "wan" drop
	}

	chain forward {
		type filter hook forward priority 0; policy accept;
		tcp dport ssh accept
		tcp dport http accept
		tcp dport https accept
		tcp dport 22000 accept
		iifname "br0" accept
		iifname "wan" ct state established,related accept
		iifname "wan" drop
	}
}
table ip nat {
	chain prerouting {
		type nat hook prerouting priority 0; policy accept;
	}

	chain postrouting {
		type nat hook postrouting priority 0; policy accept;
		oifname "wan" masquerade
	}
}
table inet x {
	flowtable f {
		hook ingress priority 0
		devices = { wan, br0 }
	}

	chain y {
		type filter hook forward priority 0; policy accept;
		ip protocol { tcp, udp } flow offload @f
		counter packets 20348 bytes 2159513
	}
}

[Chadster766]

@LeBrad its seem to be offloading properly.

The firewall rules look ok.

Did you add sudo to your McDebian? I wondering if you are running a ubuntu variant.

Did you test iperf3 between to laptop and the WRT? This should get gigabit no matter what.

[LeBrad]

Yes, I installed sudo, apt-cache says sudo: Installed: 1.8.27-1+deb10u2

Testing iperf3 directly to the McWRT was a good idea, it revealed more info about the bottleneck! When my computer is the iperf3 host and the WRT is the client, the link gets full gigabit speed, but when the WRT is the iperf3 host and the computer is the client it only gets a fraction of that speed. Here's the bottlenecked result over a wired connection with the WRT as the host:

brad@u-turn:~$ date && iperf3 -c cinefile.local
Mon 21 Dec 2020 07:33:41 PM CET
Connecting to host cinefile.local, port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  19.7 MBytes   166 Mbits/sec   23    489 KBytes       
[  5]   1.00-2.00   sec  15.0 MBytes   126 Mbits/sec    0    560 KBytes       
[  5]   2.00-3.00   sec  16.2 MBytes   136 Mbits/sec    0    611 KBytes       
[  5]   3.00-4.00   sec  13.8 MBytes   115 Mbits/sec    3    454 KBytes       
[  5]   4.00-5.00   sec  15.0 MBytes   126 Mbits/sec    0    496 KBytes       
[  5]   5.00-6.00   sec  17.5 MBytes   147 Mbits/sec   25    379 KBytes       
[  5]   6.00-7.00   sec  15.0 MBytes   126 Mbits/sec    0    406 KBytes       
[  5]   7.00-8.00   sec  15.0 MBytes   126 Mbits/sec    0    427 KBytes       
[  5]   8.00-9.00   sec  15.0 MBytes   126 Mbits/sec    0    454 KBytes       
[  5]   9.00-10.00  sec  15.0 MBytes   126 Mbits/sec    0    479 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   157 MBytes   132 Mbits/sec   51             sender
[  5]   0.00-10.03  sec   155 MBytes   130 Mbits/sec                  receiver

iperf Done.

[Chadster766]

When doing throughtput testing with iPerf3 keep in mind that "-c" means the client is sending to the host and "-R" the host to send to the client. (upload or download from same iPerf3 host)

[Mark-GR73]

LeBrad, Interesting your nftables ,If you'like post the conf of nftables...

Finnally a solution for IPv6 settings for pppoe with Prefix Delegation from ISP.

Ipv6 Prefix Delegration pppoe.txt

Any additional idea or tip?

[Mark-GR73]

Hi,
Dear Chadster766 i need help for uboot
Of course i do not know if here is the right place for this kind of questions.......anyway;
I have the 5.6.14 release and not rootfs who i tried but never booted the kernel...

Now,
I have two ssds ,one connected to e-sata port and one more to usb3 port.
root directory is in esata disk ,which there are two partitions ...
-the usb3 has the /var /swap /tmp and /home. mounting from /etc/fstab-

Now what i need...

As primary boot
I want to boot McDebian ,to load the .img from esata from 2nd partition and the root dirs from the 1st partition from esata .

As alternative boot i would like the flexibility to boot a wrt image from internal nand ,for easier maintanance purposes..

Please can you advice me?
Of course we expecting the next McDebian ultra racing and clever release....

[Chadster766]

You need a drive connected to the WRT USB 2.0\eSATA port that has the McDebian rootfs and have that operational before you can do anything else.

[Mark-GR73]

Any wiki or to read something?
How the machine will Know at boot time from which device must load the .img file and root dir/s ?
I do not need for root-fs edition ,i need it for 5.6.14 ..

Thanks..

[Chadster766]

Any wiki or to read something?
How the machine will Know at boot time from which device must load the .img file and root dir/s ?
I do not need for root-fs edition ,i need it for 5.6.14 ..

Thanks..

https://github.com/Chadster766/McDebian/wiki/3.-Make-Root-File-System

[Mark-GR73]

Thanks for your reply.
It is a good start point for that i need.
Nice wiki but it is little bit hidden ...on web...

Could i be useful to Mcdebian project someway?

[Chadster766]

Thanks for your reply.
It is a good start point for that i need.
Nice wiki but it is little bit hidden ...on web...

Could i be useful to Mcdebian project someway?

Thanks but I'm not sure there is much to do at this point.

[Mark-GR73]

Success u boot booting to load image from esata.
Thanks to your wiki ,and older posts of you.

A nice question...

If the device's nand in this case /dev/mtd5 up to mtd 8 ,are empty ,is there possibility to work as ram ?

[Chadster766]

It's possible but I wouldn't recommend it.

This type of nand memory can be easily be destroyed by to many write operations where RAM isn't effected in that way.

[Mark-GR73]

Thanks...

[Mark-GR73]

Well ..
In usb 3 port add a usb3.1 to nvme m2.
At boot time the u boot not recognise it at all .
Is there something i must know?

[Chadster766]

Well ..
In usb 3 port add a usb3.1 to nvme m2.
At boot time the u boot not recognise it at all .
Is there something i must know?

You have to have your boot USB key in the USB 2.0 port due to a u-boot limitation.

Your other storage can be connected to the USB 3.0 port.

[Mark-GR73]

Finally , my previous set up was :
esata to sata as root mount,
usb3 to sata as /var swap /tmp and /home dir....
A good reason to have two buses divided interworkings and probably higher speed.
And two of them have the almost same speed with hdparm about 700 and 400 M.
Working perfectly that way....
-General the thought is that from esata protocol to usb3 in our case , of course the limits are the esata..

-If we try with nvme card ,m2 convertor to usb3 ....
With our topology to be :
nvme m2 to usb3 as root
and sata to esata mount as /var swap /tmp and /home dir....

The results have two different situations ....

u-boot-usb3.log.txt

u-boot-usb3.log2.txt

-Any opinion or advice?

[Mark-GR73]

It is converter's the problem , it is not possible to read it from any linux machine..
-Pure chinese machines....
It is convertor from nvme m2 to usb 3.1 of course backward compatible with usb3 protocol.

-I will try again but with nvme m2 to usb3 Hardware..

-Anyway...thanks..

[sfrost]

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]

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]

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

[Mark-GR73]

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]

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]

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]

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

[Mark-GR73]

I,m waiting...

[Chadster766]

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

[fakemanhk]

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.