OpenWrt Meeting - March 27, 2015

Jump to: navigation, search

Attendees: Eric, Art, Mathieu, Charlie, Kathy, Felix (nbd)

Event updates:

Next global hangout. April 6 at 6PM UTC/10AM PT. The meeting should last about an hour. Let Eric know if you didn't have a chance to signup but would like to attend. He will also record it in case you can't attend live and want to watch later.

April 18 Hackathon

  • Imre Kaloz confirmed that he will come. Sweet! Welcome Imre.
  • Cesare Garlati will attend too (prpl security consultant),-2015

Virtualization and Security working group off and running, about 10 companies involved. Calls will be 7am PST every other Monday.

Battlemesh v8 - prpl will offer some sponsorship $ for it


Excellent dialog, mainly between Felix and Mathieu. Felix says that semiconductor companies and ODMs/OEMs need to do a better job staying closer to OpenWrt trunk and latest release instead of holding onto an old fork. True, but most corporate engineers are assigned to get product out the door as quickly as possible and maintain the static release image, not proactively contribute to OpenWrt as they go along. ODMs and OEMs also fear change, especially kernel upgrades. We all agreed that industry needs to rebase internal OpenWrt trees more often and contribute to OpenWrt trunk better, but how to make that happen? Mathieu says one hurdle is the pace of internal development -- it is growing ever faster, and the number of resources capable of rebasing and pushing code externally is insufficiently staffed to be able to keep up.

What if we were able to pool industry $ to fund more external engineering development on OpenWrt? Or perhaps offer prize money or other incentives for contributions? Or companies can bring forward development projects to be funded and others with expertise in OpenWrt could bid on assignments?

Eric suggests that industry should rebase from OpenWrt at least once per month, preferably more frequently. Need parallel stable release testing and submission testing.

Art willing to evangelize benefits of better OpenWrt alignment to semiconductor companies and ODMs/OEMs. We can help them realize the increased market potential if everyone collaborated together and contributed back. Commercial hardware would be more adaptable to new use cases with an open development environment.

Some core team status to report:

John Crispin has been working on some cool new security enhancements. Hot off the press:

Felix reports that the first OpenWrt CC release candidate (rc1) should be in a couple weeks. It will stay on trunk for a couple more rc's until the development stabilizes, and then a branch will be pulled. It will remain 3.18 kernel, which fortunately is an LTS kernel. It will have the SE advantages, LXC containers, performance improvements, netfilter caching, better scaling across multiple cores, ... These days the release notes are written up at the end but maybe there could be a "whiteboard area" on the wiki and/or a change log in the tree for developers to jot down significant changes as they go along rather than have to remember them all at the time of the release.

Other updates:

Mathieu has been working on a Linux kernel DSA implementation of the AR8337 Gig Eth switch; for now it's just a basic switch driver, but it does register to the appropriate interfaces. The framework isn't as good as OpenWrt's swconfig. Most of the kernel framework is for different use cases, like high-end data center switches instead of Wi-Fi routers. Once legal approval is done he will send upstream for code review. Felix suggests that Mathieu continue to point out that better Linux switch architecture is needed. Refer to a simple, well-defined use case and show how Linux doesn't handle it well and use that to explain what needs to be resolved. Get Jamal on your side, also use Florian to help.

Kathy has some ideas for impressing upon industry to get out of the static, non-moving, non-upgradeable, non-smart-app-ready router rut. Why should router software be updatable and open? Because a router is the perfect place for translating information between Internet of Things (IoT) devices. New types of "connected" devices and appliances come on-line all the time. They expose their capabilities through an API which might be brand new or part of a recent protocol or app service model. Since the router/gateway is always on, and likely the hub of the network, it can load new software to translate messages between IoT devices and pass data from devices to the cloud. To glue disparate device APIs together, the router/gateway needs updateable software and the ability to host 3rd party IoT glue logic. OpenWrt is moving in a direction to be able to securely enable a global developer ecosystem. It's a win for ODMs/OEMs to drive more smarts to their products if they align the router software closer to the latest OpenWrt software. And it's a win for OpenWrt if more ODMs/OEMs adopt it as a moving and improving target, rather than a place from which to branch a fork that goes stale or diverges. In summary, to become smart app ready and stay secure, the platform needs to be open and updatable.