+1
Actually, I am using the RUT955 running PPP, _not_ qmi.
For the requirement (or precaution) of a reset of the modem, using the GPIO for
the RUT955
looks like the proper solution to go.
In the opposite, ZBT confirmed, that on their WE826 there is no wiring
to (power-)reset the installed
W dniu 2021-06-29 o 01:07, Sergey Ryazanov pisze:
On Mon, Jun 28, 2021 at 11:57 PM Lech Perczak wrote:
W dniu 2021-06-28 o 21:55, Paul Spooren pisze:
On 6/28/21 9:53 AM, John Crispin wrote:
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
On Mon, Jun 28, 2021 at 11:57 PM Lech Perczak wrote:
> W dniu 2021-06-28 o 21:55, Paul Spooren pisze:
>> On 6/28/21 9:53 AM, John Crispin wrote:
>>> 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
On Mon, Jun 28, 2021 at 02:19:11PM +0200, John Crispin wrote:
>
> 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
W dniu 2021-06-28 o 21:55, Paul Spooren pisze:
On 6/28/21 9:53 AM, John Crispin wrote:
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,
Hello,
While upgrading from 19.07 to 21.02, there is an scary error message
when target migrates to DSA (both Luci or CLI):
root@OpenWrt:/tmp# sysupgrade -n
openwrt-21.02.0-rc3-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin
Device linksys,shelby not supported by this image
Supported
On 6/28/21 9:53 AM, John Crispin wrote:
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,
Agree, APU boards etc also need some extra
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
On 6/28/21 8:53 AM, Piotr Dymacz wrote:
Hi John,
On 28.06.2021 20:32, John Crispin wrote:
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
Hi John,
On 28.06.2021 20:32, John Crispin wrote:
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
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
Hi Arjun,
On 28.06.2021 19:43, Arjun AK wrote:
On 28/06/21 10:56 pm, Piotr Dymacz wrote:
Hi Arjun,
On 28.06.2021 18:52, Arjun AK wrote:
Signed-off-by: Arjun AK
The only problem here is a D-Link DWR-512B device (ramips/rt305x target)
which has 'comgt-ncm' package listed under
On 28/06/21 10:56 pm, Piotr Dymacz wrote:
Hi Arjun,
On 28.06.2021 18:52, Arjun AK wrote:
Signed-off-by: Arjun AK
The only problem here is a D-Link DWR-512B device (ramips/rt305x target)
which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1].
But the package name is "comgt"
Hi Arjun,
On 28.06.2021 18:52, Arjun AK wrote:
Signed-off-by: Arjun AK
The only problem here is a D-Link DWR-512B device (ramips/rt305x target)
which has 'comgt-ncm' package listed under 'DEVICE_PACKAGES', see [1].
I might be wrong here but I think we don't include packages from
external
On 28/06/21 10:22 pm, Arjun AK wrote:
Signed-off-by: Arjun AK
---
package/network/utils/comgt/Makefile | 106
package/network/utils/comgt/files/3g.chat | 12 -
package/network/utils/comgt/files/3g.sh | 116
package/network/utils/comgt/files/3g.usb
Signed-off-by: Arjun AK
---
package/network/utils/comgt/Makefile | 106
package/network/utils/comgt/files/3g.chat | 12 -
package/network/utils/comgt/files/3g.sh | 116
package/network/utils/comgt/files/3g.usb | 33 ---
Hello Ontje,
On Mon, Jun 28, 2021 at 3:00 PM wrote:
> The rut955 fails to activate its modem upon every second reboot otherwise.
What does it mean "fails to activate modem"? Could you be more
specific? A bit more detailed issue description will be helpful if
someone faces a similar case, even
On 28/06/21 5:26 pm, ontje.luensd...@dlr.de wrote:
From: Ontje Lünsdorf
Hi all,
The rut955 fails to activate its modem upon every second reboot. By resetting
the modem upon initialization, we get it to work reliably.
This will probably affect all other modems and we are not sure if this may
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
Hi Ontje,
On 28.06.2021 13:56, ontje.luensd...@dlr.de wrote:
From: Ontje Lünsdorf
The rut955 fails to activate its modem upon every second reboot otherwise.
This will issue reset every time the qmi connection is (re-)initialized,
making the whole (re-)connection process much longer. Does
From: Ontje Lünsdorf
The rut955 fails to activate its modem upon every second reboot otherwise.
Co-authored-by: hans-hermann.reden...@dlr.de
Co-authored-by: jonas.stuehrenb...@dlr.de
---
package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh | 4
1 file changed, 4 insertions(+)
diff
From: Ontje Lünsdorf
Hi all,
The rut955 fails to activate its modem upon every second reboot. By resetting
the modem upon initialization, we get it to work reliably.
This will probably affect all other modems and we are not sure if this may cause
side-effects on other devices.
Best regards,
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
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
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
Hi,
On Fri, Jun 25, 2021 at 07:43:05AM +0800, eveans2...@gmail.com wrote:
> From: Ian Chang
>
> Hardware specification
> --
> * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz
> * 4 GB DDR
> * 4 GB eMMC
> mmcblk0
> ├─mmcblk0p164M kernel_1
> ├─mmcblk0p264M
ACK I like this. Good for many applications, not the least of which
include a quick "stealth mode" LED setting or warning/notification LED
blink patterns.
All the best,
Nick
On Mon, 28 Jun 2021 at 17:18, John Crispin wrote:
>
> This allows us to make all leds blink or force all leds to off.
>
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
On 6/27/21 6:10 PM, Ansuel Smith wrote:
> Il giorno dom 27 giu 2021 alle ore 23:41 Baptiste Jonglez
> ha scritto:
>>
>> Ansuel, do you have any feedback on this backport? It seems to help things.
>>
> It's good but consider that also the dts changes are required and also there
> is a pending pr
29 matches
Mail list logo
