On Thu, 7 Oct 2021 at 00:33, Hauke Mehrtens wrote:
>
> On 10/6/21 12:33 AM, Robert Marko wrote:
> > On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote:
> >>
> >> Hi all,
> >>
> >> based on my overview[1] things are moving forward and being tested,
> >> great! What about the targets that did not see
On 10/6/21 12:33 AM, Robert Marko wrote:
On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote:
Hi all,
based on my overview[1] things are moving forward and being tested,
great! What about the targets that did not see any 5.10 ambitions yet?
Specifically:
- arc770
- archs38
- ath25
- bcm47xx
-
The existing wnm_disassoc_imminent ubus method only supports issuing a
bss transition request with the disassoc imminent flag set.
For use-cases, where the client is requested to roam to another BSS
without a pending disassoc, this existing method is not suitable.
Add a new bss_transition_request
To allow steering daemons to be aware of the STA-decided transition
target, publish WNM transition responses to ubus. This way, steerings
daemons can learn about STA-chosen targets and send a better selection
of transition candidates.
Signed-off-by: David Bauer
---
The below is a fairly prescient analysis of the situation, and a good
approach, Rui. I think openwrt will be fine staying put on iptables,
until bpfilter matures. I think I have about 20 individual rules on my
FW. Having the capability is nice, but most home users probably don't
have or need
On Wed, Oct 6, 2021 at 10:46 AM Rui Salvaterra wrote:
>
> Hi, Rich,
>
> On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote:
> >
> > Paul, Rafał,
> >
> > I think our emails passed in the ether...
> > (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html)
> >
> > As I said in that
Hi, Rich,
On Wed, 6 Oct 2021 at 17:54, Rich Brown wrote:
>
> Paul, Rafał,
>
> I think our emails passed in the ether...
> (http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html)
>
> As I said in that message, I am very aware of the time constraints of the
> volunteers for
Paul, Rafał,
I think our emails passed in the ether...
(http://lists.openwrt.org/pipermail/openwrt-devel/2021-October/036637.html)
As I said in that message, I am very aware of the time constraints of the
volunteers for OpenWrt. And I don't mean to suck the conversation into "grand
Wise words from the experienced!
If making a yearly release is unattainable, isn't making point releases
more achievable? Even if it's adding a single commit, point releases
send a signal to the outside world that the project is still active, and
e.g. that security is in focus. Any point
On 2021-10-05 21:17, Rich Brown wrote:
On Oct 5, 2021, at 10:24 AM, Paul D wrote:
Write this up into an FAQ/howto on openwrt.org (this is, after all, the OWRT
way)
Yes, it's always more powerful (and useful) to tell people what TO do, instead
of what NOT to do.
I contribute very
> On Oct 6, 2021, at 1:58 AM, Rafał Miłecki wrote:
>
> On 30.09.2021 03:34, Rich Brown wrote:
>> My desire would be to name our next release "22.03", with a target release
>> date in March 2022. And we should name the following release "22.09" with a
>> release date in September. And so
On 05.10.21 17:42, Piotr Dymacz wrote:
Hi Tim,
On 04.10.2021 00:22, Tim Harvey wrote:
Piotr,
How is your progress regarding submitting patches to OpenWrt to split
the imx target into multiple arch related subtargets (like cortexa7,
cortexa9)?
I'm planning to clean it up and send patches
On 30.09.2021 03:34, Rich Brown wrote:
My desire would be to name our next release "22.03", with a target release date in March
2022. And we should name the following release "22.09" with a release date in
September. And so on - every six months (or whatever interval we believe we can
13 matches
Mail list logo
