Rename fw3_hotplug function to fw3_hotplug_zone to use fw3_hotlpug for
common hotplug events like start|stop|flush|reload|restart
Signed-off-by: Florian Eckert
---
utils.c | 2 +-
utils.h | 2 +-
zones.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/utils.c b/utils.c
ind
Add -e option for fw3 start|stop|flush|reload|restart events.
If option is set, then common hotplug events are executed in dir
'/etc/hotplug.d/firewall'
Signed-off-by: Florian Eckert
---
main.c | 13 +++--
utils.c | 33 +
utils.h | 5 -
3 files chang
Hi guys,
we would like to use SSL client certificates to authenticate to a OpenWRT/LEDE
router using UHTTPD/LUCI. We use a private PKI/certificate chain and would only
like to admit users to the WebUI which present a valid SSL client certificate
through their web browser.
I've found a note in
Hello again,
On Sat, Aug 26, 2017 at 4:57 PM, Kristian Evensen
wrote:
> I did not have to wait very long before anything. Unfortunately, my
> router crashed right after I sent the previous email. So I guess that
> means back to the drawing board.
I have kept working on this issue throughout the
Hi Simon,
this is not implemented in uhttpd.
~ J
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Citeren Simon Wunderlich :
Hi guys,
we would like to use SSL client certificates to authenticate to a
OpenWRT/LEDE
router using UHTTPD/LUCI. We use a private PKI/certificate chain and
would only
like to admit users to the WebUI which present a valid SSL client certificate
through their web
Refreshed all patches
Compiled & run-tested on targets: cns3xxx, imx6
Signed-off-by: Koen Vandeputte
---
include/kernel-version.mk | 4 ++--
target/linux/generic/hack-4.9/930-crashlog.patch | 4 ++--
...alloc_node_mem_map-with-ARCH_PFN_OFFSET-calcu.patch |
Dear All,
i'm fighting with an odd build error on my build server VPS, using
current master and the RT5350F-OLINUXINO profile:
When trying to re-build the LEDE tree (after a successful initial
build), i get this error:
> make[5]: Entering directory
> '/home/zgyarmati/lede/build_dir/target-mipsel
On 11 August 2017 at 00:14, Hauke Mehrtens wrote:
> This fixes the VDSO problems on the Lantiq VR9 MIPS SoC.
> The gettimeofday() sometimes returned old data because of a cache
> aliasing problems on MIPS CPUs, to work around this problem VDSO
> gettimeofday support was deactivated for MIPS in LED
been away from openwrt for a while, just jumped back in with LEDE, so
will have a few questions shortly, but this one should(?) be simple.
the recipe for submitting patches for LEDE looks pretty straightforward,
but is there anything special that needs to be done if said patch should
also be
Few people asked me about the MTD_SPI_NOR_USE_4K_SECTORS. Somehow I
got responsible for it ;) It doesn't seem like a big thing, but since
I was asked, let me describe it.
So initially this feature was added by Gabor in:
generic: disable 'small sector' erase in m25p80 driver
https://dev.openwrt.or
Tested-by: Koen Vandeputte
Run-tested on cns3xxx target.
Nothing broke afaik :)
Koen
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
On 08/28/2017 02:08 PM, Rafał Miłecki wrote:
> On 11 August 2017 at 00:14, Hauke Mehrtens wrote:
>> This fixes the VDSO problems on the Lantiq VR9 MIPS SoC.
>> The gettimeofday() sometimes returned old data because of a cache
>> aliasing problems on MIPS CPUs, to work around this problem VDSO
>> g
Work around a problem where answer_request() attempts to clear from the
end of a request to end of request buffer but the end of the buffer is
at the same place as the start.
Originally this meant that memset() tried to clear data before the
buffer leading to segmentation violation. Instead only
rpj...@crashcourse.ca schrieb am 28.08.2017 um 14:15:
>
>been away from openwrt for a while, just jumped back in with LEDE, so
> will have a few questions shortly, but this one should(?) be simple.
>
>the recipe for submitting patches for LEDE looks pretty straightforward,
> but is there
Hi,
On 03-08-17, Hauke Mehrtens wrote:
> This adds initial support for the A64 Allwinner SoC to LEDE.
> It will be build in the new cortexa53 subtarget.
>
> Currently it only supports the pine64 and the image is able to boot on
> this SoC.
Thanks for the patches!
I tested them on a pine64+ 1GB
On 08/28/2017 01:52 PM, Zoltan Gyarmati wrote:
> Dear All,
>
> i'm fighting with an odd build error on my build server VPS, using
> current master and the RT5350F-OLINUXINO profile:
>
> When trying to re-build the LEDE tree (after a successful initial
> build), i get this error:
>
>> make[5]: Enter
> On Aug 28, 2017, at 6:15 AM, rpj...@crashcourse.ca wrote:
>
> do the LEDE admins look for that stuff like that
> and upstream it automatically?
No, as it’s your patch, you need to be the one presenting it so you can answer
questions about it, make changes if asked to do so, etc.
_
> On Aug 28, 2017, at 6:17 PM, Zoltan Gyarmati
> wrote:
>
> On 08/28/2017 01:52 PM, Zoltan Gyarmati wrote:
>> Dear All,
>>
>> i'm fighting with an odd build error on my build server VPS, using
>> current master and the RT5350F-OLINUXINO profile:
>>
>> When trying to re-build the LEDE tree (af
Hi all,
I don’t know if sysupgrade is the problem, or if this is where things manifest.
But I recently (within the last week, but I only rebase once or twice a week)
started seeing issues with doing sysupgrade on x86_64 hardware.
The sysupgrade will appear to go okay, but then when the machine
20 matches
Mail list logo
