Re: [LEDE-DEV] A state of network acceleration / test on Archer C7 v4
On Wed, 2018-01-17 at 19:30 +0100, Pablo Neira Ayuso wrote: > Hi Rafal, > > On Wed, Jan 17, 2018 at 04:25:10PM +0100, Rafał Miłecki wrote: > > Getting better network performance (mostly for NAT) using some kind > > of > > acceleration was always a hot topic and people are still > > looking/asking for it. I'd like to write a short summary and share > > my > > understanding of current state so that: > > 1) People can undesrtand it better > > 2) We can have some rough plan > > > > First of all there are two possible ways of accelerating network > > traffic: in software and in hardware. Software solution is > > independent > > of architecture/device and is mostly just bypassing in-kernel > > packets > > flow. It still uses device's CPU which can be a bottleneck. Various > > software implementations are reported to be faster from 2x to 5x. > > This is what I've been observing for the software acceleration here, > see slide 19 at: > > https://www.netdevconf.org/2.1/slides/apr8/ayuso-netdev-netfilter-upd > ates-canada-2017.pdf > > The flowtable representation, in software, is providing a faster > forwarding path between two nics. So it's basically an alternative to > the classic forwarding path, that is faster. Packets kick in at the > Netfilter ingress hook (right at the same location as 'tc' ingress), > if there is a hit in the software flowtable, ttl gets decremented, > NATs are done and the packet is placed in the destination NIC via > neigh_xmit() - through the neighbour layer. Hi Pablo, I tested today a few things on a brand new TP-Link Archer C7 v4.0, LAN client Dell Latitude 7480 (eth I219-LM, wifi 8265 / 8275) WAN server NUC5i3RYB (eth I218-V), NAT between them, <1 ms latency (everything on the same table), IPv4 unless specified, using iperf3 LAN=>WAN and -R for WAN=>LAN (both TCP). With the TP-Link firmware: - wired 930+ Mbit/s both ways - wireless 5G 560+ Mbit/s down 440+ Mbit/s up - wireless 2.4G 100+ Mbit/s both ways With OpenWRT/LEDE trunk 20180128 4.4 kernel: - wired 350-400 Mbit/s both ways - wired with firewall deactivated 550 Mbit/s (just "iptables -t nat -A POSTROUTING -j MASQUERADE") - wired IPv6 routing, no NAT, no firewall 250 Mbit/s - wireless 5G 150-200 Mbit/s - wireless 2.4G forgot to test top on the router shows sirq at 90%+ during network load, other load indicators are under 5%. IPv6 performance without NAT being below IPv4 with NAT seems to indicate there are potential gains in software :). I didn't test OpenWRT in bridge mode but I got with LEDE 17.01 on an Archer C7 v2 about 550-600 Mbit/s iperf3 so I think radio is good on these ath10k routers. So if OpenWRT can do about x2 in software routing performance we're good against our TP-Link firmware friends :). tetaneutral.net (not-for-profit ISP, hosting OpenWRT and LEDE mirror in FR) is going to install 40+ Archer C7 v4 running OpenWRT as CPE, each with individual gigabit fiber uplink (TP-Link MC220L fiber converter), and total 10G uplink (Dell/Force10 S4810 48x10G, yes some of our members will get 10G on their PC at home :). We build our images from git source, generating imagebuilder and then a custom python script. We have 5+ spare C7, fast build (20mn from scratch) and testing environment, and of course we're interested in suggestions on what to do. Thanks in advance for your help, Sincerely, Laurent http://tetaneutral.net ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A state of network acceleration / test on Archer C7 v4
Hi Michael, On Sun, 2018-01-28 at 17:09 -0500, Michael Richardson wrote: > Laurent GUERBY wrote: > > I tested today a few things on a brand new TP-Link Archer C7 > v4.0, > > LAN client Dell Latitude 7480 (eth I219-LM, wifi 8265 / 8275) > > WAN server NUC5i3RYB (eth I218-V), NAT between them, <1 ms > latency > > (everything on the same table), IPv4 unless specified, > > using iperf3 LAN=>WAN and -R for WAN=>LAN (both TCP). > > > With the TP-Link firmware: > > - wired 930+ Mbit/s both ways > > - wireless 5G 560+ Mbit/s down 440+ Mbit/s up > > - wireless 2.4G 100+ Mbit/s both ways > > > With OpenWRT/LEDE trunk 20180128 4.4 kernel: > > - wired 350-400 Mbit/s both ways > > - wired with firewall deactivated 550 Mbit/s > > (just "iptables -t nat -A POSTROUTING -j MASQUERADE") > > That still means you have conn-tracking loaded. > Have you tried without that? What should I do to enable NAT without conn-tracking? (I see a few nf_conntrack* modules in lsmod) > > - wired IPv6 routing, no NAT, no firewall 250 Mbit/s > > - wireless 5G 150-200 Mbit/s > > - wireless 2.4G forgot to test > > Does the TP-Link firmware support any IPv6? > You could report 0Mb/s for IPv6 :-) TP-Link has now added full IPv6 support AFAIK. I will test it and report when I get my hand on another spare. > > IPv6 performance without NAT being below IPv4 with NAT seems > > to indicate there are potential gains in software :). > > Depends upon whether there is hardware support for NAT, > which many devices have, wrapped up under NDAs. I don't think OpenWRT has support for NAT accelerators at this point, IPv4 and IPv6 are both done in software. Sincerely, Laurent > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works| network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/| ruby on > rails[ > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] A state of network acceleration / test on Archer C7 v4
On Sun, 2018-01-28 at 19:12 -0500, Michael Richardson wrote: > Laurent GUERBY wrote: > > On Sun, 2018-01-28 at 17:09 -0500, Michael Richardson wrote: > >> Laurent GUERBY wrote: > >> > I tested today a few things on a brand new TP-Link > Archer C7 > >> v4.0, > >> > LAN client Dell Latitude 7480 (eth I219-LM, wifi 8265 / > 8275) > >> > WAN server NUC5i3RYB (eth I218-V), NAT between them, <1 > ms > >> latency > >> > (everything on the same table), IPv4 unless specified, > >> > using iperf3 LAN=>WAN and -R for WAN=>LAN (both TCP). > >> > >> > With the TP-Link firmware: > >> > - wired 930+ Mbit/s both ways > >> > - wireless 5G 560+ Mbit/s down 440+ Mbit/s up > >> > - wireless 2.4G 100+ Mbit/s both ways > >> > >> > With OpenWRT/LEDE trunk 20180128 4.4 kernel: > >> > - wired 350-400 Mbit/s both ways > >> > - wired with firewall deactivated 550 Mbit/s > >> > (just "iptables -t nat -A POSTROUTING -j MASQUERADE") > >> > >> That still means you have conn-tracking loaded. > >> Have you tried without that? > > > What should I do to enable NAT without conn-tracking? > > (I see a few nf_conntrack* modules in lsmod) > > Unfortunately, you don't. > > It's also hard to get rid of the conntrack modules, other than > clearing > everything and then rmmod'ing them. Sometimes I've had to rename the > .ko > files and reboot to get rid of them. > > So that means that you have to do the performance testing for routing > between two subnets. Hi, With wired, firewall off and using routing (no MASQUERADE, explicit LAN route added on the NUC via WAN IP): - IPv4 590+ Mbit/s up and 690+ Mbit/s down - IPv6 270+ Mbit/s same both ways So without NAT/conntrack we gain about 50% on IPv4 and we're closer to line rate. For the record I tested without the router to check iperf3 my setup and IPv4 and IPv6 are 910+ Mbit/s both ways. Sincerely, Laurent PS: kernel is 4.9.77 on the archer (not 4.4, thinko in my first mail) NUC and laptop are running 4.9 debian stretch too. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: LEDE mirror from RCS&RDS Romania / tetaneutral.net in France
On Fri, 2016-05-06 at 12:41 +0300, Daniel Petre wrote: > Hello, so per jow's last night's info i have rsynced the downloads part > from LEDE to the RCS&RDS ( www.rcs-rds.ro ) mirroring server: > > http://mirrors.linux.ro/lede/ > > Two more questions please: > > 1. How often can we rsync? > 2. Do you need anything else rsynced? > > Thanks! > > P.S. Contact e-mail for the mirror should be daniel.pe...@rcs-rds.ro > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev Hi, Another mirror is up here: http://lede-project.tetaneutral.net/ http://lede-project.tetaneutral.net/README.txt Mirror of by http://downloads.lede-project.org/ by not-for-profit http://tetaneutral.net IPv4 + IPv6 10 gigabit+ AS197422 network in Toulouse, France In case of issue (corrupted or missing file) please mail lede-project-contact AT tetaneutral DOT net With the same questions :) Laurent ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] raising rsync bwlimit ? was: LEDE mirror from RCS&RDS Romania
On Wed, 2016-05-11 at 02:17 +0300, Daniel Petre wrote: > On 05/06/2016 12:41 PM, Daniel Petre wrote: > > Hello, so per jow's last night's info i have rsynced the downloads part > > from LEDE to the RCS&RDS ( www.rcs-rds.ro ) mirroring server: > > > > http://mirrors.linux.ro/lede/ > > > > Two more questions please: > > > > 1. How often can we rsync? > > Seems i cannot resync so often since the original point has insufficient > bandwidth so far.. > I will try again when LEDE has a better connection, until then i will > rsync daily. Hi, I noticed rsync is about 750 kbyte/s whereas wget (on the same file) gets > 20 Mbyte/s so I assume there's a bwlimit on the rsync server that is not there on the web server, and that LEDE has a good connection. If I'm right I think it would be better to raise the rsync bwlimit. Sincerely, Laurent PS: thanks for having listed the mirrors :) https://www.lede-project.org/downloads.html We have now enabled rsync in addition to WWW. ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] Test farm for routers / tetaneutral.net
Hi, The not-for-profit ISP tetaneutral.net would like to provide a hardware test farm for small routers in addition to the LEDE mirror (and GCC Compile Farm machines hosting, RIPE probe, NLNOG ring VM), as we use OpenWRT/LEDE for all of our member "internet box" (1) Has anyone made and documented such a setup? I can think of: - ssh access to the gateway with LAN services (DHCP/RA/VLAN trunk) - switch with per port configurable VLAN (doc for what is plugged where) - client/server machines to generate LAN/WAN traffic - remote power control - remote push button control - webcam view (for LEDs) - remote serial (soldering needed) - local build servers Other things? We can start small with TP-Link TL-WR841N v11.1 which works well with LEDE snapshort (wifi+LAN+WAN v4/v6) but has (cosmetics) LEDs not working :). We have pile of hardware for our needs (TP-Link, Ubiquity, Mikrotik, Netonix, ...) and have budget of around 1500 EUR per month free to invest on what we want (1). Sincerely Laurent AS197422 http://tetaneutral.net (1) Our imagebuilder based scripts https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools/revisions/master/entry/quick_841n_ttn_lede.sh (2) We're transparent about it: https://chiliproject.tetaneutral.net/projects/tetaneutral/wiki/Inventaire https://tetaneutral.net/#Transparence http://pad.tetaneutral.net/p/budget2016 http://pad.tetaneutral.net/p/stock ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] TP-Link TL-WR841N v11.1 hardware led change vs v8/9/10
Hi,
TP-Link TL-WR841N is now at version "11.1" in stores and the
number of leds of the device changed: the "system" led is gone and the
"wan" led seems to be able to be green or orange.
The antennas are also slightly different (a bit longer).
I flashed it with LEDE snapshot "v11".
Just after power on:
http://guerby.org/ftp/IMG_20160528_181137.jpg
A bit later:
http://guerby.org/ftp/IMG_20160528_181155.jpg
After LEDE (snapshot) boot is done :
http://guerby.org/ftp/IMG_20160528_180545.jpg
Notice that the power LED is off.
The two hardware buttons (wifi and reset/wps) seem to have their
normal function. network/wifi seem to be working fine.
Following
https://wiki.openwrt.org/doc/devel/add.new.device
I could get the power and wan "orange/green" control GPIO:
GPIO 1 : power led 0 => green, 1 => off
GPIO 2 : wan led 0 => change color to orange, 1 => back to green
GPIO/LED seems to be defined here:
source/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c
I can provide ssh remote access to the hardware + webcam on the LED,
ping me on IRC.
Sincerely,
Laurent ("guerby" on IRC)
root@lede:/sys/class/gpio# cat /tmp/sysinfo/*
tl-wr841n-v9
TP-Link TL-WR841N/ND v11
root@lede:/sys/class/gpio# cat /tmp/gpiod.sh
#!/bin/sh
GPIOCHIP=0
BASE=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/base)
NGPIO=$(cat /sys/class/gpio/gpiochip${GPIOCHIP}/ngpio)
max=$(($BASE+$NGPIO))
gpio=$BASE
while [ $gpio -lt $max ] ; do
echo $gpio > /sys/class/gpio/export
[ -d /sys/class/gpio/gpio${gpio} ] && {
echo in > /sys/class/gpio/gpio${gpio}/direction
echo "[GPIO${gpio}] value $(cat /sys/class/gpio/gpio
${gpio}/value)"
echo ${gpio} > /sys/class/gpio/unexport
}
gpio=$((gpio+1))
done
root@lede:/sys/class/gpio# /tmp/gpiod.sh
[GPIO0] value 0
[GPIO1] value 0
[GPIO2] value 0
sh: write error: Resource busy
sh: write error: Resource busy
[GPIO5] value 1
[GPIO6] value 1
[GPIO7] value 0
[GPIO8] value 0
[GPIO9] value 0
[GPIO10] value 1
sh: write error: Resource busy
sh: write error: Resource busy
sh: write error: Resource busy
sh: write error: Resource busy
sh: write error: Resource busy
sh: write error: Resource busy
sh: write error: Resource busy
root@lede:/sys/class/gpio# GPIO=1;echo $GPIO > export;echo "out" > gpio
$GPIO/direction;echo 0 > gpio$GPIO/value;sleep 1s;echo 1 > gpio
$GPIO/value;sleep 1s;echo $GPIO > unexport
root@lede:/sys/class/gpio# GPIO=2;echo $GPIO > export;echo "out" > gpio
$GPIO/direction;echo 0 > gpio$GPIO/value;sleep 1s;echo 1 > gpio
$GPIO/value;sleep 1s;echo $GPIO > unexport
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] ImageBuilder generated image does not create LED entries in /etc/config/system on first boot, why?
Hi, On a 841N v11 on current LEDE git with patch from (1) I'm trying to solve a puzzle: - when doing "make" the generated image in bin/targets/ar71xx/generic/lede-ar71xx-generic-tl-wr841-v11-squashfs-sysupgrade.bin does create on first boot /etc/config/system 'led' entries and so the LED work as expected - whe using a script (2) based on the imagebuilder generated by the same "make" build (menuconfig activated) bin/targets/ar71xx/generic/LEDE-ImageBuilder-ar71xx-generic.Linux-x86_64.tar.bz2 the image works but /etc/config/system is not populated with 'led' entries on first boot (or second boot I tried) so the LAN/WAN LED stay off (only power LED is on). If I populate manually /etc/config/system all works. I couldn't find what script running on the router which generates the /etc/config/system led entries on first boot (where to look to debug this issue), I assume something is missing flag or package or kernel module in my imagebuilder (or make menuconfig) setup but I'm not able to find it. I did not have this issue with older versions of OpenWRT imagebuilder. Any help appreciated, Sincerely, Laurent (1) https://github.com/lede-project/source/pull/64 (2) https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools/revisions/master/entry/quick_841n_ttn_lede.sh ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] ImageBuilder generated image does not create LED entries in /etc/config/system on first boot, why?
On Tue, 2016-05-31 at 00:39 +0200, Laurent GUERBY wrote:
> Hi,
>
> On a 841N v11 on current LEDE git with patch from (1) I'm trying to
> solve a puzzle:
> - when doing "make" the generated image in
> bin/targets/ar71xx/generic/lede-ar71xx-generic-tl-wr841-v11-squashfs-sysupgrade.bin
> does create on first boot /etc/config/system 'led' entries and so
> the LED work as expected
> - whe using a script (2) based on the imagebuilder generated by the same
> "make" build (menuconfig activated)
> bin/targets/ar71xx/generic/LEDE-ImageBuilder-ar71xx-generic.Linux-x86_64.tar.bz2
> the image works but /etc/config/system is not populated with 'led'
> entries on first boot (or second boot I tried) so the LAN/WAN LED stay
> off (only power LED is on). If I populate manually /etc/config/system
> all works.
>
> I couldn't find what script running on the router which generates
> the /etc/config/system led entries on first boot (where to look to debug
> this issue), I assume something is missing flag or package or kernel
> module in my imagebuilder (or make menuconfig) setup but I'm not able to
> find it. I did not have this issue with older versions of OpenWRT
> imagebuilder.
>
> Any help appreciated,
>
> Sincerely,
>
> Laurent
>
> (1) https://github.com/lede-project/source/pull/64
> (2)
> https://chiliproject.tetaneutral.net/projects/git-tetaneutral-net/repository/openwrt-tools/revisions/master/entry/quick_841n_ttn_lede.sh
Hi again,
Thanks to jow on IRC for pointing out /bin/board_detect which
has a test on /etc/config/network to decide wether or not to call
config_generate which creates the /etc/config/system
LED (amongst other things).
Since we use imagebuilder with FILES="..." to
generate /etc/config/network (and other things) for our WISP setup the
led configuration wasn't generated on first boot.
I assume a solution will be proposed soon.
Sincerely,
Laurent
root@lede:~# cat /bin/board_detect
#!/bin/sh
[ -d "/etc/board.d/" -a ! -f "/etc/board.json" ] && {
for a in `ls /etc/board.d/*`; do
[ -x $a ] || continue;
$(. $a)
done
}
[ -f "/etc/board.json" ] || return 1
[ -f "/etc/config/network" ] || {
touch /etc/config/network
/bin/config_generate
}
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dropbear: Add IPPort parameter
The new IPPort parameter allows to pass unchanged parameters to dropbear,
dropbear uses -p [ip6]:port for IPv6 and this was not supported with
existing scripts.
Signed-off-by: Laurent GUERBY
---
package/network/services/dropbear/files/dropbear.init | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dropbear/files/dropbear.init
b/package/network/services/dropbear/files/dropbear.init
index 5c3345d..867efd8 100755
--- a/package/network/services/dropbear/files/dropbear.init
+++ b/package/network/services/dropbear/files/dropbear.init
@@ -41,7 +41,8 @@ validate_section_dropbear()
'Port:list(port):22' \
'SSHKeepAlive:uinteger:300' \
'IdleTimeout:uinteger:0' \
- 'mdns:uinteger:1'
+ 'mdns:uinteger:1' \
+ 'IPPort:string'
}
dropbear_instance()
@@ -75,7 +76,11 @@ dropbear_instance()
[ "${RootLogin}" -eq 0 ] && procd_append_param command -w
[ -n "${rsakeyfile}" ] && procd_append_param command -r "${rsakeyfile}"
[ -n "${BannerFile}" ] && procd_append_param command -b "${BannerFile}"
- append_ports "${ipaddrs}" "${Port}"
+ if [ -n "${IPPort}" ];
+ procd_append_param command -p "${IPPort}"
+else
+ append_ports "${ipaddrs}" "${Port}"
+fi
[ "${IdleTimeout}" -ne 0 ] && procd_append_param command -I
"${IdleTimeout}"
[ "${SSHKeepAlive}" -ne 0 ] && procd_append_param command -K
"${SSHKeepAlive}"
[ "${mdns}" -ne 0 ] && procd_add_mdns "ssh" "tcp" "$Port"
"daemon=dropbear"
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dropbear: Fix append_port in IPv6 case
dropbear uses -p [ip6%phy]:port syntax, now correctly handled by append_port.
Signed-off-by: Laurent GUERBY
---
package/network/services/dropbear/files/dropbear.init | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/package/network/services/dropbear/files/dropbear.init
b/package/network/services/dropbear/files/dropbear.init
index 5c3345d..d04df44 100755
--- a/package/network/services/dropbear/files/dropbear.init
+++ b/package/network/services/dropbear/files/dropbear.init
@@ -16,13 +16,21 @@ append_ports()
{
local ipaddrs="$1"
local port="$2"
+ local iface="$3"
+ local phy
[ -z "$ipaddrs" ] && {
procd_append_param command -p "$port"
return
}
+ network_get_physdev phy "$iface"
+
for addr in $ipaddrs; do
+ case "$addr" in
+ *:*) dropbear_addr="[$addr%$phy]";;
+ *) dropbear_addr="$addr";;
+ esac
procd_append_param command -p "$addr:$port"
done
}
@@ -75,7 +83,7 @@ dropbear_instance()
[ "${RootLogin}" -eq 0 ] && procd_append_param command -w
[ -n "${rsakeyfile}" ] && procd_append_param command -r "${rsakeyfile}"
[ -n "${BannerFile}" ] && procd_append_param command -b "${BannerFile}"
- append_ports "${ipaddrs}" "${Port}"
+ append_ports "${ipaddrs}" "${Port}" "${Interface}"
[ "${IdleTimeout}" -ne 0 ] && procd_append_param command -I
"${IdleTimeout}"
[ "${SSHKeepAlive}" -ne 0 ] && procd_append_param command -K
"${SSHKeepAlive}"
[ "${mdns}" -ne 0 ] && procd_add_mdns "ssh" "tcp" "$Port"
"daemon=dropbear"
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
[LEDE-DEV] [PATCH] dropbear: Fix append_port in IPv6 case (v2)
The new IPPort parameter allows to pass unchanged parameters to dropbear,
dropbear uses -p [ip6]:port for IPv6 and this was not supported with
existing scripts.
Fix indentation and missing then of previous patch.
Signed-off-by: Laurent GUERBY
---
package/network/services/dropbear/files/dropbear.init | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/package/network/services/dropbear/files/dropbear.init
b/package/network/services/dropbear/files/dropbear.init
index 5c3345d..c4d6c78 100755
--- a/package/network/services/dropbear/files/dropbear.init
+++ b/package/network/services/dropbear/files/dropbear.init
@@ -41,7 +41,8 @@ validate_section_dropbear()
'Port:list(port):22' \
'SSHKeepAlive:uinteger:300' \
'IdleTimeout:uinteger:0' \
- 'mdns:uinteger:1'
+ 'mdns:uinteger:1' \
+ 'IPPort:string'
}
dropbear_instance()
@@ -75,7 +76,11 @@ dropbear_instance()
[ "${RootLogin}" -eq 0 ] && procd_append_param command -w
[ -n "${rsakeyfile}" ] && procd_append_param command -r "${rsakeyfile}"
[ -n "${BannerFile}" ] && procd_append_param command -b "${BannerFile}"
- append_ports "${ipaddrs}" "${Port}"
+ if [ -n "${IPPort}" ]; then
+ procd_append_param command -p "${IPPort}"
+ else
+ append_ports "${ipaddrs}" "${Port}"
+ fi
[ "${IdleTimeout}" -ne 0 ] && procd_append_param command -I
"${IdleTimeout}"
[ "${SSHKeepAlive}" -ne 0 ] && procd_append_param command -K
"${SSHKeepAlive}"
[ "${mdns}" -ne 0 ] && procd_add_mdns "ssh" "tcp" "$Port"
"daemon=dropbear"
--
2.1.4
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] [PATCH] dropbear: Fix append_port in IPv6 case (v2)
On Thu, 2016-07-28 at 07:07 +0200, John Crispin wrote:
>
> On 09/07/2016 23:55, Laurent GUERBY wrote:
> > The new IPPort parameter allows to pass unchanged parameters to dropbear,
> > dropbear uses -p [ip6]:port for IPv6 and this was not supported with
> > existing scripts.
> >
> > Fix indentation and missing then of previous patch.
> >
> > Signed-off-by: Laurent GUERBY
> > ---
> > package/network/services/dropbear/files/dropbear.init | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/package/network/services/dropbear/files/dropbear.init
> > b/package/network/services/dropbear/files/dropbear.init
> > index 5c3345d..c4d6c78 100755
> > --- a/package/network/services/dropbear/files/dropbear.init
> > +++ b/package/network/services/dropbear/files/dropbear.init
> > @@ -41,7 +41,8 @@ validate_section_dropbear()
> > 'Port:list(port):22' \
> > 'SSHKeepAlive:uinteger:300' \
> > 'IdleTimeout:uinteger:0' \
> > - 'mdns:uinteger:1'
> > + 'mdns:uinteger:1' \
> > + 'IPPort:string'
> > }
>
> Hi,
>
> maybe ipaddrs6 and Port6 might be better ? depending the choice of v4 vs
> v6 on the name of the port parameter seems odd, specially as it is not
> named in a consistent manner.
>
> John
Hi,
I chose IPPort because the option is not specific to v6 : it just
tells the script system to pass an unmodified "-p" argument to dropbear.
The current Port option if not given an IP will listen
on both v4 and v6 (that's what make it currently "work"
in v6). Making Port work only in IPv4 is quite a bit more
work, you have to get all the IPv4 and pass them as "-p IPv4:port"
(and it will change the current behaviour).
But may be I'm misunderstanding your proposal?
Sincerely,
Laurent
>
> >
> > dropbear_instance()
> > @@ -75,7 +76,11 @@ dropbear_instance()
> > [ "${RootLogin}" -eq 0 ] && procd_append_param command -w
> > [ -n "${rsakeyfile}" ] && procd_append_param command -r "${rsakeyfile}"
> > [ -n "${BannerFile}" ] && procd_append_param command -b "${BannerFile}"
> > - append_ports "${ipaddrs}" "${Port}"
> > + if [ -n "${IPPort}" ]; then
> > + procd_append_param command -p "${IPPort}"
> > + else
> > + append_ports "${ipaddrs}" "${Port}"
> > + fi
> > [ "${IdleTimeout}" -ne 0 ] && procd_append_param command -I
> > "${IdleTimeout}"
> > [ "${SSHKeepAlive}" -ne 0 ] && procd_append_param command -K
> > "${SSHKeepAlive}"
> > [ "${mdns}" -ne 0 ] && procd_add_mdns "ssh" "tcp" "$Port"
> > "daemon=dropbear"
> >
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
