Re: [OpenWrt-Devel] [PATCH] openwrt/hardening: Fix CFLAGS usage for -D_FORTIFY_SOURCE
Hi Am 07.09.2015 um 17:32 schrieb Helmut Schaa: > Fix the following configure error with c-ares by using CPPFLAGS for > -D_FORTIFY_SOURCE. > Not sure if any other packages suffer from the same issue. > > configure: using CFLAGS: -Os -pipe -march=74kc -fno-caller-saves > -mno-branch-likely -g3 -fno-caller-saves -fhonour-copts > -Wno-error=unused-but-set-variable -msoft-float -D_FORTIFY_SOURCE=1 > -Wl,-z,now -Wl,-z,relro > configure: CFLAGS error: CFLAGS may only be used to specify C compiler flags, > not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=1 > configure: error: Can not continue. Fix errors mentioned immediately above > this line. Did you get this in the CC branch? According to https://github.com/openwrt/packages/pull/1464 this should be fixed in master and applying this patch on top of the CC branch worked for me. With kind regards Stefan Peter ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openwrt/hardening: Fix CFLAGS usage for -D_FORTIFY_SOURCE
On Mon, Sep 7, 2015 at 6:19 PM, Steven Barth wrote: > NAK. > Not many package build systems honors CPPFLAGS so this solution is > impractical, > since it effectively disables fortification for many of them. > > To my knowledge c-ares is the only package enforcing this kind of behavior > so it should be fixed to work with our buildsystem instead. Thanks for the info. Please drop this patch then ... Helmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openwrt/hardening: Fix CFLAGS usage for -D_FORTIFY_SOURCE
On Tue, Sep 8, 2015 at 9:03 AM, Stefan Peter wrote: > Hi > Am 07.09.2015 um 17:32 schrieb Helmut Schaa: >> Fix the following configure error with c-ares by using CPPFLAGS for >> -D_FORTIFY_SOURCE. >> Not sure if any other packages suffer from the same issue. >> >> configure: using CFLAGS: -Os -pipe -march=74kc -fno-caller-saves >> -mno-branch-likely -g3 -fno-caller-saves -fhonour-copts >> -Wno-error=unused-but-set-variable -msoft-float -D_FORTIFY_SOURCE=1 >> -Wl,-z,now -Wl,-z,relro >> configure: CFLAGS error: CFLAGS may only be used to specify C compiler >> flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=1 >> configure: error: Can not continue. Fix errors mentioned immediately above >> this line. > > Did you get this in the CC branch? > > According to > https://github.com/openwrt/packages/pull/1464 > this should be fixed in master and applying this patch on top of the CC > branch worked for me. I came up with a similar patch now :) but good to know it's fixed in master already. Helmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Removing Telnet
Hello everyone, as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of the base images. As a replacement, it is now possible to login to the root- account via SSH without a password prompt whenever no root password is set, e.g. after a flash without keeping config, factory reset or in failsafe. We will see how that goes. Let us know if there are any issues. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fwd: Removing Telnet
Is slow login still present on ssh? Because we had problem, that ssh login takes about 10seconds and telnet is instant. It is difference if we do initial bulk setup for more devices. If I login to my pc, ssh login takes <1sec. Thanks for reply. -- S pozdravom Jakub Janco 2015-09-08 10:15 GMT+02:00 Steven Barth : > Hello everyone, > > as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of > the base images. As a replacement, it is now possible to login to the root- > account via SSH without a password prompt whenever no root password is set, > e.g. after a flash without keeping config, factory reset or in failsafe. > > We will see how that goes. Let us know if there are any issues. > > > Cheers, > > Steven > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Restore 640-bridge_no_eap_forward.patch to its original form
Restore 640-bridge_no_eap_forward.patch to its original form.
It was corrupted in rev 62a2176cb144. The most obvious symptom is repeated
messages like this:
Tue Sep 8 08:25:18 2015 kern.warn kernel: [77141.972226] br-lan: received
packet on wlan0 with own address as source address
Signed-off-by: Dmitry Ivanov
---
target/linux/generic/patches-3.18/640-bridge_no_eap_forward.patch | 2 +-
target/linux/generic/patches-4.0/640-bridge_no_eap_forward.patch | 2 +-
target/linux/generic/patches-4.1/640-bridge_no_eap_forward.patch | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/generic/patches-3.18/640-bridge_no_eap_forward.patch
b/target/linux/generic/patches-3.18/640-bridge_no_eap_forward.patch
index acbf1e2..69a9949 100644
--- a/target/linux/generic/patches-3.18/640-bridge_no_eap_forward.patch
+++ b/target/linux/generic/patches-3.18/640-bridge_no_eap_forward.patch
@@ -8,7 +8,7 @@
+ if (skb->protocol == htons(ETH_P_PAE)) {
+ skb2 = skb;
+ /* Do not forward 802.1x/EAP frames */
-+
++ skb = NULL;
+ } else if (is_broadcast_ether_addr(dest)) {
skb2 = skb;
unicast = false;
diff --git a/target/linux/generic/patches-4.0/640-bridge_no_eap_forward.patch
b/target/linux/generic/patches-4.0/640-bridge_no_eap_forward.patch
index 7a9dc26..c9b8613 100644
--- a/target/linux/generic/patches-4.0/640-bridge_no_eap_forward.patch
+++ b/target/linux/generic/patches-4.0/640-bridge_no_eap_forward.patch
@@ -8,7 +8,7 @@
+ if (skb->protocol == htons(ETH_P_PAE)) {
+ skb2 = skb;
+ /* Do not forward 802.1x/EAP frames */
-+
++ skb = NULL;
+ } else if (is_broadcast_ether_addr(dest)) {
if (IS_ENABLED(CONFIG_INET) &&
p->flags & BR_PROXYARP &&
diff --git a/target/linux/generic/patches-4.1/640-bridge_no_eap_forward.patch
b/target/linux/generic/patches-4.1/640-bridge_no_eap_forward.patch
index 283bc85..d3871eb 100644
--- a/target/linux/generic/patches-4.1/640-bridge_no_eap_forward.patch
+++ b/target/linux/generic/patches-4.1/640-bridge_no_eap_forward.patch
@@ -8,7 +8,7 @@
+ if (skb->protocol == htons(ETH_P_PAE)) {
+ skb2 = skb;
+ /* Do not forward 802.1x/EAP frames */
-+
++ skb = NULL;
+ } else if (is_broadcast_ether_addr(dest)) {
skb2 = skb;
unicast = false;
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Restore 640-bridge_no_eap_forward.patch to its original form
Hi, On Tue, Sep 8, 2015 at 2:31 PM, Dmitry Ivanov wrote: > Restore 640-bridge_no_eap_forward.patch to its original form. > It was corrupted in rev 62a2176cb144. The most obvious symptom is repeated > messages like this: Please state the svn revision and/or the commit subject in () to make it easier to find the offending commit. > > Tue Sep 8 08:25:18 2015 kern.warn kernel: [77141.972226] br-lan: received > packet on wlan0 with own address as source address > > Signed-off-by: Dmitry Ivanov Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] linux: add support of Synopsys ARC boards
Hi Alexey, On Fri, Sep 4, 2015 at 4:12 PM, Alexey Brodkin wrote: > Hi Jonas, > > On Fri, 2015-09-04 at 15:44 +0200, Jonas Gorski wrote: >> Hi, >> >> On Fri, Sep 4, 2015 at 1:24 PM, Alexey Brodkin >> wrote: >> > Hi Jonas, >> > >> > On Fri, 2015-09-04 at 13:01 +0200, Jonas Gorski wrote: >> > > On Fri, Sep 4, 2015 at 12:45 PM, Alexey Brodkin >> > > wrote: >> > > > Hi Jonas, >> > > > >> > > > On Fri, 2015-09-04 at 12:40 +0200, Jonas Gorski wrote: >> > > > > Hi, >> > > > > >> > > > > On Fri, Sep 4, 2015 at 12:35 PM, Alexey Brodkin >> > > > > > If one of my proposals above ok? >> > > > > > For example this one? >> > > > > > --->8 >> > > > > > * target/linux/arcv1 (or arc700) >> > > > > > * target/linux/arcv2 (or archs38) >> > > > > > --->8 >> > > > > > >> > > > > > In this scheme we do have different architectures with incompatible >> > > > > > tools and binaries. >> > > > > >> > > > > Right, although I would think >> > > > > >> > > > > target/linux/arc/arcv1/ >> > > > > target/linux/arc/arcv2/ >> > > > > >> > > > > would be better, as surely they will share all the driver options, >> > > > > and >> > > > > only differ in the selected cpu. Also that would mean you/we only >> > > > > have >> > > > > one set of kernel patches to maintain. >> > > > >> > > > Agree. >> > > > So then what about boards? Where should they be placed in this >> > > > hierarchy? >> > > > Will it be something like that? >> > > > >> > > > * target/linux/arc/arcv1/axs101 (or "axs10x" for uniformity) >> > > > /nsim_700 (or "nsim" for uniformity) >> > > > * target/linux/arc/arcv2/axs103 (or "axs10x") >> > > > /nsim_hs (or "nsim") >> > > >> > > Boards usually don't have their own directories, you would define >> > > profiles in target/linux/arc//profiles. These are usually >> > > grouped by manufacturer, so a synopsis.mk would contain all >> > > reference/development boards directly offered by you. It is also >> > > common to provide a "Default" / "Generic" profile for building all >> > > boards at once, which has a reasonable set of packages (mostly kmods) >> > > to include that cover the most common devices found on the boards >> > > (e.g. if most boards have usb, it should include the usb modules etc). >> > > >> > > Within your target/linux/arc/base-files you would use a runtime >> > > detection mechanism for determining the board at first boot to >> > > generate an appropriate network config etc. Since you are using device >> > > tree, you can easily use /proc/device-tree/model (or compatible) for >> > > identifying the board you are running on. >> > > >> > > The most recent iteration of setup-default-config uses >> > > base-files/etc/board.d/ (see ramips), and the most common is setting >> > > up through base-files/etc/uci-defaults/ scripts. I can't really give >> > > you much information about the former, since I haven't used it myself. >> > >> > Thanks for the pointer, I'll play with that dynamic setup of board >> > things and .dts patching. >> > >> > Still I have one question unsolved. >> > ARC architecture is very configurable, i.e. there could be >> > arc700-based SoC with MMU page 4, 8 or 16 kB or cache line length >> > typically of 32 or 64 bytes. >> > >> > And unfortunately .dts doesn't help here because those values >> > a defined during kernel configuration and then become built-ins. >> > >> > I.e. I need to have a way to use a bit different kernel config for >> > each board. Well it's not really required for all boards to have >> > different configs - at least within Synopsys we try to keep configs >> > aligned between platforms but tomorrow new board will appear with >> > different core settings and I'd like to be prepared to it. >> > >> > Any thoughts on how to solve it properly in OpenWRT? >> >> Are the MMU page sizes hardcoded in the silicon/by pin strapping, or >> are they selectable at run time? Of course which are available likely >> depends on the core. But maybe there is a common one that's always >> available. > > No this those options are selected during ASIC design process HW > engineer and then RTL gets built with hard-coded setting. > That said if MMU page size was set to 8k there's no way to either change > this value in runtime or somehow run kernel built for 4k or 16k pages. > Kernel will panic on early boot. After thinking about this a bit more, I don't think we want an "arc" target at all, as we neither have a "mips" or a "arm" target. So I guess having axs10x nsim targets is the way to go (each with arc700 and hs3x subtargets), as we usually model our targets after SoC (families), not CPUs. But I wonder, would it be possible to create a kernel that boots on both nsim and axs10x, assuming one includes all required drivers and both use the same cpu? I don't see anything preventing that in linux 4.2, apart from the ARC_HAS_COH_CACHES for SMP, which is true for HS3x but isn't true for ARC700, but OTOH at least from a descriptio
[OpenWrt-Devel] QinQ on MT7530/MT7621
Hi, I was testing QinQ/stacked vlan/double vlan/doubletag on MT7621 and noticed that it didn't work. I see packets correctly send with the the stacked VLAN tag but the replies are never received by eth0. Setup = -- | eth0.1.23 | eth0.1.42 | eth0.1.5 | eth0.2.23 | eth0.2.5 | eth0.2.6 | |--|---| | eth0.1 | eth0.2| |--| |eth0 | -- * eth0 is the raw device/switch which gives the packets up with vlan headers based on the ports (we need to address each port separately). * eth0.1 is for port 1 and eth0.2 is for port 2 * eth0.1.23 is for packets which are send out to port 1 with vlan header 23 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 23 set * eth0.1.42 is for packets which are send out to port 1 with vlan header 42 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 42 set * eth0.1.5 is for packets which are send out to port 1 with vlan header 5 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 5 set * eth0.2.23 is for packets which are send out to port 2 with vlan header 23 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 23 set * eth0.2.5 is for packets which are send out to port 2 with vlan header 5 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 5 set * eth0.2.6 is for packets which are send out to port 2 with vlan header 6 sending already works but we don't receive packets on eth0 from this port when the received packet had vlan header 6 set I would expect that I see following ethernet frame when I send a simple ping through eth0.1.23: -- |ETH HDR|VLAN 23|IP stuff| -- This seems to work perfectly fine. Now the receiver of the ICMP packet will send a reply: -- |ETH HDR|VLAN 23|IP stuff| -- And thus I would expect that the CPU (eth0) sees following packet: - |ETH HDR|VLAN 1|VLAN 23|IP stuff| - But instead I get nothing at all. I've already tried to change the tagged CPU port egress mode to stack but then I will get following packets as replies for eth0.1 |ETH HDR|VLAN 0|VLAN 1|IP stuff| And I get no replies for eth0.1.23 on eth0. Question I was told that on older ralink (esw_rt3052) switches there was a register 0xe4 (SGC2) which could influence the behavior of vlan-in-vlan. I don't have more information about that. Does anyone have the register specification for the MT7530 or any other idea how I could configure specific VLANs for each port. Kind regards, Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Restore 640-bridge_no_eap_forward.patch to its original form
> Please state the svn revision and/or the commit subject in () to make > it easier to find the offending commit. The "offending commit" seems to be r38528 , the introduction of Linux 3.12. https://dev.openwrt.org/changeset/38528 https://dev.openwrt.org/changeset/38528#file55 http://git.openwrt.org/?p=openwrt.git;a=commit;h=62a2176cb1446f865b58299f080493f26ce53573 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Removing Telnet
On Tue, Sep 8, 2015 at 4:13 AM, Jakub Jančo wrote: > Is slow login still present on ssh? > Because we had problem, that ssh login takes about 10seconds and > telnet is instant. It is difference if we do initial bulk setup for > more devices. Experience with SSH breakage tells me that kind of slowness might be due to the SSHD attempting to use DNS to check the origin system (OpenSSH's UseDNS flag). It's been a while since I dug into the OpenWRT SSH config, but is it generating the SSH keys upon first connection? That might be a source of slowness as well. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Restore 640-bridge_no_eap_forward.patch to its original form
On 2015-09-08 14:31, Dmitry Ivanov wrote: > Restore 640-bridge_no_eap_forward.patch to its original form. > It was corrupted in rev 62a2176cb144. The most obvious symptom is repeated > messages like this: > > Tue Sep 8 08:25:18 2015 kern.warn kernel: [77141.972226] br-lan: received > packet on wlan0 with own address as source address > > Signed-off-by: Dmitry Ivanov Applied in r46821. Next time, please don't repeat the subject in the message body, and add a prefix like "kernel: ". Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Removing Telnet
On Tue, Sep 8, 2015 at 7:47 AM, RB wrote: > Experience with SSH breakage tells me that kind of slowness might be > due to the SSHD attempting to use DNS to check the origin system > (OpenSSH's UseDNS flag). It's been a while since I dug into the > OpenWRT SSH config, but is it generating the SSH keys upon first > connection? That might be a source of slowness as well. Slowness probably depends on hardware as well as all the possibilities listed by others. I have a model of router that always takes 2-3 seconds to initiate an SSH connection, just to set up encryption (brief, but computationally intensive; happens with every connection). 10 seconds seems really slow, though. Smells like DNS. -- Brent ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] uqmi: Add proper IPv6 support
Use the new --ip-family option to start both IPv4 and IPv6 sessions
by default. Autoconnect can't be used when starting two sessions,
so revert back to using the client IDs and packet data handles for
handling the network connection.
Some modem firmwares do not implement a RA server, therefore by
default use outband IP configuration and static addressing. Some
other firmwares report bogus IP configuration with the WDS get
current settings command. In this case inband configuration with
DHCP/RA can be optionally enabled by setting option dhcp to 1.
Per 3GPP standard a /64 prefix is served to all clients, which is
extended to LAN as specified in RFC 7278.
Tested-by: Antti Sepp??l??
Signed-off-by: Matti Laakso
---
package/network/utils/uqmi/Makefile| 4 +-
.../utils/uqmi/files/lib/netifd/proto/qmi.sh | 199 +++--
2 files changed, 145 insertions(+), 58 deletions(-)
mode change 100755 => 100644
package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
diff --git a/package/network/utils/uqmi/Makefile
b/package/network/utils/uqmi/Makefile
index 8ca7b85..16e7fea 100644
--- a/package/network/utils/uqmi/Makefile
+++ b/package/network/utils/uqmi/Makefile
@@ -1,13 +1,13 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=uqmi
-PKG_VERSION:=2014-12-03
+PKG_VERSION:=2015-08-13
PKG_RELEASE=$(PKG_SOURCE_VERSION)
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://nbd.name/uqmi.git
PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION)
-PKG_SOURCE_VERSION:=86bcdb8cca652676a78b2df8b5e3fb27a40c60a4
+PKG_SOURCE_VERSION:=8a97586e9445a60e355dea13aa87885ab3dcb277
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz
PKG_MAINTAINER:=Matti Laakso
# PKG_MIRROR_MD5SUM:=
diff --git a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
old mode 100755
new mode 100644
index b416da6..a089a0c
--- a/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
+++ b/package/network/utils/uqmi/files/lib/netifd/proto/qmi.sh
@@ -17,28 +17,25 @@ proto_qmi_init_config() {
proto_config_add_string pincode
proto_config_add_string delay
proto_config_add_string modes
+ proto_config_add_boolean ipv6
+ proto_config_add_boolean dhcp
}
-qmi_disconnect() {
- # disable previous autoconnect state using the global handle
- # do not reuse previous wds client id to prevent hangs caused by stale
data
- uqmi -s -d "$device" \
- --stop-network 0x \
- --autoconnect > /dev/null
-}
-
-qmi_wds_release() {
- [ -n "$cid" ] || return 0
+proto_qmi_setup() {
+ local interface="$1"
- uqmi -s -d "$device" --set-client-id wds,"$cid" --release-client-id wds
- uci_revert_state network $interface cid
-}
+ local device apn auth username password pincode delay modes ipv6 dhcp
+ local cid_4 pdh_4 cid_6 pdh_6 ipv4
+ local ip subnet gateway dns1 dns2 ip_6 ip_prefix_length gateway_6
dns1_6 dns2_6
+ json_get_vars device apn auth username password pincode delay modes
ipv6 dhcp
-_proto_qmi_setup() {
- local interface="$1"
+ ipv4=1
- local device apn auth username password pincode delay modes cid pdh
- json_get_vars device apn auth username password pincode delay modes
+ if [ "$ipv6" = 0 ]; then
+ ipv6=""
+ else
+ ipv6=1
+ fi
[ -n "$ctl_device" ] && device=$ctl_device
@@ -86,8 +83,6 @@ _proto_qmi_setup() {
return 1
}
- qmi_disconnect
-
uqmi -s -d "$device" --set-data-format 802.3
uqmi -s -d "$device" --wda-set-data-format 802.3
@@ -99,67 +94,159 @@ _proto_qmi_setup() {
[ -n "$modes" ] && uqmi -s -d "$device" --set-network-modes "$modes"
echo "Starting network $apn"
- cid=`uqmi -s -d "$device" --get-client-id wds`
+
+ cid_4=`uqmi -s -d "$device" --get-client-id wds`
[ $? -ne 0 ] && {
echo "Unable to obtain client ID"
proto_notify_error "$interface" NO_CID
return 1
}
- uqmi -s -d "$device" --set-client-id wds,"$cid" \
+ pdh_4=`uqmi -s -d "$device" --set-client-id wds,"$cid_4" \
--start-network "$apn" \
${auth:+--auth-type $auth} \
${username:+--username $username} \
${password:+--password $password} \
- --autoconnect > /dev/null
-
- echo "Starting DHCP"
- proto_init_update "$ifname" 1
- proto_send_update "$interface"
-
- json_init
- json_add_string name "${interface}_4"
- json_add_string ifname "@$interface"
- json_add_string proto "dhcp"
- json_close_object
- ubus call network add_dynamic "$(json_dump)"
-
- json_init
- json_add_string name "${interface}_6"
- json_add_string ifname "@$interface"
- json_add_string proto "dhcpv6"
- json_add_s
Re: [OpenWrt-Devel] Fwd: Removing Telnet
Il 08.09.2015 17:42 Brent Thomson ha scritto: Slowness probably depends on hardware as well as all the possibilities listed by others. I have a model of router that always takes 2-3 seconds to initiate an SSH connection, just to set up encryption (brief, but computationally intensive; happens with every connection). 10 seconds seems really slow, though. Smells like DNS. It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...) starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on slower routers the login time can be longer. If you login with ssh -v, you can see that it waits between debug1: expecting SSH2_MSG_KEXDH_REPLY and debug1: Server host key: RSA [...] If you check the CPU usage on the router while the client is waiting for the reply, you can see that dropbear is at 100%. Cheers, Vittorio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openwrt/hardening: Fix CFLAGS usage for -D_FORTIFY_SOURCE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Helmut Schaa wrote: > On Tue, Sep 8, 2015 at 9:03 AM, Stefan Peter > wrote: > > Hi > > Am 07.09.2015 um 17:32 schrieb Helmut Schaa: > >> Fix the following configure error with c-ares by using CPPFLAGS for > >> -D_FORTIFY_SOURCE. > >> Not sure if any other packages suffer from the same issue. > >> > >> configure: using CFLAGS: -Os -pipe -march=74kc -fno-caller-saves > >> -mno-branch-likely -g3 -fno-caller-saves -fhonour-copts > >> -Wno-error=unused-but-set-variable -msoft-float -D_FORTIFY_SOURCE=1 > >> -Wl,-z,now -Wl,-z,relro > >> configure: CFLAGS error: CFLAGS may only be used to specify C compiler > >> flags, not macro definitions. Use CPPFLAGS for: -D_FORTIFY_SOURCE=1 > >> configure: error: Can not continue. Fix errors mentioned immediately above > >> this line. > > > > Did you get this in the CC branch? > > > > According to > > https://github.com/openwrt/packages/pull/1464 > > this should be fixed in master and applying this patch on top of the CC > > branch worked for me. > > I came up with a similar patch now :) but good to know it's fixed in > master already. > Helmut Also, I took it up with c-ares, they largely feel that we're "wrong" but agreed that they could probably relax their check from an error to a warning: http://c-ares.haxx.se/mail/c-ares-archive-2015-06/0005.shtml However, that's "in the future" Cheers, Karl P -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJV7wXfAAoJEBmotQ/U1cr2ISAP/3so2iplIZldSEM+nvQZPbcj nlRu2uLw8A0ZaMiu0kgdDt2Qbm+cD/ZXAPmnavOmS3A0v7v9E8DYqJq44WAJiDH+ 7LHQf/UKMm0VLXBAFp1x/271mwS+hNa29qsUIZQYWsaL0rI3a7MV7vCBzkwjmtAZ obRxrWT2zlBQYquXiHe+2bO362s7GGu51XqGFFDSFz2kYX+lKYQkpzTUuU/6jzQI byTXcW0rNwSehcIM5lMOo7oMuXTmsZrqsC+YRxAx3C/jAgNbFwSPkAN9YQankA8m PIvtjGvB86svimlFZXKVIurlXYFfbN48hPfYKhbGkM7ZPtanc8MJ+PtzAqI3HRR1 eDJ/RRZPEnBwShN/Waz3p1hV7UV1H0mVaEoWtOdZt7wYudRauQJTM89eIeAcaqYq I3LZqOimeOYeY4Qaw8KoP9EecX+pfFC9EOSnvjvZnYjeFMeoXLB7g7qyy1g2SQSW rE2zM00KDcBulRegVSLnMobnbj6kINNbk0jIK+kvDI7bd805IRB5upAtx0dHHDPE qOivN8oKlWHOOnNKdmwpgwcMuUJzotTX8We+fMUF/Wq2hO0in76T2EaFiX3dntBJ yoqv+wXG5vghK5vunu5+825wHwwjEBfEmiFuh8FhGpIXs5Ft2fqPQjLEzzh9c15J w762vHTLSp0MKmba93jQ =Dp1P -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] comgt-ncm: Add possibility to choose PDP context type
By setting the option pdptype to IP, IPV6 or IPV4V6 the user can
choose the context type between IPv4, IPv6 and dual stack,
respectively. The default setting is dual stack, except if option
ipv6=0 is specified, in which case IPv4 context is the default.
This allows for an out-of-the-box IPv6 support with modems
utilizing NCM-like protocols.
While we are at it, also add commands for Sierra DirectIP modems
(currently untested), which will allow us to drop the separate
comgt-directip package (once tested and verified working).
Signed-off-by: Matti Laakso
---
package/network/utils/comgt/Makefile | 2 +-
package/network/utils/comgt/files/ncm.json | 26 +
package/network/utils/comgt/files/ncm.sh | 36 ++
3 files changed, 50 insertions(+), 14 deletions(-)
diff --git a/package/network/utils/comgt/Makefile
b/package/network/utils/comgt/Makefile
index 18085a6..716bbbf 100644
--- a/package/network/utils/comgt/Makefile
+++ b/package/network/utils/comgt/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=comgt
PKG_VERSION:=0.32
-PKG_RELEASE:=25
+PKG_RELEASE:=26
PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
PKG_SOURCE_URL:=@SF/comgt
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index ea4f984..d1f8699 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -6,7 +6,8 @@
"ATQ0",
"ATV1",
"ATE1",
- "ATS0=0"
+ "ATS0=0",
+ "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\""
],
"modes": {
"preferlte":
"AT^SYSCFGEX=\\\"030201\\\",3fff,2,4,7fff,,",
@@ -25,7 +26,7 @@
"AT+CGREG=2",
"AT+CFUN=5",
"AT+MODESELECT=3",
- "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\""
+ "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\""
],
"modes": {
"umts": "AT+CHANGEALLPATH=1"
@@ -33,10 +34,27 @@
"connect": "AT+CGATT=1",
"disconnect": "AT+CGATT=0"
},
- "sony": {
+ "sierra wireless, incorporated": {
"initialize": [
"AT+CFUN=1",
- "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\"",
+ "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\"",
+
"AT$QCPDPP=1${auth:+,$auth}${password:+,\\\"$password\\\"}${username:+,\\\"$username\\\"}"
+ ],
+ "modes": {
+ "preferlte": "AT!SELRAT=07",
+ "preferumts": "AT!SELRAT=05",
+ "lte": "AT!SELRAT=06",
+ "umts": "AT!SELRAT=01",
+ "gsm": "AT!SELRAT=02",
+ "auto": "AT!SELRAT=00"
+ },
+ "connect": "AT!SCACT=1,1",
+ "disconnect": "AT!SCACT=0,1"
+ },
+ "sony ericsson": {
+ "initialize": [
+ "AT+CFUN=1",
+ "AT+CGDCONT=1,\\\"${pdptype}\\\",\\\"${apn}\\\"",
"AT*EIAAUW=1,1,\\\"${username}\\\",\\\"${password}\\\",${auth:-00111}"
],
"modes": {
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index ffe5615..571cfaa 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -17,6 +17,8 @@ proto_ncm_init_config() {
proto_config_add_string pincode
proto_config_add_string delay
proto_config_add_string mode
+ proto_config_add_string pdptype
+ proto_config_add_boolean ipv6
}
proto_ncm_setup() {
@@ -24,8 +26,22 @@ proto_ncm_setup() {
local manufacturer initialize setmode connect ifname devname devpath
- local device apn auth username password pincode delay mode
- json_get_vars device apn auth username password pincode delay mode
+ local device apn auth username password pincode delay mode pdptype ipv6
+ json_get_vars device apn auth username password pincode delay mode
pdptype ipv6
+
+ if [ "$ipv6" = 0 ]; then
+ ipv6=""
+ else
+ ipv6=1
+ fi
+
+ [ -z "$pdptype" ] && {
+ if [ -n "$ipv6" ]; then
+ pdptype="IPV4V6"
+ else
+ pdptype="IP"
+ fi
+ }
[ -n "$ctl_device" ] && device=$ctl_device
@@ -116,7 +132,7 @@ proto_ncm_setup() {
return 1
}
- echo "Connected, starting DHCP"
+ echo "Connected, starting DHCP on $ifname"
proto_init_update "$ifname" 1
Re: [OpenWrt-Devel] Fwd: Removing Telnet
Vittorio is right. Some seconds I got with disabling testing all my public keys. I tried add dns to /etc/hosts, but no gain. It waits where Vittorio wrote. I searched for disabling ciphers but didnt found anything. Probably it cannot be done. -- S pozdravom Jakub Janco 2015-09-08 18:00 GMT+02:00 Vittorio G (VittGam) : > Il 08.09.2015 17:42 Brent Thomson ha scritto: >> >> Slowness probably depends on hardware as well as all the possibilities >> listed by others. I have a model of router that always takes 2-3 >> seconds to initiate an SSH connection, just to set up encryption >> (brief, but computationally intensive; happens with every connection). >> 10 seconds seems really slow, though. Smells like DNS. > > > It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...) > starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on > slower routers the login time can be longer. > > If you login with ssh -v, you can see that it waits between > >> debug1: expecting SSH2_MSG_KEXDH_REPLY > > > and > >> debug1: Server host key: RSA [...] > > > If you check the CPU usage on the router while the client is waiting for > the reply, you can see that dropbear is at 100%. > > Cheers, > Vittorio > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Removing Telnet
2015-09-08 18:00 GMT+02:00 Vittorio G (VittGam) : > Il 08.09.2015 17:42 Brent Thomson ha scritto: >> >> Slowness probably depends on hardware as well as all the possibilities >> listed by others. I have a model of router that always takes 2-3 >> seconds to initiate an SSH connection, just to set up encryption >> (brief, but computationally intensive; happens with every connection). >> 10 seconds seems really slow, though. Smells like DNS. > > > It might not be DNS in fact. On AR9331 (MIPS 24k CPU, not that fast...) > starting from Barrier Breaker SSH is pretty slow (3-4 seconds), so on > slower routers the login time can be longer. > > If you login with ssh -v, you can see that it waits between > >> debug1: expecting SSH2_MSG_KEXDH_REPLY > > > and > >> debug1: Server host key: RSA [...] > > > If you check the CPU usage on the router while the client is waiting for > the reply, you can see that dropbear is at 100%. SSH time can be greatly reduced by using ECDSA host key. Dropbear can be compiled with ECDSA support, however: - it is disabled by default in OpenWRT - startup script only generates RSA/DSA host keys, ECDSA host key must be generated manually Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not sure about other architectures. I can try to send a patch that enables ECDSA by default and fixes the startup script, if there is any interest. dropbear package size increases by about 20kB. -- Janusz Dziemidowicz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: Use the BAR0 base address in the ath PCI fixup code
Fixes support for AR9287 on TP-Link TD-W8980 and possibly other devices
which have an ath wifi chip at a PCI address other than 0xb800
(TD-W8980 for example has it's wifi chip at 0xbc00).
Signed-off-by: Geoffrey McRae
Signed-off-by: Martin Blumenstingl
---
This patch was initially written by Geoffrey McRae but it was never included
due to whitespace problems with his patch:
https://lists.openwrt.org/pipermail/openwrt-devel/2014-September/028130.html
.../0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch | 8
.../0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git
a/target/linux/lantiq/patches-3.18/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
b/target/linux/lantiq/patches-3.18/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
index 094d16c..ec769ccf 100644
---
a/target/linux/lantiq/patches-3.18/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
+++
b/target/linux/lantiq/patches-3.18/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
@@ -431,8 +431,6 @@ Signed-off-by: John Crispin
+#include
+#include
+
-+#define LTQ_PCI_MEM_BASE 0x1800
-+
+struct ath_fixup {
+ u16 *cal_data;
+ unsignedslot;
@@ -448,6 +446,7 @@ Signed-off-by: John Crispin
+ u16 cmd;
+ u32 bar0;
+ u32 val;
++ u32 base;
+ unsigned i;
+
+ for (i = 0; i < ath_num_fixups; i++) {
@@ -471,14 +470,15 @@ Signed-off-by: John Crispin
+
+ pr_info("pci %s: fixup device configuration\n", pci_name(dev));
+
-+ mem = ioremap(LTQ_PCI_MEM_BASE, 0x1);
++ base = dev->resource[0].start;
++ mem = ioremap(base, 0x1);
+ if (!mem) {
+ pr_err("pci %s: ioremap error\n", pci_name(dev));
+ return;
+ }
+
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar0);
-+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, LTQ_PCI_MEM_BASE);
++ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, base);
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
diff --git
a/target/linux/lantiq/patches-4.1/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
b/target/linux/lantiq/patches-4.1/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
index 04c2071..72ae1c9 100644
---
a/target/linux/lantiq/patches-4.1/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
+++
b/target/linux/lantiq/patches-4.1/0035-owrt-lantiq-wifi-and-ethernet-eeprom-handling.patch
@@ -431,8 +431,6 @@ Signed-off-by: John Crispin
+#include
+#include
+
-+#define LTQ_PCI_MEM_BASE 0x1800
-+
+struct ath_fixup {
+ u16 *cal_data;
+ unsignedslot;
@@ -448,6 +446,7 @@ Signed-off-by: John Crispin
+ u16 cmd;
+ u32 bar0;
+ u32 val;
++ u32 base;
+ unsigned i;
+
+ for (i = 0; i < ath_num_fixups; i++) {
@@ -471,14 +470,15 @@ Signed-off-by: John Crispin
+
+ pr_info("pci %s: fixup device configuration\n", pci_name(dev));
+
-+ mem = ioremap(LTQ_PCI_MEM_BASE, 0x1);
++ base = dev->resource[0].start;
++ mem = ioremap(base, 0x1);
+ if (!mem) {
+ pr_err("pci %s: ioremap error\n", pci_name(dev));
+ return;
+ }
+
+ pci_read_config_dword(dev, PCI_BASE_ADDRESS_0, &bar0);
-+ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, LTQ_PCI_MEM_BASE);
++ pci_write_config_dword(dev, PCI_BASE_ADDRESS_0, base);
+ pci_read_config_word(dev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(dev, PCI_COMMAND, cmd);
--
2.5.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [SIGNED-OFF] Add WeIO board (http://we-io.net) profile. This patch adds support for WeIO board, which is based on Carambola2 board from 8Devices.
Signed-off-by: Drasko DRASKOVIC
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 3 +-
target/linux/ar71xx/config-4.1 | 1 +
.../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 145 +
target/linux/ar71xx/generic/profiles/weio.mk | 17 +++
target/linux/ar71xx/image/Makefile | 8 ++
.../700-MIPS-ath79-openwrt-machines.patch | 21 ++-
7 files changed, 192 insertions(+), 6 deletions(-)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e1f345e..e30cac2 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -832,6 +832,9 @@ ar71xx_board_detect() {
*"UniFi AP Pro")
name="uap-pro"
;;
+ *"WeIO")
+ name="weio"
+ ;;
*WHR-G301N)
name="whr-g301n"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index c1962e4..b681fb8 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -250,7 +250,8 @@ platform_check_image() {
nbg460n_550n_550nh | \
unifi | \
unifi-outdoor | \
- carambola2 )
+ carambola2 | \
+ weio )
[ "$magic" != "2705" ] && {
echo "Invalid image type."
return 1
diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 21c4601..7d836d9 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -139,6 +139,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
CONFIG_ATH79_MACH_TUBE2H=y
CONFIG_ATH79_MACH_UBNT=y
CONFIG_ATH79_MACH_UBNT_XM=y
+CONFIG_ATH79_MACH_WEIO=y
CONFIG_ATH79_MACH_WHR_HP_G300N=y
CONFIG_ATH79_MACH_WLAE_AG300N=y
CONFIG_ATH79_MACH_WLR8100=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
new file mode 100644
index 000..bd230a9
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
@@ -0,0 +1,145 @@
+/**
+ * WEIO Web Of Things Platform
+ *
+ * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
+ *
+ * ## ## ###
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ### ### ###
+ *
+ * Web Of Things Platform
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Authors :
+ * Drasko DRASKOVIC
+ * Uros PETREVSKI
+ */
+
+#include
+#include
+#include "common.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-spi.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+#include "linux/i2c-gpio.h"
+#include "linux/platform_device.h"
+
+#define WEIO_GPIO_LED_STA 1
+#define WEIO_GPIO_LED_AP 16
+
+#define WEIO_GPIO_BTN_AP 20
+#define WEIO_GPIO_BTN_RESET23
+
+#define WEIO_KEYS_POLL_INTERVAL20 /* msecs */
+#define WEIO_KEYS_DEBOUNCE_INTERVAL(3 * WEIO_KEYS_POLL_INTERVAL)
+
+#define WEIO_MAC0_OFFSET 0x
+#define WEIO_MAC1_OFFSET 0x0006
+#define WEIO_CALDATA_OFFSET0x1000
+#define WEIO_WMAC_MAC_OFFSET 0x1002
+
+static struct gpio_led weio_leds_gpio[] __initdata = {
+{
+.name = "weio:green:sta",
+.gpio = WEIO_GPIO_LED_STA,
+.active_low= 1,
+.default_state = LEDS_GPIO_DEFSTATE_ON,
+}, {
+.name = "weio:green:ap",
+.gpio = WEIO_GPIO_LED_AP,
+.active_low= 1,
+.default_state = LEDS_GPIO_D
Re: [OpenWrt-Devel] Fwd: Removing Telnet
Il 08.09.2015 18:31 Janusz Dziemidowicz ha scritto: SSH time can be greatly reduced by using ECDSA host key. Dropbear can be compiled with ECDSA support, however: - it is disabled by default in OpenWRT - startup script only generates RSA/DSA host keys, ECDSA host key must be generated manually Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not sure about other architectures. Also, I think ed25519 keys and chacha20-poly1305 encryption might be worth a try. They should be faster than ECDSA + AES on embedded processors, but they need a relatively recent version of the SSH client (read: possible problems on Windows and Macs). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Removing Telnet
Does Dropbeard support ether? I know OpenSSH does, but default installation does not use that. Olmari On Sep 8, 2015 21:01, "Vittorio G (VittGam)" wrote: > Il 08.09.2015 18:31 Janusz Dziemidowicz ha scritto: > >> SSH time can be greatly reduced by using ECDSA host key. Dropbear can >> be compiled with ECDSA support, however: >> - it is disabled by default in OpenWRT >> - startup script only generates RSA/DSA host keys, ECDSA host key must >> be generated manually >> >> Using 256 bit ECDSA host key reduces SSH login time for me from 0.7s >> down to 0.13s. Tested on Netgear WNDR3800, ar71xx/generic, I am not >> sure about other architectures. >> > > Also, I think ed25519 keys and chacha20-poly1305 encryption might be worth > a try. They should be faster than ECDSA + AES on embedded processors, but > they need a relatively recent version of the SSH client (read: possible > problems on Windows and Macs). > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [SIGNED-OFF] Add WeIO board (http://we-io.net) profile. This patch adds support for WeIO board, which is based on Carambola2 board from 8Devices.
Hi Karl,
corrected patch re-sent.
My comments below.
BR,
Drasko
On Sat, Aug 8, 2015 at 3:03 AM, Karl Palsson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Comments inline...
>
> Drasko DRASKOVIC wrote:
>> Signed-off-by: Drasko DRASKOVIC
>> ---
>
>
> Might just be my mail client, but might be yours, did you change
> anything to send this? you seem to have lost all the commit message up
> into the subject?
Actually, I use `git send-email` directly, exactly to avoid problems
with different mail clients. All my patches are send via git.
>
>
>> target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
>> .../ar71xx/base-files/lib/upgrade/platform.sh | 3 +-
>> target/linux/ar71xx/config-4.1 | 1 +
>> .../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 146
>> +
>> target/linux/ar71xx/generic/profiles/weio.mk | 17 +++
>> target/linux/ar71xx/image/Makefile | 8 ++
>> .../700-MIPS-ath79-openwrt-machines.patch | 21 ++-
>> 7 files changed, 193 insertions(+), 6 deletions(-)
>> create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>> create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
>>
>> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> index 256bd10..80af14b 100755
>> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
>> @@ -823,6 +823,9 @@ ar71xx_board_detect() {
>> *"UniFi AP Pro")
>> name="uap-pro"
>> ;;
>> + *"WeIO")
>> + name="weio"
>> + ;;
>> *WHR-G301N)
>> name="whr-g301n"
>> ;;
>> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> index 76d8c5b..57df672 100755
>> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
>> @@ -250,7 +250,8 @@ platform_check_image() {
>> nbg460n_550n_550nh | \
>> unifi | \
>> unifi-outdoor | \
>> - carambola2 )
>> + carambola2 | \
>> + weio )
>> [ "$magic" != "2705" ] && {
>> echo "Invalid image type."
>> return 1
>> diff --git a/target/linux/ar71xx/config-4.1
>> b/target/linux/ar71xx/config-4.1
>> index 1e31a01..0f80804 100644
>> --- a/target/linux/ar71xx/config-4.1
>> +++ b/target/linux/ar71xx/config-4.1
>> @@ -137,6 +137,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
>> CONFIG_ATH79_MACH_TUBE2H=y
>> CONFIG_ATH79_MACH_UBNT=y
>> CONFIG_ATH79_MACH_UBNT_XM=y
>> +CONFIG_ATH79_MACH_WEIO=y
>> CONFIG_ATH79_MACH_WHR_HP_G300N=y
>> CONFIG_ATH79_MACH_WLAE_AG300N=y
>> CONFIG_ATH79_MACH_WLR8100=y
>> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>> b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>> new file mode 100644
>> index 000..5c707ec
>> --- /dev/null
>> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
>> @@ -0,0 +1,146 @@
>> +/**
>> + * WEIO Web Of Things Platform
>> + *
>> + * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
>> + *
>> + * ## ## ###
>> + * ## ## ## #### ## ##
>> + * ## ## ## #### ## ##
>> + * ## ## ## #### ## ##
>> + * ## ## ## #### ## ##
>> + * ## ## ## #### ## ##
>> + * ### ### ###
>> + *
>> + * Web Of Things Platform
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version 2
>> + * of the License, or (at your option) any later version.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, write to the Free Software
>> + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
>> USA.
>> + *
>> + * Authors :
>> + * Drasko DRASKOVIC
>> + * Uros PETREVSKI
>> + */
>> +
>> +#include
>> +#include
>> +#include "common.h"
>> +#include "dev-eth.h"
>> +#include "dev-gpio-buttons.h"
>> +#include "dev-leds-gpio.h"
>> +#include "dev-m25p80.h"
>> +#include "dev-spi.h"
>> +#include "dev-usb.h"
>> +#include "dev-wmac.h"
>> +#include "machtypes.h"
>> +#include "linux/i2c-gpio.h"
>> +#include "linux/platform_device.h"
>> +
>> +#define WEIO_GPIO_LED_STA1
>> +#define WEIO_GPIO_LED_AP 16
>> +//#define WEIO
[OpenWrt-Devel] [PATCH] lantiq: Update to the latest DSL driver / application versions
Thanks to Sylwester Petela for testing my patch (successfully on an ADSL connection) and for pointing out some configuration mistakes. Others (including me) have also successfully tested this extensively on VDSL connections. Signed-off-by: Martin Blumenstingl --- package/kernel/lantiq/ltq-ifxos/Makefile | 9 +- .../lantiq/ltq-ifxos/patches/100-compat.patch | 27 +- package/kernel/lantiq/ltq-vdsl-mei/Makefile| 9 +- .../lantiq/ltq-vdsl-mei/patches/100-compat.patch | 496 ++--- package/kernel/lantiq/ltq-vdsl/Makefile| 12 +- .../lantiq/ltq-vdsl/patches/100-compat.patch | 156 ++- package/network/config/ltq-vdsl-app/Makefile | 13 +- .../network/config/ltq-vdsl-app/files/dsl_control | 106 - .../config/ltq-vdsl-app/patches/100-compat.patch | 34 +- 9 files changed, 316 insertions(+), 546 deletions(-) diff --git a/package/kernel/lantiq/ltq-ifxos/Makefile b/package/kernel/lantiq/ltq-ifxos/Makefile index 3758752..9919a9b 100644 --- a/package/kernel/lantiq/ltq-ifxos/Makefile +++ b/package/kernel/lantiq/ltq-ifxos/Makefile @@ -7,11 +7,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=lib_ifxos -PKG_VERSION:=1.5.14 +PKG_VERSION:=1.5.19 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_RELEASE:=3 -PKG_SOURCE_URL:=http://mirror2.openwrt.org/sources -PKG_MD5SUM:=bc107f9d8ff6bed4c2760a2817bbb029 +PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION) +PKG_SOURCE_URL:=https://github.com/xdarklight/$(PKG_NAME)/archive/v$(PKG_VERSION) +PKG_MD5SUM:=39eace039ae4c3dde4da96bfdbee2721 PKG_MAINTAINER:=John Crispin PKG_USE_MIPS16:=0 diff --git a/package/kernel/lantiq/ltq-ifxos/patches/100-compat.patch b/package/kernel/lantiq/ltq-ifxos/patches/100-compat.patch index db2dd8b..dcd260e 100644 --- a/package/kernel/lantiq/ltq-ifxos/patches/100-compat.patch +++ b/package/kernel/lantiq/ltq-ifxos/patches/100-compat.patch @@ -1,27 +1,14 @@ a/configure.in -+++ b/configure.in -@@ -64,7 +64,7 @@ dnl Set kernel build path - AC_ARG_ENABLE(kernelbuild, - AS_HELP_STRING(--enable-kernelbuild=x,Set the target kernel build path (only for kernel 2.6.x)), - [ -- if test -e $enableval/include/linux/autoconf.h; then -+ if test -e $enableval/include/linux/autoconf.h -o -e $enableval/include/generated/autoconf.h; then - AC_SUBST([KERNEL_BUILD_PATH],[$enableval]) - else - AC_MSG_ERROR([The kernel build directory is not valid or not configured!]) --- a/src/linux/ifxos_linux_thread_drv.c +++ b/src/linux/ifxos_linux_thread_drv.c -@@ -34,8 +34,8 @@ - #include - #include - #include --#include +@@ -38,6 +38,7 @@ + #include + #endif #include +#include #include "ifx_types.h" -@@ -68,10 +68,6 @@ +@@ -70,10 +71,6 @@ #if ( defined(IFXOS_HAVE_THREAD) && (IFXOS_HAVE_THREAD == 1) ) @@ -32,7 +19,7 @@ /* IFX Linux adaptation - Kernel Thread handling = */ -@@ -96,9 +92,9 @@ IFXOS_STATIC IFX_int32_t IFXOS_KernelThr +@@ -98,9 +95,9 @@ IFXOS_STATIC IFX_int32_t IFXOS_KernelThr - IFX_SUCCESS on success - IFX_ERROR on error */ @@ -44,7 +31,7 @@ IFX_int32_t retVal = IFX_ERROR; #if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0)) struct task_struct *kthread = current; -@@ -139,7 +135,7 @@ IFXOS_STATIC IFX_int32_t IFXOS_KernelThr +@@ -141,7 +138,7 @@ IFXOS_STATIC IFX_int32_t IFXOS_KernelThr /* let others run */ unlock_kernel(); #else @@ -53,7 +40,7 @@ /* Enable signals in Kernel >= 2.6 */ allow_signal(SIGKILL); -@@ -218,9 +214,7 @@ IFX_int32_t IFXOS_ThreadInit( +@@ -221,9 +218,7 @@ IFX_int32_t IFXOS_ThreadInit( init_completion(&pThrCntrl->thrCompletion); /* start kernel thread via the wrapper function */ diff --git a/package/kernel/lantiq/ltq-vdsl-mei/Makefile b/package/kernel/lantiq/ltq-vdsl-mei/Makefile index 17d7755..0f9f48d 100644 --- a/package/kernel/lantiq/ltq-vdsl-mei/Makefile +++ b/package/kernel/lantiq/ltq-vdsl-mei/Makefile @@ -7,14 +7,14 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=ltq-vdsl-vr9-mei -PKG_VERSION:=1.2.0 +PKG_VERSION:=1.4.8.4 PKG_RELEASE:=1 PKG_BASE_NAME:=drv_mei_cpe PKG_SOURCE:=$(PKG_BASE_NAME)-$(PKG_VERSION).tar.gz PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/$(PKG_BASE_NAME)-$(PKG_VERSION) -PKG_SOURCE_URL:=http://downloads.openwrt.org/sources/ -PKG_MD5SUM:=cf2fccc1bc72390b2aec46650abf2f20 +PKG_SOURCE_URL:=https://github.com/xdarklight/$(PKG_BASE_NAME)/archive/v$(PKG_VERSION) +PKG_MD5SUM:=30570722dc7f19ff2f0228838043f2a2 PKG_FIXUP:=autoreconf PKG_MAINTAINER:=John Crispin PKG_USE_MIPS16:=0 @@ -49,9 +49,10 @@ CONFIGURE_ARGS += \ --enable-error_print \ --enable-ifxos-include="-I$(STAGING_DIR)/usr/
Re: [OpenWrt-Devel] Fwd: Removing Telnet
Il 08.09.2015 20:06 Sami Olmari ha scritto: Does Dropbeard support ether? I know OpenSSH does, but default installation does not use that. I just checked the changelog[1] and I remembered wrong about chacha20. But it does support curve25519 indeed; it was added along ECDSA: 2013.61test - Thursday 14 November 2013 - ECC (elliptic curve) support. Supports ECDSA hostkeys (requires new keys to be generated) and ECDH for setting up encryption keys (no intervention required). This is significantly faster. - curve25519-sha...@libssh.org support for setting up encryption keys. This is another elliptic curve mode with less potential of NSA interference in algorithm parameters. curve25519-donna code thanks to Adam Langley By the way, dropbearkey might not be required anymore, and removing it will improve CSPRNG security... but that's OT here :) - -R option to automatically generate hostkeys. This is recommended for embedded platforms since it allows the system random number device /dev/urandom a longer startup time to generate a secure seed before the hostkey is required. Cheers, Vittorio [1]: https://matt.ucc.asn.au/dropbear/CHANGES ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Removing Telnet
Il 08.09.2015 10:15 Steven Barth ha scritto: as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of the base images. As a replacement, it is now possible to login to the root- account via SSH without a password prompt whenever no root password is set, e.g. after a flash without keeping config, factory reset or in failsafe. What about empty root password but authorized_keys for root present? This behavior is not clear from the patch... Maybe it would just be better to set the default root password to 'openwrt' or 'insecure' or 'change_me!'? Cheers, Vittorio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Removing Telnet
Il 08.09.2015 20:34 Vittorio G (VittGam) ha scritto: Maybe it would just be better to set the default root password to 'openwrt' or 'insecure' or 'change_me!'? Maybe along with a preauthentication banner that tells the user about the default password and the fact that it should be changed as soon as possible. Cheers, Vittorio ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Removing Telnet
Nak on setting a default password. The blank password has served its purpose well for years now. Any preset password is asking for users to leave it default. The only problem with blank ssh logins is it removes one of the ways openwrt encouraged the user to set a password. A banner that warns about a blank password would be fine, similar to what Luci does. Any thoughts about forcing a password change on first ssh login? I haven't thought through the idea fully myself. On Tue, Sep 8, 2015 at 1:35 PM Vittorio G (VittGam) wrote: > Il 08.09.2015 10:15 Steven Barth ha scritto: > > as of https://dev.openwrt.org/changeset/46809 telnet is no longer part > of > > the base images. As a replacement, it is now possible to login to the > root- > > account via SSH without a password prompt whenever no root password is > set, > > e.g. after a flash without keeping config, factory reset or in failsafe. > > What about empty root password but authorized_keys for root present? This > behavior is not clear from the patch... > > Maybe it would just be better to set the default root password to 'openwrt' > or 'insecure' or 'change_me!'? > > Cheers, > Vittorio > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [SIGNED-OFF] Add WeIO board (http://we-io.net) profile. This patch adds support for WeIO board, which is based on Carambola2 board from 8Devices.
On Tue, Sep 8, 2015 at 8:07 PM, Drasko DRASKOVIC wrote: > Hi Karl, > corrected patch re-sent. > > My comments below. > > BR, > Drasko > > On Sat, Aug 8, 2015 at 3:03 AM, Karl Palsson wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Comments inline... >> >> Drasko DRASKOVIC wrote: >>> Signed-off-by: Drasko DRASKOVIC >>> --- >> >> >> Might just be my mail client, but might be yours, did you change >> anything to send this? you seem to have lost all the commit message up >> into the subject? > > Actually, I use `git send-email` directly, exactly to avoid problems > with different mail clients. All my patches are send via git. I just figured out that `git send-email` will actually expect commit message to have a subject separated by a blank line from the commit message. Reading this helped: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html. Please ignore previous patch - I will re-send one with correctly formatted commit message. BR, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [SIGNED-OFF] Add initial support for WeIO board
Add support for WeIO board (http://we-io.net), which is based on
Carambola2 board from 8Devices.
Signed-off-by: Drasko DRASKOVIC
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 3 +-
target/linux/ar71xx/config-4.1 | 1 +
.../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 145 +
target/linux/ar71xx/generic/profiles/weio.mk | 17 +++
target/linux/ar71xx/image/Makefile | 8 ++
.../700-MIPS-ath79-openwrt-machines.patch | 21 ++-
7 files changed, 192 insertions(+), 6 deletions(-)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index e1f345e..e30cac2 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -832,6 +832,9 @@ ar71xx_board_detect() {
*"UniFi AP Pro")
name="uap-pro"
;;
+ *"WeIO")
+ name="weio"
+ ;;
*WHR-G301N)
name="whr-g301n"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index c1962e4..b681fb8 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -250,7 +250,8 @@ platform_check_image() {
nbg460n_550n_550nh | \
unifi | \
unifi-outdoor | \
- carambola2 )
+ carambola2 | \
+ weio )
[ "$magic" != "2705" ] && {
echo "Invalid image type."
return 1
diff --git a/target/linux/ar71xx/config-4.1 b/target/linux/ar71xx/config-4.1
index 21c4601..7d836d9 100644
--- a/target/linux/ar71xx/config-4.1
+++ b/target/linux/ar71xx/config-4.1
@@ -139,6 +139,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
CONFIG_ATH79_MACH_TUBE2H=y
CONFIG_ATH79_MACH_UBNT=y
CONFIG_ATH79_MACH_UBNT_XM=y
+CONFIG_ATH79_MACH_WEIO=y
CONFIG_ATH79_MACH_WHR_HP_G300N=y
CONFIG_ATH79_MACH_WLAE_AG300N=y
CONFIG_ATH79_MACH_WLR8100=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
new file mode 100644
index 000..791991c
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
@@ -0,0 +1,145 @@
+/**
+ * WEIO Web Of Things Platform
+ *
+ * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
+ *
+ * ## ## ###
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ### ### ###
+ *
+ * Web Of Things Platform
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Authors :
+ * Drasko DRASKOVIC
+ * Uros PETREVSKI
+ */
+
+#include
+#include
+#include "common.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-spi.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+#include "linux/i2c-gpio.h"
+#include "linux/platform_device.h"
+
+#define WEIO_GPIO_LED_STA 1
+#define WEIO_GPIO_LED_AP 16
+
+#define WEIO_GPIO_BTN_AP 20
+#define WEIO_GPIO_BTN_RESET23
+
+#define WEIO_KEYS_POLL_INTERVAL20 /* msecs */
+#define WEIO_KEYS_DEBOUNCE_INTERVAL(3 * WEIO_KEYS_POLL_INTERVAL)
+
+#define WEIO_MAC0_OFFSET 0x
+#define WEIO_MAC1_OFFSET 0x0006
+#define WEIO_CALDATA_OFFSET0x1000
+#define WEIO_WMAC_MAC_OFFSET 0x1002
+
+static struct gpio_led weio_leds_gpio[] __initdata = {
+{
+.name = "weio:green:sta",
+.gpio = WEIO_GPIO_LED_STA,
+.active_low= 1,
+.default_state = LEDS_GPIO_DEFSTATE_ON,
+}, {
+.name = "weio:green:ap",
+.gp
Re: [OpenWrt-Devel] Removing Telnet
Am Dienstag, 8. September 2015, 10:15:52 schrieb Steven Barth: > Hello everyone, > > as of https://dev.openwrt.org/changeset/46809 telnet is no longer part of > the base images. As a replacement, it is now possible to login to the root- > account via SSH without a password prompt whenever no root password is set, > e.g. after a flash without keeping config, factory reset or in failsafe. > > We will see how that goes. Let us know if there are any issues. just for the record, at my last employer, we developed various custom OpenWrt based embedded devices. During manufacturing process, we had a stage where the final device was equipped with serial numbers, mac addresses and so on - we called this stage 'device baptism'. So was done by logging into the device via telnet, because this was fast and available nearly immediately after reboot (and because the somewhat old-fashion production toolsuite only supports telnet, but not SSH). I also remember that "long time ago" there were issues because of not enough entropy available on embedded devices. Is this still an issue? Should only delay the time when logging in is possible, right? So...I'll dry my tears and then go with it :-) Regards, Michael ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Removing Telnet
Il 08.09.2015 21:31 Michael Heimpold ha scritto: I also remember that "long time ago" there were issues because of not enough entropy available on embedded devices. Is this still an issue? Should only delay the time when logging in is possible, right? The dropbearkey key generation will delay dropbear start, so it will reply with connection refused until it's ready. It would be worth trying the -R option instead of dropbearkey... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix ar724x clock calculation
Signed-off-by: Weijie Gao
According to the AR7242 datasheet section 2.8, AR724X CPUs use a 40MHz
input clock as the REF_CLK instead of 5MHz.
The correct CPU PLL calculation procedure is as follows:
CPU_PLL = (DIV * REF_CLK) / REF_DIV / 2.
This patch is compatible with the current calculation procedure with default
DIV and REF_DIV values.
Test on both AR7240, AR7241 and AR7242.
---
...MIPS-ath79-ar724x-clock-calculation-fixes.patch | 22 ++
1 file changed, 22 insertions(+)
create mode 100644
target/linux/ar71xx/patches-4.1/634-MIPS-ath79-ar724x-clock-calculation-fixes.patch
diff --git
a/target/linux/ar71xx/patches-4.1/634-MIPS-ath79-ar724x-clock-calculation-fixes.patch
b/target/linux/ar71xx/patches-4.1/634-MIPS-ath79-ar724x-clock-calculation-fixes.patch
new file mode 100644
index 000..16d4621
--- /dev/null
+++
b/target/linux/ar71xx/patches-4.1/634-MIPS-ath79-ar724x-clock-calculation-fixes.patch
@@ -0,0 +1,22 @@
+--- a/arch/mips/ath79/clock.c
b/arch/mips/ath79/clock.c
+@@ -25,7 +25,7 @@
+ #include "common.h"
+
+ #define AR71XX_BASE_FREQ 4000
+-#define AR724X_BASE_FREQ 500
++#define AR724X_BASE_FREQ 4000
+ #define AR913X_BASE_FREQ 500
+
+ struct clk {
+@@ -99,8 +99,8 @@
+ div = ((pll >> AR724X_PLL_DIV_SHIFT) & AR724X_PLL_DIV_MASK);
+ freq = div * ref_rate;
+
+- div = ((pll >> AR724X_PLL_REF_DIV_SHIFT) & AR724X_PLL_REF_DIV_MASK);
+- freq *= div;
++ div = ((pll >> AR724X_PLL_REF_DIV_SHIFT) & AR724X_PLL_REF_DIV_MASK) * 2;
++ freq /= div;
+
+ cpu_rate = freq;
+
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Removing Telnet
Hello Michael, that is interesting, though I guess since these are mainly our default it shouldn't be too hard for someone manufacturing to change the config and readd a simple init-script for telnetd if that is really required. Lack of entropy doesn't seem to be too much of an issue here, in fact in failsafe mode we generate a 1024 bit RSA-key on demand which takes <2s on my old Buffalo here. Granted its only 1024-bit but still. Now the regular keys are 2048-bit which takes about a minute which could be seen as problematic. However in the verge of making these changes we also removed DSS support and removed some of the ciphers (3DES, Twofish) and CBC mode in general as well, so we at least save ourselves the DSS key generation. In the future we might want to switch to add ed25519 since its more secure and probably faster than the classical approaches mechanisms here, but we have to ensure that it is compatible with at least most common SSH clients out there, mainly probably Putty on Windows and OpenSSH on Linux & OS X. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
