Not sure if the maillist will accept tar attachment.
Attached.
From: Jiri Slachta
To: Ming-Ching Tiew ; OpenWrt Development List
Sent: Wednesday, May 1, 2013 12:13 AM
Subject: Re: [OpenWrt-Devel] Anyone working on having libpri, dahdi-linux and
dahdi
I tried the asterisk 11 feeds on the trunk.
Noticed that it does not have dahdi-linux, dahdi-tools and libpri.
Anyone currently working on or plan to work on these ?
I cook up some make files for it but because of limited knowledge on the make
files, the significance of various variables and di
Thunderbird is buggy and diffcult to use. it is hard to send a plain text email.
anyway, i found the patch can be reviewed at
http://patchwork.openwrt.org/patch/2112/
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.o
On Sunday, April 22, 2012 01:44 AM,
openwrt-devel-requ...@lists.openwrt.org wrote:
--
Date: Sat, 21 Apr 2012 20:54:44 +0800
From: ching
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] base-files: implement new config
&qu
..@lists.openwrt.org wrote:
--
Date: Sat, 21 Apr 2012 20:54:44 +0800
From: ching
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] base-files: implement new config
"root_readonly" (RESENT)
Message-ID:<4f92ae14@gmail.com>
d flashing.
root_readonly=0 #0 - root will be read-write, 1 - root will be read-only
Assumption
1. Early boot process do not trigger unnecessary flashing
2. default setting=0 (read-write) to preserve backward compatibility
3. user know how to remount root rw manually if he/she set this option
Signed-off-by:
d flashing.
root_readonly=0 #0 - root will be read-write, 1 - root will be read-only
Assumption
1. Early boot process do not trigger unnecessary flashing
2. default setting=0 (read-write) to preserve backward compatibility
3. user know how to remount root rw manually if he/she set this option
Signed-off-by:
rules exist for other ICMP packet.
5. remove limit 1000 to avoid possible denial of service (attacker
can stop all ICMP traffic by sending more than 1000 ICMP packet/s)
As I already mentioned in the ticket, instead of removing the limit, I'd
rather see hashlimits implemented, that rate-li
d possible denial of service (attacker
can stop all ICMP traffic by sending more than 1000 ICMP packet/s)
As I already mentioned in the ticket, instead of removing the limit, I'd
rather see hashlimits implemented, that rate-limit the traffic per host
or prefix.
answered you at the ticket.
4. Allow most icmpv6 neighbour discovery traffic as kernel will enforce
"hop-limit=255" rule (packet is not forwarded)
5. remove limit 1000 to avoid possible denial of service (attacker can
stop all ICMP traffic by sending more than 1000 ICMP packet/s)
Signed-off-by: ching
1 files changed
10 matches
Mail list logo
