Ingo Feinerer writes:
> This adds support to query the home provider, mainly for debugging and
> information purposes.
Looks nice to me. Did a simple run test just to confirm that it works
as expected with my EM7455 at least:
$ ./umbim -p -d /dev/cdc-wdm0 home
provider_id: 24201
provider_n
Dear Bjorn,
Thank you very very much! You've been always helpful tome... :)
thank you for pointing me at your work - it has been very useful. I was using
as references sources from the TP-Link Archer D2.
thanks to your hints and work, I arrived to some of the conclusions you did.
Your device w
Hello Karl,
the version built last is the one which will have the symlink set.
However, i think this is not the ideal solution in terms of
reproducibility, so we should probably only symlink lua5.1 for
the Host installation?
A bit more background on this topic (as I've forgotten to add this
to th
How is this meant to work when you have both?
David Bauer wrote:
> Since the binaries for both lua as well as lua5.3 contain the
> version number, invocations of the "lua" binary are failing, as
> it's not created anymore for the host package.
>
> Fixes: fe59b46 ("lua: include version number in
Since the binaries for both lua as well as lua5.3 contain the version
number, invocations of the "lua" binary are failing, as it's not created
anymore for the host package.
Fixes: fe59b46 ("lua: include version number in installed files")
Signed-off-by: David Bauer
---
package/utils/lua/Makefile
firewall3 currently creates one rule for each interface that is a member of a
zone. On for example devices with multiple interfaces, the current firewall3
behavior quickly leads to a lot of rules. In order to reduce the number of
rules, this patch replaces the per-interface rules with ipset matches
> > initialized the ackto to max:
> >
> > A) avoidance of late-ack state
> > B) not require wpa_supplicant -- not in use by our community today
> > C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
> > "late ack" (consistent, with observation of low SNR Neighbors sticking
> > at m
Enrico Mioso writes:
> I am still trying to port a FRITZ!BOX3272 device to OpenWRt.
> I tried to grab as much informations as I could, but I am arriving to the
> conclusion I hould be doing something really wrong.
>
> First of all, the kernel panics due to a data abort at
> linux-4.19.66/arch/mi
Dear OpenWRt list,
Dear Martin,
Dear Hauke,
TL;DR:
Can you help me out with the DTS? I have no access to datasheets and I couldn't
recover useful infos from the original firmware...
Attached my DTS
I am still trying to port a FRITZ!BOX3272 device to OpenWRt.
I tried to grab as much informations
زبان چینی رابه انگلیسی تغییردهید
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
initialized the ackto to max:
A) avoidance of late-ack state
B) not require wpa_supplicant -- not in use by our community today
C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
"late ack" (consistent, with observation of low SNR Neighbors sticking
at max ack_to with my chang
- CMIIT ID: 2019AP2581
- SoC: MediaTek MT7621
- Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
- RAM: 128MiB DDR3 (ESMT M15T1G1664A)
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
- Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
- WIFI0:MT7603E 2.4GHz 802.11b/
12 matches
Mail list logo
