[sdwalker/sdwalker.github.io] f71444: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: f71444a5f359e4cfdafdae29b04c25d7818a1d0d https://github.com/sdwalker/sdwalker.github.io/commit/f71444a5f359e4cfdafdae29b04c25d7818a1d0d Author: Stephen Walker Date: 2023-05-07 (Sun, 07 May 2023) Changed paths: M uscan/index-21.02.html M uscan/index-22.03.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/6] realtek: fix management of mdb entries
On Sun, 2023-05-07 at 01:05 +0200, Jan Hoffmann wrote:
> This series fixes multiple issues related to the L2 table and multicast
> table. That includes an issue that causes corruption of the port mask
> for unknown multicast forwarding, which can occur even when multicast
> snooping is disabled.
>
> As discussed previously, these changes don't make multicast snooping
> fully work, as that would still need additional changes in the kernel
> for all DSA switches (see the follow-up messages to the original patch
> series at [1] and [2] for details).
>
> v2:
> - properly deal with redundant is_lagmember check by removing it
>
> [1] http://lists.openwrt.org/pipermail/openwrt-devel/2023-March/040621.html
> [2] https://lore.kernel.org/netdev/20230306134636.p2ufzoqk6kf3hu3y@skbuf/
>
> Jan Hoffmann (6):
> realtek: fix writing/deletion of CAM entries
> realtek: don't treat first multicast portmask entry as reserved
> realtek: actually remove port from multicast portmask
> realtek: don't add CPU port to multicast portmasks
> realtek: remove store_mcgroups/load_mcgroups
git-am didn't like this patch as submitted, but I did apply these patches after
the other series ("realtek: fix multiple issues with L2 forwarding"). Should be
resolved though, looks like it was just due to some code moving around.
> realtek: remove redundant is_lagmember checks
Thanks for fixing these multicast issues! Applied to master.
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt vs Defense positions
On 5/1/23 21:28, Peter Naulls wrote: For those of you who track the small but very real OpenWrt job market, you may have seen there's a creep into Defense/Clearance jobs. Here's but one example: https://careers-bluehalo.icims.com/jobs/3844/job As a self-declared pacifist (and anyway, dual citizen which would limit my ability to get clearance), this is most certainly not for me, but I thought it should be something you guys might want to be aware of. I check from time to time which companies in the US are looking for OpenWrt experts [0] to get an overview who is using it. About 10% to 30% of these job offers require clearance. It looks like the US military and US intelligence community is using OpenWrt. Once I saw a job offer where someone was looking for a person who has experience in writing exploits for OpenWrt and DD-WRT in the Washington, D.C. area, this scared me a bit, normally I do not have the NSA in my thread model. Someone from BAE Systems (largest defence contractor in Europe) was also contacting us at OpenWrt some years ago with questions about the license. I hope that these companies use OpenWrt mostly to provide Internet access for their soldiers and it is not part of any real weapon system. As OpenWrt is now used by many vendors I think the intelligence agencies around the world are interested in exploits fro OpenWrt. I heard a rumor some years ago that one of the biggest OpenWrt installation was at the fence between the US and Mexico, but I have no prove that this is true. The GPL and the other licenses used by OpenWrt do not prevent the usage by any military or intelligence agency. OpenWrt does not do a background check on external contributors. We have contributions from people from many countries the US does not like. Hauke [0]: https://www.indeed.com/jobs?q=openwrt= ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/4] realtek: fix multiple issues with L2 forwarding
On Sat, 2023-05-06 at 19:28 +0200, Jan Hoffmann wrote: > This series fixes several bugs that can result in packets being > forwarded incorrectly. The port isolation and VLAN issues probably > remained unnoticed so far, because they only manifest after a port > leaves a bridge, or when an existing VLAN membership is changed. > > v2: > - Fixed checkpatch.pl warnings > - Removed comment about RTL838X_PORT_ISO_CTRL, as the traffic_set > method is now used instead of accessing the register directly > - Added Fixes tags for first commit > > Jan Hoffmann (4): > realtek: properly update port masks when port leaves bridge > realtek: initialize port masks to match the default state > realtek: fix standalone ports in presence of static fdb entries > realtek: handle changed flags in VLAN configuration Thanks for the updates. Patches applied to master! Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Any plans to submit realtek target drivers to mainline Linux?
On Sun, May 07, 2023 at 11:56:59AM -0300, Luiz Angelo Daros de Luca wrote: > Em sáb., 6 de mai. de 2023 06:12, Arınç ÜNAL escreveu: > > > > Hi. > > Hi Arinç, > > > I see a lot of development on the network drivers like DSA, PHY, etc. > > Are there any plans to put all these drivers on the realtek target on > > mainline Linux? To fully support these SoCs on mainline Linux? > > > > Arınç > > > > I'm a minor contributor to the DSA driver for the realtek target, but > I have my 2 cents to share. I believe we can start to enlist what > would be needed to get the drivers upstream. We can start the > discussion from there: > > - The DSA driver uses a lot of magic numbers that would not be > accepted by the upstream kernel. They must be converted into macros, > enum, inline functions and friends. > - There are shared functions with internal conditions (if modelA then > ...). Mixed with magic numbers, it is much easier to miss a > peculiarity about a subtarget and introduce bugs. A nice way to avoid > that is to convert them into indirect calls to subtarget functions > (*_ops). > - The driver uses hardcoded addresses and direct memory writes. I > don't know if there is anything incompatible but upstream drivers > normally use regmap. It will also clean up a lot of things and > introduce nice functions. > - The DSA driver uses a generic tag that is converted afterwards by > each (ethernet?) driver into its CPU tag. The DSA taggers were > designed to decouple CPU tag from ethernet driver logic and upstream > maintainters might ask to implement each CPU tagger as a proper DSA > tag. Although it might not make sense to have an ethernet driver > without a tag in this target, it would get closer to how outer drivers > work and make it easier to understand the driver. - The RealTek SoCs can (and must!) offload paged MDIO phy access operations. In order to not use patched PHY drivers which directly use SoC-specific MDIO access functions, we will need to introduce support for offloading paged Clause-22 MDIO to vanilla Linux. I've started with that, but it certainly needs more work and preparation to be less vendor-specific. Practically *all* PHY vendors use register 0x1f for selecting the register page. The RealTek SoCs poll PHY state in hardware and hence require using the offloaded page access methods also when accessing PHY registers from Linux, as that would otherwise interfere with that hardware-driven PHY polling. > > Regards, > > Luiz > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
./scripts/feeds update may fail with: "fatal: refusing to merge unrelated histories"
I've a custom feeds git repository with development branch that gets rebased. I use it with a simple feeds.conf "src-git" entry like: src-git foo g...@example.foo:my-packages.git;feature The problem is that ./scripts/feeds uses a simple "git pull --ff-only" for updates. That doesn't work for branches that get rebased. It results in: fatal: refusing to merge unrelated histories Could some git expert suggest a fix for that? I'd like to modify "update" command of "src-git" to support rebases. For full clones we could probably use "git fetch" and "git rebase" but I don't know the proper solution for clones with "--depth 1". -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Any plans to submit realtek target drivers to mainline Linux?
Em sáb., 6 de mai. de 2023 06:12, Arınç ÜNAL escreveu: > > Hi. Hi Arinç, > I see a lot of development on the network drivers like DSA, PHY, etc. > Are there any plans to put all these drivers on the realtek target on > mainline Linux? To fully support these SoCs on mainline Linux? > > Arınç > I'm a minor contributor to the DSA driver for the realtek target, but I have my 2 cents to share. I believe we can start to enlist what would be needed to get the drivers upstream. We can start the discussion from there: - The DSA driver uses a lot of magic numbers that would not be accepted by the upstream kernel. They must be converted into macros, enum, inline functions and friends. - There are shared functions with internal conditions (if modelA then ...). Mixed with magic numbers, it is much easier to miss a peculiarity about a subtarget and introduce bugs. A nice way to avoid that is to convert them into indirect calls to subtarget functions (*_ops). - The driver uses hardcoded addresses and direct memory writes. I don't know if there is anything incompatible but upstream drivers normally use regmap. It will also clean up a lot of things and introduce nice functions. - The DSA driver uses a generic tag that is converted afterwards by each (ethernet?) driver into its CPU tag. The DSA taggers were designed to decouple CPU tag from ethernet driver logic and upstream maintainters might ask to implement each CPU tagger as a proper DSA tag. Although it might not make sense to have an ethernet driver without a tag in this target, it would get closer to how outer drivers work and make it easier to understand the driver. Regards, Luiz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 0/6] realtek: fix management of mdb entries
Jan Hoffmann writes: > This series fixes multiple issues related to the L2 table and multicast > table. That includes an issue that causes corruption of the port mask > for unknown multicast forwarding, which can occur even when multicast > snooping is disabled. Thanks for cleaning up this mess. I was curious and started looking at how all these bugs were introduced. And, uhm, I should know better by now... THANKS A LOT! Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
