Itus Networks Shield Firmware v2 Released

Updated 7/25/2020: New Gihhub Org created to hold the repositories for both the code and the opkgs.
This update brings the system to kernel 5.4.52, updates the toolchain to musl 1.2.0, updates gcc to 10.x, and fixes the sysupgrade system, fixed the issue with luCi where the "MTD" device was invalid (we don't have MTD devices)

*******************************************

This thread is for the Itus Networks Shield Firmware v2 that I created.  This firmware is based on OpenWrt SNAPSHOT r13926+6-f94b09867d, built from the main branch.

This firmware only makes use of the BRIDGE and ROUTER modes, leaving the GATEWAY mode as a Recovery mode, or you can leave it as it came from Itus.  I would HIGHLY suggest the Recovery Mode option (instructions below)

These images DEFAULT to a 192.168.1.1 IP address.  These images DEFAULT to WAN on eth0, LAN on eth1 and eth2

This will remove the existing Itus Networks operating system and replace it

This Firmware is a BASE OpenWrt image.  It contains only the basic bootstrapped packages (include luCi) to get the system booted.  After the system is booted, you can add packages via opkg or luCi.

It is recommended you have a console cable, if available.  I've tested this many (many) times, but solar storms happen.

Instructions for Installation:

Installing the Recovery Image to Gateway (RECOMMENDED)

Download the file openwrt-octeon-itus-itusgateway-initramfs-kernel.bin

On the Shield:

mount /dev/mmcblk0p1 /mnt          ( NOTE: If you are already using a previous v2 firmware, this will be: mount /dev/mmcblk1p1 /mnt )

scp openwrt-octeon-itus-itusbridge-initramfs-kernel.bin to /mnt/ItusgatewayImage

Unmount /mnt so we don't potentially damage it...
umount /mnt

Place the switch in the (G)ateway mode, and reboot (Original Firmware owners use: reboot -f      v2 users can just use: reboot)

The system should be booted around 60-70 seconds.  The (M) light on the front panel will turn CYAN/GREENISH-BLUE when the boot is complete.  The network should be up at that point as well.

Congratulations!  You have successfully installed your new Recovery system..

This image is EXACTLY the same as the Router and Bridge images, except it does NOT use storage - it is completely RAM resident.  It's a LiveCD install, if that makes it easier to understand.  ANY CHANGES you make to the system (Network, Packages, etc) will NOT survive a REBOOT!

This is a good way to get a sense for the system, you can install packages, configure them, bring the networks up and down, etc, just note the above about reboots

Now that you have a stable recovery platform, it's time to move to the next step.  

Prior to this point, you've replaced the non-functional Gateway image with a working image.
ANYTHING FROM THIS STEP IS DESTRUCTIVE TO THE ORIGINAL ITUS FIRMWARE - YOU HAVE BEEN WARNED

Edited 7/25/2020: See Notes in First Post - Updated links.

Now it is time to decide which slot you want to use first.

There is NO practical difference between the modes, with the exception of the (M)ode light.  ROUTER is Dark Blue and Bridge is Orange (where-as the Recovery is Cyan).

After that, they are exactly the same, so it's really a choice of aesthetics.

openwrt-octeon-itus_shield-bridge-initramfs-kernel.bin
openwrt-octeon-itus_shield-router-initramfs-kernel.bin

Install the image to /mnt (see first post) to their respective names (ItusbridgeImage and ItusrouterImage) and unmount /mnt

Switch to the mode you selected, and reboot  (reboot -f is not needed, simple reboot works..)

System will boot, the (M)ode light will indicate boot complete.

Looks familiar?  It's exactly the same as the Recovery image.  Same rules apply, but we can fix that..

Download the sysupgrade file below for the Mode your targeting.
openwrt-octeon-itus_shield-bridge-squashfs-sysupgrade.tar
openwrt-octeon-itus_shield-router-squashfs-sysupgrade.tar

(Additionally, you can run the sysupgrade flie for the gateway mode (found in the repo), which will turn your gateway slot from a emergency recovery to full-storage image.  I would recommend leaving it as the recovery image unless you have need of additional slots)

You need to ssh/console to the Shield, and run the following command (depending on your mode selection!)

This WILL DESTROY your DATA!

ROUTER:
mkfs.f2fs /dev/mmcblk1p2

BRIDGE:
mkfs.f2fs /dev/mmcblk1p4

(Gateway: If you choose to utilize the Gateway slot as a proper slot: mkfs.f2fs /dev/mmcblk1p3)

Log into luCi (192.168.1.1), go to System | Backup / Flash Firmware.

Scroll to the Bottom:


Upload the sysupgrade file for the Mode you are in (Router vs Bridge).



Click Continue and wait for it to reboot and restart (Watch the (M)ode light!).

Once it is booted, you have successfully installed your new Itus Networks v2 firmware with perm. storage on the Flash-Friendly File System (f2fs).  Technical Geek note: If you have a console cable, you'll notice I now manage to pass proper kernel cmd lines and we don't have any of the waiting for root bunk anymore...

Once again, log into luCi (192.168.1.1) and change the Password (and install your ssh key, if you use one).  Change your Network settings to what you need it to be if 192.168.1.1 will not work in your environment.

There is a setting that needs to be set In Network | Firewall.  Turn ON both Software and Hardware Packet Offloading..



Next: Package installation

Updated 7/25/2020 (See first post): Removed need for custom distfeeds.conf - All repos are static from here on out.

Installing packages and making the Shield do things:

Go to System | Software, Click Update Lists.

Let it do it's thing, and then it'll finish and you'll have a enormous list of opks..  The binary repo is 1.4Gb in size..

Let's do some basic things to help you get accustomed to how this works.

In the Filter box, put: luci-theme



You'll see a few available.  The Bootstrap theme is not the best, I'm partial to the new 2020 theme.  Select one you want, click Install.



And, let it finish..



Congrats!  You've installed your first opkg!  To turn it on, go to System | System | Language and Style

You may also want to install the luci-app-commands package, as this will allow you to execute shell commands from the luci interface.   It isn't an interactive terminal, but it'll pipe to shell..



Next: Something more advanced - with hints..

This image is a BLANK SLATE - It is not pre-configured with much of anything..  Now, we will go over AdBlock..

Go to System | Software, enter adblock in the Filter box.



You will see Adblock and anything that contains "Adblock"..  Notice the luci-app-adblock package?  luCi packages are NOT part of the applications install..

My hint to you, if you look for a app, check to see if it has an existing luci-app- package for that package.  If so.. SELECT the luci-app verion!



Notice that a dependency of the luci-app-adblock is.. well, Adblock!  Installing the luci-app-adblock will install Adblock itself..

While we are here, Check to see if tcpdump is installed (not tcpdump-mini).  If it isn't already installed, please install it now (adblock uses it for reporting).

Reload the website, Adblock will appear under Services.

Some basic settings that I've used without issue:









I add Blocksources from oisd_nl and Youtube, in addition to what is defaulted.
 

Amazing work Grommish! I’m away at the moment but can’t wait to give this a shot, thanks very much for this!

I am still tracking down a few issues with the sysupgrade system.  It works, but it doesn't save everything I think it should..  But, that's an issue that can be addressed in the future.  This is good enough to run daily, or has been for what I use it for.

It should be noted that this is NOT the "Turn key" solutions we talked about in our collaboration.  This is a viable base-platform in which to build something on top of.  The advantage is that you don't necessarily need to use the Shield as a Router or a Bridge.. At this point, it is a unusually powerful System on Chip (SoC) device with three Gigabit Ethernet ports that runs Linux (Kernel 4.19 for now), gcc 10.1 (which causes it's own problem.), and musl 1.2.0 (the newest toolchain available).

I had thought about making making a VoIP server..

Maybe a iSCSI front end to a NAS?

Automatic Failover?  You could do an Inverted Router, have 2 WAN Ports and a Single LAN and allow it to failover for connectivity purposes.

Etc, etc.. I had to finally decide to remove the Itus preconceived "package" in order to make any sense in doing this for what may be the 4 or 5 of us total who might be interested in using the device still.

It SHOULD provide a platform for SOMETHING at least!

Assuming you have the bandwidth, it'll handle quite a bit of throughput.


You can find my source for the project here

Wow, nice work! Will definitely be trying this... What are your thoughts on the snapshot build? Stable?

The PLATFORM is stable, the device is stable, but it's just a platform to build on...

Some things to keep in mind:  If you are using your Shield in a production environment, take the time to play with the recovery before you commit to anything.  Keep in mind that if you're using the Shield in a production environment, you're using a device with inherent security flaws due to the age of the kernel and the packages..  That, honestly, was my main concern when starting this.

Installing the apps you want shouldn't be difficult.  Most of the popular applications all have luCi interfaces, but some do not (like snort/snort+, which I'm having issues with) and packages like e2guardian have been removed from OpenWrt completely.  I'm working on bring e2guardian back and updated, but it's just one of those things that "has to be done" in good time.  Just checking the repo, snort3/Snort+ built, but snort 2.x did not (probably because I'm using gcc10.1 rather than gcc8).  Snort3, if you install it, doesn't come with much pre-setup and doesn't have a luCi page.  So, if you want snort3, you'll have to work at it.  Those type of "turn-key" installs are something I (or anyone who wants to now that I've put the source up) can build out..  I would SUGGEST getting in touch with me if you want to try and build your own version, because the repo will build EVERY SINGLE PACKAGE and it takes forever (which is how we can have a opkg repo)

My goal is to migrate to kernel 5.4, but I'm having issues forward-porting the Ethernet drivers.  If any of you know a decent C programmer, send them this way hehe.  I can build (as evidenced by the dev thread) a 5.4 kernel, but the network fails to do anything.  One of those things, again, for the future.

Example idea:

You could, in theory, set eth0 and eth2 as WAN ports, eth1 as LAN port, using the mwan3 package to create a hot-failover WAN link with load-balancing..



I was wondering if OpenWrt has iSCSI packages and the Shield could be used as a NAS front-end

In any case, I am going to continue playing with the codebase.  For example, I just realized OpenWrt was build using -Os for space-constrained devices, and we probably would get BETTER results from an -O2 or -O3 - But, that's for later, and if I do go that direction, it'll be a sysupgrade file so at the worse, sysupgrade won't have been full fixed yet and it doesn't save some things (but saves others) - So an upgrade would simply mean resetting some things back up (Network settings get saved, for example, the password didn't, the theme didn't, etc).  it still needs to be looked at, but I figure what is here is stable enough to do what you need it to do.

Awesome work!

I take it the Itus theme was custom made?

Will have to dig out my shield and blow the dust off it :)

I've been using an Intel i7 router solution that sucks power and is loud running Sophos XG, this little device might finally be the answer!


What mode was that speed test screenshot taken in? I will probably want to use Bridged mode as I already have a Ubiquiti router I disabled the features on because it hurts bandwidth, etc so looking forward to test it.

harpss1ngh wrote

What mode was that speed test screenshot taken in? I will probably want to use Bridged mode as I already have a Ubiquiti router I disabled the features on because it hurts bandwidth, etc so looking forward to test it.

I run everything as a Router, and I've not tested a Bridge configuration (keep in mind, both images are identical until you change it).

I don't see why setup as a Bridge would hurt the speed any though.  I wasn't running Snort, though I was running Adblock.  Snort would probably drop it some, but I wouldn't expect TOO much.

The Itus version of OpenWrt, yes, I am working on bringing up the device so it can be included as an official device.  I've heard from some people that the Itus board was tested (at the time) for another manufacturer, so it's entirely possible someone will eventually bring it back under a different name.  But, for now, even if I can't get OpenWrt to include the device, being able to issue updates for the packages would already be in place.  It only becomes an issue when kernel gets updated (and I'm still working on 5.4).

Funny enough, if/when the Shield gets into OpenWrt, it'll share the repo with the Edgerouter and ER Lite..  Though, we've got better specs :D


(See how nice I made it look)

It's nice that you did the opkg repo... I'm rusty but I think I remember having to get everything manually from the generic mips64 one.
I think I'm going to get this going as a router with DNSCrypt, DNS hijacking, bufferbloat package, and maybe adblock. You've really made it easier w/ the package manager fix. It should be a really powerful router.

What version of OpenWrt is the snapshot build based off of?

user8446 wrote

What version of OpenWrt is the snapshot build based off of?

Master branch as of 7/13? Maybe the day before.  However, I keep the packages outside the core updated (the ./scripts/feeds update -a) which doesn't change the kernel or core (unlike git pull)

As of this post, my fork reads:   This branch is 8 commits ahead, 21 commits behind openwrt:master

This is the build repo: https://github.com/Grommish/openwrt/tree/r13832+6-2dc5ce622a

user8446 wrote

I think I'm going to get this going as a router with DNSCrypt, DNS hijacking, bufferbloat package, and maybe adblock. You've really made it easier w/ the package manager fix. It should be a really powerful router.

Oh ho, then you can help test is this works :)

https://marc.info/?l=linux-crypto-vger&m=159428481428796&w=4

Balance the irqs of the marvell cesa driver over all
available cpus.
Currently all interrupts are handled by the first CPU.

From my testing with IPSec AES 256 SHA256
on my clearfog base with 2 Cores I get a 2x speed increase:

Before the patch: 26.74 Kpps
With the patch: 56.11 Kpps

I can also be a guinea pig as I don't use the shield in production. I don't have any C knowledge but I have plenty of linux knowledge from my day job :)

That is far more valuable than you realize in a situation like this.  Especially given the barebones environment.

Anyone who finds an enhancement, it can be included into the build framework.  I know the Shield works, now we have to make it work well :D

AFAIK, unless the eMMC chip gets physically damaged, it's almost impossible to brick the Shield, so.. go wild!

Went to give the gateway/LiveCD partition a shot and ran out of time but it would never give an IP on multiple reboots. The image is definitely there:



It's definitely the Cyan LED:

Interesting..

if you do uname -a does it report 4.19 or 5.4?  I had an early 5.4 build that did NOT have the ethernet driver enabled, which would cause what you see to happen.  I corrected that fairly early but maybe that is the one you have.  None of the 4.19 images should be effected by it though.  Please let me know!

Can you do me a favor and try this file (https://github.com/Grommish/shield_opkgs/raw/r13871-546e140382/targets/octeon/generic/openwrt-octeon-itusgateway-initramfs-kernel.bin) as your ItusgatewayImage?  This is the latest test build under the 5.4 kernel / musl 1.2.0 / gcc10 toolchains.

user8446 wrote

Went to give the gateway/LiveCD partition a shot and ran out of time but it would never give an IP on multiple reboots. The image is definitely there:



It's definitely the Cyan LED:

I was on 4.19 but now I'm on your latest 5.4 build you linked. Still won't give an IP address so it's not on your end. I remember there being a random bug before w/ the shield where you couldn't get an IP on the LAN until it got an IP on the WAN but I just eliminated that. I connected it to a modem today where yesterday I was only on the LAN.
I'll try my 2nd spare shield when I get a chance

Please let me know..  

I know that ethernet driver issues will cause issues similar to the "bug" your describing, since eth1/eth2 are bridged and static IP'ed by default.  To doing an ifconfig would show the br-lan IP and nothing under eth0, but would seem to work once you "got a WAN IP"..

Well, I think it's just because it decided to work at all and the WAN IP is a easy and visible variable to check.  I am concerned you saw any issues at all on a 4.19 build though, I'll have to retest it.  All of this was a swirling cloud as to  how the target was setup, how it was sharing space, etc, then the jump to 5.4..  It was a mess.

By default, OpenWrt uses eth1 as WAN and eth0 as LAN.  I set it so it should at least be eth0=WAN, eth1/eth2=LAN by default.. If you get into a No-IP situation, will you check /etc/board.d/01_network and make sure that is there?  If not, try hooking it up WAN=Eth1, LAN=eth0.

root@Shield:/# cat /etc/board.d/01_network
#!/bin/sh
#
# Copyright (C) 2014-2015 OpenWrt.org
#

. /lib/functions/uci-defaults.sh

board_config_update

case "$(board_name)" in
itus*)
        ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0"
        ;;
*)
        ucidef_set_interfaces_lan_wan "eth0" "eth1"
        ;;
esac

board_config_flush

exit 0
root@Shield:/#

I'm still working on things, so we'll get it figured out :)