Hey Kids! Let's Make a Router!

[System Error Message]

Just found out another antivirus developer that decided to try their hand at router design:

https://www.tweaktown.com/reviews/8400/secure-sense-ac1750-wireless-router-review/index.html

with your experience on ASUSWRT, and mine on optimising algorithm based code, lets make our own home security router that would be far better and faster than any of these junk security routers.

 

[RMerlin]

with your experience on ASUSWRT, and mine on optimising algorithm based code, lets make our own home security router that would be far better and faster than any of these junk security routers.

If I were to develop a new router and wanted to reuse Asuswrt, I'd probably end up rewriting half of it, and have a product ready to ship by 2025 or something...

 

[sfx2000]

If I were to develop a new router and wanted to reuse Asuswrt, I'd probably end up rewriting half of it, and have a product ready to ship by 2025 or something...

My little science project last fall/winter spun up functioning code in about 6 weeks from concept to production quality - the hardware was the hard part, and the most expensive part... the engineering stuff was pretty straight forward - it was the business side that was 80 percent of my work it seems like...

Would I do something like that again - probably not - it was a good experience, and in the end, came out whole and good (I got my investment back and paid everyone off) - it does live in a limited way as a white box solution for the company I sold the project off to...

 

[System Error Message]

If I were to develop a new router and wanted to reuse Asuswrt, I'd probably end up rewriting half of it, and have a product ready to ship by 2025 or something...

how many programmers and EEEs would it take to create such a router in 1 year?

 

[sfx2000]

how many programmers and EEEs would it take to create such a router in 1 year?

For the science project - 2 ninja level principal devs full time for SW, and we did a bit of outsource for UI/UX...

HW - one full time EE to do the basic schematics, a CAD guy on contract for the layout and PCB design, and a lab tech for various purposes... brought in a few folks for contract jobs on specific tasks related to getting boards built and then debug. Calling in a butt load of favors which saved me time and money with lab and test gear availability...

Add to that - an attorney and a cpa - which is critical at certain points...

I did most of the architecture work up front, along with getting everything else running (getting repos up, CI for nightly builds, etc...) - along with the hustle of running the business (biz plan, finance, etc) - which was 80 hours a week, and impacting my personal life and health.

The technology was the easy part - setting up and running the business was incredibly hard - and money is burning all the time. Most of that was my money initially, and pulled in an angel investor that really did help out when needed...

We did get to that moment, a minimum viable product - and the numbers for retail just didn't work - so it was about planning the exit on that one, and deciding do we continue as an ODM, or... so in the end, sold the HW/SW to another company, and that was that.

So getting back to @System Error Message question - spinning up a router/device from scratch can be done in 6 months if the stars align, and they rarely do - but 12 months is reasonable if one has quality people and relationships, and a fair amount of luck.

It was crazy fun, frustrating, up and down, and it can consume people - I made new friends, and lost old ones.

It was a good experience, but not one I would do again without better planning and funding up front.

 

[System Error Message]

For the science project - 2 ninja level principal devs full time for SW, and we did a bit of outsource for UI/UX...

HW - one full time EE to do the basic schematics, a CAD guy on contract for the layout and PCB design, and a lab tech for various purposes... brought in a few folks for contract jobs on specific tasks related to getting boards built and then debug. Calling in a butt load of favors which saved me time and money with lab and test gear availability...

Add to that - an attorney and a cpa - which is critical at certain points...

I did most of the architecture work up front, along with getting everything else running (getting repos up, CI for nightly builds, etc...) - along with the hustle of running the business (biz plan, finance, etc) - which was 80 hours a week, and impacting my personal life and health.

The technology was the easy part - setting up and running the business was incredibly hard - and money is burning all the time. Most of that was my money initially, and pulled in an angel investor that really did help out when needed...

We did get to that moment, a minimum viable product - and the numbers for retail just didn't work - so it was about planning the exit on that one, and deciding do we continue as an ODM, or... so in the end, sold the HW/SW to another company, and that was that.

So getting back to @System Error Message question - spinning up a router/device from scratch can be done in 6 months if the stars align, and they rarely do - but 12 months is reasonable if one has quality people and relationships, and a fair amount of luck.

It was crazy fun, frustrating, up and down, and it can consume people - I made new friends, and lost old ones.

It was a good experience, but not one I would do again without better planning and funding up front.

lets do it though i'd have to find funding.

 

[RMerlin]

how many programmers and EEEs would it take to create such a router in 1 year?

Quite a few. A router is more complex than a basic embedded system, when you consider the radio part, the general features, support for all those ISPs with oddball setups (Beeline using a combination of DHCP + PPTP on the WAN interface, some Asian ISPs enforcing a TTL of 1, UK ISPs using DHCP options 60 and 61 for authentication, etc...). Add to that working on IPv6 support that's still hit-or-miss for the majority of routers out there due to varying ISP implementations (some of which flat out broken and not following RFCs).

For the software part, looking at the size of the OpenWRT dev team should give you an idea. I also know roughly how many engineers Asus employs in their router development team. I won't share that number, but it's probably more than you'd expect.

A year is probably not realistic, based on the Securifi experience when developing the Almond. I think they ended up shipping one year late due to issues with the hardware part. Don't forget that on top of that you have the various certification processes to go through with the FCC and the likes. Expensive and time-consuming.

 

[RMerlin]

but 12 months is reasonable if one has quality people and relationships, and a fair amount of luck.

I suspect just the FCC validation process could add close to 2-3 months to that whole figure, provided everything goes well the first try.

 

[sfx2000]

I suspect just the FCC validation process could add close to 2-3 months to that whole figure, provided everything goes well the first try.

If the device has a radio (e.g. WiFi), it adds an incredible amount of extra effort and cost for regulatory testing and approval... FCC is ok for US, but let's say adding Canada and Mexico into the plan - that's even more time and money (it's paperwork and filing fees, as typically they'll accept the FCC lab results for cofetel and industry canada) - go into the EU, then that's even more testing (EU has it's own test plan requirements)...

The science project, by intent and purpose, had no WiFi just for those reasons...

 

[sfx2000]

For the software part, looking at the size of the OpenWRT dev team should give you an idea. I also know roughly how many engineers Asus employs in their router development team. I won't share that number, but it's probably more than you'd expect.

Looking at OpenWRT - one has to look at the number of active committers and the amount of contributions they add - and the real work added just to manage that code base.

(BTW - OpenWRT/LEDE is a great piece of work, and if one wanted to build a router, I would suggest starting with OpenWRT)

On AsusWRT - keep in mind how many devices are in play - legacy support, the current products, and next year's roadmap - so yep, it's big team. It has to be...

Going back to the science project - it's one item, and a clear scope of what was being done - so a small team can do it in a relatively short period of time - but taking it commercial into production as a retail product, one has to staff up - consider the size of UBNT or MicroTik, and that's a realistic picture...

 

[System Error Message]

Looking at OpenWRT - one has to look at the number of active committers and the amount of contributions they add - and the real work added just to manage that code base.

(BTW - OpenWRT/LEDE is a great piece of work, and if one wanted to build a router, I would suggest starting with OpenWRT)

On AsusWRT - keep in mind how many devices are in play - legacy support, the current products, and next year's roadmap - so yep, it's big team. It has to be...

Going back to the science project - it's one item, and a clear scope of what was being done - so a small team can do it in a relatively short period of time - but taking it commercial into production as a retail product, one has to staff up - consider the size of UBNT or MicroTik, and that's a realistic picture...

I suspect just the FCC validation process could add close to 2-3 months to that whole figure, provided everything goes well the first try.

planning guys. While the FCC validation takes place, firmware improvements can be made. EEE also do learn C coding so theres no reason they cant count as a programmer after they've made the hardware while the rf engineer can enjoy making sure the circuits, PSU and so on arent passing AC voltages and only the wanted DC voltages with good voltage stability.

I have an emf radiation measuring tool, placing it next to one of dlink's AC wifi routers further away from where the electrical input is, it reads a voltage of 388V electrical field, rf emissions in the read. phones and even asus routers dont do this as they only peak every so often rather than be in the red always.

So i really dont know how dlink gets validated when it's PSU is passing AC voltage through with the case being plastic.

 

[sfx2000]

@System Error Message - food for thought...

MacchiatoBin with LEDE 17.02 pretty much meets most of your needs... when science project was in development, I had a week of access to one of these - and it's a real beast...

http://macchiatobin.net

If one wants to start a bit smaller - espressobin is a good place, same with LEDE - steps are similar for bringup... the science project was a seriously cost reduced version of espressobin from a HW perspective

http://espressobin.net

We used LEDE/OpenWRT as a point of comparison for benchmarking cafeole on a SW basis... our BSP was our "special sauce" and was much different than LEDE/OpenWRT. For ARM - I really like the Marvell solutions - once we got in the door, and access to closed source, they were very supportive...

For Intel, consider MinnowBoard Turbot Dual-E - this board is supported fully by pfSense, and pretty easy to get LEDE running on it.

http://www.adiengineering.com/products/minnowboard-turbot-duale/

Or Up2 -- http://www.up-board.org/upsquared/specifications-up2/

Hardware is easy/hard - depends on the approach - that's something CafeOLE learned up front, that's why I say, I won't do HW again - it's hard to do "right" at a productive quality level, and "bug fixes" to redo a board are very expensive if rolling one's own.

The investment of time/energy/money was better spent on SW - much effort was done on the first board, rest was incremental work until the architecture jump from ARMv7a to ARMv8, and even that was less effort than the initial builds.

In the end, CafeOLE supported the following chips;

• Broadcom 2710 - ARMv7a - Pi3 (internal target for our UI/UX contractors as I needed cheap boards)
• Marvell Armada 3720 - ARMv7a (GA and Production) - minimum viable product for CafeOLE HW and EspressoBIN
• Marvell Armada 3720 - ARMv8 (internal target for toolchain dev for Marvell 8040)
• Marvell ArmadaXP - ARMv7a (GA and Production) <-- late target, but one that buyer required we support
• Marvell Armada 8040 - ARMv8 (Internal Beta) <-- see above
• NXP i.MX6 - ARMv7a (side project for a group developing a board around that chip)

Again - the technology aspects are relatively easy compared to actually standing up a business and building a channel.

 

[sfx2000]

planning guys. While the FCC validation takes place, firmware improvements can be made. EEE also do learn C coding so theres no reason they cant count as a programmer after they've made the hardware while the rf engineer can enjoy making sure the circuits, PSU and so on arent passing AC voltages and only the wanted DC voltages with good voltage stability.

I have an emf radiation measuring tool, placing it next to one of dlink's AC wifi routers further away from where the electrical input is, it reads a voltage of 388V electrical field, rf emissions in the read. phones and even asus routers dont do this as they only peak every so often rather than be in the red always.

So i really dont know how dlink gets validated when it's PSU is passing AC voltage through with the case being plastic.

Not sure what's up with the DLINK device you tested with your EMF thingy - but casual testing is not the same as formal testing for FCC/EU type approval.

Check the assumptions - while many EE's know some code - my Dev's were experts at embedded development and Android - from the mobile phone business...

My CAD guy was a retired CAD/CAM guy from Nokia for board layout - and he knew the tips and tricks about getting clean for FCC Part 15 Class B -- My HW lead was also an ex-mobile phone guy - so we went thru some internal testing to ensure we were good, and even then a board spin ($$$) to solve a couple of issues with spurious emissions...

BTW here's a great ref point for Part 15 Class B/Class A - https://transition.fcc.gov/bureaus/oet/info/documents/bulletins/oet62/oet62rev.pdf

I suppose one of the benefits of being based out of San Diego - access to a lot of very smart, very experienced handset people... for engineering, as part of the business, was finding and hiring a good team.

 

[System Error Message]

Not sure what's up with the DLINK device you tested with your EMF thingy - but casual testing is not the same as formal testing for FCC/EU type approval.

Check the assumptions - while many EE's know some code - my Dev's were experts at embedded development and Android - from the mobile phone business...

My CAD guy was a retired CAD/CAM guy from Nokia for board layout - and he knew the tips and tricks about getting clean for FCC Part 15 Class B -- My HW lead was also an ex-mobile phone guy - so we went thru some internal testing to ensure we were good, and even then a board spin ($$$) to solve a couple of issues with spurious emissions...

BTW here's a great ref point for Part 15 Class B/Class A - https://transition.fcc.gov/bureaus/oet/info/documents/bulletins/oet62/oet62rev.pdf

I suppose one of the benefits of being based out of San Diego - access to a lot of very smart, very experienced handset people... for engineering, as part of the business, was finding and hiring a good team.

Yeah, the EEs dont need to be embedded experts. Thing is, many EEE projects require coding C/java for embedded hardware (arduino is an obvious example).

Im not in the US unfortunately so not sure about that. But regarding the router i measured with my emf radiation meter, it will detect emf fields around wires that carry voltage and also antennas. For example, phones fluctuate between 2V and 8V, Measuring the DC output from a laptop PSU, at the laptop PSU itself it is high from the AC voltage and it drops down to 20V the closer to the device you get. 388V is higher than the outlet, switching PSU involving high frequency and high voltage for compact transformers and footprint, however the fact that this was measured at the device and a bit further away including very high levels of rf power (talking about mW/m2) which while within the FCC's specification regarding rf isnt particularly good when i checked closeby either. Laptops, phones and even asus routers dont exhibit this sort of behaviour rather they just peak often and not continuous.

What there is a lack of regulation for is the electrical field. This is something known to cause cancer at high voltage like living under the electrical grid for instance which has very high voltage but even when it reaches the person, the voltage is still high even though it is much lower. This is the same problem for the dlink router as the dlink router is much closer but has a similarly high electrical field voltage. The only regulations that exist specific limitation within the KV range.

 

[pege63]

Dont forget that you are NOW talking about the Turris Omnia Router.
There you can switch out the components and its build on Openwrt.

 

[sfx2000]

In the end, CafeOLE supported the following chips;

• Broadcom 2710 - ARMv7a - Pi3 (internal target for our UI/UX contractors as I needed cheap boards)
• Marvell Armada 3720 - ARMv7a (GA and Production) - minimum viable product for CafeOLE HW and EspressoBIN
• Marvell Armada 3720 - ARMv8 (internal target for toolchain dev for Marvell 8040)
• Marvell ArmadaXP - ARMv7a (GA and Production) <-- late target, but one that buyer required we support
• Marvell Armada 8040 - ARMv8 (Internal Beta) <-- see above
• NXP i.MX6 - ARMv7a (side project for a group developing a board around that chip)

After four weeks of effort - CafeoleNG 0.3 (my fork from the code base I sold off*) now supports AMD64... and we're now supporting OpenStack Pike (and hooks into ONAP/ECOMP) which we couldn't with the older Cafeole code base that was focused more on edge stuff for the SNB market because of resource restrictions. Four weeks for the port was enabled by a lot more resources - manpower and money basically...

Short version - the project grew up big time.

At the moment - CafeoleNG is running on Skylake-SP with 4*10G SFP in a 2U rackmount - and it's very competitive from a cost perspective... we've been testing with IEPL, MPLS, and SDWAN - full support for DPDK and QAT. Using containers and modularity at an architecture level was a smart move, and really sped things up for the port and the added functionality. It can do bare metal, run as a cloud image - can be private, hosted, and hosted/managed.

Which pretty much validates the technical approach taken back in fall of 2016 in the design phase.

CafeoleNG hasn't given up on ARM - we're looking at some interesting ARMv8 stuff from vendors I won't name at the moment. And the architecture is flexible enough to support GPU/FPGA support for acceleration of certain functions.

The takeaway here for @System Error Message - design it right, and it'll scale - and keep it portable and not bound to a single architecture...

* CafeOLE (project name) was sold as an edgerouter board support platform - they have a release branch that they own - I get royalties from them, and I still own my fork - only restriction is that we don't compete - they have a whitebox edgerouter business as an OEM/ODM, and these days I'm focused on backbone/data center/cloud stuff - we're all in the same investor ecosystem, so if we need to go back to the edge for premises gear, it's fairly easy...

 

[sfx2000]

In the end, CafeOLE supported the following chips;

• Broadcom 2710/2837 - ARMv7a - Pi3 (internal target for our UI/UX contractors as I needed cheap boards)
• Marvell Armada 3720 - ARMv7a (GA and Production) - minimum viable product for CafeOLE HW and EspressoBIN
• Marvell Armada 3720 - alpha ARMv8 (internal target for toolchain dev for Marvell 8040)
• Marvell ArmadaXP - ARMv7a (GA and Production) <-- late target, but one that buyer required we support
• Marvell Armada 38x - ARMv7a - Production
• Marvell Armada 8040 - ARMv8 (Internal Beta) <-- see above
• NXP i.MX6 - ARMv7a (side project for a group developing a board around that chip)

Again - the technology aspects are relatively easy compared to actually standing up a business and building a channel

A quick update - I was told that the Japan team* completed the port over to the nVidia Jetson TX2 module with the CTI Orbitty and Gogswell support board (they promised to send me one) - that port is focused on specific functions... if you follow Jetson, you know the focus there.

I did a side project to support Rockchip 3288, which is a cortex-A17 ARMv7A variant, that one was pretty straightforward, sorting out DT and uBoot params...

@Voxel - that's the benefit of focusing on portability...

NG is working - both on x86-64 (AMD and Intel server class) and ARMv8 on chips that are interesting - it's scaling well.

*Japan team - the folks that I sold the Caleole BSP to some time back, not my business these days, but I do get a small licensing royalty on things they do... in hindsight, maybe I should have stuck a bit longer...

 

[sfx2000]

While the FCC validation takes place, firmware improvements can be made

@System Error Message @RMerlin

One thing to note - with the original project - we had a requirement to support WiFi with one of the prospective customers, and show that it works... going thru FCC certs (much less RE-D for EU)... Part 15 without WiFi was fairly straight forward as we were not an intentional emitter...

Getting WiFi on to the dev board - we bit-banged an Espressif WiFi module firmware, as it was already certified - so one less challenge there.

(we could have gone with Ampak modules, but we didn't have the pins without a major redesign of the board - and besides, the Ampak's didn't have antennae - the Espressif modules did)

The Ampak - typical one... this one is B/G/N... they have a few - some are broadcom based, some are Realtek based

The Espressif - again, a representative example... it's more of an IOT oriented device, but the firmware was relatively open, hence the bit-banging...

 

[System Error Message]

@System Error Message @RMerlin

One thing to note - with the original project - we had a requirement to support WiFi with one of the prospective customers, and show that it works... going thru FCC certs (much less RE-D for EU)... Part 15 without WiFi was fairly straight forward as we were not an intentional emitter...

Getting WiFi on to the dev board - we bit-banged an Espressif WiFi module firmware, as it was already certified - so one less challenge there.

(we could have gone with Ampak modules, but we didn't have the pins without a major redesign of the board - and besides, the Ampak's didn't have antennae - the Espressif modules did)

The Ampak - typical one... this one is B/G/N... they have a few - some are broadcom based, some are Realtek based

View attachment 12765

The Espressif - again, a representative example... it's more of an IOT oriented device, but the firmware was relatively open, hence the bit-banging...

View attachment 12766

Since i dont have a job and am free, why dont we get started on making one.

 

[sfx2000]

Since i dont have a job and am free, why dont we get started on making one.

Toss the Wifi - it gets pretty easy - until one runs into the eternal problem - "what is the market, and what they are willing to pay."

$50USD routers without WiFi is a pretty small market - no matter how good they are... and science project was pretty damn good.

Mostly because in the Big Box stores - "what do you mean it doesn't have WiFi?" - we moved around a bit, grabbed on to an IoT hub kind of solution, but that's very fragmented space there.

Which is a problem... that's why I pivoted - sold the BSP that the science project developed, moved up market...