Ok, Friday I will be given the serial cable. I'll let you know using the snapshot.
I remember asking the Turris people for netcat support by default but their response was that the only usable port would be the WAN port and having netcat exposed over WAN would be bad.
netcat would avoid needing serial.
Who wants to use OpenWRT must necessarily avoid Turris.
well said!
it is probably the best in class of all-in-one devices but not de-classing.
a very nice tinker device, but (hence?) has more quirks in comparison to price and performance than other solutions.
In the end with the serial cable, of course with a bit of imagination (given the smallness of the guide; but what do I expect? The ready meal? It's normal that I buy a new car, but I have to think about how to develop the engine and refine the oil for fuel) I managed to recover Omnia, this jewel of the 21st century! The state of human and divine art! With Turris OS however, that of installing OpenWRT there is no way. Let's say it's really forbidden!
After all my experience with Turris OS lead to the following consumption/solution:
- Don't use Turris devices as your router if you want to reach higher NAT/VPN speeds, use a X86 physical or virtual machine instead. Its just the same with all other embedded devices - none(!) will satisfy all of your needs if you are a real enthusiast.
- Use Turris Omnia or MOX as access point only and buy some compex WLE1216v5-20 for 802.11ac wave 2 WiFi. MOX could come in handy if one can really make use of POE availability.
- look for used devices, I got my second Omnia for 150€ on ebay and my MOX for 85€ in the turris omnia forum.
I have quite a hard time to get virtualization running - I am right now working on getting a x86-installation inside vm working which is just as pain as using those consumer bluff packages, even though I am using pure Intel Hardware by now for the virtualization....
I will for sure abandon the virtualization project as soon as I have to admit it doesn't work. Therefore...
...may I ask which devices exactly you are talking about?
Redo your eyes, but this is perhaps one of many. I do not know. I discovered them too late. You don't need virtualization here.
I ran into Turris, because they have great marketing and are committed to it, but I misunderstood their project, which is completely amateur, but presented as a professional thing.
1 Like
I wouldn't quite say that.
The ethernet driver's been getting really good upstream development. It even has XDP support!!!
As an access point it's not great. Maybe it is with good wifi cards...
apu is also an embedded device with a lowpower cpu. dont expect too much.
also i would not trust a shop that has an affiliate deal with a "vpn-vendor".
This is true. Then I too disagree with the affiliation to a VPN which is the stupidest thing in the world in that sense. But a piece of hardware remains that and you can install OpenWRT stock. Then it is clear that an amd64 APU is no different from a 32-bit or 64-bit Marvell ARM. But these also sell routers with an Intel i7 processor. Then it's just an example. There will be another thousand stores or a thousand ways to create your own device. However I contacted them and they are extremely available.
Mine is not a suggestion for purchases, it's just an example. And then have something to install the blessed OpenWRT without biting the world or having 90% less potential.
1 Like
Which is introduced with kernel 5.4 and will probably not make it into the OpenWrt stable branch for many months to come, perhaps even years (seeing how the 19.07 branch currently goes and the 5.4 kernel not yet being introduced in the Master branch)
The limitations of the device's CPU, controlers and board buses are known but still outclass most of the other devices that are supported by OpenWrt.
At some point OpenWrt may not even be the best distro choice for the device considering that the distro is trying to support as many devices under one umbrella (efforts to support device with scarcity of hardware resources) and not being sufficiently diverse to unleash the full potential of the TO.
Whilst the TO probably still falls within the classification of a SOHO device it is already hovering on the edge of industrial grade equipment and for such other distros are better suited.
Unless there will be significant development with embedded boards, controllers and CPUs such devices will not meet the performance of what is today's classification of industrial grade equipment.
Considering that multi-homed and/or 1Gb/s+ WAN connectivity are being introduced to SOHO subscribers it will require hardware in SOHO devices to match the subscriber line capabilities, hardware that today is considered industrial grade equipment.
That may be an exaggeration given that it's already being tested out in Koen's staging tree – https://git.openwrt.org/?p=openwrt/staging/xback.git;a=summary
As well as David's – https://git.openwrt.org/?p=openwrt/staging/blocktrron.git;a=shortlog;h=refs/heads/k54
And Christian's – https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=summary
They're aiming to get things moved into Kernel 5.4 for v20.07 – so perhaps, just months.
I myself has made a half attempt at porting 5.4 to mvebu but only for Linksys WRT devices (cherry picking Koen's commits). Haven't compiled it yet though.
This would only be enabled for those using software buffers on RX for mvneta. OpenWrt's mvebu (often paired with Marvell switches given that they're from the same company) kconfig uses hardware buffer management by default on RX.
I don't really know of any consumer/retail hardware that ever pairs an mvneta switch with anything other than an Armada CPU in OpenWrt's build system.
What's more is that I don't know of any public testing going on where swconfig is paired with XDP. I think it's only ever been tested with DSA. I have not heard of any plans whatsoever for OpenWrt to switch to DSA, even in their 2020 roadmap.
I genuinely think it would be more painful for OpenWrt to move away from swconfig than switching to K5.4. Just as hard as moving the project from iptables to nftables.
Will see how it pans out, 19.07 not being released now December.
swconfig is removed for the TO build and only delpoys DSA.
It is considered legacy and new switch drivers should use the DSA (distributed switch architecture) kernel framework [1]
The preferred contemporary driver architecture for ethernet switches in the Linux kernel is DSA (distributed switch architecture). [2]
[1] https://openwrt.org/docs/techref/swconfig
[2] https://openwrt.org/docs/techref/hardware/switch
For version 4.0 right? I've perused their sources in GitLab to see how they've done it – but it seems really convoluted.
Yeah it's legacy, but I haven't seen any plans or any developers assigned to oversee/manage the move of OpenWrt to DSA. I've heard chatter in that it's only because it's not as mature and that there needs to be a way to package the DSA subsystem like mac80211 backports.
Turris has a foundation backing it (I think NIC.cz?). OpenWrt is like OpenSSL. Everyone uses it – but it seems that there's no foundation or anything like that monetarily supporting it, leading to the current slow down and delays in releases and adapting to newer things like DSA and nftables. Prior to heartbleed, OpenSSL had at most two active developers who couldn't support themselves with dwindling donations.
It is not introduced by a patch in TOS (4.x+) but in the build conf for the TO in OpenWrt since 18.6x branch.
I'm sorry, I should have clarified myself. Beyond just the build, I'm talking about DSA in the overall configuration system. E.g. making/bridging VLANs and LuCI/Foris web interface.
Basically DSA support in the front-end.
http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020456.html
Till date there has been no support for VLAN conf via Foris | reForis.
(L)UCi has support for it by parsing VLAN related ip commands however lacking support for VLAN related bridge commands [3].
Thanks for authoring that issue. Though I can see that netifd has become a blocker – akin to another OpenWrt homegrown utill, fw3, being a blocker for nftables adoption...
So it seems that it would be best if this be tackled by these people collaborating with each other:
Jo-Philipp Wich – LuCI
Florian Fainelli – DSA (maintainer(?)) and former OpenWrt dev
Hans Dedecker/John Crispin – for netifd
Are hardware buffers faster?
Turris Omnia uses DSA, not swconfig. The other mvebu devices need to be migrated.
Going from swconfig to DSA results in a performance decrease. Not an issue for the Turris Omnia but can be an issue elsewhere.
Moving to nftables will definitely be difficult.
edit: Speaking of those XDP changes, it seems there were other non XDP related speedups snuck in those commits.
Back before K4.9, @davidc502 was keeping a separate patch to enable hwbm for his builds for the A38x/XP CPUs in the Linksys WRT series. I believe there was a speedup. Prior to that I believe software bm was used. The patch modified the Kconfig and the dts. However, it is obviously now mainlined.
Additionally from my previous post, these are the other Kconfig macros that enable hwbm for mvneta:
CONFIG_MVNETA_BM=y
CONFIG_MVNETA_BM_ENABLE=y
I presume this is related to the fact that a "CPU" port is not being used. I still have not followed up on whether or not DSA maintainers have agreed on a way to tackle this.