On Mon, Apr 30, 2018 at 7:58 AM, John Crispin wrote:
>
>
> On 27/04/18 16:05, Alin Năstac wrote:
>>
>> According to "Automatic variables" chapter of make manual, $* expands
>> to the pattern matched by % in an implicit rule.
>> However, the make rules in
According to "Automatic variables" chapter of make manual, $* expands
to the pattern matched by % in an implicit rule.
However, the make rules in which this patch use the $* variable is an
explicit rule, hence $* expansion will be empty.
On Fri, Apr 27, 2018 at 8:41 AM, John Crispin wrote:
>
>
>
Hi John,
I forced CONFIG_NETFILTER_XT_MATCH_STATISTIC=y in my kernel config by
adding it to openwrt/target/linux/brcm63xx/config-4.1 .
However, you have to do a complete build from scratch, I noticed that
removing iptables build directory and related files in
openwrt/staging_dir/target-*/pkginfo d
Hi Jo,
The idea is to fix log issues created by chains such as these:
iptables -S zone_lan_forward
-A zone_lan_forward -m comment --comment "!fw3: user chain for
forwarding" -j forwarding_lan_rule
-A zone_lan_forward -m comment --comment "!fw3: drop_lan_2_guest" -j
zone_guest_dest_DROP
-A zone_lan
Hi Felix,
A setup using an l2tp interface that connects to an on-link L2TP
server stopped working after cherry picking this netifd commit:
authorFelix Fietkau
Thu, 8 Mar 2018 00:14:57 +0200 (23:14 +0100)
commit1f5a29c3de6e3fec5883796ee772e25d56db6a69
ip: do not add local r
Hi Jo,
On Mon, May 22, 2017 at 9:17 AM, Jo-Philipp Wich wrote:
> wouldn't it be simpler to introduce hashlimit support for ordinary rules
> instead?
>
> Is there a particular reason for a separate chain and a separate section
> type?
The goal is to protect against a denial of service. The device
Hi Jo,
I need to add flood protection feature to firewall.
The ratelimit section parameters would be: proto, src_port, dest_port,
family, global_limit, global_burst, per_srcip_limit, per_srcip_burst,
per_srcip_mask, per_srcip_buckets. These rules will have effect on a
raw table user chain called
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'
system.ntp.dhcp_in
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 me? :)
You said yes
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 daem
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 daem
On Fri, Feb 3, 2017 at 4:19 PM, Felix Fietkau 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.
>>
>> However, I'm concern
(!recursive_calls++) {
uloop_status = 0;
uloop_cancelled = false;
uloop_setup_signals(true);
}
Cheers,
Alin
On Fri, Feb 3, 2017 at 2:47 PM, Felix Fietkau wrote:
> Hi Alin,
>
> On 2017-02-03 09:29, Alin Năstac wrote:
>> Hi Felix,
>>
>
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 is
Hi Jo,
I've submitted this patch upstream, see
https://bugzilla.netfilter.org/show_bug.cgi?id=1075 .
BR,
Alin
On Fri, Jun 24, 2016 at 2:44 PM, Jo-Philipp Wich wrote:
> Hi Alin,
>
> is there some upstream reference we can refer to? Did you submit it
> there as well?
>
> Regards,
> Jo
>
> __
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
>
> https://git.lede-project.org/?p=lede/jow/staging.git;a=commitdiff;h=6c9231baa9c5341c6e
16 matches
Mail list logo
