On Tue, Nov 19, 2019 at 4:12 PM Kevin Darbyshire-Bryant
wrote:
>
> Change dhcp no/release on shutdown to 'norelease' uci option to match
> existing proto dhcpv6 usage.
>
> Signed-off-by: Kevin Darbyshire-Bryant
Acked-by: Hans Dedecker
> ---
> v2 - store the migrate script under netifd structure
Hi,
> -Original Message-
> From: Michal Cieslakiewicz [mailto:michal.cieslakiew...@wp.pl]
> Sent: Mittwoch, 20. November 2019 00:21
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2] ath79: add support for Netgear
> WNDR4300
>
>
Hello Adrian,
>
> What is/was the reason for that change and do we have to backport it
> to ar71xx?
>
On my WNDR4300 2.4 GHz radio is at 0x1000 and 5 GHz is at 0x5000, like
many other ar9344 models have. Both areas are 0x440 in length not 0x800
- after 0x440 empty space begins (0xff) - so
>
> Typo, I did mean factory.bin ... . The type you use to initially flash
> OpenWrt ;-)
>
Ok, that will be factory.img. There is no factory.bin image for that
model to flash. If someone needs it badly, img file is 128-byte DNI
header prepended to bin file (kernel + fake rootfs).
Regards
On Tue, 19 Nov 2019 at 17:59, Michal Cieslakiewicz
wrote:
>
> >
> > That was my question, if the "new" OpenWrt sysupgrade.bin still works
> > in the initial flash.
> >
>
> sysupgrade.bin for this model is in format tar+metadata, it is not
> designed to be put into flash directly.
Typo, I did
Hello
To the best of my understanding dnsmasq's DNSSEC validation is not
working in 19.07 due to undesired behaviour introduced in commits
04b45d3 and 0299a4b. The following pull request contains the necessary
revert as a first patch (see commit message for details):
Bump
On 11/12/19 12:04 AM, Paul Spooren wrote:
This separates the options for signature creation and verification
* SIGNED_PACKAGES create Packages.sig
* SIGNED_IMAGES add ucert signature to created images
* CHECK_SIGNATURE add verification capabilities to images
* INSTALL_LOCAL_KEY add local
Hi,
> * 10-ath9k-eeprom: extract 0x440 instead of 0x800 bytes from caldata
due to https://bugs.openwrt.org/index.php?do=details_id=2612 I had another
look at this device.
What is/was the reason for that change and do we have to backport it to ar71xx?
Best
Adrian
The sender domain has a DMARC Reject/Quarantine policy which disallows
sending mailing list messages using the original "From" header.
To mitigate this problem, the original message has been wrapped
automatically by the mailing list software.--- Begin Message ---
Failsafe code of dropbear should
>
> That was my question, if the "new" OpenWrt sysupgrade.bin still works
> in the initial flash.
>
sysupgrade.bin for this model is in format tar+metadata, it is not
designed to be put into flash directly.
Regards
Michal
___
openwrt-devel mailing
Hello,
Argh, I forgot to add this to my previous email...
ubi volume is successfully resized, but ubi filesystem on top of it is
not - so /overlay does not benefit from extra space. Are there any
methods for UBIFS online resize that complement ubirsvol?
Best regards
Michal
On Tue, 19 Nov 2019 at 17:33, Michal Cieslakiewicz
wrote:
>
> Hello,
>
> >
> > Have you checked that flashing a factory.bin image through tftp still
> > works?
> >
>
> Yes, it works. On this router the easiest way to flash memory via tftp
> is to enter uboot and execute 'fw_recovery' command,
Hello,
>
> Have you checked that flashing a factory.bin image through tftp still
> works?
>
Yes, it works. On this router the easiest way to flash memory via tftp
is to enter uboot and execute 'fw_recovery' command, then factory.img
file can be uploaded via tftp client. I hope this answers
On Tue, 19 Nov 2019 at 16:18, Michal Cieslakiewicz
wrote:
>
> Hello David,
>
> Two questions were raised just after publishing 'all-flash-space' patch.
> Now I am ready to provide more information on these issues:
>
> 0. Downgrade to vendor firmware.
>
> It is possible. Just don't forget to erase
Hello David,
Two questions were raised just after publishing 'all-flash-space' patch.
Now I am ready to provide more information on these issues:
0. Downgrade to vendor firmware.
It is possible. Just don't forget to erase both ubi concat partitions:
'mtd -r erase ubi' does the job fine.
1.
Change dhcp no/release on shutdown to 'norelease' uci option to match
existing proto dhcpv6 usage.
Signed-off-by: Kevin Darbyshire-Bryant
---
v2 - store the migrate script under netifd structure instead of as part
of base-files
package/network/config/netifd/Makefile| 2 +-
This applies minor style improvements and removes commented pll
clock adjustments from ubnt_xm DTSI. The latter were introduced
(already commented out) when adding ath79 target and have never
been touched since then. For Unifi (BZ board), similar clock
adjustments are employed and used.
The USB descriptor parsing in adb fails to detect SuperSpeed devices
because of the SuperSpeed Endpoint Companion Descriptor. This
cherry-picks the upstream fix for the problem.
Unfortunately there never were a release with this fix before the
conversion to C++, so upgrading to a newer version
Hi Zefir,
On 19.11.2019 11:34, Zefir Kurtisi wrote:
[...]
We don't know whether this is a device FW issue
(we use the latest EM12GPAR01A15M4G) or whether
the device enters some undocumented power-save
mode after idling for some time.
Could you share this firmware version, is that a generic
Change dhcp no/release on shutdown to 'norelease' uci option to match
existing proto dhcpv6 usage.
Signed-off-by: Kevin Darbyshire-Bryant
---
.../etc/uci-defaults/14_migrate-dhcp-release | 23 +++
package/network/config/netifd/Makefile| 2 +-
Hi,
by coincidence, I've learned that label MAC addresses on Ubiquiti devices
aren't correct anymore after switching from phy0 to "expected" flash locations
in this patch:
https://github.com/openwrt/openwrt/commit/d421a8b9448968de0e3265f5beb469c210a909ab
I've investigated that on a Ubiquiti
On 11/17/19 11:23 AM, Zefir Kurtisi wrote:
> On 11/16/19 3:59 PM, Piotr Dymacz wrote:
>> Hi Zefir,
>>
>> On 07.11.2019 12:54, Zefir Kurtisi wrote:
>>> Working with Quectel EM12 LTE-module, we observe
>>> regular stalls of the QMI interface which cause
>>> a request issued by uqmi to hang forever.
22 matches
Mail list logo
