Re: here we are again: real name 'discussion'

[John Crispin]

I do not see anyone from the committers complaining about the revert. If 
folks felt that a vote was neccesseary, then someone would have started one.


I have a feeling that folks are happy with the old status quo and no 
vote is required.


    John

On 18.04.24 16:13, Paul D wrote:

On 2024-04-16 16:41, Etienne Champetier wrote:

Le mar. 16 avr. 2024 à 10:34, Paul D  a écrit :

On 2024-03-27 23:56, Etienne Champetier wrote:

As this is a legal issue, should we get SFC opinion first ?

Etienne


Is this happening?

Sorry I missed your last ping
This was an open question, I don't know who to contact at SFC

Looking at old emails, John, Jo and Hauke are our liaison with SFC

So, John, Jo and Hauke,

who is the current liaison to SFC?

what does the SFC think?



___
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

Re: OpenWrt One / project update

[John Crispin]

using OP-TEE and fTPM.


pretty high on my list once we find the time

https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/index.html 



https://trustedfirmware-a.readthedocs.io/en/latest/components/spd/optee-dispatcher.html


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One / project update

[John Crispin]

On 12.04.24 15:30, Michael Richardson wrote:

Is the MT7981B specification available publically at this point?

I can find a 7986 sheet on hackaday, but who knows how it differs (marketing
people and their numbers)


Hi

http://mirror2.openwrt.org/docs/

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt Summit 2024 & Battlemesh v16 Announcement

[John Crispin]

On 12.04.24 02:19, David Bauer via openwrt-devel wrote:
can you share which identifier was assigned for OpenWrt? I don't see 
it in the list of the

IEEE yet.


The process is still pending. SFC needs to register the OUI block as 
"does business as" to make sure OpenWrt shows up as the name.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt Summit 2024 & Battlemesh v16 Announcement

[John Crispin]

Hi


We will auction off one or two OpenWrt One.


The first 15 EVT samples have been tested, and a new production run of 
100 DVT samples will start shortly. these 100 samples will have OpenWrt 
OUI macs and calibration data. the winners of the auction will receive 
samples via express courier ;) @Arınç: thanks for organizing this.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt Summit 2024 & Battlemesh v16 Announcement

[John Crispin]

Hi,

We will auction off one or two OpenWrt One. 

The first 15 samples have been tested, an

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

OpenWrt One / project update

[John Crispin]

Hi,

Just dropping a quick update on the  OpenWrt One project. I've received 
the first batch of three PCBs for testing today. I am in the process of 
testing the hardware to make sure everything works as intended.


There are twelve further early prototype boards on standby in case we 
need to tweak anything hardware-wise. You can find some pictures showing 
off the PCB from different angles at these URLs:


http://mirror2.openwrt.org/OpenWrtOne_top.png
http://mirror2.openwrt.org/OpenWrtOne_bottom.png
http://mirror2.openwrt.org/OpenWrtOne_side.png

Work is underway to establish a website where all legal information and 
links to our sources will be provided. Keeping everything transparent 
and accessible is crucial for us.


MediaTek also generously released a substantial amount of programming 
manuals for the SoC used by the OpenWrt One which will be made available 
shortly.


I would like to express my gratitude to the Software Freedom Conservancy 
(SFC), our manufacturer (BPi), the silicon vendor (MTK) and fellow 
developers for their support throughout this journey.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: here we are again: real name 'discussion'

[John Crispin]

Hi,

the SoB is a DCO

https://en.wikipedia.org/wiki/Developer_Certificate_of_Origin

without a real name DCO is not assignable

    John

On 26.03.24 14:39, Paul D wrote:
We have quorum/consensus on this issue. Is it too much to ask that 
everyone now follow it, or at least have this token 'vote'?



Triggered by the yggdrasil additions of recent.

https://github.com/openwrt/packages/pull/23072



Paul S amended the policy (in packages[1] and openwrt[2] repos) with 
an open discussion in PRs for Felix to then change direction via:


https://github.com/openwrt/actions-shared-workflows/commit/12d9551f2d07ec34ac813da8612c8014fb393af6 




with comment: "should require a public discussion/vote"



[1] https://github.com/openwrt/packages/pull/23084
[2] https://github.com/openwrt/openwrt/pull/14380

___
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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

Hi Rafał,


Is there any update / schedule you could share?
I have been meaning to send an update for a few days. Thanks for 
reminding me.


I'm really looking forward to this device.

yeah, me too ;)


Lots of stuff has been happening. There was a short break due to the 
lunar new year but we are picking up pace again.


*) schematics are done
*) PCB is mostly routed (https://nbd.name/one-top.jpg 
https://nbd.name/one-bottom.png)


*) there was a small hiccup in registering the OUI block that we are 
currently resolving
*) the trademark agreement is being worked on - I have a call with SFC 
tomorrow to discuss this


I am expecting that the first 15 PCBA samples will be produced shortly 
and be shipped by end of march.


as for the software side, I modified a mt7981 RFB to have  dual flash, 
mikrobus,  s.T. I could build and test dts files. I ordered the RTC 
used on a carrier board and was able to test it.


all the u-boot patches are pretty much done. there is a pretty elaborate 
uboot-env with lots of commands to provide easy un-brickability.


I have a local OpenWrt tree with ~10 patches that I hope to send as a 
RFC later this week.


the PCB will probably be light blue (PANTONE 306 C) which is the light 
blue used inside the OpenWrt logo. we are still figuring this out with 
the supplier.


I should probably start building a page inside the wiki to provide 
better visibility into what is happening.


shout out to pepe2k, SFC and MTK for the never ending support that they 
provide on this journey.


And an extra big thank you to Simon, the designer/engineer from BPi that 
has been ultra cool in making this become a reality


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[John Crispin]

I would like to add Robert to the OpenWrt committers team.


+1

thx @robimarko for taking care of the QCA mess


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 17.01.24 20:31, David Bauer wrote:

Hi John,

On 1/9/24 11:49, John Crispin wrote:

FAQ

* Why are there are 2 different flash chips?
- the idea is to make the device (almost!) unbrickable and very easy 
to recover
- NAND will hold the main loader (U-Boot) and the Linux image and 
will be the default boot device
- NOR will be write-protected by default (with WP jumper available on 
the board) and will hold a recovery bootloader (and other essential 
data, like Wi-Fi calibration)
- a dedicated boot select switch will allow changing between NOR and 
NAND


No Idea how MTK factory calibration data is individual per-device.

If it's possible, I'd like to propose a archive of the 
radio-calibration / MAC-Address partition.


So this would be used to enable people download their calibration data 
for their serial-number and

make it "unbrickable" with an SPI clamp.

What do you think?

Best
David

Hi David

indeed, I fully agree, the calib blob holds no privacy relevant info. 
once the vote concludes positive I have the mandat to talk with the ODM. 
the idea is to provide a http/rest endpoint for the ODM to


a) grab a blob with the serial number and other TBD data to be place 
inside the flash


b) upload the calibration data for backup storage,

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 17.01.24 20:28, Daniel Santos wrote:

On 1/16/24 00:36, John Crispin wrote:


And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working 
on this!


My only request is that any unused gpios that don't make it to 
mikroBUS find their way to a (possibly unpopulated) header some 
where for the sake of hackability. 1mm pitch is fine. I've had more 
than one occasion where I wanted to add something and didn't have 
the bus or I/O lines and then discovered that the MCU did, but they 
were all N/C. Hackability is what makes the FOSS / open hardware 
world so awesome.\!


Daniel

yeah we will add all remaining GPIO togehter with GND and 3,3V on a 
2.54mm header.


HELL YES! Even better!

Even though it's on mikroBUS, maybe export the reset line on header as 
well?


Daniel


Hi Daniel,

good Idea added to my TODO notes

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 17.01.24 17:19, Fernando Frediani wrote:
Hi, again, does this SoC have any type of NAT offload capability ? Now 
a days with common Internet Broadband plans that is becoming a must.


Also is there any possibility to consider more than just 2 Ethernet 
ports (at least 4)? Would that increase the cost significantly ?


Fernando


yes via flow table offload

--> 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/mediatek/mtk_ppe_offload.c



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 17.01.24 17:46, Janusz Dziedzic wrote:

Do you think I can use m.2 A->M converter here and use wifi mt7916 A+E
(6GHz) instead of NVMe?
Eg.https://kamami.pl/akcesoria-do-raspberry-pi/587051-m2-m-key-to-m2-a-key-adapter-m2-m-key-do-m2-a-key.html
Will that work?


so the theory but we wont know until we try.

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

Additional FAQ for OpenWrt One

This is a summary of some further questions regarding the OpenWrt One 
project gathered so far. After OpenWrt voted to move forward, it will be 
converted into a page within the OpenWrt wiki as a place for collecting 
the latest information.


Q: Will the various hardware buttons and switches be fully exposed on 
the outside?
A: The latest iteration of the design will fully expose all buttons and 
switches.


Q: Will there be an option to purchase preassembled kits?
A: We're considering that option but still need to explore possibilities 
with the manufacturer.


Q: When do you expect general availability?
A: Once we vote to move forward, it will take around 45 days until the 
first PCBA engineering samples get shipped. These will be passed on to 
developers for testing. Once they are verified it will probably take 
another 30-45 days until they can be ordered. So we are looking at April 
timeframe.


Q: What kind of power supply is needed?
A: While the initial announcement imprecisely referred to the power 
supply as "USB-PD 12V" the PCB will draw its required power from a USB-C 
PD 3.0/2.0 source.


Q: Why does the current design not feature any USB 3.0 connectivity?
A: USB 3.0 always has the risk of interference with 2.4 GHz Wi-Fi. We 
would like to reduce risk as much as possible. Interference proofing the 
board would add considerable complexity and costs.


Q: Why did you implement a M.2 slot?
A: After careful consideration we came to the conclusion that directly 
exposing a PCIe 1x lane in the form of an M.2 slot provides the most 
flexibility for potential expansions. It can be used for NVMe storage 
(up to 2242 when using an enclosure), e.g. to host containers or media 
files. It also enables the simple use of other, non-OpenWrt 
distributions with larger storage footprints.


Q: Why is there no consideration for Wi-Fi 6E/7 (6GHz / Tri-Band)?
A: Neither is the mac80211 upstream support for Wi-Fi 7 complete, nor is 
there a fully integrated tri-band SoC solution available right now, let 
alone fully or partially supported upstream. Supporting Wi-Fi 7 would 
drastically increase the overall costs and make it impossible to deliver 
sufficient software support in the foreseeable future.


Q: Why are there only two ethernet ports?
A: We didn't want to impose additional complexity and costs by including 
an external managed switch IC. One port is 1GBit/s capable, while the 
other features a speed up to 2.5GBit/s. This is a limitation of the 
chosen SoC.


Q: Why should I get the One? There are more capable, more featured 
devices available!
A: The OpenWrt One is intended to serve as a robust and simple 
educational platform for OpenWrt enthusiasts, it is neither intended to 
be a competitor to off the shelf SOHO routers nor do we aim for the 
largest possible amount of features. It also serves as a donation 
vehicle for the OpenWrt project.


Q: Does that mean that OpenWrt will stop supporting other hardware?
A: There is no intention at all to change the way OpenWrt operates or 
how it implements and supports current and future hardware. The OpenWrt 
One device will be supported as one device among many others and receive 
the same level of support.


Q: Doesn't this draw attention away from properly supporting existing 
devices?
A: The OpenWrt One project is a privately led initiative by a few 
enthusiasts, there is no intent to change the focus of the OpenWrt 
project in any way.



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

And in the interest of running *my* own mouth, I'm stoked as hell -- 
LOVE that it will have mikroBUS! Thanks to John and everyone working 
on this!


My only request is that any unused gpios that don't make it to 
mikroBUS find their way to a (possibly unpopulated) header some where 
for the sake of hackability. 1mm pitch is fine. I've had more than one 
occasion where I wanted to add something and didn't have the bus or 
I/O lines and then discovered that the MCU did, but they were all N/C. 
Hackability is what makes the FOSS / open hardware world so awesome.\!


Daniel

yeah we will add all remaining GPIO togehter with GND and 3,3V on a 
2.54mm header.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

when did crowdfunding come into play here ? there is no intention of 
starting a crowdfunder.


    John

On 15.01.24 01:51, Kathy Giori wrote:

Or CrowdSupply  (founder Joshua Lifton).

Or I could introduce you to BeagleBoard.org  
-- combo of the founder and the exec dir is quite an experienced pair, 
well-aligned with OpenWrt principles, experienced with getting 
high-volume hardware manufactured and sold (that is manufactured in 
Asia). If you want to collaborate/co-brand with them, you'd have solid 
experience behind the sales and distribution of the platform to 
top-tier distributors (DigiKey, etc.). I already mentioned this 
project to founder Jason Kridner and he'd be happy to have a chat.


kathy

p.s. perhaps you could organize a discussion of this platform at FOSDEM?


On Sun, Jan 14, 2024 at 7:05 AM Dave Taht  wrote:

Can I recommend you do a kickstarter?

___
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

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 12.01.24 16:16, Bas Mevissen via openwrt-devel wrote:


Hardwarespecifications:

* SOC: MediaTek MT7981B
* Wi-Fi: MediaTek MT7976C (2x2 2.4 GHz + 3x3/2x2 + zero-wait DFS 5Ghz)


Was the MT7986AV, MT7976DA combo considered? Has 4x4 for office 
applications (MU-MIMO), so might be useful for corporate or soho use.

It also has more horse power to run some local services


That would be the BPi R3-Mini. if you need that extra HP, please grab 
that unit.






* DRAM: 1 GiB DDR4


What's the price difference with 2GB? For home automation purposes and 
other virtualisation applications it might come in handy. 


1GB is recommended and well tested. We will probably get engineering 
samples and test with 2GB


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 10.01.24 12:17, Robert Marko wrote:

Along with a well designed minimalistic case with sufficient passive
cooling and optional integrated antennas.  Thinking something along the
Flirc RPi4 cases, using the case itself as a cooler. With half the case
radio transparent and a choice between antenna pigtails and integrated
antennas.  I realize that such a case will be relatively expensive. But
without it all you have is yet another midrange dev board.  This is your
chance to make a device which shouts "OpenWrt!!!" whenever someone sees
it. Just like the original WRT did.  Not that that design was something
to brag about beauty wise :-)

I also think we should should have a pre-assembled-with-case-and-antennas
option in addition to just offering the plain board.

I think this is crucial for any OpenWrt board, as that is where the
biggest audience is.

Regards,
Robert


yes, there should be 2 SKUs.

* raw PCB

* fully assembled inside case

SFC emphasized that they think having a fully assembled option is 
crucial in their opinion.


regarding having a fancy and flashy plastic case. Would have loved to 
see that happen, but the lead time for mould casting is insane as well 
as the cost, specifically for small production runs. hence the choice 
for re-using something that already exists.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 09.01.24 14:51, Chuanhong Guo wrote:

Hi!

On Tue, Jan 9, 2024 at 6:52 PM John Crispin  wrote:

[...]
FAQ

* Why are there are 2 different flash chips?
- the idea is to make the device (almost!) unbrickable and very easy to
recover

What about a built-in JTAG probe instead of SPI-NOR+USB-UART?
It'll be actually unbrickable instead.


- NAND will hold the main loader (U-Boot) and the Linux image and will
be the default boot device
- NOR will be write-protected by default (with WP jumper available on
the board) and will hold a recovery bootloader (and other essential
data, like Wi-Fi calibration)
- a dedicated boot select switch will allow changing between NOR and NAND
[...]
* What is the purpose of the console USB-C port?
- Holtek UART to USB bridge with CDC-ACM support on USB-C makes the
device ultra easy to communicate with. No extra hardware or drivers will
be required. Android for example has CDC-ACM support enabled by default

There are several MCU-based CMSIS-DAP projects out there. They can
provide a CDC-ACM serial with a JTAG interface. It may be a bit slow if a
USB1.1 MCU is picked, but it should be enough to start a bootloader to
unbrick the device.

Here's one with USB2.0 Hi-speed interface:
https://github.com/cherry-embedded/CherryDAP
The Sipeed M0S module used costs 20CNY on Taobao
(or 2.81 USD according to google)


we looked into that kind of solution, i felt more accessible for the 
wider audience to use a CDC-ACM chip. flashing using a DAP involves 
knowing what JTAG is and how to use it. the idea is that the NOR uboot 
has a backup copy of the NAND uboot. holding down one of the buttons 
while powering on the device while BOOTSEL is on NOR will auto recover 
the NAND. cannot think of a simpler solution. as for the cdc-acm chip. 
we looked at the holtek, cypress and microchip components. the holtek 
seems to be the easiest to source for the ODM.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 09.01.24 12:56, Robert Marko wrote:

---SNIP---


Why not 6GHz?

6GHz requires an external card, and I doubt you can fit that in the
target price.

Regards,
Robert


correct. as mentioned in the email, we wanted to start out small. also 
upstream mac80211 is still missing a bunch of 11be related features.


    John



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

On 09.01.24 12:58, Rafał Miłecki wrote:


So are you looking for just a generic interest feedback? Or some
technical comments? What are next steps for this project and do you
could use some community help?


just general feedback. it felt a bit weird to jump straight into voting.

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

OpenWrt One - celebrating 20 years of OpenWrt

[John Crispin]

ACM support enabled by default


* What MAC OUI will the device have?
- we plan to register an OUI block for OpenWrt which can also be used 
for other vendor extensions such as Wi-Fi beacon IEs


* What is the purpose of the mikroBUS connector?
- mikroBUS was chosen as we wanted to make the hardware extendable. 
There are dedicated pins for UART, SPI, I2C buses and RST/INT signals. 
The standard uses regular 2.54 mm pitch connectors (you can use 
available mikroBUS modules or just connect to it something else, with 
2.54 mm jumper cables)


 * Why have the RTC on board instead of a mikroBUS module?
 - we believe there are many things a Wi-Fi (or networking in general) 
device should have on-board by default. Always having a correct time on 
the device is crucial in many applications, like VPN, DNSSEC, …



Timeline of events leading up to this e-mail

Forgive us for the lack of public communication during the initial 
phase(which as you can see was short and quick). We wanted to ensure 
that this project is feasible before disclosing it to the community. It 
would be a real shame if we announced something that we later found out 
to not be feasible thus failing expectations raised within the community.


03.12 - initial idea
06.12 - ping pepe2k, dangole, nbd
07.12 - ping MediaTek and ask if this sounds doable
08.12 - ping jow, Hauke
08.12 - request for call with SFC, we want them involved as soon as possible
09.12 - MediaTek replies and says they can help
09.12 - ping apacar, ynezz, dwmm2, lynxis, rsalvaterra
12.12 - MediaTek spoke with Banana Pi, they also like the idea
18.12 - call with SFC (Hauke joined, we found no prior slot to talk)
20.12 - started writing the U-Boot PCIe driver, made recovery from USB 
and android fastboot recovery work.
... and then the end of year celebrations started and not much happened 
for 2 weeks.

03.01-08.01 - write this text


Thanks,
Signed-off-by: Alexander Couzens 
Signed-off-by: Bradley M. Kuhn 
Signed-off-by: Daniel Golle 
Signed-off-by: David Bauer 
Signed-off-by: Denver Gingerich 
Signed-off-by: Felix Fietkau 
Signed-off-by: Hauke Mehrtens 
Signed-off-by: John Crispin 
Signed-off-by: Jo-Philipp Wich 
Signed-off-by: Paul Spooren 
Signed-off-by: Petr Štetiar 
Signed-off-by: Piotr Dymacz 
Signed-off-by: Steven Liu 



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] netifd: exclude 20-smp-packet-steering on bcm53xx

[John Crispin]

northstar could ship a uci-defaults script to populate UCI for line 37 -->

https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/network/config/netifd/files/etc/hotplug.d/net/20-smp-packet-steering;h=8a86bf75f60040e97a7779628afb0993aee87c50;hb=HEAD#l37

On 02.02.23 17:06, Rafał Miłecki wrote:

From: Rafał Miłecki 

bcm53xx comes with custom (more optimized) packet steering. A race
between two scripts was resulting in varying network performance.

Ref: fcbd39689ebf ("bcm53xx: enable & setup packet steering")
Signed-off-by: Rafał Miłecki 
---
Is this an acceptable method to handle this?
---
  package/network/config/netifd/Makefile | 4 
  1 file changed, 4 insertions(+)

diff --git a/package/network/config/netifd/Makefile 
b/package/network/config/netifd/Makefile
index 500daaa152..dac325004c 100644
--- a/package/network/config/netifd/Makefile
+++ b/package/network/config/netifd/Makefile
@@ -45,6 +45,10 @@ define Package/netifd/install
$(CP) ./files/* $(1)/
$(INSTALL_DIR) $(1)/etc/udhcpc.user.d/
$(CP) $(PKG_BUILD_DIR)/scripts/* $(1)/lib/netifd/
+ifneq ($(CONFIG_TARGET_bcm53xx),y)
+   $(INSTALL_DIR) $(1)/etc/hotplug.d/net
+   $(CP) ./files/20-smp-packet-steering $(1)/etc/hotplug.d/net/
+endif
  endef
  
  $(eval $(call BuildPackage,netifd))


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mt7621 GPIO mapping mystery

[John Crispin]

On 21.01.23 15:51, Sergio Paracuellos wrote:

AFAICS, the Ralink driver sets gpio mode for a group of pins using
set_mux operation [1] so when the
gpio_request_enable() operation is called a check for that pin is set
as gpio is performed. Nothing else.
Maybe John Crispin who is the writer of this driver can explain a bit
more about this.


the ralink mips silicon does not have a bit per pin to fiddle the mode. 
some pins are grouped. rgmii for example, there is a single bit that 
will effect 8 pins


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH procd] instance: dump netdev params

[John Crispin]

On 26.09.22 20:22, st...@linux-ipv6.be wrote:

+   if (!avl_is_empty(>netdev.avl)) {
+   struct blobmsg_list_node *var;
+   void *n = blobmsg_open_array(b, "netdev");


blank line between declaration and code


+   blobmsg_list_for_each(>netdev, var)
+   blobmsg_add_string(b, NULL, blobmsg_data(var->data));
+   blobmsg_close_array(b, n);
+   }
+


Acked-by: John Crispin 

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] ugps: add baud rate command line option

[John Crispin]

Hi,

thanks for the patch !


+   default:
+   return B0;


please default to B4800 and add a fprintf(stderr, ...) indicating this 
decision


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: mips: [RFC] adding support for APJET01 ref board

[John Crispin]

On 13.11.21 17:30, Oleksandr Hnatiuk wrote:

From: Oleksandr Hnatiuk 
Signed-off-by: Oleksandr Hnatiuk 

Changes in this version of the patch:
- removed nested rootfs partition
- added "compatible" field to the linux partition
- added IMAGE_SIZE field to device description

This patch enables booting the board and running OpenWrt, but lacks any support
for switch / wireless / USB. Posting here just to let future readers know that
some of the issues / questions from my previous emails are resolved. However,
the question regarding describing switch and ethernet ports is still relevant.
The work can be tracked here: gitlab.com/alexconst.sh/openwrt
  or here: forum.openwrt.org/t/adding-openwrt-support-for-asus-rt-ac57u-v2/53281
---

diff --git a/target/linux/ath79/dts/qcn5502_qca_apjet01-16m.dts 
b/target/linux/ath79/dts/qcn5502_qca_apjet01-16m.dts
new file mode 100644
index 00..9fa31b85d0
--- /dev/null
+++ b/target/linux/ath79/dts/qcn5502_qca_apjet01-16m.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include 
+#include 
+
+#include "qca956x.dtsi"
+
+/ {
+   compatible = "asus,rt-ac59u", "qca,qcn5502", "qca,qca9560";
+   model = "ASUS RT-AC59U";


this appears to be copy and needs to be fixed. also the patch is 
missing all the relevant changes to base-files/etc/board.d/

John

+
+   aliases {
+   serial0 = 
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mips,mips74Kc";
+   clocks = < ATH79_CLK_CPU>;
+   reg = <0>;
+   };
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x800>;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   wlan {
+   label = "apjet01:green:wlan";
+   gpios = < 15 GPIO_ACTIVE_LOW>;
+   };
+
+   usb {
+   label = "apjet01:green:usb";
+   gpios = < 4 GPIO_ACTIVE_LOW>;
+   };
+
+   lan@1 {
+   label = "apjet01:green:lan";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   };
+
+   lan@2 {
+   label = "apjet01:green:lan";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   };
+
+   lan@3 {
+   label = "apjet01:green:lan";
+   gpios = < 4 GPIO_ACTIVE_LOW>;
+   };
+
+   lan@4 {
+   label = "apjet01:green:lan";
+   gpios = < 5 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   button@0 {
+   label = "wps";
+   linux,code = ;
+   gpios = < 1 GPIO_ACTIVE_LOW>;
+   debounce-interval = <60>;
+   };
+
+   button@1 {
+   label = "reset";
+   linux,code = ;
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   debounce-interval = <60>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+
+   flash@0 {
+   compatible = "winbond,w25q128", "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <2500>;
+
+   partitions {
+   compatible = "fixed-partitions";
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   partition@0 {
+   label = "u-boot";
+   reg = <0x00 0x04>;
+   };
+
+   partition@04 {
+   label = "nvram";
+   reg = <0x04 0x01>;
+   };
+
+   partition@05 {
+   label = "factory";
+   reg = <0x05 0x01>;
+   };
+
+   partition@06 {
+   label = "linux";
+   reg = <0x06 0xf2>;
+   compatible = "denx,uimage";
+   };
+
+   partition@f8 {
+   label = "jffs2";
+   reg = <0xf8 0x08>;
+   };
+   };
+   };
+};
diff --git a/target/linux/ath79/image/generic.mk 
b/target/linux/ath79/image/generic.mk
index 9d0be2b86b..4fb10ba0a6 100644

Re: warning about which deprecated

[John Crispin]

https://lwn.net/Articles/874333/ ?!?

On 07.11.21 19:05, Ansuel Smith wrote:

Updating to latest ubuntu devel this now comes up
/home/ansuel/openwrt/staging_dir/host/bin/which: this version of
`which' is deprecated; use `command -v' in scripts instead.

I think we have to update something?

___
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

Re: [PATCH 2/2] hostapd: force ieee80211w instead of setting a default

[John Crispin]

Am 11.10.21 um 19:40 schrieb Henrique de Moraes Holschuh via openwrt-devel:

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.

right now luci will force 2

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] netifd: fix wpa enterprise mode

[John Crispin]

Currently netifd only knows 2 wpa3/eap modes, wpa3 and wpa3-mixed.
Accoring to the spec there are however 3 mode, wpa3, wpa3-192 and wpa3-mixed.
In addition the mode currently called "incorrectly" setups up wpa3-192 and there
is no wpa3(-only) mode.

Fix the handler script s.T. hostap.sh can then properly setup wpa3/eap.

Tested-on: iPhone 12, Samsung S10/S20
Signed-off-by: John Crispin 
---
 scripts/netifd-wireless.sh | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/scripts/netifd-wireless.sh b/scripts/netifd-wireless.sh
index 80fbf75..0ee95d9 100644
--- a/scripts/netifd-wireless.sh
+++ b/scripts/netifd-wireless.sh
@@ -252,11 +252,14 @@ wireless_vif_parse_encryption() {
auth_type=owe
;;
wpa3-mixed*)
-   auth_type=eap-eap192
+   auth_type=eap-eap256
;;
-   wpa3*)
+   wpa3-192*)
auth_type=eap192
;;
+   wpa3*)
+   auth_type=eap256
+   ;;
psk3-mixed*|sae-mixed*)
auth_type=psk-sae
;;
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] hostapd: force ieee80211w instead of setting a default

[John Crispin]

WPA3 modes require 11w to be set to optional/required. Using set_default would
allow forcing an invalid value from UCI.

Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/hostapd.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index efb06427ca..36156a002c 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -1211,10 +1211,10 @@ wpa_supplicant_add_network() {
 
case "$auth_type" in
sae|owe|eap192|eap-eap256|eap256)
-   set_default ieee80211w 2
+   ieee80211w=2
;;
psk-sae)
-   set_default ieee80211w 1
+   ieee80211w=1
;;
esac
 
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] hostapd: fix wpa enterprise mode

[John Crispin]

Currently netifd only knows 2 wpa3/eap modes, wpa3 and wpa3-mixed.
Accoring to the spec there are however 3 mode, wpa3, wpa3-192 and wpa3-mixed.
In addition the mode currently called "incorrectly" setups up wpa3-192 and there
is currently no wpa3(-only) mode.

Fix hostapd.sh s.T. the now corretly passed values from netifd are honoured.

Tested-on: iPhone 12, Samsung S10/S20
Signed-off-by: John Crispin 
---
 .../network/services/hostapd/files/hostapd.sh | 35 +--
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 4f306317c7..efb06427ca 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -48,14 +48,18 @@ hostapd_append_wpa_key_mgmt() {
;;
eap192)
append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
+   append wpa_key_mgmt "WPA-EAP-SHA256"
[ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-EAP"
-   ;;
-   eap-eap192)
-   append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
+   ;;
+   eap-eap256)
append wpa_key_mgmt "WPA-EAP"
+   append wpa_key_mgmt "WPA-EAP-SHA256"
[ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-EAP"
-   [ "${ieee80211w:-0}" -gt 0 ] && append wpa_key_mgmt 
"WPA-EAP-SHA256"
-   ;;
+   ;;
+   eap256)
+   append wpa_key_mgmt "WPA-EAP-SHA256"
+   [ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-EAP"
+   ;;
sae)
append wpa_key_mgmt "SAE"
[ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-SAE"
@@ -602,11 +606,11 @@ hostapd_set_bss_options() {
}
 
case "$auth_type" in
-   sae|owe|eap192|eap-eap192)
+   sae|owe|eap192|eap256)
set_default ieee80211w 2
set_default sae_require_mfp 1
;;
-   psk-sae)
+   psk-sae|eap-eap256)
set_default ieee80211w 1
set_default sae_require_mfp 1
;;
@@ -649,7 +653,7 @@ hostapd_set_bss_options() {
vlan_possible=1
wps_possible=1
;;
-   eap|eap192|eap-eap192)
+   eap|eap192|eap-eap256|eap256)
json_get_vars \
auth_server auth_secret auth_port \
dae_client dae_secret dae_port \
@@ -885,7 +889,16 @@ hostapd_set_bss_options() {
json_get_vars ieee80211w_mgmt_cipher 
ieee80211w_max_timeout ieee80211w_retry_timeout
append bss_conf "ieee80211w=$ieee80211w" "$N"
[ "$ieee80211w" -gt "0" ] && {
-   append bss_conf 
"group_mgmt_cipher=${ieee80211w_mgmt_cipher:-AES-128-CMAC}" "$N"
+   case "$auth_type" in
+   eap192)
+   append bss_conf 
"group_mgmt_cipher=BIP-GMAC-256" "$N"
+   append bss_conf 
"group_cipher=GCMP-256" "$N"
+   ;;
+   *)
+   append bss_conf 
"group_mgmt_cipher=${ieee80211w_mgmt_cipher:-AES-128-CMAC}" "$N"
+   ;;
+   esac
+
[ -n "$ieee80211w_max_timeout" ] && \
append bss_conf 
"assoc_sa_query_max_timeout=$ieee80211w_max_timeout" "$N"
[ -n "$ieee80211w_retry_timeout" ] && \
@@ -1197,7 +1210,7 @@ wpa_supplicant_add_network() {
default_disabled
 
case "$auth_type" in
-   sae|owe|eap192|eap-eap192)
+   sae|owe|eap192|eap-eap256|eap256)
set_default ieee80211w 2
;;
psk-sae)
@@ -1278,7 +1291,7 @@ wpa_supplicant_add_network() {
  

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 26.09.21 13:34, David Bauer wrote:
That being set, the goal of poemgr is not to replace the other 
efforts. I'm sorry if I caused this impression. 


it did not replace anything. I am fully with you on this one, 
realtek-poe took the same approach but merging it was NAK'ed with the 
argument, that we can only merge the ultimate solution. which is why 
till this day there is no upstream support for realtek.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

poemgr does not use the APIs provided by libubox so I doubt that this 
will land in the tree.


    John

On 26.09.21 07:22, Raylynn Knight wrote:

It’s not clear to me what OpenWrt supported device(s) the below poemgr is meant 
for!

It might be helpful to compile a list of currently supported OpenWrt devices 
that have PoE capability.
Below would be my contribution of OpenWrt supported devices that I know have 
PoE capability:

Device  Processor   
PoE out
——
D-Link DGS-1210-10P RTL8380M8x 
802.3af/at
develo WiFi pro 1750e   QCA9558 1x 802.3af
MikroTik RB750P-PBr2QCA9533 4x Passive PoE
MikroTik RB750UPr2  (hEX PoE lite)  QCA9531 4x Passive PoE
MikroTik RB2011iL-INAR9344  1x 
Passive PoE
MikroTik RBcAPGi  (cAP ac)  IPQ4018 1x Passive PoE
MikroTik RB962UiGS (hAP ac) QCA9558 1x Passive PoE
MikroTik RBmAP-2nD (wAP)QCA9531 1x Passive PoE
Netgear GS110TPPRTL8380M8x 
802.3af/at
Netgear GS310TPv1   RTL8380M8x 
802.3af/at
TP-Link TPE210  AR9344  1x 
Passive PoE
TP-Link TEP510  AR9350  1x 
Passive PoE
Ubiquiti EdgeRouter 6P  CN7130  5x 
Passive PoE
Ubiquiti EdgeRouter X   MT7621AT1x 
Passive PoE
Ubiquiti EdgeRouter X SFP   MT7621AT5x 
Passive PoE
Ubiquiti ToughSwitch TS-5-POE   AR7240  5x Passive PoE
Ubiquiti EdgePoint R6   MT7621AT5x 
Passive PoE
ZyXEL GS1900-10HP   RTL8380M8x 
802.3af/at
ZyXEL GS1900-8HPRTL8380M8x 
802.3af/at
ZyXEL GS1900-8HPRTL8380M  
8x802.3af/at
ZyXEL GS1900-24HP v2RTL8382M24x 802.3af/at

I actually have the D-Link switch, 1 of the Netgear switches, 4 of the Ubiquiti 
devices and 2 of the ZyXEL switches.
I also have additional realtek based PoE switches I plan on submitting support 
for when I get time.

Ray


On Sep 25, 2021, at 6:01 PM, Bjørn Mork  wrote:

And then we had https://github.com/blocktrron/poemgr

But without support for the MCU controlled broadcom PSE chips in the
realtek target, and without ubus support.

Time to consolidate some of this code?  Or is poemgr the result of that,
just not yet with those features implmented?


Bjørn

___
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

Re: [PATCH ubus] ubusd: log ACL init errors

[John Crispin]

On 20.08.21 18:39, Rafał Miłecki wrote:

From: Rafał Miłecki 

This makes it easier to notice ubusd (and so often a system) failing to
start properly. Some users reported procd failing to initialize fully
without a clear error with faulty /etc/passwd.

Signed-off-by: Rafał Miłecki 

Acked-by: John Crispin 

---
  ubusd_acl.c  | 13 ++---
  ubusd_main.c |  3 +++
  2 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/ubusd_acl.c b/ubusd_acl.c
index e050e2c..352c581 100644
--- a/ubusd_acl.c
+++ b/ubusd_acl.c
@@ -26,6 +26,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "ubusd.h"
  
@@ -175,19 +176,25 @@ ubusd_acl_init_client(struct ubus_client *cl, int fd)

  #ifdef SO_PEERCRED
unsigned int len = sizeof(struct ucred);
  
-	if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, , ) == -1)

+   if (getsockopt(fd, SOL_SOCKET, SO_PEERCRED, , ) == -1) {
+   ULOG_ERR("Failed getsockopt(): %m\n");
return -1;
+   }
  #else
memset(, 0, sizeof(cred));
  #endif
  
  	pwd = getpwuid(cred.uid);

-   if (!pwd)
+   if (!pwd) {
+   ULOG_ERR("Failed getpwuid(): %m\n");
return -1;
+   }
  
  	group = getgrgid(cred.gid);

-   if (!group)
+   if (!group) {
+   ULOG_ERR("Failed getgrgid(): %m\n");
return -1;
+   }
  
  	cl->uid = cred.uid;

cl->gid = cred.gid;
diff --git a/ubusd_main.c b/ubusd_main.c
index d454b1a..6b132ce 100644
--- a/ubusd_main.c
+++ b/ubusd_main.c
@@ -233,6 +233,8 @@ static void mkdir_sockdir()
free(ubus_sock_dir);
  }
  
+#include 

+
  int main(int argc, char **argv)
  {
const char *ubus_socket = UBUS_UNIX_SOCKET;
@@ -242,6 +244,7 @@ int main(int argc, char **argv)
signal(SIGPIPE, SIG_IGN);
signal(SIGHUP, sighup_handler);
  
+	ulog_open(ULOG_KMSG | ULOG_SYSLOG, LOG_DAEMON, "ubusd");

openlog("ubusd", LOG_PID, LOG_DAEMON);
uloop_init();
  


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Guidance on creating man pages for procd utilities

[John Crispin]

On 19.08.21 03:24, Lucas Ramage wrote:

Greetings,

I would like to create man pages for uxc and some of the other utilities in the 
procd repository.

Searching through some of the commits in the openwrt/packages repository shows 
that man pages are intensionally disabled from being built,  but I still think 
they are helpful to have. Perhaps there could be -doc packages like in other 
distributions?

Please advise,


I normally use asciidoc or gitbook for documentation

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] uqmi: Move to community packages repo

[John Crispin]

On 02.07.21 13:35, Koen Vandeputte wrote:



+1 for keeping it in the core



I agree, moving packages into the feed makes sense, but stuff needed for 
connectivity should stay in trunk


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] comgt: Move to community packages repo

[John Crispin]

On 28.06.21 21:14, Paul Spooren wrote:
I'm in favor of this too but if it's a core feature (i.e. SIM card 
support) we should provide the package by default to, not? 


this should be explained in the wiki,

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] comgt: Move to community packages repo

[John Crispin]

On 28.06.21 19:26, Piotr Dymacz wrote:
I might be wrong here but I think we don't include packages from 
external feeds inside 'DEVICE_PACKAGES' (not sure/don't remember why). 


I am in favour of moving all none-core packages to the feeds. the 
dependency should be removed and a note should be added to the wiki 
indicating that if a release/snapshot image is installed an opkg call 
shall be issued


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 0/1] Workaround for rut955 modem initialization

[John Crispin]

On 28.06.21 13:56, ontje.luensd...@dlr.de wrote:

This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.



As similar problem can be observed when looking at swconfig. some 
switches need a reset, others do not. for this purpose an "option reset 
0/1" was introduced in uci. In this case maybe "modem_reset" might be a 
good option.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] hostapd: fix 11w support in eap192 mode

[John Crispin]

wpa3 enterprise does not work without enabling 11w support.

Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/hostapd.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 7d035a299b..06d6c579af 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -49,6 +49,7 @@ hostapd_append_wpa_key_mgmt() {
eap192)
append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
[ "${ieee80211r:-0}" -gt 0 ] && append wpa_key_mgmt 
"FT-EAP"
+   [ "${ieee80211w:-0}" -gt 0 ] && append wpa_key_mgmt 
"WPA-EAP-SHA256"
;;
eap-eap192)
append wpa_key_mgmt "WPA-EAP-SUITE-B-192"
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] base-files: add blink and turnoff commands to the led script

[John Crispin]

you can either use the uci option to make this a boot default or use the 
commands to do this manually


this is a common feature of LEDs. they can be on/off have a trigger etc etc.

 John

On 28.06.21 12:01, Karl Palsson wrote:

John Crispin  wrote:

This allows us to make all leds blink or force all leds to off.
It is also possible to force the default behaviour to not load
any led states/triggers by setting system.@system[-1].leds_off
to 1.

You actually force them all off though, rather than "not load any
state" ? Is the intention for "leds_off" like the name, or the
intention to be "don't touch any leds" in which case the name and
implementation don't match the commit description?

Also, what's the use case for blink in the default install? It's
not pushing any stack for a temporary blink, it just hard sets
all led to blink. I can see plenty of uses for this in
private testing builds, I have something similar myself for
production testing that all leds function, but i'm having a hard
time seeing what the use case for it is in general, and why it
should be in the default build.

Sincerely,
Karl Palsson



Signed-off-by: John Crispin 
---
  package/base-files/files/etc/init.d/led | 23 +++
  1 file changed, 23 insertions(+)

diff --git a/package/base-files/files/etc/init.d/led
b/package/base-files/files/etc/init.d/led index
51cb8b5178..252bba623a 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -3,6 +3,9 @@
  
  START=96
  
+extra_command "turnoff" "Turn all leds off"

+extra_command "blink" "Blink all leds"
+
  load_led() {
local name
local sysfs
@@ -121,7 +124,25 @@ load_led() {
}
  }
  
+turnoff() {

+   for led in `ls /sys/class/leds/`; do
+   echo none > /sys/class/leds/$led/trigger
+   echo 0 > /sys/class/leds/$led/brightness
+   done
+}
+
+blink() {
+   for led in `ls /sys/class/leds/`; do
+   echo 0 > /sys/class/leds/$led/brightness
+   echo timer > /sys/class/leds/$led/trigger
+   done
+}
+
  start() {
+   [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
+   turnoff
+   exit 0
+   }
[ -e /sys/class/leds/ ] && {
[ -s /var/run/led.state ] && {
local led trigger brightness
@@ -137,5 +158,7 @@ start() {
  
  		config_load system

config_foreach load_led led
+   . /etc/diag.sh
+   set_state done
}
  }
--
2.25.1


___
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

[PATCH] base-files: add blink and turnoff commands to the led script

[John Crispin]

This allows us to make all leds blink or force all leds to off.
It is also possible to force the default behaviour to not load
any led states/triggers by setting system.@system[-1].leds_off
to 1.

Signed-off-by: John Crispin 
---
 package/base-files/files/etc/init.d/led | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/package/base-files/files/etc/init.d/led 
b/package/base-files/files/etc/init.d/led
index 51cb8b5178..252bba623a 100755
--- a/package/base-files/files/etc/init.d/led
+++ b/package/base-files/files/etc/init.d/led
@@ -3,6 +3,9 @@
 
 START=96
 
+extra_command "turnoff" "Turn all leds off"
+extra_command "blink" "Blink all leds"
+
 load_led() {
local name
local sysfs
@@ -121,7 +124,25 @@ load_led() {
}
 }
 
+turnoff() {
+   for led in `ls /sys/class/leds/`; do
+   echo none > /sys/class/leds/$led/trigger
+   echo 0 > /sys/class/leds/$led/brightness
+   done
+}
+
+blink() {
+   for led in `ls /sys/class/leds/`; do
+   echo 0 > /sys/class/leds/$led/brightness
+   echo timer > /sys/class/leds/$led/trigger
+   done
+}
+
 start() {
+   [ "$(uci get system.@system[-1].leds_off)" -eq 1 ] && {
+   turnoff
+   exit 0
+   }
[ -e /sys/class/leds/ ] && {
[ -s /var/run/led.state ] && {
local led trigger brightness
@@ -137,5 +158,7 @@ start() {
 
config_load system
config_foreach load_led led
+   . /etc/diag.sh
+   set_state done
}
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Flagship AX routers

[John Crispin]

the

On 26.05.21 18:44, Bjørn Mork wrote:

Alberto Bursi  writes:

On 26/05/21 10:56, Bjørn Mork wrote:

Daniel Golle  writes:


When using as dual-band AP, also the Gigabit Ethernet of the E8450 can
become a bottle-kneck, UniFi 6 LR got that Aquantina 2.5GBase-T PHY

But there is no driver for that yet, right?  And for those of us who
aren't familiar with these magic phy things: Does this mean that it
currently works as a 1Gbit device only?  Or doesn't it work at all?

If you are talking of Aquantia multigigabit ethernet chipsets they
work fine in Linux, there is a upstream driver for x86 and ARM archs.

I'm talking about the phy which is described as this in the DTS:

 mdio: mdio-bus {
 #address-cells = <1>;
 #size-cells = <0>;

 ethernet-phy@7 {
 /* Marvell AQRate AQR112W - no driver */
 compatible = "ethernet-phy-ieee802.3-c45";
 reg = <0x7>;
 };
 };

There is a mainline driver in drivers/net/phy/aquantia_main.c, but it
doesn't support this chip (yet).  We have a patch in the layerscape
target, but I don't know if the "W" is significant enough that it
doesn't work:

   
target/linux/layerscape/patches-5.4/701-net-0331-drivers-net-phy-aquantia-enable-AQR112-and-AQR412.patch

And it needs to move to generic in any case.

Therefore the question...


I think someone even added the kmod for that (or the USB version of
them) in OpenWrt somewhat recently.

I haven't followed this lately, but I seem to remember that the initial
USB version was a mess of phy driver mixed into the usb device driver.
Not sure that is true anymore.  But if it is, then it won't help much
for this device which IIUC is a MT7622 SoC connected to an AQR112W phy


that ubnt 6-lr unit boots fine with HEAD and delivers good performance. 
It is really hard to get hold of them right now in EU. I managed to get 
one as "used" on ebay and after initial testing sent it off to Daniel 
s.T. he can give it some loving care in regards to uboot. hoping to get 
another one soonish.


the only caveate with that unit is that on 2G it uses the built in wmac 
which is only HT.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Flagship AX routers

[John Crispin]

On 21.05.21 20:18, Stijn Segers wrote:

Oh you'd provably get the board up and running in a jiffy. I suppose the 
multi-gigabit PHYs might already be supported as well - not in the loop in 
those. The wireless? Just look at Broadcom's FOSS track record with 
802.11g/n/ac. And vote with your wallet.

lol

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Flagship AX routers

[John Crispin]

On 19.05.21 00:09, Paul Spooren wrote:

Hi,

On 5/18/21 11:52 PM, Philip Prindeville wrote:

Hi all,

I noticed that there are several AX routers from TP-Link, Netgear, 
D-Link, etc. and some of them have even had OpenWRT ported to them.


Which of these various platforms has the most CPU/RAM/FLASH? A few 
are discussed, but I'm not seeing consensus on "the best one 
currently is this..."


I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which 
are conveniently pretty much the same thing and I'm having a pretty 
good time. Would flash again.


Best,
Paul



this is the goto unit for AX right now ...

https://openwrt.org/toh/linksys/linksys_e8450

consider using this to flash the unit

https://github.com/dangowrt/linksys-e8450-openwrt-installer

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 11.05.21 19:51, Rafał Miłecki wrote:

On 11.05.2021 19:46, John Crispin wrote:

On 11.05.21 19:45, Rafał Miłecki wrote:

I'm really tired of dealing with such hacky solutions. Look at netifd,
DSA and LuCI as example. We ended up with something that noone fully
understands. Jo - our UI guru - couldn't deal with designing a proper
UI for that f*cked config syntax. 


sorry mate, I am not the reason you are having a bad day, so dont 
vent it out on me.


It's just an example of shitty situation we got. Nothing more.

I took a good amount of time to provide valuable review for the
[PATCH v2] rtl83xx-poe: add package

I described problems, missing parts, provided examples how one can
solve it. Let's discuss that please. Instead of commenting on one
example I provided.


lulz, why so aggravated ... its about the code not the person ...

possibly I missed some of your feedback, will review tomorrow, keep the 
spirit mate and just chill a little ...


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 11.05.21 19:45, Rafał Miłecki wrote:

I'm really tired of dealing with such hacky solutions. Look at netifd,
DSA and LuCI as example. We ended up with something that noone fully
understands. Jo - our UI guru - couldn't deal with designing a proper
UI for that f*cked config syntax. 


sorry mate, I am not the reason you are having a bad day, so dont vent 
it out on me.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 11.05.21 19:38, John Crispin wrote:


On 11.05.21 19:34, Rafał Miłecki wrote:


I'm happy to see C code, but this implementation still doesn't address
any of my comments I posted in the
Re: [PATCH v2] rtl83xx-poe: add package
https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 



I strongly believe we need a more generic solution. A tiny framework
with generic PoE imlementation and then rtl83xx support on top of that. 



agreed, but for now this makes PoE work for the community. the next 
step will be to move this into kernel space using the appropriate 
subsystems, however that will take time and effort.


the aim of the patch is to get support functional out of the box for 
the community and then address the real solution afterwards.


    John

that being said, I have a edgerouter-x(-sfp) on my desk. I already 
started a PoC patch to support a more generic approach for PoE that is 
agnostic of wheter the HW support is driven via GPIO or a ttyS attached 
MCU. but as I said, takes time and effort. for now, the RTL crowd will 
have PoE and 1-2 months down the line we will have a more generic 
approach... any other PoE capable HW around that we need to consider in 
the design phase ?


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 11.05.21 19:34, Rafał Miłecki wrote:


I'm happy to see C code, but this implementation still doesn't address
any of my comments I posted in the
Re: [PATCH v2] rtl83xx-poe: add package
https://patchwork.ozlabs.org/project/openwrt/patch/20210313165419.10713-1-bj...@mork.no/#2666485 



I strongly believe we need a more generic solution. A tiny framework
with generic PoE imlementation and then rtl83xx support on top of that. 



agreed, but for now this makes PoE work for the community. the next step 
will be to move this into kernel space using the appropriate subsystems, 
however that will take time and effort.


the aim of the patch is to get support functional out of the box for the 
community and then address the real solution afterwards.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

On 11.05.21 17:56, Bjørn Mork wrote:

Tested-by: Bjørn Mork

Running on a ZyXEL GS1900-10HP:


thanks for testing. I just found 2 tiny issues that I already fixed 
locally and added a uci-defaults script s.T. we can setup a sane default 
uci for the various switches. If there are no further comments, I will 
merge this in the next couple of days


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] realtek-poe: add support for PoE on Realtek switches

[John Crispin]

This patch adds a C rewrite of the LUA tool previously posted. With this new
daemon we map the DSA port names to the PSE port id. Support for several now
features was added, such as setting the priority and at/af mode. In the next
iteration addition port/mcu states will be exposed, aswell as adding support
for 4 wire mode and fault handling.

A Sample config looks like this:

config global
option budget   '65'

config port
option enable   '1'
option id   '1'
option name 'lan1'
option poe_plus '1'
option priority '2'

ubus call poe info
{
"firmware": "v48.2",
"mcu": "Nuvoton M05xx LAN Microcontroller",
"budget": 65.00,
"consumption": 2.40,
"ports": {
"lan1": {
"priority": 2,
"mode": "PoE",
"status": "Delivering power",
"consumption": 2.40
}
}
}

Signed-off-by: John Crispin 
---
 package/network/config/realtek-poe/Makefile   |  25 +
 .../config/realtek-poe/files/etc/config/poe   |   9 +
 .../config/realtek-poe/files/etc/init.d/poe   |  20 +
 .../config/realtek-poe/src/CMakeLists.txt |  28 +
 package/network/config/realtek-poe/src/main.c | 844 ++
 5 files changed, 926 insertions(+)
 create mode 100644 package/network/config/realtek-poe/Makefile
 create mode 100644 package/network/config/realtek-poe/files/etc/config/poe
 create mode 100755 package/network/config/realtek-poe/files/etc/init.d/poe
 create mode 100644 package/network/config/realtek-poe/src/CMakeLists.txt
 create mode 100644 package/network/config/realtek-poe/src/main.c

diff --git a/package/network/config/realtek-poe/Makefile 
b/package/network/config/realtek-poe/Makefile
new file mode 100644
index 00..4dba054bb2
--- /dev/null
+++ b/package/network/config/realtek-poe/Makefile
@@ -0,0 +1,25 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=realtek-poe
+PKG_RELEASE:=1
+
+PKG_LICENSE:=GPL-2.0
+PKG_MAINTAINER:=John Crispin 
+
+include $(INCLUDE_DIR)/package.mk
+include $(INCLUDE_DIR)/cmake.mk
+
+define Package/realtek-poe
+  SECTION:=net
+  CATEGORY:=Network
+  TITLE:=Realtek PoE Switch Port daemon
+  DEPENDS:=@TARGET_realtek +libubox +libubus +libuci
+endef
+
+define Package/realtek-poe/install
+   $(INSTALL_DIR) $(1)/usr/bin
+   $(INSTALL_BIN) $(PKG_BUILD_DIR)/realtek-poe $(1)/usr/bin/
+   $(CP) ./files/* $(1)
+endef
+
+$(eval $(call BuildPackage,realtek-poe))
diff --git a/package/network/config/realtek-poe/files/etc/config/poe 
b/package/network/config/realtek-poe/files/etc/config/poe
new file mode 100644
index 00..6ef9d40ad2
--- /dev/null
+++ b/package/network/config/realtek-poe/files/etc/config/poe
@@ -0,0 +1,9 @@
+config global
+   option budget   '65'
+
+config port
+   option enable   '1'
+   option id   '1'
+   option name 'lan1'
+   option poe_plus '1'
+   option priority '2'
diff --git a/package/network/config/realtek-poe/files/etc/init.d/poe 
b/package/network/config/realtek-poe/files/etc/init.d/poe
new file mode 100755
index 00..66f77d6ef9
--- /dev/null
+++ b/package/network/config/realtek-poe/files/etc/init.d/poe
@@ -0,0 +1,20 @@
+#!/bin/sh /etc/rc.common
+
+START=80
+USE_PROCD=1
+PROG=/usr/bin/realtek-poe
+
+reload_service() {
+   ubus call poe reload
+}
+
+service_triggers() {
+procd_add_config_trigger "config.change" "poe" ubus call poe reload
+}
+
+start_service() {
+   procd_open_instance
+   procd_set_param command "$PROG"
+   procd_set_param respawn
+   procd_close_instance
+}
diff --git a/package/network/config/realtek-poe/src/CMakeLists.txt 
b/package/network/config/realtek-poe/src/CMakeLists.txt
new file mode 100644
index 00..4eb81f4577
--- /dev/null
+++ b/package/network/config/realtek-poe/src/CMakeLists.txt
@@ -0,0 +1,28 @@
+cmake_minimum_required(VERSION 2.6)
+
+PROJECT(realtek-poe C)
+ADD_DEFINITIONS(-Os -ggdb -Wextra -Wall -Werror --std=gnu99 
-Wmissing-declarations -Wno-unused-parameter)
+
+SET(CMAKE_SHARED_LIBRARY_LINK_C_FLAGS "")
+
+SET(SOURCES main.c)
+
+IF(DEBUG)
+  ADD_DEFINITIONS(-DDEBUG -g3)
+ENDIF()
+
+FIND_LIBRARY(ubus NAMES ubus)
+FIND_LIBRARY(uci NAMES uci)
+FIND_LIBRARY(ubox NAMES ubox)
+FIND_PATH(uci_include_dir NAMES uci.h)
+FIND_PATH(ubus_include_dir NAMES libubus.h)
+FIND_PATH(ubox_include_dir NAMES libubox/usock.h)
+INCLUDE_DIRECTORIES(${ubox_include_dir} ${ubus_include_dir} ${uci_include_dir})
+
+ADD_EXECUTABLE(realtek-poe ${SOURCES})
+
+TARGET_LINK_LIBRARIES(realtek-poe ${ubox} ${ubus} ${uci})
+
+INSTALL(TARGETS realtek-poe
+   RUNTIME DESTINATION sbin
+)
diff --git a/package/network/config/realtek-poe/src/main.c 
b/package/network/

Re: [PATCH] realtek: Fix VLAN issues introduced by multicast patches

[John Crispin]

@bmork, kindly confirm :-)

    John

On 08.05.21 19:50, Birger Koblitz wrote:

realtek: Fix VLAN issues introduced by multicast patches

This adds the CPU port to the unknown multicast flooding port mask,
which fixes the VLAN issues introduced by the multicast group patches

Signed-off-by: Birger Koblitz 

---

diff --git 
a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c

index 8f66ae6f8f..7c0d55b67a 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c
@@ -501,7 +501,7 @@ static void rtl838x_vlan_profile_setup(int profile)
 * On RTL93XX, the portmask is directly set in the profile,
 * see e.g. rtl9300_vlan_profile_setup
 */
-   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfff);
+   rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fff);
 }

 static inline int rtl838x_vlan_port_egr_filter(int port)
diff --git 
a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c

index 74472461a1..c62dc441c1 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl839x.c
@@ -411,7 +411,7 @@ static void rtl839x_vlan_profile_setup(int profile)
    sw_w32(p[0], RTL839X_VLAN_PROFILE(profile));
    sw_w32(p[1], RTL839X_VLAN_PROFILE(profile) + 4);

-   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x000f);
+   rtl839x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x001f);
 }

 static inline int rtl839x_vlan_port_egr_filter(int port)
diff --git 
a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c 
b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c

index 820c78165a..7ff0001ec7 100644
--- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
+++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl930x.c
@@ -153,9 +153,9 @@ static void rtl930x_vlan_profile_setup(int profile)

    // Enable routing of Ipv4/6 Unicast and IPv4/6 Multicast traffic
    p[0] |= BIT(17) | BIT(16) | BIT(13) | BIT(12);
-   p[2] = 0x0fff; // L2 unknwon MC flooding portmask: all but 
the CPU-port

-   p[3] = 0x0fff; // IPv4 unknwon MC flooding portmask
-   p[4] = 0x0fff; // IPv6 unknwon MC flooding portmask
+   p[2] = 0x1fff; // L2 unknwon MC flooding portmask all 
ports, including the CPU-port

+   p[3] = 0x1fff; // IPv4 unknwon MC flooding portmask
+   p[4] = 0x1fff; // IPv6 unknwon MC flooding portmask

    sw_w32(p[0], RTL930X_VLAN_PROFILE_SET(profile));
    sw_w32(p[1], RTL930X_VLAN_PROFILE_SET(profile) + 4);

___
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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[John Crispin]

interesting. I have a rb92xx on my desk and am wondering if this would 
also work ? after a brief glance at the code I think this might work. 
the rb92xx certainly has the same latch setup ...


    John

On 06.05.21 18:19, Denis Kalashnikov wrote:

When porting RB91xG ad hoc drivers (gpio-latch and rb91x-nand) from ar71xx
to ath79, I made a decision to rework this to more clear design in my opinion:
MFD driver that requests and controls the gpio lines, and separate NAND
driver and GPIO-latch driver that uses API of the MFD driver (like
how in rb4xx-clpd is done). ar71xx gpio-latch is very good, but somewhat hacky,
so I don't think that it can be general driver for gpio controller on a latch.
I could be wrong. Also it is my first attempt to port OpenWrt to a device, so
I need a review from the community. I've tested all these on my RB912UAG-2HPnD.
Gigabit Ethernet, 2.4GHz Wi-Fi, sysupgrade and LEDs:) are working for me.
Not working: beeper, button and USB port/mPCIe (has not tested yet).

Denis Kalashnikov (4):
   ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
   ath79: add GPIO-latch driver for Mikrotik RB91xG
   ath79: add NAND driver for Mikrotik RB91xG
   ath79: add support of Mikrotik RouterBoard 91xG series

  .../dts/ar9342_mikrotik_routerboard-912g.dts  | 314 +
  .../files/drivers/gpio/gpio-latch-rb91x.c | 127 +
  .../linux/ath79/files/drivers/mfd/rb91x-ngl.c | 331 ++
  .../files/drivers/mtd/nand/raw/nand_rb91x.c   | 432 ++
  .../linux/ath79/files/include/mfd/rb91x-ngl.h |  59 +++
  target/linux/ath79/image/mikrotik.mk  |   9 +
  .../base-files/etc/board.d/02_network |   2 +
  .../etc/hotplug.d/firmware/10-ath9k-eeprom|   1 +
  .../base-files/lib/upgrade/platform.sh|   1 +
  target/linux/ath79/mikrotik/config-default|   3 +
  .../patches-5.4/939-mikrotik-rb91x.patch  |  65 +++
  11 files changed, 1344 insertions(+)
  create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
  create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch-rb91x.c
  create mode 100644 target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
  create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c
  create mode 100644 target/linux/ath79/files/include/mfd/rb91x-ngl.h
  create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02-rc1 - realtek and mediatek targets

[John Crispin]

Hi,

Do we want to keep the realtek and mediatek targets in the 21.02 
branch and release or do we want to remove them link the ipq807x target?


Hauke


keep them for sure. I am running my network on those 2 targets using 21.02

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: OpenWrt 21.02-rc1

[John Crispin]

On 07.04.21 12:16, Bas Mevissen via openwrt-devel wrote:


Will Wifi 6 support be added to the interface? We have some support 
for a couple of AX routers, so it would be nice if they can work 
without manually tweaking things.


The underlying structure seems to support it already:
https://forum.openwrt.org/t/got-802-11ax-working-in-linksys-e8450/91533

I  have a couple of patches pending that I will post the next few days 
that will make the primary HE features work on 21.02. I converged my 
home to 3xe8450


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Official OpenWrt project endorsement [Was: Re: crowdfunding to create Right to Repair laws in the USA]

[John Crispin]

context ?

    John

On 06.04.21 10:18, Petr Štetiar wrote:

Alberto Bursi  [2021-04-06 02:22:07]:

Hi,

[adding openwrt-adm to Cc:]


This is at least partially relevant for OpenWrt and I think it's interesting
for many in our community.

I agree.

What about little bit improved promotion of both EU/US efforts, for example
official front page endorsement on openwrt.org, openwrt-announce mail and
pinned forum topic (14-30 days)?

Alberto would you be willing to help preparing text for this official project
endorsement? I assume, that if nobody rejects this idea, then it probably
should be OK to proceed next Monday, April 12th.

Cheers,

Petr

___
openwrt-adm mailing list
openwrt-...@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-adm


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

mailing list outage

[John Crispin]

Hi,

Due to a power cut and failing UPS the mailing list has been offline for 
~48hrs. It is now back and operational. It will take a while for it to 
chew through the backlog.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH] procd: Adding support to detect Pantavisor Container Platform

[John Crispin]

On 20.03.21 15:46, Gaurav Pathak wrote:

  as it runs a custom modified version
of LXC


I assume that if this is a custom downstream version then the change is 
not applicable for merge into upstream owrt. please explain what "custom 
version" means.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Submitting patches to core services...

[John Crispin]

Hi Luka,

on this list, just prefix the patches with "ustream-ssl:" (or whatever) 
that way the according developer can find it


    John

On 16.02.21 16:20, Luka Logar wrote:

Hi,

I've implemented LuCI TLS user certificate authentication (instead of 
standard user/password). How/where do I submit patches to rpcd, 
ustream-ssl, uhttpd and luci?


Kind regards

Luka



___
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

[PATCH 4/4] mac80211: add AX support

[John Crispin]

Signed-off-by: John Crispin 
---
 .../files/lib/netifd/wireless/mac80211.sh | 193 +-
 .../mac80211/files/lib/wifi/mac80211.sh   |  19 +-
 2 files changed, 195 insertions(+), 17 deletions(-)

diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh 
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 92c56afd24..b717770d5e 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -56,6 +56,13 @@ drv_mac80211_init_device_config() {
short_gi_40 \
max_amsdu \
dsss_cck_40
+   config_add_int \
+   he_su_beamformer \
+   he_su_beamformee \
+   he_mu_beamformer \
+   he_bss_color \
+   he_spr_sr_control \
+   he_spr_non_srg_obss_pd_max_offset
 }
 
 drv_mac80211_init_iface_config() {
@@ -69,6 +76,7 @@ drv_mac80211_init_iface_config() {
config_add_int max_listen_int
config_add_int dtim_period
config_add_int start_disabled
+   config_add_int he_twt_required he_spr_sr_control
 
# mesh
config_add_string mesh_id
@@ -96,6 +104,77 @@ mac80211_add_capabilities() {
export -n -- "$__var=$__out"
 }
 
+mac80211_add_he_capabilities() {
+   local __out= oifs
+
+   oifs="$IFS"
+   IFS=:
+   for capab in "$@"; do
+   set -- $capab
+   [ "$(($4))" -gt 0 ] || continue
+   [ "$(((0x$2) & $3))" -gt 0 ] || continue
+   append base_cfg "$1=1" "$N"
+   done
+   IFS="$oifs"
+}
+
+mac80211_get_seg0() {
+   local ht_mode="$1"
+   local seg0=0
+
+   case "$ht_mode" in
+   40)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$(( ($channel / 4) % 2 ))" in
+   1) seg0=$(($channel - 2));;
+   0) seg0=$(($channel + 2));;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$(( ($channel / 4) % 2 ))" in
+   1) seg0=$(($channel + 2));;
+   0) seg0=$(($channel - 2));;
+   esac
+   fi
+   ;;
+   80)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$(( ($channel / 4) % 4 ))" in
+   0) seg0=$(($channel + 6));;
+   1) seg0=$(($channel + 2));;
+   2) seg0=$(($channel - 2));;
+   3) seg0=$(($channel - 6));;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$(( ($channel / 4) % 4 ))" in
+   1) seg0=$(($channel + 6));;
+   2) seg0=$(($channel + 2));;
+   3) seg0=$(($channel - 2));;
+   0) seg0=$(($channel - 6));;
+   esac
+   fi
+   ;;
+   160)
+   if [ $freq -gt 5950 ] && [ $freq -le 7115 ]; then
+   case "$channel" in
+   1|5|9|13|17|21|25|29) seg0=15;;
+   33|37|41|45|49|53|57|61) seg0=47;;
+   65|69|73|77|81|85|89|93) seg0=79;;
+   97|101|105|109|113|117|121|125) 
seg0=111;;
+   129|133|137|141|145|149|153|157) 
seg0=143;;
+   161|165|169|173|177|181|185|189) 
seg0=175;;
+   193|197|201|205|209|213|217|221) 
seg0=207;;
+   esac
+   elif [ $freq != 5935 ]; then
+   case "$channel" in
+   36|40|44|48|52|56|60|64) seg0=50;;
+   100|104|108|112|116|120|124|128) 
seg0=114;;
+   esac
+   fi
+   ;;
+   esac
+   printf "$seg0"
+}
+
 mac80211_hostapd_setup_base() {
local phy="$1"
 
@@ -333,20 +412,105 @@ mac80211_hostapd_setup_base() {
# 802.11ax
enable_ax=0
case "$htmode" in
-   HE*) e

[PATCH 2/4] hostapd: add additional radius options

[John Crispin]

- add functionality to configure RADIUS NAS-Id and Operator-Name
- sdd functionality to configure RADIUS accounting interval
- enable RADIUS "Chargeable User Identity"

Signed-off-by: John Crispin 
---
 .../network/services/hostapd/files/hostapd.sh  | 18 --
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index fb9629170c..1ded08a6f6 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -335,6 +335,9 @@ hostapd_common_add_bss_config() {
config_add_array hostapd_bss_options
 
config_add_int rts_threshold
+   config_add_boolean request_cui
+   config_add_array radius_auth_req_attr
+   config_add_array radius_acct_req_attr
 }
 
 hostapd_set_vlan_file() {
@@ -462,6 +465,14 @@ append_airtime_sta_weight() {
[ -n "$1" ] && append bss_conf "airtime_sta_weight=$1" "$N"
 }
 
+append_radius_acct_req_attr() {
+   [ -n "$1" ] && append bss_conf "radius_acct_req_attr=$1" "$N"
+}
+
+append_radius_auth_req_attr() {
+   [ -n "$1" ] && append bss_conf "radius_auth_req_attr=$1" "$N"
+}
+
 hostapd_set_bss_options() {
local var="$1"
local phy="$2"
@@ -551,6 +562,7 @@ hostapd_set_bss_options() {
append bss_conf 
"acct_server_shared_secret=$acct_secret" "$N"
[ -n "$acct_interval" ] && \
append bss_conf 
"radius_acct_interim_interval=$acct_interval" "$N"
+   json_for_each_item append_radius_acct_req_attr 
radius_acct_req_attr
}
 
case "$auth_type" in
@@ -605,7 +617,7 @@ hostapd_set_bss_options() {
auth_server auth_secret auth_port \
dae_client dae_secret dae_port \
ownip radius_client_addr \
-   eap_reauth_period
+   eap_reauth_period request_cui
 
# radius can provide VLAN ID for clients
vlan_possible=1
@@ -617,7 +629,7 @@ hostapd_set_bss_options() {
 
set_default auth_port 1812
set_default dae_port 3799
-
+   set_default request_cui 0
 
append bss_conf "auth_server_addr=$auth_server" "$N"
append bss_conf "auth_server_port=$auth_port" "$N"
@@ -636,6 +648,8 @@ hostapd_set_bss_options() {
append bss_conf "ieee8021x=1" "$N"
 
[ "$eapol_version" -ge "1" -a "$eapol_version" -le "2" 
] && append bss_conf "eapol_version=$eapol_version" "$N"
+   [ "$request_cui" -gt 0 ] && append bss_conf 
"radius_request_cui=$request_cui" "$N"
+   json_for_each_item append_radius_auth_req_attr 
radius_auth_req_attr
;;
wep)
local wep_keyidx=0
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/4] hostapd: add rts_threshold support

[John Crispin]

Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/hostapd.sh | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 45a49b8faa..fb9629170c 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -333,6 +333,8 @@ hostapd_common_add_bss_config() {
config_add_boolean multicast_to_unicast per_sta_vif
 
config_add_array hostapd_bss_options
+
+   config_add_int rts_threshold
 }
 
 hostapd_set_vlan_file() {
@@ -482,7 +484,7 @@ hostapd_set_bss_options() {
bss_load_update_period chan_util_avg_period sae_require_mfp \
multi_ap multi_ap_backhaul_ssid multi_ap_backhaul_key 
skip_inactivity_poll \
airtime_bss_weight airtime_bss_limit airtime_sta_weight \
-   multicast_to_unicast per_sta_vif
+   multicast_to_unicast per_sta_vif rts_threshold
 
set_default isolate 0
set_default maxassoc 0
@@ -503,6 +505,7 @@ hostapd_set_bss_options() {
set_default multi_ap 0
set_default airtime_bss_weight 0
set_default airtime_bss_limit 0
+   set_default rts_threshold -1
 
append bss_conf "ctrl_interface=/var/run/hostapd"
if [ "$isolate" -gt 0 ]; then
@@ -529,6 +532,7 @@ hostapd_set_bss_options() {
append bss_conf "uapsd_advertisement_enabled=$uapsd" "$N"
append bss_conf "utf8_ssid=$utf8_ssid" "$N"
append bss_conf "multi_ap=$multi_ap" "$N"
+   append bss_conf "rts_threshold=$rts_threshold" "$N"
 
[ "$tdls_prohibit" -gt 0 ] && append bss_conf 
"tdls_prohibit=$tdls_prohibit" "$N"
 
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 3/4] hostapd: add HE support

[John Crispin]

Signed-off-by: John Crispin 
---
 .../network/services/hostapd/files/hostapd.sh | 19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/package/network/services/hostapd/files/hostapd.sh 
b/package/network/services/hostapd/files/hostapd.sh
index 1ded08a6f6..3842aa2b34 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -105,6 +105,8 @@ hostapd_common_add_device_config() {
 
config_add_int airtime_mode
 
+   config_add_boolean multiple_bssid rnr_beacon he_co_locate ema
+
hostapd_add_log_config
 }
 
@@ -115,7 +117,8 @@ hostapd_prepare_device_config() {
local base_cfg=
 
json_get_vars country country_ie beacon_int:100 dtim_period:2 doth 
require_mode legacy_rates \
-   acs_chan_bias local_pwr_constraint spectrum_mgmt_required 
airtime_mode cell_density
+   acs_chan_bias local_pwr_constraint spectrum_mgmt_required 
airtime_mode cell_density \
+   multiple_bssid he_co_locate rnr_beacon ema
 
hostapd_set_log_options base_cfg
 
@@ -125,6 +128,10 @@ hostapd_prepare_device_config() {
set_default legacy_rates 0
set_default airtime_mode 0
set_default cell_density 0
+   set_default multiple_bssid 0
+   set_default rnr_beacon 0
+   set_default he_co_locate 0
+   set_default ema 0
 
[ -n "$country" ] && {
append base_cfg "country_code=$country" "$N"
@@ -211,6 +218,10 @@ hostapd_prepare_device_config() {
append base_cfg "beacon_int=$beacon_int" "$N"
append base_cfg "dtim_period=$dtim_period" "$N"
[ "$airtime_mode" -gt 0 ] && append base_cfg 
"airtime_mode=$airtime_mode" "$N"
+   [ "$multiple_bssid" -gt 0 ] && append base_cfg 
"multiple_bssid=$multiple_bssid" "$N"
+   [ "$rnr_beacon" -gt 0 ] && append base_cfg "rnr_beacon=$rnr_beacon" "$N"
+   [ "$ema" -gt 0 ] && append base_cfg "ema=$ema" "$N"
+   [ "$he_co_locate" -gt 0 ] && append base_cfg 
"he_co_locate=$he_co_locate" "$N"
 
json_get_values opts hostapd_options
for val in $opts; do
@@ -1097,9 +1108,9 @@ wpa_supplicant_set_fixed_freq() {
VHT*) append network_data "vht=1" "$N$T";;
esac
case "$htmode" in
-   VHT80) append network_data "max_oper_chwidth=1" "$N$T";;
-   VHT160) append network_data "max_oper_chwidth=2" "$N$T";;
-   VHT20|VHT40) append network_data "max_oper_chwidth=0" "$N$T";;
+   VHT80|HE80) append network_data "max_oper_chwidth=1" "$N$T";;
+   VHT160|HE160) append network_data "max_oper_chwidth=2" "$N$T";;
+   VHT20|HE20|VHT40|HE40) append network_data "max_oper_chwidth=0" 
"$N$T";;
*) append network_data "disable_vht=1" "$N$T";;
esac
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH procd] hotplug.c: set nl_pid to zero

[John Crispin]

On 24.01.21 23:58, eich...@gmail.com wrote:

From: Stefan Eichenberger 

With the current solution where nl_pid is set through getpid we run into
problems when running procd in a different PID namespace (e.g.
container). The PID number inside the active PID namespace will be set
which doesn't match the global PID. Therefore, procd will never receive
any netlink messages.

By setting nl_pid to zero the kernel will assign the global PID
automatically and fixes the issue.

Signed-off-by: Stefan Eichenberger 
---
  plug/hotplug.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/plug/hotplug.c b/plug/hotplug.c
index 9aeb1c1..beff38a 100644
--- a/plug/hotplug.c
+++ b/plug/hotplug.c
@@ -612,7 +612,7 @@ void hotplug(char *rules)
  
  	rule_file = strdup(rules);

nls.nl_family = AF_NETLINK;
-   nls.nl_pid = getpid();
+   nls.nl_pid = 0;
nls.nl_groups = -1;
  
  	if ((hotplug_fd.fd = socket(PF_NETLINK, SOCK_DGRAM | SOCK_CLOEXEC, NETLINK_KOBJECT_UEVENT)) == -1) {


Acked-by: John Crispin 

Just tested this locally outside a pid namespace.


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH v6 1/2] [v6, 1/2] ipq806x: add support for Linksys E8350 v1

[John Crispin]

On 24.01.21 09:53, Todor Colov wrote:

+ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wifi" "phy0tpt"


Hi,

we stopped adding the ${boardname}: prefix on leds. Please remove it 
here and also inside the dts file


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Job board support on openwrt.org?

[John Crispin]

Hi,

I do not think this is a good idea. The project should remain 
commercially and politically independent in order to guarantee its 
sovereignty. Hauke gave some good pointers on how to contact individuals 
devs.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] lldpd: fix init.d script

[John Crispin]

On 11.12.20 09:30, Bjørn Mork wrote:

John Crispin  writes:


iff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 7a5b25e016..8200556786 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -10,6 +10,10 @@ LLDPSOCKET=/var/run/lldpd.socket
  LLDPD_CONF=/tmp/lldpd.conf
  LLDPD_CONFS_DIR=/tmp/lldpd.d
  
+service_triggers() {

+   procd_add_reload_trigger lldpd
+}
+
  find_release_info()
  {
[ -s /etc/os-release ] && . /etc/os-release
@@ -38,6 +42,10 @@ write_lldpd_conf()
for iface in $ifaces; do
local ifname=""
if network_get_device ifname "$iface" || [ -e 
"/sys/class/net/$iface" ]; then
+   if [ -e "/sys/class/net/$ifname/bridge" -o -e 
"/sys/class/net/$ifname/lower_bridge" ] ; then
+   local ports=$(jsonfilter -i /etc/board.json -e 
"@.network.$iface.ifname")
+   [ "${ports// /,}" ] && ifname="${ports// /,}"
+   fi
append ifnames "${ifname:-$iface}" ","
fi
done


Doesn't this assume too much about /etc/config/network names always
matching /etc/board.json?  How about just getting the bridge ports from

   /sys/class/net/switch/brif/*

if the configured interface resolves to a bridge?

Note BTW: The "bridge" in "lower_bridge" is the name of the symlink
target. It's not a static name. Try creating a subinterface under
something that isn't named "brigde" :-)



Bjørn

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Hi Bjørn,

correct, this is not the ideal solution right now. using 
/sys/class/net/switch/brif/* is also quirky as devices might later be 
added or removed (wifi). Right now the code is totally de-funct and this 
patch will fix it for a vast number of std use cases. I plan to pay some 
attention to lldpd post release and also add a small ubus interface. 
This would then be usable to listen to netifd notifications, thus fixing 
the problem properly.


This patch does however improve the current situation a lot. For all 
other cases you will have to manually add the interfaces as is required 
right now.


    John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 2/2] lldpd: fix init.d script

[John Crispin]

On 11.12.20 09:30, Bjørn Mork wrote:

John Crispin  writes:


iff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 7a5b25e016..8200556786 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -10,6 +10,10 @@ LLDPSOCKET=/var/run/lldpd.socket
  LLDPD_CONF=/tmp/lldpd.conf
  LLDPD_CONFS_DIR=/tmp/lldpd.d
  
+service_triggers() {

+   procd_add_reload_trigger lldpd
+}
+
  find_release_info()
  {
[ -s /etc/os-release ] && . /etc/os-release
@@ -38,6 +42,10 @@ write_lldpd_conf()
for iface in $ifaces; do
local ifname=""
if network_get_device ifname "$iface" || [ -e 
"/sys/class/net/$iface" ]; then
+   if [ -e "/sys/class/net/$ifname/bridge" -o -e 
"/sys/class/net/$ifname/lower_bridge" ] ; then
+   local ports=$(jsonfilter -i /etc/board.json -e 
"@.network.$iface.ifname")
+   [ "${ports// /,}" ] && ifname="${ports// /,}"
+   fi
append ifnames "${ifname:-$iface}" ","
fi
done


Doesn't this assume too much about /etc/config/network names always
matching /etc/board.json?  How about just getting the bridge ports from

   /sys/class/net/switch/brif/*

if the configured interface resolves to a bridge?

Note BTW: The "bridge" in "lower_bridge" is the name of the symlink
target. It's not a static name. Try creating a subinterface under
something that isn't named "brigde" :-)



Bjørn


Hi Bjørn,

correct, this is not the ideal solution right now. using 
/sys/class/net/switch/brif/* is also quirky as devices might later be 
added or removed (wifi). Right now the code is totally de-funct and this 
patch will fix it for a vast number of std use cases. I plan to pay some 
attention to lldpd post release and also add a small ubus interface. 
This would then be usable to listen to netifd notifications, thus fixing 
the problem properly.


This patch does however improve the current situation a lot.

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] hostapd: pass respawn settings when registering the service

[John Crispin]

When hostapd gets restarted to often/quickly will cause procd to not restart it
anymore. it will think that hapd is in a crash loop.

Signed-off-by: John Crispin 
---
 package/network/services/hostapd/files/wpad.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/package/network/services/hostapd/files/wpad.init 
b/package/network/services/hostapd/files/wpad.init
index 3198e9801f..e2cd380cb5 100644
--- a/package/network/services/hostapd/files/wpad.init
+++ b/package/network/services/hostapd/files/wpad.init
@@ -11,7 +11,7 @@ start_service() {
mkdir -p /var/run/hostapd
procd_open_instance hostapd
procd_set_param command /usr/sbin/hostapd -s -g 
/var/run/hostapd/global
-   procd_set_param respawn
+   procd_set_param respawn 3600 5 0
procd_close_instance
fi
 
@@ -19,7 +19,7 @@ start_service() {
mkdir -p /var/run/wpa_supplicant
procd_open_instance supplicant
procd_set_param command /usr/sbin/wpa_supplicant -n -s -g 
/var/run/wpa_supplicant/global
-   procd_set_param respawn
+   procd_set_param respawn 3600 5 0
procd_close_instance
fi
 }
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/2] lldpd: fix init.d script

[John Crispin]

The script was missing the reload trigger. Additionally running lldpid on a
bridge is not correct. Rather than running lldpd on the L3 bridge, it needs
to be run on all the L2 members.

Signed-off-by: John Crispin 
---
 package/network/services/lldpd/files/lldpd.init | 8 
 1 file changed, 8 insertions(+)

diff --git a/package/network/services/lldpd/files/lldpd.init 
b/package/network/services/lldpd/files/lldpd.init
index 7a5b25e016..8200556786 100644
--- a/package/network/services/lldpd/files/lldpd.init
+++ b/package/network/services/lldpd/files/lldpd.init
@@ -10,6 +10,10 @@ LLDPSOCKET=/var/run/lldpd.socket
 LLDPD_CONF=/tmp/lldpd.conf
 LLDPD_CONFS_DIR=/tmp/lldpd.d
 
+service_triggers() {
+   procd_add_reload_trigger lldpd
+}
+
 find_release_info()
 {
[ -s /etc/os-release ] && . /etc/os-release
@@ -38,6 +42,10 @@ write_lldpd_conf()
for iface in $ifaces; do
local ifname=""
if network_get_device ifname "$iface" || [ -e 
"/sys/class/net/$iface" ]; then
+   if [ -e "/sys/class/net/$ifname/bridge" -o -e 
"/sys/class/net/$ifname/lower_bridge" ] ; then
+   local ports=$(jsonfilter -i /etc/board.json -e 
"@.network.$iface.ifname")
+   [ "${ports// /,}" ] && ifname="${ports// /,}"
+   fi
append ifnames "${ifname:-$iface}" ","
fi
done
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/2] lldpd: do not start lldpd on the loopback device

[John Crispin]

Starting lldpd on 'lo' makes no sense. We know that we are the only one on
that device.

Signed-off-by: John Crispin 
---
 package/network/services/lldpd/files/lldpd.config | 1 -
 1 file changed, 1 deletion(-)

diff --git a/package/network/services/lldpd/files/lldpd.config 
b/package/network/services/lldpd/files/lldpd.config
index 5e7c51ba7e..6a4b3e3dfa 100644
--- a/package/network/services/lldpd/files/lldpd.config
+++ b/package/network/services/lldpd/files/lldpd.config
@@ -16,5 +16,4 @@ config lldpd config
#option lldp_mgmt_ip "!192.168.1.1"
 
# interfaces to listen on
-   list interface "loopback"
list interface "lan"
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 5/5] procd: add api wrapper

[John Crispin]

can we augment we augment the procd_add_trigger/procd_close_trigger into 
the helper such as reload_trigger() does ?


    John

On 02.12.20 15:52, Florian Eckert wrote:

This commit add a wrapper for procd services, to add a callback script
if the "service.restart" trigger event was fired.

Example:

service_trigger() {
procd_add_trigger
procd_add service_trigger "service.restart" "firewall" 

Re: [PATCH] rtl838x: fine tune default package set

[John Crispin]

On 09.11.20 18:32, Petr Štetiar wrote:

Althought most of the switches aren't routers, they can be used as such,
so let's add some of the packages from the router's DEVICE_TYPE. While
at it, remove swconfig package which is not needed on DSA targets.

Signed-off-by: Petr Štetiar 

Acked-by: John Crispin 

---
  target/linux/rtl838x/Makefile | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target/linux/rtl838x/Makefile b/target/linux/rtl838x/Makefile
index 83cb074b89b6..a4e203718d90 100644
--- a/target/linux/rtl838x/Makefile
+++ b/target/linux/rtl838x/Makefile
@@ -21,6 +21,7 @@ include $(INCLUDE_DIR)/target.mk
  
  FEATURES := $(filter-out mips16,$(FEATURES))
  
-DEFAULT_PACKAGES += swconfig uboot-envtools ethtool kmod-gpio-button-hotplug

+DEFAULT_PACKAGES += uboot-envtools ethtool kmod-gpio-button-hotplug \
+   dnsmasq firewall ip6tables iptables odhcp6c odhcpd-ipv6only
  
  $(eval $(call BuildTarget))


___
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

Re: [PATCH] base-files: add board.d support for bridge device

[John Crispin]

thanks for the quick review

    John

On 03.11.20 18:24, Adrian Schmutzler wrote:

Hi John,


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of John Crispin
Sent: Dienstag, 3. November 2020 17:43
To: openwrt-devel@lists.openwrt.org
Cc: John Crispin 
Subject: [PATCH] base-files: add board.d support for bridge device

Latest netifd allows us to setup network bridges with implicit vlan tagging. For
this to work, we need to setup several additional uci sections. This feature is
particularly usefull for DSA tupe devices.
Add board.d and uci-defaults support for generating the sections.

Please also bump PKG_RELEASE for base-files when you apply this.

One typo below ...


Signed-off-by: John Crispin 
---
  package/base-files/files/bin/config_generate  | 35 +--
  .../files/lib/functions/uci-defaults.sh   |  4 +++
  2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/package/base-files/files/bin/config_generate b/package/base-
files/files/bin/config_generate
index eb6816e519..e23f901504 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -7,6 +7,28 @@ CFG=/etc/board.json
  [ -s $CFG ] || /bin/board_detect || exit 1  [ -s /etc/config/network -a -s
/etc/config/system ] && exit 0

+generate_bridge() {
+   local name=$1
+   uci -q batch <<-EOF
+   set network.$name=device
+   set network.$name.name=$name
+   set network.$name.type=bridge
+   EOF
+}
+
+bridge_vlan_id=0
+generate_bridge_vlan() {
+   local device=$1
+   local ports="$2"
+   bridge_vlan_id=$((bridge_vlan_id + 1))
+   uci -q batch <<-EOF
+   add network bridge-vlan
+   set network.@bridge-vlan[-1].device='$device'
+   set network.@bridge-vlan[-1].vlan='$bridge_vlan_id'
+   set network.@bridge-vlan[-1].ports='$ports'
+   EOF
+}
+
  generate_static_network() {
uci -q batch <<-EOF
delete network.loopback
@@ -63,6 +85,7 @@ generate_static_network() {
  addr_offset=2
  generate_network() {
local ifname macaddr protocol type ipaddr netmask
+   local bridge=$2

json_select network
json_select "$1"
@@ -77,6 +100,12 @@ generate_network() {
*\ * | lan:*) type="bridge" ;;
esac

+   [ -n "$bridge" ] && {
+   generate_bridge_vlan $bridge "$ifname"
+   ifname=$bridge.$bridge_vlan_id
+   type=""
+   }
+
uci -q batch <<-EOF
delete network.$1
set network.$1='interface'
@@ -236,7 +265,6 @@ generate_switch() {
json_select ..
  }

-
  generate_static_system() {
uci -q batch <<-EOF
delete system.@system[0]
@@ -439,8 +467,11 @@ if [ ! -s /etc/config/network ]; then
touch /etc/config/network
generate_static_network

+   json_get_vars bridge
+   [ -n "$bridge" ] && generate_bridge $bridge
+
json_get_keys keys network
-   for key in $keys; do generate_network $key; done
+   for key in $keys; do generate_network $key $bridge; done

json_get_keys keys switch
for key in $keys; do generate_switch $key; done diff --git
a/package/base-files/files/lib/functions/uci-defaults.sh b/package/base-
files/files/lib/functions/uci-defaults.sh
index 27a409fe3b..73ba279fd5 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -90,6 +90,10 @@ ucidef_set_interfaces_lan_wan() {
ucidef_set_interface_wan "$wan_if"
  }

+ucidef_set_brigde_device() {

brigde->bridge

Best

Adrian


+   json_add_string bridge "${1:switch0}"
+}
+
  _ucidef_add_switch_port() {
# inherited: $num $device $need_tag $want_untag $role $index
$prev_role
# inherited: $n_cpu $n_ports $n_vlan $cpu0 $cpu1 $cpu2 $cpu3 $cpu4
$cpu5
--
2.25.1


___
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

[PATCH] base-files: add board.d support for bridge device

[John Crispin]

Latest netifd allows us to setup network bridges with implicit vlan
tagging. For this to work, we need to setup several additional uci
sections. This feature is particularly usefull for DSA tupe devices.
Add board.d and uci-defaults support for generating the sections.

Signed-off-by: John Crispin 
---
 package/base-files/files/bin/config_generate  | 35 +--
 .../files/lib/functions/uci-defaults.sh   |  4 +++
 2 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/package/base-files/files/bin/config_generate 
b/package/base-files/files/bin/config_generate
index eb6816e519..e23f901504 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -7,6 +7,28 @@ CFG=/etc/board.json
 [ -s $CFG ] || /bin/board_detect || exit 1
 [ -s /etc/config/network -a -s /etc/config/system ] && exit 0
 
+generate_bridge() {
+   local name=$1
+   uci -q batch <<-EOF
+   set network.$name=device
+   set network.$name.name=$name
+   set network.$name.type=bridge
+   EOF
+}
+
+bridge_vlan_id=0
+generate_bridge_vlan() {
+   local device=$1
+   local ports="$2"
+   bridge_vlan_id=$((bridge_vlan_id + 1))
+   uci -q batch <<-EOF
+   add network bridge-vlan
+   set network.@bridge-vlan[-1].device='$device'
+   set network.@bridge-vlan[-1].vlan='$bridge_vlan_id'
+   set network.@bridge-vlan[-1].ports='$ports'
+   EOF
+}
+
 generate_static_network() {
uci -q batch <<-EOF
delete network.loopback
@@ -63,6 +85,7 @@ generate_static_network() {
 addr_offset=2
 generate_network() {
local ifname macaddr protocol type ipaddr netmask
+   local bridge=$2
 
json_select network
json_select "$1"
@@ -77,6 +100,12 @@ generate_network() {
*\ * | lan:*) type="bridge" ;;
esac
 
+   [ -n "$bridge" ] && {
+   generate_bridge_vlan $bridge "$ifname"
+   ifname=$bridge.$bridge_vlan_id
+   type=""
+   }
+
uci -q batch <<-EOF
delete network.$1
set network.$1='interface'
@@ -236,7 +265,6 @@ generate_switch() {
json_select ..
 }
 
-
 generate_static_system() {
uci -q batch <<-EOF
delete system.@system[0]
@@ -439,8 +467,11 @@ if [ ! -s /etc/config/network ]; then
touch /etc/config/network
generate_static_network
 
+   json_get_vars bridge
+   [ -n "$bridge" ] && generate_bridge $bridge
+
json_get_keys keys network
-   for key in $keys; do generate_network $key; done
+   for key in $keys; do generate_network $key $bridge; done
 
json_get_keys keys switch
for key in $keys; do generate_switch $key; done
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh 
b/package/base-files/files/lib/functions/uci-defaults.sh
index 27a409fe3b..73ba279fd5 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -90,6 +90,10 @@ ucidef_set_interfaces_lan_wan() {
ucidef_set_interface_wan "$wan_if"
 }
 
+ucidef_set_brigde_device() {
+   json_add_string bridge "${1:switch0}"
+}
+
 _ucidef_add_switch_port() {
# inherited: $num $device $need_tag $want_untag $role $index $prev_role
# inherited: $n_cpu $n_ports $n_vlan $cpu0 $cpu1 $cpu2 $cpu3 $cpu4 $cpu5
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH] ath79: remove model name from LED labels

[John Crispin]

skimmed over the thread and wondered what upstream does. a quick search 
yielded ...


-- https://www.kernel.org/doc/html/latest/leds/leds-class.html

Examples of proper LED names:

“red:disk”
“white:flash”
“red:indicator”
“phy1:green:wlan”
“phy3::wlan”
“:kbd_backlight”
“input5::kbd_backlight”
“input3::numlock”
“input3::scrolllock”
“input3::capslock”
“mmc1::status”
“white:status”

so there is not $board:: listed.

a script to drop the ^foo: from uci looks feasible. as a second step 
unifying the :function part should be a no brainer and a few greps 
showed that this look pretty consistent already.


I am certainly in favour of this.

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/5] initd: Don't search the environment list if the watchdog, fd is initialized

[John Crispin]

On 29.09.20 21:00, Michael Jones wrote:

On Tue, Sep 29, 2020 at 1:59 PM John Crispin  wrote:


On 29.09.20 20:55, Michael Jones wrote:

On Tue, Sep 29, 2020 at 1:47 PM John Crispin  wrote:

On 29.09.20 18:22, Michael Jones wrote:

Signed-off-by: Michael Jones 
---
watchdog.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/watchdog.c b/watchdog.c
index 20830c3..ac5b656 100644
--- a/watchdog.c
+++ b/watchdog.c
@@ -49,11 +49,11 @@ static void watchdog_timeout_cb(struct uloop_timeout *t)

static int watchdog_open(bool cloexec)
{
-char *env = getenv("WDTFD");
-
if (wdt_fd >= 0)
return wdt_fd;

+char *env = getenv("WDTFD");
+
if (env) {
DEBUG(2, "Watchdog handover: fd=%s\n", env);
wdt_fd = atoi(env);

this breaks c99 compliance

   John


Do you mean C89 compliance? This should compile just fine in C99.

C99 was released 20 years ago, and C89 30 years ago. I'm personally
not interested in supporting either.

The patch can be modified, or used as inspiration, by someone who is
concerned about C89/C99 compliance and would like to see the
watchdog_open() function improved in this way.


variable declarations should always be at the start of the function.

  John


Sorry, I disagree, and there was no documentation that I could see
anywhere related to this on either the OpenWRT wiki, or the procd
repository.

Take the patches or leave them. I'm not going to make updates.


ok !

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/5] initd: Don't search the environment list if the watchdog, fd is initialized

[John Crispin]

On 29.09.20 20:55, Michael Jones wrote:

On Tue, Sep 29, 2020 at 1:47 PM John Crispin  wrote:


On 29.09.20 18:22, Michael Jones wrote:

Signed-off-by: Michael Jones 
---
   watchdog.c | 4 ++--
   1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/watchdog.c b/watchdog.c
index 20830c3..ac5b656 100644
--- a/watchdog.c
+++ b/watchdog.c
@@ -49,11 +49,11 @@ static void watchdog_timeout_cb(struct uloop_timeout *t)

   static int watchdog_open(bool cloexec)
   {
-char *env = getenv("WDTFD");
-
   if (wdt_fd >= 0)
   return wdt_fd;

+char *env = getenv("WDTFD");
+
   if (env) {
   DEBUG(2, "Watchdog handover: fd=%s\n", env);
   wdt_fd = atoi(env);

this breaks c99 compliance

  John


Do you mean C89 compliance? This should compile just fine in C99.

C99 was released 20 years ago, and C89 30 years ago. I'm personally
not interested in supporting either.

The patch can be modified, or used as inspiration, by someone who is
concerned about C89/C99 compliance and would like to see the
watchdog_open() function improved in this way.



variable declarations should always be at the start of the function.

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 4/5] initd: Don't search the environment list if the watchdog, fd is initialized

[John Crispin]

On 29.09.20 18:22, Michael Jones wrote:

Signed-off-by: Michael Jones 
---
  watchdog.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/watchdog.c b/watchdog.c
index 20830c3..ac5b656 100644
--- a/watchdog.c
+++ b/watchdog.c
@@ -49,11 +49,11 @@ static void watchdog_timeout_cb(struct uloop_timeout *t)
  
  static int watchdog_open(bool cloexec)

  {
-    char *env = getenv("WDTFD");
-
  if (wdt_fd >= 0)
      return wdt_fd;
  
+    char *env = getenv("WDTFD");

+
  if (env) {
      DEBUG(2, "Watchdog handover: fd=%s\n", env);
      wdt_fd = atoi(env);


this breaks c99 compliance

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Licensing an OpenWrt router - No response to Trademark use

[John Crispin]

On 19.08.20 23:25, Piotr Dymacz wrote:

Hi Scott,

On 18.08.2020 23:27, Heppler, J. Scott wrote:

request.
Reply-To:
Organization:

I sent an email to cont...@openwrt.org, subject line Trademark Use
Request, inquiring about crowd funding an OpenWrt router.  I never
received a reply.  The email gave the background, links to forum
discussion and a poll and outlined the basic structure.  The contents:


Probably nobody with access to this mailbox was interested in your idea.

[...]


Would the project be interested in exploring this further?"


Personally, I don't think so. 3y ago we (some of devs with commit 
access) were discussing similar idea. But there just wasn't enough 
interest in it.


OpenWrt is a software project, setting up a HW supply chain would imho 
eat way too much time and resources. there are already thousands of 
routers running OpenWrt and several open HW projects making use of OpenWrt.


my 2 cents

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: MT7621 Flow Control

[John Crispin]

On 06.08.20 14:31, Andre Valentin wrote:

Hi Jaap,


Am 06.08.20 um 13:43 schrieb Jaap Buurman:

Dear all,

I have noticed the flow control work for mt7621 in the following
Openwrt patch: 
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0

However, the problem that the patch is supposed to fix is still
occurring, even in combination with other experimental patches
submitted. These experiences can be read about here:
https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/

However, on this mailing list a user by the name of Kristian claims
that disabling flow control helps fix this problem, as can be read
here: 
https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html

 From what I understood, he was running many mt7621 devices
commercially, with many of them experiencing the issue, which were all
fixed with his own flow control patch. My question is why the decision
was made to only disable flow control on port 5 in the above mentioned
Openwrt patch? AFAIK, Kristian's own patch disables flow control on
all of the ports and he claims the issue is fixed for him. Perhaps the
current patch should be extended to disable flow control on all ports?
What are people's thoughts on this?

I'm facing the same issue now after upgrading to 5.4 kernel more often than 
before.
Every second reboot reboot with 5.4 fails with this timeout error.


Yours sincerely,

Jaap

André


from previous discussions with MTK and looking at the SDK code, the flow 
control should always be disabled.


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Release goals for 20.XX

[John Crispin]

On 31.07.20 21:49, Stefan Lippers-Hollmann wrote:

I don't think this is going to happen for a 20.xy.0 release, basically
there are only two platforms for this on the horizon at the moment:


I am holding my patches back on purpose to not interfere with the 
release. AX will be a post 20.x thing


    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules

[John Crispin]

On 15.07.20 13:39, Jo-Philipp Wich wrote:

Hi,


If we can't come up with a working automatic scheme, maybe we could have
an option to disable the cpu port per vlan?

Having a default-enabled "option self" or "option local" was my idea as
well. Any idea which name fits better?

~ Jo


self is what ip-bridge uses as a parameter name for this feature

    John


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 2/3] bridge: allow adding vlans to a bridge

[John Crispin]

Add a rtnl helper for adding vlans to a bridge interface.

Signed-off-by: John Crispin 
---
 system-linux.c | 48 
 system.h   |  1 +
 2 files changed, 49 insertions(+)

diff --git a/system-linux.c b/system-linux.c
index 97b38e7..130d057 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -854,6 +854,54 @@ int system_bridge_delif(struct device *bridge, struct 
device *dev)
return system_bridge_if(bridge->ifname, dev, SIOCBRDELIF, NULL);
 }
 
+int system_bridge_vlan(const char *iface, int pvid, int vid, int tagged,
+  int self, int add)
+{
+   struct ifinfomsg ifi = { .ifi_family = PF_BRIDGE, };
+   struct bridge_vlan_info vinfo = { .vid = vid, };
+   unsigned short flags = 0;
+   struct nlattr *afspec;
+   struct nl_msg *nlm;
+   int ret = 0;
+
+   ifi.ifi_index = if_nametoindex(iface);
+   if (!ifi.ifi_index)
+   return -1;
+
+   nlm = nlmsg_alloc_simple(add ? RTM_SETLINK : RTM_DELLINK, 
NLM_F_REQUEST);
+   if (!nlm)
+   return -1;
+
+   nlmsg_append(nlm, , sizeof(ifi), 0);
+
+   if (self)
+   flags |= BRIDGE_FLAGS_SELF;
+
+   if (pvid)
+   vinfo.flags |= BRIDGE_VLAN_INFO_PVID;
+
+   if (!tagged)
+   vinfo.flags |= BRIDGE_VLAN_INFO_UNTAGGED;
+
+   afspec = nla_nest_start(nlm, IFLA_AF_SPEC);
+   if (!afspec) {
+   ret = -ENOMEM;
+   goto failure;
+   }
+
+   if (flags)
+   nla_put_u16(nlm, IFLA_BRIDGE_FLAGS, flags);
+
+   nla_put(nlm, IFLA_BRIDGE_VLAN_INFO, sizeof(vinfo), );
+   nla_nest_end(nlm, afspec);
+
+   return system_rtnl_call(nlm);
+
+failure:
+   nlmsg_free(nlm);
+   return ret;
+}
+
 int system_if_resolve(struct device *dev)
 {
struct ifreq ifr;
diff --git a/system.h b/system.h
index 258b1af..6a7f738 100644
--- a/system.h
+++ b/system.h
@@ -196,6 +196,7 @@ int system_bridge_addbr(struct device *bridge, struct 
bridge_config *cfg);
 int system_bridge_delbr(struct device *bridge);
 int system_bridge_addif(struct device *bridge, struct device *dev);
 int system_bridge_delif(struct device *bridge, struct device *dev);
+int system_bridge_vlan(const char *iface, int pvid, int vid, int tagged, int 
self, int add);
 
 int system_macvlan_add(struct device *macvlan, struct device *dev, struct 
macvlan_config *cfg);
 int system_macvlan_del(struct device *macvlan);
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 3/3] wireless: allow adding bridge vlans

[John Crispin]

An AP/Vlan will only have a virtual 802.1q tag. Add code to make the bridge
add the define vid and take care of possibly tagging when the packet leaves
the bridge.

Signed-off-by: John Crispin 
---
 wireless.c | 49 +
 wireless.h |  4 
 2 files changed, 53 insertions(+)

diff --git a/wireless.c b/wireless.c
index efb7992..0596b59 100644
--- a/wireless.c
+++ b/wireless.c
@@ -16,6 +16,7 @@
 #include "wireless.h"
 #include "handler.h"
 #include "ubus.h"
+#include "system.h"
 
 #define WIRELESS_SETUP_RETRY   3
 
@@ -49,6 +50,8 @@ enum {
VIF_ATTR_NETWORK,
VIF_ATTR_ISOLATE,
VIF_ATTR_MODE,
+   VIF_ATTR_VID,
+   VIF_ATTR_UNTAG,
__VIF_ATTR_MAX,
 };
 
@@ -57,6 +60,8 @@ static const struct blobmsg_policy vif_policy[__VIF_ATTR_MAX] 
= {
[VIF_ATTR_NETWORK] = { .name = "network", .type = BLOBMSG_TYPE_ARRAY },
[VIF_ATTR_ISOLATE] = { .name = "isolate", .type = BLOBMSG_TYPE_BOOL },
[VIF_ATTR_MODE] = { .name = "mode", .type = BLOBMSG_TYPE_STRING },
+   [VIF_ATTR_VID] = { .name = "vid", .type = BLOBMSG_TYPE_INT32 },
+   [VIF_ATTR_UNTAG] = { .name = "vlan_untag", .type = BLOBMSG_TYPE_BOOL },
 };
 
 static const struct uci_blob_param_list vif_param = {
@@ -68,6 +73,8 @@ enum {
VLAN_ATTR_DISABLED,
VLAN_ATTR_NETWORK,
VLAN_ATTR_ISOLATE,
+   VLAN_ATTR_VID,
+   VLAN_ATTR_UNTAG,
__VLAN_ATTR_MAX,
 };
 
@@ -75,6 +82,8 @@ static const struct blobmsg_policy 
vlan_policy[__VLAN_ATTR_MAX] = {
[VLAN_ATTR_DISABLED] = { .name = "disabled", .type = BLOBMSG_TYPE_BOOL 
},
[VLAN_ATTR_NETWORK] = { .name = "network", .type = BLOBMSG_TYPE_ARRAY },
[VLAN_ATTR_ISOLATE] = { .name = "isolate", .type = BLOBMSG_TYPE_BOOL },
+   [VLAN_ATTR_VID] = { .name = "vid", .type = BLOBMSG_TYPE_INT32 },
+   [VLAN_ATTR_UNTAG] = { .name = "vlan_untag", .type = BLOBMSG_TYPE_BOOL },
 };
 
 static const struct uci_blob_param_list vlan_param = {
@@ -313,6 +322,8 @@ static void wireless_interface_handle_link(struct 
wireless_interface *vif, bool
}
 
blobmsg_for_each_attr(cur, vif->network, rem) {
+   struct device *bridge;
+
network = blobmsg_data(cur);
 
iface = vlist_find(, network, iface, node);
@@ -320,6 +331,16 @@ static void wireless_interface_handle_link(struct 
wireless_interface *vif, bool
continue;
 
interface_handle_link(iface, vif->ifname, up, true);
+
+   if (!vif->vid)
+   continue;
+
+   bridge = device_get(iface->ifname, 0);
+   if (!bridge || !bridge->type->bridge_capability)
+   continue;
+
+   system_bridge_vlan(vif->ifname, 1, vif->vid, 0, 0, 1);
+   system_bridge_vlan(iface->ifname, 0, vif->vid, !vif->untag, 1, 
1);
}
 }
 
@@ -343,6 +364,8 @@ static void wireless_vlan_handle_link(struct wireless_vlan 
*vlan, bool up)
}
 
blobmsg_for_each_attr(cur, vlan->network, rem) {
+   struct device *bridge;
+
network = blobmsg_data(cur);
 
iface = vlist_find(, network, iface, node);
@@ -350,6 +373,16 @@ static void wireless_vlan_handle_link(struct wireless_vlan 
*vlan, bool up)
continue;
 
interface_handle_link(iface, vlan->ifname, up, true);
+
+   if (!vlan->vid)
+   continue;
+
+   bridge = device_get(iface->ifname, 0);
+   if (!bridge || !bridge->type->bridge_capability)
+   continue;
+
+   system_bridge_vlan(vlan->ifname, 1, vlan->vid, 0, 0, 1);
+   system_bridge_vlan(iface->ifname, 0, vlan->vid, !vlan->untag, 
1, 1);
}
 }
 
@@ -767,6 +800,14 @@ wireless_interface_init_config(struct wireless_interface 
*vif)
cur = tb[VIF_ATTR_MODE];
if (cur)
vif->ap_mode = !strcmp(blobmsg_get_string(cur), "ap");
+
+   cur = tb[VIF_ATTR_UNTAG];
+   if (cur)
+   vif->untag = blobmsg_get_bool(cur);
+
+   cur = tb[VIF_ATTR_VID];
+   if (cur)
+   vif->vid = blobmsg_get_u32(cur);
 }
 
 static void
@@ -829,6 +870,14 @@ wireless_vlan_init_config(struct wireless_vlan *vlan)
cur = tb[VLAN_ATTR_ISOLATE];
if (cur)
vlan->isolate = blobmsg_get_bool(cur);
+
+   cur = tb[VLAN_ATTR_UNTAG];
+   if (cur)
+   vlan->untag = blobmsg_get_bool(cur);
+
+   cur = tb[VLAN_ATTR_VID];
+   if (cur)
+   vlan->vid = blobmsg_get_u32(cur);
 }
 
 static void
diff --git a/wireless.h b/wireless.h
index 5fedd20..2160451 100644
--- a/wi

[PATCH 0/3] netifd: add bridge/vlan support

[John Crispin]

Allow handling wifi interfaces with vlans attached to them inside a bridge.

We can now add the follwoing optiosn to wifi-iface and wifi-vlan sections.
option vid 100
option vlan_untag 0/1
The traffic will then be handled inside the bridge with the defined vid.
We can also control if egress bridge traffic should be tagged or not.
For this to work the following option needs to be set in the corresponding
networks interface section.
option vlan_filtering 1

John Crispin (3):
  bridge: allow turning on vlan_filtering
  bridge: allow adding vlans to a bridge
  wireless: allow adding bridge vlans

 bridge.c   |  6 ++
 system-linux.c | 54 ++
 system.h   |  3 +++
 wireless.c | 49 +
 wireless.h |  4 
 5 files changed, 116 insertions(+)

-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH 1/3] bridge: allow turning on vlan_filtering

[John Crispin]

If we want a bridge to be vlan aware we need to be able to turn on
filtering.

Signed-off-by: John Crispin 
---
 bridge.c   | 6 ++
 system-linux.c | 6 ++
 system.h   | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/bridge.c b/bridge.c
index c1f4ffa..e4ec597 100644
--- a/bridge.c
+++ b/bridge.c
@@ -38,6 +38,7 @@ enum {
BRIDGE_ATTR_QUERY_INTERVAL,
BRIDGE_ATTR_QUERY_RESPONSE_INTERVAL,
BRIDGE_ATTR_LAST_MEMBER_INTERVAL,
+   BRIDGE_ATTR_VLAN_FILTERING,
__BRIDGE_ATTR_MAX
 };
 
@@ -57,6 +58,7 @@ static const struct blobmsg_policy 
bridge_attrs[__BRIDGE_ATTR_MAX] = {
[BRIDGE_ATTR_QUERY_INTERVAL] = { "query_interval", BLOBMSG_TYPE_INT32 },
[BRIDGE_ATTR_QUERY_RESPONSE_INTERVAL] = { "query_response_interval", 
BLOBMSG_TYPE_INT32 },
[BRIDGE_ATTR_LAST_MEMBER_INTERVAL] = { "last_member_interval", 
BLOBMSG_TYPE_INT32 },
+   [BRIDGE_ATTR_VLAN_FILTERING] = { "vlan_filtering", BLOBMSG_TYPE_BOOL },
 };
 
 static const struct uci_blob_param_info bridge_attr_info[__BRIDGE_ATTR_MAX] = {
@@ -577,6 +579,7 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
cfg->hash_max = 512;
cfg->bridge_empty = false;
cfg->priority = 0x7FFF;
+   cfg->vlan_filtering = false;
 
if ((cur = tb[BRIDGE_ATTR_STP]))
cfg->stp = blobmsg_get_bool(cur);
@@ -633,6 +636,9 @@ bridge_apply_settings(struct bridge_state *bst, struct 
blob_attr **tb)
 
if ((cur = tb[BRIDGE_ATTR_BRIDGE_EMPTY]))
cfg->bridge_empty = blobmsg_get_bool(cur);
+
+   if ((cur = tb[BRIDGE_ATTR_VLAN_FILTERING]))
+   cfg->vlan_filtering = blobmsg_get_bool(cur);
 }
 
 static enum dev_change_type
diff --git a/system-linux.c b/system-linux.c
index 3b09bbb..97b38e7 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -470,6 +470,11 @@ static void system_set_sendredirects(struct device *dev, 
const char *val)
system_set_dev_sysctl("/proc/sys/net/ipv4/conf/%s/send_redirects", 
dev->ifname, val);
 }
 
+static void system_bridge_set_vlan_filtering(struct device *dev, const char 
*val)
+{
+   
system_set_dev_sysctl("/sys/devices/virtual/net/%s/bridge/vlan_filtering", 
dev->ifname, val);
+}
+
 static int system_get_sysctl(const char *path, char *buf, const size_t buf_sz)
 {
int fd = -1, ret = -1;
@@ -1170,6 +1175,7 @@ int system_bridge_addbr(struct device *bridge, struct 
bridge_config *cfg)
system_bridge_set_forward_delay(bridge, buf);
 
system_bridge_conf_multicast(bridge, cfg, buf, sizeof(buf));
+   system_bridge_set_vlan_filtering(bridge, cfg->vlan_filtering ? "1" : 
"0");
 
snprintf(buf, sizeof(buf), "%d", cfg->priority);
system_bridge_set_priority(bridge, buf);
diff --git a/system.h b/system.h
index 252fd92..258b1af 100644
--- a/system.h
+++ b/system.h
@@ -127,6 +127,8 @@ struct bridge_config {
int hello_time;
int max_age;
int hash_max;
+
+   bool vlan_filtering;
 };
 
 enum macvlan_opt {
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH 1/1] dsaconfig: introduce package for UCI configuration of VLAN filter rules

[John Crispin]

On 07.07.20 15:34, Jo-Philipp Wich wrote:

This package provides the necessary files to translate `config switch_vlan`
and `config switch_port` sections  of `/etc/config/network` into appropriate
bridge vlan filter rules.

The approach of the configuration is to bridge all DSA ports into a logical
bridge device, called "switch0" by default, and to set VLAN port membership,
tagging state and PVID as specified by UCI on each port and on the switch
bridge device itself, allowing logical interfaces to reference port VLAN
groups by using "switch0.N" as ifname, where N denotes the VLAN ID.

Signed-off-by: Jo-Philipp Wich 



very nice, now we need to move this to netifd :-)

    John


---
  package/network/config/dsaconfig/Makefile |  40 +++
  .../config/dsaconfig/files/dsaconfig.hotplug  |   7 +
  .../config/dsaconfig/files/dsaconfig.include  |  11 +
  .../config/dsaconfig/files/dsaconfig.sh   | 296 ++
  4 files changed, 354 insertions(+)
  create mode 100644 package/network/config/dsaconfig/Makefile
  create mode 100644 package/network/config/dsaconfig/files/dsaconfig.hotplug
  create mode 100755 package/network/config/dsaconfig/files/dsaconfig.include
  create mode 100755 package/network/config/dsaconfig/files/dsaconfig.sh

diff --git a/package/network/config/dsaconfig/Makefile 
b/package/network/config/dsaconfig/Makefile
new file mode 100644
index 00..406904
--- /dev/null
+++ b/package/network/config/dsaconfig/Makefile
@@ -0,0 +1,40 @@
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=dsaconfig
+PKG_RELEASE:=1
+PKG_LICENSE:=GPL-2.0
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/dsaconfig
+  SECTION:=net
+  CATEGORY:=Network
+  MAINTAINER:=Jo-Philipp Wich 
+  TITLE:=UCI configuration support for DSA switch VLAN filtering
+  DEPENDS:= +ip-bridge +ip-full
+  PKGARCH:=all
+endef
+
+define Package/dsaconfig/description
+ This package provides UCI configuration abstraction for VLAN filter rules
+ on top of DSA switches.
+endef
+
+define Build/Compile
+endef
+
+define Build/Configure
+endef
+
+define Package/dsaconfig/install
+   $(INSTALL_DIR) $(1)/etc/hotplug.d/iface
+   $(INSTALL_DATA) ./files/dsaconfig.hotplug 
$(1)/etc/hotplug.d/iface/01-dsaconfig
+
+   $(INSTALL_DIR) $(1)/lib/network
+   $(INSTALL_DATA) ./files/dsaconfig.include $(1)/lib/network/dsaconfig.sh
+
+   $(INSTALL_DIR) $(1)/sbin
+   $(INSTALL_BIN) ./files/dsaconfig.sh $(1)/sbin/dsaconfig
+endef
+
+$(eval $(call BuildPackage,dsaconfig))
diff --git a/package/network/config/dsaconfig/files/dsaconfig.hotplug 
b/package/network/config/dsaconfig/files/dsaconfig.hotplug
new file mode 100644
index 00..fc2a489dea
--- /dev/null
+++ b/package/network/config/dsaconfig/files/dsaconfig.hotplug
@@ -0,0 +1,7 @@
+#!/bin/sh
+
+if [ "$ACTION" = ifup ] && [ "$INTERFACE" = loopback ]; then
+   . /lib/network/dsaconfig.sh
+   setup_switch
+fi
+
diff --git a/package/network/config/dsaconfig/files/dsaconfig.include 
b/package/network/config/dsaconfig/files/dsaconfig.include
new file mode 100755
index 00..4ac11d8061
--- /dev/null
+++ b/package/network/config/dsaconfig/files/dsaconfig.include
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+setup_switch() {
+   # Skip switch setup on network restart. The netifd process
+   # will be started afterwards and remove all interfaces again...
+   if [ "$initscript" = /etc/init.d/network ] && [ "$action" = restart ]; 
then
+   return 0
+   fi
+
+   /sbin/dsaconfig apply 2>&1 | logger -t dsaconfig
+}
diff --git a/package/network/config/dsaconfig/files/dsaconfig.sh 
b/package/network/config/dsaconfig/files/dsaconfig.sh
new file mode 100755
index 00..0182f340ba
--- /dev/null
+++ b/package/network/config/dsaconfig/files/dsaconfig.sh
@@ -0,0 +1,296 @@
+#!/bin/sh
+
+. /lib/functions.sh
+. /lib/functions/network.sh
+
+switch_names=""
+
+warn() {
+   echo "$@" >&2
+}
+
+clear_port_vlans() {
+   local port=$1
+   local self=$2
+   local vlans=$(bridge vlan show dev "$port" | sed -ne 's#^[^ ]* 
\+\([0-9]\+\).*$#\1#p')
+
+   local vlan
+   for vlan in $vlans; do
+   bridge vlan del vid "$vlan" dev "$port" $self
+   done
+}
+
+lookup_switch() {
+   local cfg=$1
+   local swname
+
+   config_get swname "$cfg" switch
+
+   # Auto-determine switch if not specified ...
+   if [ -z "$swname" ]; then
+   case "$switch_names" in
+   *\ *)
+   warn "VLAN section '$cfg' does not specify a switch 
but multiple switches present, using first one"
+   swname=${switch_names%% *}
+   ;;
+   *)
+   swname=${switch_names}
+   ;;
+   esac
+
+   # ... otherwise check if the referenced switch is declared
+   else
+   case " $switch_names " in
+   *" $swname "*) : ;;
+

Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4

[John Crispin]

On 05.07.20 14:24, David Bauer wrote:

Hi all,

On 4/2/20 9:53 PM, David Bauer wrote:

As the reported major bugs are ironed out, switch to the new kernel to
begin testing with a broader audience.


As the DSP exception is now sorted out we should be good to go here.

Any objections on applying this patch left?

Best wishes
David


works for me on the 5 units I tested today.

   John




Signed-off-by: David Bauer 
---
  target/linux/ath79/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/target/linux/ath79/Makefile b/target/linux/ath79/Makefile
index 9b203cf48e..a955602ba9 100644
--- a/target/linux/ath79/Makefile
+++ b/target/linux/ath79/Makefile
@@ -8,7 +8,7 @@ SUBTARGETS:=generic mikrotik nand tiny
    FEATURES:=ramdisk
  -KERNEL_PATCHVER:=4.19
+KERNEL_PATCHVER:=5.4
  KERNEL_TESTING_PATCHVER:=5.4
    include $(INCLUDE_DIR)/target.mk



___
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

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 22:05, Luca Olivetti wrote:

El 3/7/20 a les 21:31, Luca Olivetti ha escrit:

I suppose it's the call to devm_regulator_get_optional, which should 
lead to regulator/core.c


static struct regulator_dev *regulator_dev_lookup(struct device *dev,
   const char *supply)
{
 struct regulator_dev *r = NULL;
 struct device_node *node;
 struct regulator_map *map;
 const char *devname = NULL;

 regulator_supply_alias(, );

 /* first do a dt based lookup */
 if (dev && dev->of_node) {
 node = of_get_regulator(dev, supply);
 if (node) {
 r = of_find_regulator_by_node(node);
 if (r)
 return r;

 /*
  * We have a node, but there is no device.
  * assume it has not registered yet.
  */


I added a printk here and it's exactly as I supposed.
Now what?



 return ERR_PTR(-EPROBE_DEFER);
 }
 }



Bye
chicken and egg ? is your dts correct ? go on. inspire us with you 
skills ...


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 21:10, John Crispin wrote:


On 03.07.20 21:07, Luca Olivetti wrote:

El 3/7/20 a les 20:07, Luca Olivetti ha escrit:

El 3/7/20 a les 20:06, John Crispin ha escrit:


On 03.07.20 19:57, Luca Olivetti wrote:

El 3/7/20 a les 19:49, John Crispin ha escrit:


On 03.07.20 19:47, Luca Olivetti wrote:

El 3/7/20 a les 19:37, John Crispin ha escrit:



Why not use the gpio regulator ?


Because I don't know how :-(

https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml 



Oh, I see, but that's the one I had to *remove* because it 
didn't work.


Bye



CONFIG_REGULATOR_GPIO is not enabled in the kernel config




So it's just a matter of adding it to 
target/linux/lantiq/xway/config-4.14 after



CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y


?


(and put back the entry I removed in the dts)

Bye



correct




Thank you, I'm building it now (but my system is slow). I'll report 
back if it works.


Nope, it doesn't



printk the driver with a salt shaker and see if it loads and if so 
where it breaks





make kernel_menuconfig CONFIG_TARGET=subtarget

that will drop you into the kernel menu config. you can make sure the 
driver is selected




# dmesg | grep dwc2
[    5.751540] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[    5.758454] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[    5.76] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[    5.912432] dwc2 1e101000.usb: DWC OTG Controller
[    5.915747] dwc2 1e101000.usb: new USB bus registered, assigned 
bus number 1

[    5.922594] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[    5.927811] dwc2 1e101000.usb: startup error -517
[    5.932278] dwc2 1e101000.usb: USB bus 1 deregistered
[    5.937340] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.308465] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.315362] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator

[   50.360539] dwc2 1e101000.usb: DWC OTG Controller
[   50.363823] dwc2 1e101000.usb: new USB bus registered, assigned 
bus number 1

[   50.370726] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   50.375988] dwc2 1e101000.usb: startup error -517
[   50.380385] dwc2 1e101000.usb: USB bus 1 deregistered
[   50.385438] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.457833] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.464747] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   50.472906] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   50.632565] dwc2 1e101000.usb: DWC OTG Controller
[   50.635942] dwc2 1e101000.usb: new USB bus registered, assigned 
bus number 1

[   50.642733] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   50.647992] dwc2 1e101000.usb: startup error -517
[   50.652411] dwc2 1e101000.usb: USB bus 1 deregistered
[   50.657463] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.767275] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.774183] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   50.782345] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   51.098453] dwc2 1e101000.usb: DWC OTG Controller
[   51.101832] dwc2 1e101000.usb: new USB bus registered, assigned 
bus number 1

[   51.108645] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   51.113845] dwc2 1e101000.usb: startup error -517
[   51.118306] dwc2 1e101000.usb: USB bus 1 deregistered
[   51.123355] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   86.412437] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   86.419349] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   86.427592] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   86.620575] dwc2 1e101000.usb: DWC OTG Controller
[   86.623972] dwc2 1e101000.usb: new USB bus registered, assigned 
bus number 1

[   86.630735] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   86.636020] dwc2 1e101000.usb: startup error -517
[   86.640421] dwc2 1e101000.usb: USB bus 1 deregistered
[   86.645483] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517


Bye


___
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

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 21:07, Luca Olivetti wrote:

El 3/7/20 a les 20:07, Luca Olivetti ha escrit:

El 3/7/20 a les 20:06, John Crispin ha escrit:


On 03.07.20 19:57, Luca Olivetti wrote:

El 3/7/20 a les 19:49, John Crispin ha escrit:


On 03.07.20 19:47, Luca Olivetti wrote:

El 3/7/20 a les 19:37, John Crispin ha escrit:



Why not use the gpio regulator ?


Because I don't know how :-(

https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml 



Oh, I see, but that's the one I had to *remove* because it didn't 
work.


Bye



CONFIG_REGULATOR_GPIO is not enabled in the kernel config




So it's just a matter of adding it to 
target/linux/lantiq/xway/config-4.14 after



CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y


?


(and put back the entry I removed in the dts)

Bye



correct




Thank you, I'm building it now (but my system is slow). I'll report 
back if it works.


Nope, it doesn't



printk the driver with a salt shaker and see if it loads and if so where 
it breaks





# dmesg | grep dwc2
[    5.751540] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[    5.758454] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[    5.76] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[    5.912432] dwc2 1e101000.usb: DWC OTG Controller
[    5.915747] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[    5.922594] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[    5.927811] dwc2 1e101000.usb: startup error -517
[    5.932278] dwc2 1e101000.usb: USB bus 1 deregistered
[    5.937340] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.308465] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.315362] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator

[   50.360539] dwc2 1e101000.usb: DWC OTG Controller
[   50.363823] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[   50.370726] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   50.375988] dwc2 1e101000.usb: startup error -517
[   50.380385] dwc2 1e101000.usb: USB bus 1 deregistered
[   50.385438] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.457833] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.464747] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   50.472906] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   50.632565] dwc2 1e101000.usb: DWC OTG Controller
[   50.635942] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[   50.642733] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   50.647992] dwc2 1e101000.usb: startup error -517
[   50.652411] dwc2 1e101000.usb: USB bus 1 deregistered
[   50.657463] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   50.767275] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   50.774183] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   50.782345] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   51.098453] dwc2 1e101000.usb: DWC OTG Controller
[   51.101832] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[   51.108645] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   51.113845] dwc2 1e101000.usb: startup error -517
[   51.118306] dwc2 1e101000.usb: USB bus 1 deregistered
[   51.123355] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517
[   86.412437] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not 
found, using dummy regulator
[   86.419349] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not 
found, using dummy regulator
[   86.427592] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[   86.620575] dwc2 1e101000.usb: DWC OTG Controller
[   86.623972] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[   86.630735] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[   86.636020] dwc2 1e101000.usb: startup error -517
[   86.640421] dwc2 1e101000.usb: USB bus 1 deregistered
[   86.645483] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517


Bye


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 19:47, Luca Olivetti wrote:

El 3/7/20 a les 19:37, John Crispin ha escrit:



Why not use the gpio regulator ?


Because I don't know how :-(

https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml 



Oh, I see, but that's the one I had to *remove* because it didn't work.

Bye



CONFIG_REGULATOR_GPIO is not enabled in the kernel config



___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 19:57, Luca Olivetti wrote:

El 3/7/20 a les 19:49, John Crispin ha escrit:


On 03.07.20 19:47, Luca Olivetti wrote:

El 3/7/20 a les 19:37, John Crispin ha escrit:



Why not use the gpio regulator ?


Because I don't know how :-(

https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml 



Oh, I see, but that's the one I had to *remove* because it didn't work.

Bye



CONFIG_REGULATOR_GPIO is not enabled in the kernel config




So it's just a matter of adding it to 
target/linux/lantiq/xway/config-4.14 after



CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y


?


(and put back the entry I removed in the dts)

Bye



correct


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: fix for lantiq (danube) usb

[John Crispin]

On 03.07.20 19:23, Luca Olivetti wrote:

El 3/7/20 a les 18:42, John Crispin ha escrit:


On 03.07.20 18:10, Luca Olivetti wrote:

Hello,

around 2 years ago, this patch

https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=6eaf8b3d89571992a0aa7142cfab3f1dcef3c802#patch7 



broke the usb on my arv7518pw: when it tries to power up the usb it 
returns error -537 (EPROBE_DEFER, see 
https://bugs.openwrt.org/index.php?do=details_id=1634).


[ 5.431505] dwc2 1e101000.usb: 1e101000.usb supply vusb_d not found, 
using dummy regulator
[ 5.438418] dwc2 1e101000.usb: 1e101000.usb supply vusb_a not found, 
using dummy regulator
[ 5.446581] dwc2 1e101000.usb: dwc2_core_reset() HANG! Soft Reset 
GRSTCTL=8001

[ 5.593255] dwc2 1e101000.usb: DWC OTG Controller
[ 5.596565] dwc2 1e101000.usb: new USB bus registered, assigned bus 
number 1

[ 5.603417] dwc2 1e101000.usb: irq 62, io mem 0x1e101000
[ 5.608632] dwc2 1e101000.usb: startup error -517
[ 5.613124] dwc2 1e101000.usb: USB bus 1 deregistered
[ 5.618080] dwc2 1e101000.usb: dwc2_hcd_init() FAILED, returning -517


If I revert the above patch, the usb initializes correctly, but 
there's no 5V on the port so it doesn't work.


I hacked a fake led on gpio 14 so I can turn on the 5V from user 
space, and the usb works (I tried with a memory stick and an rt73 
wifi stick, an rtl8812au doesn't work but I think because its driver 
is ... meh).


What's the proper way to turn on the 5V on gpio 14 (i.e. fix the 
-EPROBE_DEFER error)?



I suppose that the issue also affects other danube based devices, 
but I can only test the one I have.


This is against 19.07.3



Why not use the gpio regulator ?


Because I don't know how :-(


https://www.kernel.org/doc/Documentation/devicetree/bindings/regulator/fixed-regulator.yaml

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [PATCH V1] netifd: fix wdev->data lifetime

[John Crispin]

On 23.06.20 11:40, John Crispin wrote:

The reconf patch breaks wifi down under certain conditions. The root cause
is that during reload the wdev state gets flushed. This has the effect, that
the phy is lost from the state resulting in teardown breaking.
Fix this by changing the lifetime of wdev->data.

Signed-off-by: John Crispin 
---
Changes in V2
* free() call was in the wrong place

  wireless.c | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/wireless.c b/wireless.c
index efb7992..e295f28 100644
--- a/wireless.c
+++ b/wireless.c
@@ -275,8 +275,6 @@ wireless_device_free_state(struct wireless_device *wdev)
uloop_timeout_cancel(>script_check);
uloop_timeout_cancel(>timeout);
wireless_complete_kill_request(wdev);
-   free(wdev->data);
-   wdev->data = NULL;
vlist_for_each_element(>interfaces, vif, node) {
free(vif->data);
vif->data = NULL;
@@ -460,6 +458,7 @@ wireless_device_free(struct wireless_device *wdev)
vlist_flush_all(>vlans);
vlist_flush_all(>stations);
avl_delete(_devices.avl, >node.avl);
+   free(wdev->data);
free(wdev->config);
free(wdev->prev_config);
free(wdev);
@@ -1414,6 +1413,8 @@ wireless_device_notify(struct wireless_device *wdev, 
struct blob_attr *data,
if (*pdata)
return UBUS_STATUS_INVALID_ARGUMENT;
  
+		if (*pdata)

+   free(*pdata);
*pdata = blob_memdup(cur);
if (vif)
wireless_interface_set_data(vif);
 


thx, looks like the  rest of the patch fixes the issue, been stress testing 
this today, will have a closer look tomorrow ..

John

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[PATCH V1] netifd: fix wdev->data lifetime

[John Crispin]

The reconf patch breaks wifi down under certain conditions. The root cause
is that during reload the wdev state gets flushed. This has the effect, that
the phy is lost from the state resulting in teardown breaking.
Fix this by changing the lifetime of wdev->data.

Signed-off-by: John Crispin 
---
Changes in V2
* free() call was in the wrong place

 wireless.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/wireless.c b/wireless.c
index efb7992..e295f28 100644
--- a/wireless.c
+++ b/wireless.c
@@ -275,8 +275,6 @@ wireless_device_free_state(struct wireless_device *wdev)
uloop_timeout_cancel(>script_check);
uloop_timeout_cancel(>timeout);
wireless_complete_kill_request(wdev);
-   free(wdev->data);
-   wdev->data = NULL;
vlist_for_each_element(>interfaces, vif, node) {
free(vif->data);
vif->data = NULL;
@@ -460,6 +458,7 @@ wireless_device_free(struct wireless_device *wdev)
vlist_flush_all(>vlans);
vlist_flush_all(>stations);
avl_delete(_devices.avl, >node.avl);
+   free(wdev->data);
free(wdev->config);
free(wdev->prev_config);
free(wdev);
@@ -1414,6 +1413,8 @@ wireless_device_notify(struct wireless_device *wdev, 
struct blob_attr *data,
if (*pdata)
return UBUS_STATUS_INVALID_ARGUMENT;
 
+   if (*pdata)
+   free(*pdata);
*pdata = blob_memdup(cur);
if (vif)
wireless_interface_set_data(vif);
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[PATCH] netifd: fix wdev->data lifetime

[John Crispin]

The reconf patch breaks wifi down under certain conditions. The root cause
is that during reload the wdev state gets flushed. This has the effect, that
the phy is lost from the state resulting in teardown breaking.
Fix this by changing the lifetime of wdev->data.

Signed-off-by: John Crispin 
---
 wireless.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/wireless.c b/wireless.c
index efb7992..0aad8c7 100644
--- a/wireless.c
+++ b/wireless.c
@@ -275,8 +275,6 @@ wireless_device_free_state(struct wireless_device *wdev)
uloop_timeout_cancel(>script_check);
uloop_timeout_cancel(>timeout);
wireless_complete_kill_request(wdev);
-   free(wdev->data);
-   wdev->data = NULL;
vlist_for_each_element(>interfaces, vif, node) {
free(vif->data);
vif->data = NULL;
@@ -460,6 +458,7 @@ wireless_device_free(struct wireless_device *wdev)
vlist_flush_all(>vlans);
vlist_flush_all(>stations);
avl_delete(_devices.avl, >node.avl);
+   free(wdev->data);
free(wdev->config);
free(wdev->prev_config);
free(wdev);
@@ -1415,6 +1414,8 @@ wireless_device_notify(struct wireless_device *wdev, 
struct blob_attr *data,
return UBUS_STATUS_INVALID_ARGUMENT;
 
*pdata = blob_memdup(cur);
+   if (*pdata)
+   free(*pdata);
if (vif)
wireless_interface_set_data(vif);
else if (vlan)
-- 
2.25.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel