Search the Community

Hi! I've been reading a lot about iptables in last few days but I can't get my head around the configuration that I need. I'm still learning and this is beyond my scope. I've set the Rock64 as an access point connected to a vpn server. I need to access any devices that are connected to my main router in 192.168.10.1. My wlan access point is in 172.24.1.1. eth0 and wlan0 are always tunnelled through tun0 and it must stay that way. Connected from wlan0 I can ping 192.168.10.176 (eth0) but not 192.168.10.1 (Internet router) or anything else outside wlan0 subnet. My aim is to access smb servers, nfs servers and ssh to any ip in this subnet 192.168.10.x from wlan0 while connected to the vpn and viceversa. Is this even possible? This is my ip route output: ip route 0.0.0.0/1 via 10.8.8.1 dev tun0 default via 192.168.10.1 dev br0 10.8.8.0/24 dev tun0 proto kernel scope link src 10.8.8.55 128.0.0.0/1 via 10.8.8.1 dev tun0 169.254.0.0/16 dev wlan0 scope link metric 1000 172.24.1.0/24 dev wlan0 proto kernel scope link src 172.24.1.1 185.44.76.118 via 192.168.10.1 dev br0 192.168.10.0/24 dev br0 proto kernel scope link src 192.168.10.176 output of ip addr: ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000 link/ether 9e:0d:db:d2:f9:a1 brd ff:ff:ff:ff:ff:ff 3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 9e:0d:db:d2:f9:a1 brd ff:ff:ff:ff:ff:ff inet 192.168.10.176/24 brd 192.168.10.255 scope global br0 valid_lft forever preferred_lft forever inet6 fd7c:b18a:e451:0:9c0d:dbff:fed2:f9a1/64 scope global mngtmpaddr valid_lft forever preferred_lft forever inet6 fe80::9c0d:dbff:fed2:f9a1/64 scope link valid_lft forever preferred_lft forever 4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 08:10:7b:15:4a:31 brd ff:ff:ff:ff:ff:ff inet 172.24.1.1/24 brd 172.24.1.255 scope global wlan0 valid_lft forever preferred_lft forever 6: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100 link/none inet 10.8.8.55/24 brd 10.8.8.255 scope global tun0 valid_lft forever preferred_lft forever and this is my iptables: # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *raw :PREROUTING ACCEPT [6734:463678] :OUTPUT ACCEPT [6489:2129649] COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *mangle :PREROUTING ACCEPT [6734:463678] :INPUT ACCEPT [6730:463225] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [6489:2129649] :POSTROUTING ACCEPT [6571:2139731] COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] -A POSTROUTING -o tun0 -j MASQUERADE COMMIT # Completed on Thu Sep 20 11:15:24 2018 # Generated by iptables-save v1.6.0 on Thu Sep 20 11:15:24 2018 *filter :INPUT ACCEPT [10:1262] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [16:2170] -A FORWARD -i tun0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i wlan0 -o tun0 -j ACCEPT COMMIT # Completed on Thu Sep 20 11:15:24 2018 This is my /etc/network/interfaces: # Network is managed by Network manager auto lo iface lo inet loopback auto br0 iface br0 inet dhcp bridge-ports eth0 wlan0 And finally my hostapd.conf just to show that I've commented br0 in order to be able to tunnel wlan0 traffic throug the vpn. If I uncomment it I can access the other devices but wlan0 stops being tunneled # # armbian hostapd configuration example # # nl80211 mode # ssid=ARMBIAN interface=wlan0 #bridge=br0 hw_mode=g channel=40 driver=nl80211 logger_syslog=0 logger_syslog_level=0 wmm_enabled=1 wpa=2 preamble=1 wpa_psk=66eb31d2b48d19ba216f2e50c6831ee11be98e2fa3a8075e30b866f4a5ccda27 wpa_passphrase=12345678 wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP auth_algs=1 macaddr_acl=0 noscan=1 Many thanks for any help given!

IMO push them to open the repo immediately only to tell them after its: well no mainline no armbian is a bit.... questionable. You knew exactly before that there won't be a mainline kernel, you knew that the only efforts in mainlining the SoC is done by Andreas Färber and not Realtek and that he as a 'lone survivor' will probably not be ready to deliver a mainline (based) linux soon. Assuming you would be a copyright holder (for parts of the kernel) and we take https://github.com/torvalds/linux/blob/master/Documentation/process/kernel-enforcement-statement.rst as a baseline for 'being good' (at least a bunch of kernel developers signed it) you informed them on September 4th that they have a GPL violation and on September 19th they released the sources (15 days). Assuming you're the first one who noticed the GPL violation, the majority of the kernel developers would agree that they act as they should. For sure someone more experienced in kernel-development and bsp kernel-quality would have to check it first. But as said a full check of the BSP kernelsources was (until yet) never a prerequisite for provide Armbian with BSP-kernels. It's also obvious that this SoC is far away from mainline support and that some of the interesting features will probably never run in mainline (e.g. the whole encoding and decoding stuff cause it is partly, as far as I understand, behind some blobs e.g. 'bluecore.audio'). But as an other example, pinebook is marked as 'supported'. 3.10 got EOL a year ago (and was likely never fully reviewed too) and mainline has (as far as I know) issues with the PMIC (which will be important for a 'notebook') and only marked as beta. By those standards Pinebook should go back to wip or CSC. I completely agree that at least a headless usable mainline based linux should be available before we start to support a new SoC. I also agree that support SoCs which have only one available board is questionable (the efforts maintaining just a new set of kernels BSP/Mainline is just too much for one board - expect the MT7623 for which I might prepare a PR as soon as we reach the next LTS kernel, it works without major issues on mainline without patching, so it's only an adjustment of the config file, something I think isn't that much work I may write a THS patch cause those settings are IMO a bit conservative). But a full check of the BSP kernel as prerequisite is IMO double standard - we didn't do it for any BSP kernel in the past and this should be IMO discussed in the developer subforum first before we define it as a new standard - in this case we had to drop a bunch of 'suggested' images from the download page (e.g. RK3399, RK3328 Rock64/Renegade, A64 Pine64 et al, ). For all those boards we suggest to use the BSP kernel..

Ok, I'm halfway through setting my vpn router, I still need to change the iptables rules so I can access the local network devices through the armbian access point. I've got some interesting results after enabling the access point and routing all my traffic through tun0. My first surprise was that without implementing any of the jmandawg suggestions about isolating core 2, from my laptop. Connected to the ARMBIAN access point and routing the traffic through tun0, I ran speedtest and I got constant speeds of 72mbit/s which is almost the maximum I can reach from my connection, pings were 28ms, the minimum I reach even without the vpn, directly from my router. I'm very pleased with this performance and I wasn't expecting it. I suppose the fact that the Rock64 only job in this scenario is to encrypt and the run of the tests, web browsing and any other processing is done by my laptop shows the real encrypting potential of the openvpn running in the rock64 without any tweaking. The next step was to test the speedtest from the Rock64 directly, results: 25mbit/s speeds and pings of 40ms. Expected Then I implemented jmandawg suggestions the results from my laptop didn't vary a bit, they were excellent before and stayed the same. The results from the Rock64 directly varied greatly. When I ran the tests with "taskset -c 1 speedtest-cli" the results are 68mbit/s and ping 28ms. Same test, this time only "speedtest-cli" and the speed went down to 23mbit/s or maximum 30mbit/s I don't fully understand why if I've isolated a core for openvpn, I still need to isolate another core to run another program in order to achieve good performance with openvpn. Shouldn't it be enough to have core 2 isolated? Another thing is I didn't have "/etc/systemd/system/openvpn.service" The only other place where I found openvpn.service and where I made the changes is "/etc/systemd/system/multi-user.target.wants/openvpn.service" Could this be affecting anything? I don't run my openvpn through the network manager but by the openvpn command

Honestly: I think you're the only one doing this The reasons to specify these settings are as follows: CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough) CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary) I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

Boot priority with Rockchip boards is AFAIK always eMMC first then SD card. So once RK3399 finds a bootloader signature on the eMMC it will boot from there even if a bootable SD card is inserted. If you want to reflash eMMC in this situation you either need to use Maskrom mode (or how it's called exactly) which requires another host and USB delete the bootloader on the eMMC (can be done from the running system: 'dd if=/dev/null of=/dev/mmcblk1 bs=1M count=64 ; sync') I successfully bricked my NanoPC-T4 while developing with nand-sata-install and now have working bootloader on the eMMC that is not able to boot a kernel so I'm locked out and would need to try variants 2) or 3) here: http://wiki.friendlyarm.com/wiki/index.php/NanoPC-T4#Flash_Image_to_eMMC (which is not that easy since my physical x86 machines all run macOS and my Linux boxes are all ARM based -- I might try a VM with USB pass-thru soon) I asked @mindee for help but his advice to boot an eflasher image from SD card doesn't work since I have a working bootloader on the eMMC (but an otherwise bricked system). Would be great to temporarily disable the eMMC as it can be done on Rock64 and RockPro64 (a jumper allows the eMMC to be grounded or something like that so you can boot with this jumper set from a bootable SD card inserted and if you remove the jumper within 2 seconds after boot you can even access the eMMC afterwards to flash a new image)

It's not that I'm fighting for seconds. It was more curiosity. If i can use this thing after ~30 seconds everything is OK. My TV or satellite receiver are slower :D I will buy a Rock64 next month for another use case (surveillance cam display h265) and then i will see how the boot time is there. And if there is no difference in boot time between SD and eMMC i now know i don't need a eMMC there.

Well, don't think so. You asked another entirely different question: And... Rock64 will boot way faster than your outdated Banana Pi regardless of the boot media. But as already said: if you're interested in a specific use case IMO you should look also at this use case. Stop watch waiting for login prompt is pretty much irrelevant for 'wireless NAS being ready to serve' Check your own armbianmonitor -u output for 'link becomes ready' occurrences then you know how much time it already takes since the kernel has started for the wireless link to come up. I've seen quite some delays with some USB wireless dongles in the past so this is something at least I would take care of.

Ref: https://www.cnx-software.com/2017/11/27/amlogic-s905x-vs-rockchip-rk3328-vs-allwinner-h6/ CPU wise roughly: RK3399 > Amlogic S912 > Allwinner H6 > Amlogic S905X = RK3328 On the other hand, there are very few H6 based TV Box and majority of them are based on S912/S905W and RK3328. Some of the RK3328 based boxes have the advantages of higher memory and storage) (4GB/64G) compared to S912 based (usually 3GB/32GB) and S905W based (usually 2GB/16GB). I like my recently bought X96 Mini but I also ordered Rock64 and RK3328 based box (H96 Max 4GB/64GB) and S912 based box (H96 Pro Plus 3GB/32GB) to play with Android and follow the Armbian development here. The RK3328 based TV box is actually more expensive than S912 based because of the higher memory/storage.

I've done what you suggested and the result has dramatically improved the speed: from 21 mbit/s to 50-55mbit/s I thought that by having the crypto extensions enabled in ARMv8 the performance of Openvpn would automatically rocket compared to the raspberry pi for instance without need to alter anything. This the output, I've noticed that the ping is 55% higher through connections from the Rock64 than from my laptop, that could be interfering with the speed: WITH VPN AND CORE 2 ISOLATED FOR OPENVPN_____________ Linux 4.4.152-rockchip64 (rock64) 09/15/2018 _aarch64_ (4 CP$ avg-cpu: %user %nice %system %iowait %steal %idle 0.28 0.00 0.25 0.02 0.00 99.45 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.01 0.00 108 0 mmcblk1 0.39 16.28 0.22 242009 3240 zram0 0.11 0.05 0.38 736 5584 zram1 0.02 0.08 0.00 1196 4 zram2 0.02 0.08 0.00 1196 4 zram3 0.02 0.08 0.00 1196 4 zram4 0.02 0.08 0.00 1196 4 avg-cpu: %user %nice %system %iowait %steal %idle 11.94 0.00 0.70 0.00 0.00 87.36 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.00 0.00 0 0 ping -c 5 185.44.76.118 PING 185.44.76.118 (185.44.76.118) 56(84) bytes of data. 64 bytes from 185.44.76.118: icmp_seq=1 ttl=49 time=25.5 ms 64 bytes from 185.44.76.118: icmp_seq=2 ttl=49 time=24.6 ms 64 bytes from 185.44.76.118: icmp_seq=3 ttl=49 time=24.7 ms 64 bytes from 185.44.76.118: icmp_seq=4 ttl=49 time=26.1 ms 64 bytes from 185.44.76.118: icmp_seq=5 ttl=49 time=24.9 ms --- 185.44.76.118 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 24.633/25.221/26.146/0.572 ms WITHOUT VPN AND CORE 2 ISOLATED FOR VPN ------------------------Linux 4.4.152-rockchip64 (rock64) 09/15/2018 _aarch64_ (4 CP$ avg-cpu: %user %nice %system %iowait %steal %idle 0.30 0.00 0.27 0.02 0.00 99.42 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.01 0.00 108 0 mmcblk1 0.39 16.06 0.24 242009 3608 zram0 0.10 0.05 0.37 736 5584 zram1 0.02 0.08 0.00 1196 4 zram2 0.02 0.08 0.00 1196 4 zram3 0.02 0.08 0.00 1196 4 zram4 0.02 0.08 0.00 1196 4 avg-cpu: %user %nice %system %iowait %steal %idle 13.59 0.00 2.14 0.00 0.00 84.27 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn mtdblock0 0.00 0.00 0.00 0 0 ping -c 5 86.158.85.129 PING 86.158.85.129 (86.158.85.129) 56(84) bytes of data. 64 bytes from 86.158.85.129: icmp_seq=1 ttl=63 time=2.46 ms 64 bytes from 86.158.85.129: icmp_seq=2 ttl=63 time=6.16 ms 64 bytes from 86.158.85.129: icmp_seq=3 ttl=63 time=2.82 ms 64 bytes from 86.158.85.129: icmp_seq=4 ttl=63 time=6.07 ms 64 bytes from 86.158.85.129: icmp_seq=5 ttl=63 time=4.89 ms --- 86.158.85.129 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 2.462/4.484/6.167/1.575 ms If there aren't any further improvements that can be implemented to improve the performance of openvpn, I will try to use wireguard, it sounds like the ideal solution for devices like ours. If anyone thinks that the openvpn performance should be better than what we've seen in this post, I'm all ears. Thanks all for your answers

I would use something a little more reliable than speedtest.net, try using curl. Here are my results using my renegade (almost same hw as rock64): Without vpn (direct connection): root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 812M 100 812M 0 0 2948k 0 0:04:41 0:04:41 --:--:-- 4202k With openvpn: root@renegade:~# curl -L http://www.gtlib.gatech.edu/pub/ubuntu-releases/18.04/ubuntu-18.04.1-live-server-amd64.iso > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 812M 100 812M 0 0 1758k 0 0:07:52 0:07:52 --:--:-- 1856k This is using windscribe vpn. I think the only way to truly test openvpn speed would be on your internal network. I may try it when i have time.

I guess you are right, at least for what I tried with Rock64 and Armbian I have USB3.0 problems mentioned elsewhere on this forum and on https://forum.pine64.org/showthread.php?tid=5137&pid=37535#pid37535 I used tips above for an el cheapo USB3.0 JMS597 SATA adapter cable 0x152d:0x0578 In Armbian 5.59 I had read/write speed around 80MBps ish using samba (varying between 109 and 70) But with read, after a few seconds full speed, it froze for 10-15 sec, no errors in the transferred data, but with "ERROR Transfer event for disabled endpoint or incorrect stream ring" in dmesg every time it froze. With above tips I don't have freezes anymore, and using samba as server and W10 client, write speed still 80MBps ish, but read speed down to 50MBps. And as you predicted, I have now another error : "reset SuperSpeed USB device number 3 using xhci-hcd" But not in red :-) and without any noticeable delay. Hopefully the USB "ERROR Transfer event for disabled endpoint or incorrect stream ring" gets solved soon. Ill do some more testing on Pine and Armbian. Also always interested if you have better fixes.

Well I can confirm that the 155 image @igor provided works on my 4gb rock64, also. I admit that I only did the most basic of testing, loging in, running nano, ps and ls etc. Is there a specific command or test I should run to confirm all is as expected?

Is it simply not pingable, or is it just plain not booting? Can you give me the age of the Rock64 and the part number of the Ethernet chip? Power domains, time to reset/bring up the SD card might not be waiting long enough either (I think it simply waits default 10 ms, might need a little longer) Can everyone involved please give me the exact SD cards being used, or even pictures of them?

Hi everybody, I have experienced something very similar on my rock64. The HDMI output isn't working -- is this normal with the headless armbian? Also when starting the rock64 (most times on a soft reboot) with the armbian image, which is connected via ethernet -- it dosen't seem to use the ethernet connection. The rock is not pingable. Sometimes I have to hard reset the rock and/or to unplug the ethernet cable and replug it. Then it is pingable and I can connect via SSH. This behaviour is very annoying and I am running out of ideas. I am thankful for every idea. best regards

No worries, my rock64 is happy with all of my cards and various images, so I have a hard time verifying... And yes, I confused the boards, but the patches are to the dtsi, so should affect both builds equally. I noticed late last night the added clocks for rk3328 dw-mmc controller had one that I believe to be a typo (ciu-drv instead of ciu-drive), which is corrected in the Renegade dts. It involves phase correction/adjustment, I didn't think much of it since Rock64 doesn't have UHS capabilities to my knowledge and I thought the phase adjustments wouldn't be fooled with. I'll see if my board is complaining about it, fix it, and post it. (Should push to Ayufan)

I guess you mean in my Renegade, since I don't have a Rock64. Bad news is that today I traveled and won't be back home until Sunday. Will do then, G.w.

Hello All. I am fairly new in Embedded Linux and in this forum. I need to develop a small size IoT ARM Quad Core Board. I like to have some advise on my project's proper development path. First let me share my target needs of the project: -1. ARM CPU (run Linux) - I think for my project, Quad-Core is more than enough -2. RAM 1GB/2GB -3. eMMC 16GB for OS Boot -4. SD Card for file storage (up-to 512GB) -5. Two USB2.0 (One Host Mode and One Device Mode) and one USB3.0 (Only Host Mode is Ok. Its for faster file transfer to connected external Portable HDD) -6. Capacitive Touchscreen 3.5 Inch (as we will run some Python based GUI App) -7. Sensor connection via GPIO, UART, I2C, SPI (Sensors are Ambient Light, Sound, Motion PIR, 9-Axis MEMS Accelerometer, Gyro, Magnetometer) -8. Wireless including GPS, WiFi and Bluetooth 5.0 -9. Small Form factor (if find any Core CPU Module is great, else need to do custom PCB design) -10. Less heat generation Now based on the above spec USB 3.0 feature makes my choice very narrow as there are very few CPU supports USB 3.0. So far I am thinking about RK3328 or Allwinner H6. RK3339 will be great and more powerful but its very costly so don't wanted to use it. My ques are: - Based on my online research for start development I can use Orange Pi Lite 2 (in case of Allwinner H6) or Rock64 (for RK3328). But which one will be best choice for my project? In terms of implement features, easy of development, available online resource ... etc? - is there any Open Hardware project which I can consider as base of my study. All the available SBC's are open source and only Schematic is available. - Anyone know any small Core CPU Module (SMT or DPI) based on the H6 or RK3328)? Thanks. Looking forward your guideline. Regards.

Hey there! I too am trying to get my 4gb rock64 to "work". I am willing to be added to the sample set. :) Thus, should I use this image? New image: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.155.7z

@Vin New image: https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.155.7z

I didn't get any feedback on you about the HDMI hotplug, however on some favorable testing on a Renegade I've pushed a patch into the build system to set the drive levels on the SD to 8mA, up from 4mA. I don't have a failuyre to boot issue with my SD cards, supply and Rock64, however a sample size of 1 is not representative, and my conclusion was that bumping all rk3328 devices to 8mA was advisable. At @Igor's discretion this can be built for nightly or test.

Hi Thanks. Sorry for my typo on 3329. I mean 3399. Great to know about SOM204. But it will be long time to wait till 2019. Do you know how the performance of 3328 Boards like Rock64 for USB 3.0 Data? Regards.

For the "Recover" button -> https://github.com/ayufan-rock64/linux-u-boot/commit/ea6efecdfecc57c853a6f32f78469d1b2417329b

Thank you very much for reply. I personally more biased with RockChip than Allwinner. However, I did checked the prices of CPU's but 3329 is very expensive and it gets exceed or target BoM cost that's why I am more like to use 3328. But surely I agree 3329 in current trend and resource, support is more rich. How will be to use 3328 you think and If I consider my development based on Pine64's Rock64 or Firefly's ROC-RK3328-CC? Regards.

@Igor if you've the time to humor the topic some more, the patch below is changing the pin drive levels to 8 mA from 4. I'm building a rock64 image now to test, of course I have the old board, I don't know if anything besides the ethernet has changed. I'll see if I can force modes and observe errors. kernel-rockchip64-default.patch

Kernel changed back to the one used in that OMV image. https://dl.armbian.com/rock64/archive/test/Armbian_5.59_Rock64_Debian_stretch_default_4.4.154.7z