Table of Contents
Meeting notes - 18th January 2022 virtual meeting
Date: 18th January 2022
Participants: Hauke, Daniel, Paul, pepe2k, chunkeey, Adrian, Ted, stintel, Rui, lynxis, Rafał, blocktrron, wigyori, richb-hanover
next release (Paul)
- firewall4
- stintel's use cases are now working
- problems:
- append arbitrary strings to firewall3 rules
- e.g. add arbitrary match classes
- firewall3 works fine with ipset, firewall4 has its own ipset for netfilter
- ban ip does not work, also not with the iptables wrapper (iptables-nft)
- probably more cases
- firewall meta package problem in image builder is fixed
- mwan3 could work with the wrapper (iptables-nft)
- add a conflict with firewall4 into the packages which do not work with firewall4 but make sure the buildbot still builds them
- We want to use firewall4 in the release and users having problems with firewall4 can still use firewall3 using the image builder
- The automated upgrader could help users to build images with firewall3
- we will merge the pull requests
- Kernel 5.10
- octeon: has a memory leak in network path (reboots after 1 day)
- make it source only and upgrade to kernel 5.10 (Hauke)
- octeontx: we do not know
- layerscape: Paul will merge
- flow offloading on MT7622 (MT7621 seems to be fine) crashes occasionally: https://forum.openwrt.org/t/belkin-rt3200-linksys-e8450-wifi-ax-discussion/94302/1376
- arc770: drop (Hauke)
- Hauke will try to follow up
- include multi-CPU-port DSA patch? (Daniel)
- For routers with two Ethernet ports between the SoC and the switch
- Getting this into upstream Linux could be hard, multiple people already failed
- code looks good in general
- Switch to qca8k? (ath79, ipq806x) (Hauke)
- apm821xx: https://git.openwrt.org/?p=openwrt/staging/chunkeey.git;a=commit;h=b9a9446b47aaccfc0f0c260bb287e3ebcaee837e (older, but can be revamped)
- there is a performance regression
- probably because of the extra 2-byte QCA header needed for DSA framework for the switch (not 4-byte aligned)
- Daniel will take care of the multi CPU patch, we are fine with merging it in general. We will have a look at the qca8k change separately. the Multi CPU part is a no op when it is not activated.
Infrastructure
- Issue tracking
- replace bugs.openwrt.org ?
- many people do not like it
- maintaining it cost efforts
- alternatives:
- GitHub.com
- big part of the community is already at github
- codeberg.org (GiTea)
- todo.sr.ht (Sourcehut)
- Do we want to import the old issues? Options:
- people could create new issues if they still have the problem
- run bugs.openwrt.org as a dump in a static HTML pages
- import all bugs and close them
- having code and bugs in one place will allow to link code and bugs, which is very nice
- Paul will create a vote if we want to use github for bugs
- migration: either static pages or import to github
- git root
- use github as main repo?
- github rate limits git clones, this causes problems in CI
- DMCA request could shut us down
- Ted could also maintain the git servers, currently jow does it
- Multiple of our servers are running outdated version of Debian
- CI
- We can use different CIs in parallel
- github CI needs a .github file
- github CI could check github pull requests before merge
- Paul will start with this, contact him for ideas
- Hosting
- Currently we host multiple VMs at Digital Ocean
- It looks like their open source sponsoring changed
- Hetzner organization account (Hauke)
- Who wants to manage this with Hetzner and SFC?
- Migrate infrastructure to Hetzner? (Hauke)
- We are running out of credits at DO
- cutting us down would probably create bad publicity for DO, but it could be that they do not think before
- Ted will organize a meeting for an infrastructure group
- Ted will talk with DO
- There is an organization in north of the US, @dvn is part of it, Daniel will establish contact
New User Feature: Automatic Renumbering of LAN interface if it conflicts with WAN. (richb)
- There's a proposal at: https://forum.openwrt.org/t/automatic-renumbering-of-lan-in-case-of-conflict-with-wan/115752/51 that suggests simplifying first-time user experience by letting them use mDNS instead of forcing them to figure out subnetting as their first intro to OpenWrt. Is there any deep reason this proposal could not be made to work?
- And most germane to this meeting: if we had a working prototype, what process do we use to determine if it should go into the base release?
- shifted to new meeting
(richb) Embracing new devices - does it cause undue burden?
- I see lots of requests on the forum: “I got this $15 gizmo from eBay/Alibaba/my neighbor. Can you guys make it work with OpenWrt?” I am asking for clarification for my own information... (richb)
- How much work do these new devices put on the core developers?
- How much of a long-term obligation does it put on OpenWrt? (I worry that we say, “We can't implement X because of a few $15 devices...”)
- How much do they delay the release of the next version?
Answers:
- Review is the biggest effort
- maintenance is not much, sometimes the image gets too big and we just remove it
- pull request adding new devices probably do not shift away attention from other things
ApkWrt (Paul)
- possible replacement for opkg
next meeting 15. February 8PM CET