Re: [PATCH odhcpd 2/2] router: always check ra_lifetime

On Mon, Feb 13, 2023 at 9:18 PM wrote: > > @@ -495,13 +503,10 @@ static int send_router_advert(struct interface *iface, > const struct in6_addr *fr > memcpy(addrs, iface->addr6, sizeof(*addrs) * > valid_addr_cnt); > > /* Check default route */ > -

Re: [PATCH][netifd] system-linux: initialize ifreq struct before using it

Hi Hans, I have the confirmation, this change fixed my problem. Given the fact that my commit fixes an obvious programming error, I don't think I need to put a detailed explanation in the commit description. BR, Alin On Thu, Oct 8, 2020 at 2:35 PM Alin Năstac wrote: > > Hi Hans, > &g

Re: [PATCH][netifd] system-linux: initialize ifreq struct before using it

Hi Hans, The issue I have involved adding an external device to the lan bridge through add_device ubus call. Sometimes this operation fails to add the new bridge port with the following device debug traces: Wed Oct 7 04:22:57 2020 daemon.err netifd[2843]: device_create_default(525): Create

Re: [OpenWrt-Devel] [PATCH] iproute2: revert add libcap support, enabled in ip-full

On Sun, Mar 15, 2020 at 11:40 PM Mathias Kresin wrote: > > 05/03/2020 23:29, Alin Năstac: > > On Thu, Mar 5, 2020 at 8:34 PM Mathias Kresin wrote: > >> > >> This reverts commit a6da3f9ef746101b84a6f530f5a40de28341b69a. > > > > Not exactly a revert, since

Re: [OpenWrt-Devel] [PATCH] iproute2: revert add libcap support, enabled in ip-full

On Thu, Mar 5, 2020 at 8:34 PM Mathias Kresin wrote: > > This reverts commit a6da3f9ef746101b84a6f530f5a40de28341b69a. Not exactly a revert, since it keeps HAVE_CAP logic. > The libcap isn't as optional as the commit messages suggests. A hard > dependency to the libcap package is added, which

Re: [OpenWrt-Devel] [netifd][PATCH] interface-ip: transfer prefix route ownership to kernel when IPv6 address becomes deprecated

Since it has a different title, I presumed patchwork site will not understand is the 2nd version of previous patch. On Wed, Feb 5, 2020 at 2:39 PM Adrian Schmutzler wrote: > > Hi, > > please use a "v2" next time. > > Best > > Adrian > > > -

Re: [OpenWrt-Devel] [netifd][PATCH] interface-ip: transfer prefix route ownership to kernel when IPv6 address becomes deprecated

Hi Adrian, This patch has been superseded by https://patchwork.ozlabs.org/patch/1233845/ Alin On Wed, Feb 5, 2020 at 1:56 PM Adrian Schmutzler wrote: > > Hi, > > works for me as well. > > However, I'd prefer a shorter commit title, e.g. > > interface-ip: transfer prefix route ownership for

Re: [OpenWrt-Devel] [netifd][PATCH] interface-ip: transfer prefix route ownership to kernel when IPv6 address becomes deprecated

Hi Hans, On Tue, Feb 4, 2020 at 10:49 PM Hans Dedecker wrote: > > Hi Alin, > On Mon, Feb 3, 2020 at 4:27 PM Alin Nastac wrote: > > > > From: Alin Nastac > > > > When netifd manages the prefix route directly, it will remove it > > the moment prefix gets deprecated. This will make it impossible

Re: [OpenWrt-Devel] [PATCH] interface: add IPv6 addresses without IFA_F_NOPREFIXROUTE

On Wed, Dec 18, 2019 at 11:44 AM Alin Nastac wrote: > > When netifd manages the prefix route directly, it will remove it > the moment prefix gets deprecated. This will make it impossible > for the target to send ICMPv6 errors back to LAN devices still > using the deprecated prefix, thus breaking

Re: [OpenWrt-Devel] [PATCH v2] fstools: add a hook before mounting the overlay

On Thu, Oct 24, 2019 at 11:24 PM Karl Palsson wrote: > > > Alin Nastac wrote: > > From: Alin Nastac > > > > Scripts located in the directory /etc/mount_root.d will be > > executed before mounting the overlay. It can be used to > > implement configuration merges between old & new setup after > >

Re: [OpenWrt-Devel] [PATCH] fstools: add a hook before mounting the overlay

On Wed, Oct 9, 2019 at 4:52 PM Alin Năstac wrote: > > On Wed, Oct 9, 2019 at 4:41 PM John Crispin wrote: > > > > > > On 09/10/2019 16:34, Alin Năstac wrote: > > > On Wed, Oct 9, 2019 at 2:59 PM John Crispin wrote: > > >> > > >> On 09/

Re: [OpenWrt-Devel] [PATCH] fstools: add a hook before mounting the overlay

On Wed, Oct 9, 2019 at 4:41 PM John Crispin wrote: > > > On 09/10/2019 16:34, Alin Năstac wrote: > > On Wed, Oct 9, 2019 at 2:59 PM John Crispin wrote: > >> > >> On 09/10/2019 14:41, Alin Nastac wrote: > >>> Scripts located in the directory /lib/moun

Re: [OpenWrt-Devel] [PATCH] firewall3: make reject types selectable by user

On Tue, Jul 3, 2018 at 11:32 PM Philip Prindeville wrote: > > On Jul 3, 2018, at 3:22 PM, Alin Năstac wrote: > > > > On Tue, Jul 3, 2018 at 6:39 PM Philip Prindeville > > wrote: > >> > >> Aren’t all inbound SYNs unsolicited by definition? Is

Re: [OpenWrt-Devel] [PATCH] firewall3: make reject types selectable by user

On Tue, Jul 3, 2018 at 6:39 PM Philip Prindeville wrote: > > Aren’t all inbound SYNs unsolicited by definition? Is there a danger of > reflection attacks? Not all inbound SYNs are unsolicited. Take for instance active mode FTP transfers where the client resides on the LAN . In this case the FTP

Re: [OpenWrt-Devel] [PATCH] procd: service gets deleted when its last instance is freed

Hi John, On Fri, Feb 24, 2017 at 10:53 AM, John Crispin wrote: > can you write a little more info as to why this is needed and what > scenario this fixes/changes ? 1) root@OpenWrt:~# uci show system.ntp system.ntp=timeserver system.ntp.enable_server='0' system.ntp.use_dhcp='1'

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] procd: stop service using SIGKILL if SIGTERM failed to do so

On Thu, Feb 9, 2017 at 11:54 AM, John Crispin wrote: > Hi, > > i know that someone else is about to send a fix for the same issue but > with a different approach of fixing it. i'd like to wait for this 2nd > patch to arrive before we decide which to merge Are you sure it wasn't

Re: [OpenWrt-Devel] procd: service instance restart does not wait for old process to be closed before lanching the new one

Hi John, One of the daemons I use takes sometime a couple of seconds to close after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon restart" there will be 2 instances of that service running in parallel until the initial instance will finally manage to handle the SIGTERM signal. This

[OpenWrt-Devel] procd: service instance restart does not wait for old process to be closed before lanching the new one

Hi John, One of the daemons I use takes sometime a couple of seconds to close after receiving SIGTERM, so when I issue "/etc/init.d/mydaemon restart" there will be 2 instances of that service running in parallel until the initial instance will finally manage to handle the SIGTERM signal. This

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau <n...@nbd.name> wrote: > On 2017-02-03 15:57, Alin Năstac wrote: >> Hi Felix, >> >> The SIGTERM ignore issue I was experiencing before is no longer >> reproducible after I apply your patch. >> >> H

Re: [OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

cursive_calls++) { uloop_status = 0; uloop_cancelled = false; uloop_setup_signals(true); } Cheers, Alin On Fri, Feb 3, 2017 at 2:47 PM, Felix Fietkau <n...@nbd.name> wrote: > Hi Alin, > > On 2017-02-03 09:29, Alin Năstac wrote: >> Hi Felix, >&

[OpenWrt-Devel] ubus/libubox: SIGTERM/SIGINT signals received during ubus_complete_request() calls are ignored

Hi Felix, SIGTERM & SIGINT signals received during ubus_complete_request() waiting for ubus_poll_data() to return are ignored due to uloop_cancelled being restored to its previous value it had before uloop_poll_data() was called. The reproduction scenario is this: 1) cancelled local variable

Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH] conntrack: enable support for netfilter conntrack zones

Hi Jo, You have my ACK. ;) Sorry about that, I will sign my patches from now on. BR, Alin On Thu, May 19, 2016 at 6:21 PM, Jo-Philipp Wich wrote: > Hi Alin, > > I merged your patch into my staging tree at > >

Re: [OpenWrt-Devel] [PATCH firewall] zones : Redirect incoming WAN traffic only when the destination IP address matches the IP masquerading address

Here is the original description I gave to my patch (see http://patchwork.ozlabs.org/patch/516167/): Basically it prevents zone_wan_prerouting rules to affect traffic towards IP addresses that are not used for masquerading LAN private IP space and it does that by setting destination IP address of

[OpenWrt-Devel] [PATCH] [package] firewall: Redirect incoming WAN traffic only when destination IP address matches the IP address used for masquerading

This is a git patch for the firewall3 git repo at git://nbd.name/firewall3.git Basically it prevents zone_wan_prerouting rules to affect traffic towards IP addresses that are not used for masquerading LAN private IP space and it does that by setting destination IP address of the