Re: [OpenWrt-Devel] b53: leaking packets for a second during initialization?
2014-01-30 Rafał Miłecki zaj...@gmail.com: * CONCLUSION * b53_switch_reset_gpio resets switch into a vulnerable state, where machine behind the WAN can access LAN machines. We need to put switch in some safe state before we call b53_switch_reset_gpio. Example of configuring ports into a safe state is b53_enable_ports. Any idea what exactly we should do before calling b53_switch_reset_gpio? I started wondering how Broadcom does handle this. In bcmrobo.c (bcm_robo_attach): http://svn.dd-wrt.com/browser/src/linux/universal/linux-3.10/brcm/mipsel/shared/bcmrobo.c?rev=23025 they also do GPIO reset as the first thing. So maybe it's something about the time when bcm_robo_attach should be called? Can putting PHY in some specific state stop switch? I looked at etcgmac.c (chipattach): http://svn.dd-wrt.com/browser/src/linux/universal/linux-3.10/brcm/mipsel/et/sys/etcgmac.c?rev=23025 and Broadcom calls bcm_robo_attach right after: /* reset phy: reset it once now */ chipphyreset(ch, etc-phyaddr); But we do the same in bgmac.c. We call bgmac_phy_reset(bgmac); and then we call bgmac_mii_register(bgmac); -- Rafał ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] pyload: update to current version 0.4.9
Signed-off-by: Oliver Ertl oli...@ertls-netzwerk.de --- net/pyload/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/pyload/Makefile b/net/pyload/Makefile index 4a5d9e4..bdb60ca 100644 --- a/net/pyload/Makefile +++ b/net/pyload/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2011 OpenWrt.org +# Copyright (C) 2011-2014 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=pyload -PKG_VERSION:=0.4.8 +PKG_VERSION:=0.4.9 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-src-v$(PKG_VERSION).zip PKG_SOURCE_URL:=http://download.pyload.org/ -PKG_MD5SUM:=5bcf8411ef9e48ef6e9ade55bc697900 +PKG_MD5SUM:=28876150af22999b6f539c8579d3b415 PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)/ -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/2] *** SUBJECT HERE ***
*** BLURB HERE *** Oliver Ertl (2): pyload: update to current version 0.4.9 pyload: add LIBCURL_COOKIES dependency net/pyload/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] pyload: add LIBCURL_COOKIES dependency
Signed-off-by: Oliver Ertl oli...@ertls-netzwerk.de --- net/pyload/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/pyload/Makefile b/net/pyload/Makefile index bdb60ca..d6f237c 100644 --- a/net/pyload/Makefile +++ b/net/pyload/Makefile @@ -26,7 +26,7 @@ define Package/pyload CATEGORY:=Network DEPENDS:=+python +pyopenssl +python-curl +python-crypto +python-django \ +python-expat +python-imaging-library +python-sqlite3 +js \ - +tesseract +unrar + +tesseract +unrar +@LIBCURL_COOKIES TITLE:=A fast, lightweight and full featured download manager URL:=http://pyload.org endef -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [packages] dropbear: update to 2013.62
support ecdsa and refresh patches
Signed-off-by: Reiner Herrmann rei...@reiner-h.de
---
package/network/services/dropbear/Makefile | 8 +---
.../network/services/dropbear/files/dropbear.init | 11 +++
.../services/dropbear/patches/100-pubkey_path.patch | 4 ++--
.../services/dropbear/patches/110-change_user.patch | 2 +-
.../dropbear/patches/120-openwrt_options.patch | 21 ++---
.../dropbear/patches/140-disable_assert.patch | 2 +-
.../dropbear/patches/150-dbconvert_standalone.patch | 6 +++---
.../dropbear/patches/200-lcrypt_bsdfix.patch| 8
.../dropbear/patches/500-set-default-path.patch | 2 +-
9 files changed, 30 insertions(+), 34 deletions(-)
diff --git a/package/network/services/dropbear/Makefile
b/package/network/services/dropbear/Makefile
index 02be761..04dd8b9 100644
--- a/package/network/services/dropbear/Makefile
+++ b/package/network/services/dropbear/Makefile
@@ -8,14 +8,14 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=dropbear
-PKG_VERSION:=2013.59
+PKG_VERSION:=2013.62
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:= \
http://matt.ucc.asn.au/dropbear/releases/ \
https://dropbear.nl/mirror/releases/
-PKG_MD5SUM:=6c1e6c2c297f4034488ffc95e8b7e6e9
+PKG_MD5SUM:=ca2c7932a1399cf361f795aaa3843998
PKG_LICENSE:=MIT
PKG_LICENSE_FILES:=LICENSE libtomcrypt/LICENSE libtommath/LICENSE
@@ -41,7 +41,8 @@ endef
define Package/dropbear/conffiles
/etc/dropbear/dropbear_rsa_host_key
-/etc/dropbear/dropbear_dss_host_key
+/etc/dropbear/dropbear_dss_host_key
+/etc/dropbear/dropbear_ecdsa_host_key
/etc/config/dropbear
endef
@@ -98,6 +99,7 @@ define Package/dropbear/install
$(INSTALL_DIR) $(1)/etc/dropbear
touch $(1)/etc/dropbear/dropbear_rsa_host_key
touch $(1)/etc/dropbear/dropbear_dss_host_key
+ touch $(1)/etc/dropbear/dropbear_ecdsa_host_key
endef
define Package/dropbearconvert/install
diff --git a/package/network/services/dropbear/files/dropbear.init
b/package/network/services/dropbear/files/dropbear.init
index ebef526..a2fedcd 100755
--- a/package/network/services/dropbear/files/dropbear.init
+++ b/package/network/services/dropbear/files/dropbear.init
@@ -43,6 +43,7 @@ validate_section_dropbear()
'RootLogin:bool:1' \
'rsakeyfile:file' \
'dsskeyfile:file' \
+ 'ecdsakeyfile:file' \
'BannerFile:file' \
'Port:list(port):22'
return $?
@@ -52,7 +53,7 @@ dropbear_instance()
{
local PasswordAuth enable Interface GatewayPorts \
RootPasswordAuth RootLogin rsakeyfile \
- dsskeyfile BannerFile Port
+ dsskeyfile ecdsakeyfile BannerFile Port
validate_section_dropbear ${1} || {
echo validation failed
@@ -70,7 +71,8 @@ dropbear_instance()
[ ${RootPasswordAuth} -eq 0 ] procd_append_param command -g
[ ${RootLogin} -eq 0 ] procd_append_param command -w
[ -n ${rsakeyfile} ] procd_append_param command -r ${rsakeyfile}
- [ -n ${dsskeyfile} ] procd_append_param command -d ${dsskeyfile}
+ [ -n ${dsskeyfile} ] procd_append_param command -r ${dsskeyfile}
+ [ -n ${ecdsakeyfile} ] procd_append_param command -r
${ecdsakeyfile}
[ -n ${BannerFile} ] procd_append_param command -b ${BannerFile}
[ -n ${interface} ] network_get_device interface ${interface}
append_ports ${interface} ${Port}
@@ -79,7 +81,7 @@ dropbear_instance()
keygen()
{
- for keytype in rsa dss; do
+ for keytype in rsa dss ecdsa; do
# check for keys
key=dropbear/dropbear_${keytype}_host_key
[ -f /tmp/$key -o -s /etc/$key ] || {
@@ -103,7 +105,8 @@ keygen()
start_service()
{
[ -s /etc/dropbear/dropbear_rsa_host_key -a \
- -s /etc/dropbear/dropbear_dss_host_key ] || keygen
+ -s /etc/dropbear/dropbear_dss_host_key -a \
+ -s /etc/dropbear/dropbear_ecdsa_host_key ] || keygen
. /lib/functions.sh
. /lib/functions/network.sh
diff --git a/package/network/services/dropbear/patches/100-pubkey_path.patch
b/package/network/services/dropbear/patches/100-pubkey_path.patch
index c1802f5..456874b 100644
--- a/package/network/services/dropbear/patches/100-pubkey_path.patch
+++ b/package/network/services/dropbear/patches/100-pubkey_path.patch
@@ -1,6 +1,6 @@
--- a/svr-authpubkey.c
+++ b/svr-authpubkey.c
-@@ -209,17 +209,21 @@ static int checkpubkey(unsigned char* al
+@@ -208,17 +208,21 @@ static int checkpubkey(unsigned char* al
goto out;
}
@@ -33,7 +33,7 @@
if (authfile == NULL) {
goto out;
}
-@@ -372,26 +376,35 @@ static int checkpubkeyperms() {
+@@ -371,26 +375,35 @@ static int checkpubkeyperms() {
goto out;
}
diff --git
Re: [OpenWrt-Devel] [PATCH] hostapd: fix basic_rate list format
On 2014-01-30 09:52, Daniel wrote: hostapd expects basic_rates list to be space separated and in 100kbit/s units. This patch would have broken the other uses of hostapd_add_rate. I've committed a fix in r39431 - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] pyload: add LIBCURL_COOKIES dependency
On Fri, Jan 31, 2014 at 10:31 AM, Oliver Ertl oli...@ertls-netzwerk.de wrote: Signed-off-by: Oliver Ertl oli...@ertls-netzwerk.de Please describe in a sentence why this change is necessary. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] *** SUBJECT HERE ***
On Fri, Jan 31, 2014 at 10:31 AM, Oliver Ertl oli...@ertls-netzwerk.de wrote: *** BLURB HERE *** I guess you forgot to fill in something here. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] *** SUBJECT HERE ***
Ok, you can delete the patches then. No need for the patch then :-( Am 31. Januar 2014 12:38:43 schrieb Jonas Gorski j...@openwrt.org: On Fri, Jan 31, 2014 at 10:31 AM, Oliver Ertl oli...@ertls-netzwerk.de wrote: *** BLURB HERE *** I guess you forgot to fill in something here. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
On 2014-01-16 13:40, Sven Eckelmann wrote:
From: Matti Laakso malaa...@elisanet.fi
This patch introduces 802.11ac support to base-files, mac80211 and hostapd.
The
split of VHT160 in two 80 MHz bands is not yet supported, since it requires an
additional user supplied parameter for the channel of the second band.
Signed-off-by: Matti Laakso malaa...@elisanet.fi
Signed-off-by: Simon Wunderlich si...@open-mesh.com
[s...@open-mesh.com: Rebased patch, renamed hwmode to ac,
fixed hostapd integration]
Signed-off-by: Sven Eckelmann s...@open-mesh.com
---
v2:
* reordered package/kernel/mac80211/files/lib/wifi/mac80211.sh to avoid
11aca mode on 5GHz-only devices
package/base-files/files/sbin/wifi | 9 +++-
.../mac80211/files/lib/netifd/wireless/mac80211.sh | 43 ++
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 51
+-
.../config/netifd/patches/002-vht_support.patch| 42 ++
.../services/hostapd/files/hostapd-full.config | 3 ++
.../services/hostapd/files/hostapd-mini.config | 3 ++
6 files changed, 148 insertions(+), 3 deletions(-)
create mode 100644
package/network/config/netifd/patches/002-vht_support.patch
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index 051bc89..2c6de96 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -72,7 +72,7 @@ prepare_key_wep() {
wifi_fixup_hwmode() {
local device=$1
local default=$2
- local hwmode hwmode_11n
+ local hwmode hwmode_11n hwmode_11ac
config_get channel $device channel
config_get hwmode $device hwmode
@@ -89,6 +89,12 @@ wifi_fixup_hwmode() {
esac
config_set $device hwmode_11n $hwmode_11n
;;
+ 11ac)
+ hwmode_11n=a
+ hwmode_11ac=a
+ config_set $device hwmode_11n $hwmode_11n
+ config_set $device hwmode_11ac $hwmode_11ac
+ ;;
*)
hwmode=
if [ ${channel:-0} -gt 0 ]; then
@@ -203,6 +209,7 @@ scan_wifi() {
append DEVICES $section
config_set $section vifs
config_set $section ht_capab
+ config_set $section vht_capab
;;
esac
I think all of the above changes are unnecessary.
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 1896fe0..301ec22 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -23,6 +23,7 @@ drv_mac80211_init_device_config() {
config_add_int rxantenna txantenna antenna_gain txpower
config_add_boolean noscan
config_add_array ht_capab
+ config_add_array vht_capab
}
drv_mac80211_init_iface_config() {
@@ -63,6 +64,48 @@ mac80211_hostapd_setup_base() {
[ -n $ht_capab ] append base_cfg ht_capab=$ht_capab $N
}
+ [ $enable_vht -gt 0 ] {
+ append base_cfg ieee80211ac=1 $N
+
+ json_get_values vht_capab_list vht_capab
+ idx=$channel
+ case $vhtmode in
+ VHT80)
+ case $channel in
+ 36|40|44|48) idx=42;;
+ 52|56|60|64) idx=58;;
+ 100|104|108|112) idx=106;;
+ 116|120|124|128) idx=122;;
+ 132|136|140|144) idx=138;;
+ 149|153|157|161) idx=155;;
+ esac
+ append base_cfg vht_oper_chwidth=1 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT160)
+ case $channel in
+ 36|40|44|48|52|56|60|64) idx=50;;
+ 100|104|108|112|116|120|124|128)
idx=114;;
+ esac
+ append base_cfg vht_oper_chwidth=2 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ *)
+ case $htmode in
+ HT20) ;;
+ HT40+) idx=$((idx+2));;
+ HT40-) idx=$((idx-2));;
+ esac
+ append base_cfg vht_oper_chwidth=0 $N
+
Re: [OpenWrt-Devel] [PATCH] [package] iw: update to 3.13
On 2014-01-23 12:23, Dirk Neukirchen wrote: update to 3.13 refresh and delete obsolete patches 200-reduce_size.patch has coalesce removed from Makefile iw 3.10 vs. 3.13: 92456 Jan 21 11:29 /usr/sbin/iw 97288 Jan 23 10:33 build_dir/target-mips_34kc_uClibc-0.9.33.2/iw-3.13/ipkg-ar71xx/iw/usr/sbin/iw Signed-off-by: Dirk Neukirchen dirkneukirc...@web.de I tried to apply the patch but got rejects and it didn't work. Please resend a working patch. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath10k: add all patches from trunk, change to 10.x firmware
On 2014-01-16 11:48, Sven Eckelmann wrote: From: Simon Wunderlich si...@open-mesh.com The current version of the driver includes a lot of bug fixes necessary to get 802.11ac connections working at all. These patches also need a never firmware to work correctly. Signed-off-by: Simon Wunderlich si...@open-mesh.com [s...@open-mesh.com: Refreshed patches] Signed-off-by: Sven Eckelmann s...@open-mesh.com Please try with the current version and send the firmware update patch separately. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [packages] dropbear: update to 2013.62
Hi, whats the size increase of the dropbear package? ~ Jow signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] *** SUBJECT HERE ***
On 01/31/2014 01:49 PM, Oliver Ertl wrote: Ok, you can delete the patches then. No need for the patch then :-( Hey Oliver , it's just the patch guideline , Jonas trying to help you submit a full decent patch, no need to be upset ;-) Am 31. Januar 2014 12:38:43 schrieb Jonas Gorski j...@openwrt.org: On Fri, Jan 31, 2014 at 10:31 AM, Oliver Ertl oli...@ertls-netzwerk.de wrote: *** BLURB HERE *** I guess you forgot to fill in something here. Jonas ___ 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] [packages] dropbear: update to 2013.62
On Fri, Jan 31, 2014 at 01:22:32PM +0100, Jo-Philipp Wich wrote: whats the size increase of the dropbear package? 2013.59: 80789 bytes 2013.62: 98661 bytes So the increase is about 18 kB. signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/2] *** SUBJECT HERE ***
On Fri, Jan 31, 2014 at 1:34 PM, Daniel Petre daniel.pe...@gmail.com wrote: On 01/31/2014 01:49 PM, Oliver Ertl wrote: Ok, you can delete the patches then. No need for the patch then :-( Hey Oliver , it's just the patch guideline , Jonas trying to help you submit a full decent patch, no need to be upset ;-) That's my intention. Actually the cover-letter could be just dropped. You usually only need it for bigger series to add a detailed explanation that is too big for the individual patches, or to note on which git tree something is based on, or if there are certain other patches that this patchset depend on, and other things that shouldn't be in the commit log. Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
On Friday 31 January 2014 03:54:19 Felix Fietkau wrote:
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -72,7 +72,7 @@ prepare_key_wep() {
wifi_fixup_hwmode() {
local device=$1
local default=$2
- local hwmode hwmode_11n
+ local hwmode hwmode_11n hwmode_11ac
config_get channel $device channel
config_get hwmode $device hwmode
@@ -89,6 +89,12 @@ wifi_fixup_hwmode() {
esac
config_set $device hwmode_11n $hwmode_11n
;;
+ 11ac)
+ hwmode_11n=a
+ hwmode_11ac=a
+ config_set $device hwmode_11n $hwmode_11n
+ config_set $device hwmode_11ac $hwmode_11ac
+ ;;
*)
hwmode=
if [ ${channel:-0} -gt 0 ]; then
@@ -203,6 +209,7 @@ scan_wifi() {
append DEVICES $section
config_set $section vifs
config_set $section ht_capab
+ config_set $section vht_capab
;;
esac
I think all of the above changes are unnecessary.
Because of your next suggestion or is there another reason?
[...]
I think reusing htmode instead of introducing vhtmode would be a better
choice, especially since it never makes sense to configure both separately.
So we would change it to just use VHT40, VHT80, VHT160 and someone could
later introduce options to configure the center freq0 (and maybe freq1 for
80+80mhz mode) manually with another option.
[...]
- option hwmode 11${mode_11n}${mode_band}
+ option hwmode 11${mode_11ac}${mode_11n}${mode_band}
$dev_id
$ht_capab
+$vht_capab
# REMOVE THIS LINE TO ENABLE WIFI:
option disabled 1
I think we should probably introduce a new option that avoids the
overload of mode and band into one single option. We can keep backwards
compatibility for 11n.
I am not quite sure what you want to say here. You seem to want to have 11n
and band separated, ok. Are you now suggestion that the uci should get a new
option to say enable ht/disable ht? Wouldn't it make more sense to just to
keep mode_11n as it was before and make the decision whether ieee80211ac=1 can
be enabled on the modified htmode wireless option?
At the end I would suggest following approach:
* Introduce wireless.@wifi-device[*].vht_capab with a similar function as
list ht_capab
* Allow VHT40, VHT80 (default when AC is found), VHT160 in htmode
* enable ieee80211ac=1 when one of the new htmode's are found
This would mean following user visible changes to the patch:
* no wireless.@wifi-device[*].vhtmode
* no wireless.@wifi-device[*].hwmode='11ac' and instead 11na would be the
default for AC devices
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
On Friday 31 January 2014 06:06:58 Felix Fietkau wrote: [...] I think all of the above changes are unnecessary. Because of your next suggestion or is there another reason? Because it's touching legacy code that will not be used for 802.11ac drivers. wifi_fixup_hwmode is not called from netifd based scripts. Ok, thanks for the explanation. [...] I am not quite sure what you want to say here. You seem to want to have 11n and band separated, ok. Are you now suggestion that the uci should get a new option to say enable ht/disable ht? Wouldn't it make more sense to just to keep mode_11n as it was before and make the decision whether ieee80211ac=1 can be enabled on the modified htmode wireless option? I think in new configs, the mode should only be 11a or 11g, and 802.11n/802.11ac is enabled through the htmode option. 11na and 11ng would only be supported for compatibility reasons. Ok, sounds good. I will avoid to touch it. At the end I would suggest following approach: * Introduce wireless.@wifi-device[*].vht_capab with a similar function as list ht_capab I actually want to get rid of ht_capab as well, because it's annoying to deal with wrt. UI, config changes, etc. It also makes it more annoying to port configs between devices (capabilities might be different). I would prefer enabling all capabilities by default (aside from the mode related ones), and allowing the user to selectively disable them via individual bool options. Example: option rx_stbc_123 0 Sounds interesting. Do you want to implement it in the next days or should we proceed by leaving it in the patch and let you remove it during your modifications? * Allow VHT40, VHT80 (default when AC is found), VHT160 in htmode * enable ieee80211ac=1 when one of the new htmode's are found This would mean following user visible changes to the patch: * no wireless.@wifi-device[*].vhtmode * no wireless.@wifi-device[*].hwmode='11ac' and instead 11na would be the default for AC devices Right, in addition to what I mentioned above. Ok. Kind regards, Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
I actually want to get rid of ht_capab as well, because it's annoying to deal with wrt. UI, config changes, etc. It also makes it more annoying to port configs between devices (capabilities might be different). I would prefer enabling all capabilities by default (aside from the mode related ones), and allowing the user to selectively disable them via individual bool options. Example: option rx_stbc_123 0 So just to be clear, your idea is that the capabilities would be queried with iw (or is there a better way?) and set up in mac80211_hostapd_setup_base() every time hostapd is started? Matti ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
2014-01-31 Sven Eckelmann s...@open-mesh.com: I think reusing htmode instead of introducing vhtmode would be a better choice, especially since it never makes sense to configure both separately. So we would change it to just use VHT40, VHT80, VHT160 and someone could later introduce options to configure the center freq0 (and maybe freq1 for 80+80mhz mode) manually with another option. Why anyone would like to configure center frequency instead of primary channel? In 802.11ac for every primary channel you have a pre-defined center frequency for 40MHz, 80MHz and 160MHz. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv3] wifi: Introduce 802.11ac support
From: Matti Laakso malaa...@elisanet.fi
This patch introduces 802.11ac support to base-files, mac80211 and hostapd. The
split of VHT160 in two 80 MHz bands is not yet supported, since it requires an
additional user supplied parameter for the channel of the second band.
Signed-off-by: Matti Laakso malaa...@elisanet.fi
Signed-off-by: Simon Wunderlich si...@open-mesh.com
[s...@open-mesh.com: Rebased patch, merged htmode and vhtmode,
removed special hwmode, fixed hostapd integration]
Signed-off-by: Sven Eckelmann s...@open-mesh.com
---
v3: see http://article.gmane.org/gmane.comp.embedded.openwrt.devel/22511
The ath10k patch wasn't resent because the driver patches are now integrated
in the OpenWrt mac80211 package. The answer in
http://article.gmane.org/gmane.comp.embedded.openwrt.devel/22422 also wasn't
quite promising.
.../mac80211/files/lib/netifd/wireless/mac80211.sh | 61 +-
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 41 ++-
.../services/hostapd/files/hostapd-full.config | 3 ++
.../services/hostapd/files/hostapd-mini.config | 3 ++
4 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 1896fe0..71d565e 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -23,6 +23,7 @@ drv_mac80211_init_device_config() {
config_add_int rxantenna txantenna antenna_gain txpower
config_add_boolean noscan
config_add_array ht_capab
+ config_add_array vht_capab
}
drv_mac80211_init_iface_config() {
@@ -55,12 +56,70 @@ mac80211_hostapd_setup_base() {
append base_cfg ieee80211n=1 $N
ht_capab=
- [ -n $htmode ] ht_capab=[$htmode]
+ case $htmode in
+ HT20|HT40-|HT40+) ht_capab=[$htmode];;
+ VHT40|VHT80|VHT160) ht_capab=[HT40+];;
+ esac
for cap in $ht_capab_list; do
ht_capab=$ht_capab[$cap]
done
[ -n $ht_capab ] append base_cfg ht_capab=$ht_capab $N
+
+ # 802.11ac
+ enable_ac=0
+ json_get_values vht_capab_list vht_capab
+ idx=$channel
+ case $htmode in
+ VHT40)
+ case $channel in
+ 36|40) idx=38;;
+ 44|48) idx=42;;
+ 52|56) idx=54;;
+ 60|64) idx=58;;
+ 100|104) idx=102;;
+ 108|112) idx=110;;
+ 116|120) idx=118;;
+ 124|128) idx=126;;
+ 132|136) idx=134;;
+ 140|144) idx=142;;
+ 149|153) idx=151;;
+ 157|161) idx=159;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=0 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT80)
+ case $channel in
+ 36|40|44|48) idx=42;;
+ 52|56|60|64) idx=58;;
+ 100|104|108|112) idx=106;;
+ 116|120|124|128) idx=122;;
+ 132|136|140|144) idx=138;;
+ 149|153|157|161) idx=155;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=1 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT160)
+ case $channel in
+ 36|40|44|48|52|56|60|64) idx=50;;
+ 100|104|108|112|116|120|124|128)
idx=114;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=2 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ esac
+ if [ $enable_ac != 0 ]; then
+ append base_cfg ieee80211ac=1 $N
+ for cap in $vht_capab_list; do
+ vht_capab=$vht_capab[$cap]
+ done
+
Re: [OpenWrt-Devel] [PATCHv3] wifi: Introduce 802.11ac support
@@ -55,12 +56,70 @@ mac80211_hostapd_setup_base() {
append base_cfg ieee80211n=1 $N
ht_capab=
- [ -n $htmode ] ht_capab=[$htmode]
+ case $htmode in
+ HT20|HT40-|HT40+) ht_capab=[$htmode];;
+ VHT40|VHT80|VHT160) ht_capab=[HT40+];;
+ esac
for cap in $ht_capab_list; do
ht_capab=$ht_capab[$cap]
done
I don't think that you can set ht_capab=[HT40+] indiscriminately here.
If I pick channel 40, for example, it must be [HT40-] or otherwise
hostapd will refuse to start.
Matti
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv3] wifi: Introduce 802.11ac support
On Friday 31 January 2014 08:38:40 Matti Laakso wrote:
@@ -55,12 +56,70 @@ mac80211_hostapd_setup_base() {
append base_cfg ieee80211n=1 $N
ht_capab=
- [ -n $htmode ] ht_capab=[$htmode]
+ case $htmode in
+ HT20|HT40-|HT40+) ht_capab=[$htmode];;
+ VHT40|VHT80|VHT160) ht_capab=[HT40+];;
+ esac
for cap in $ht_capab_list; do
ht_capab=$ht_capab[$cap]
done
I don't think that you can set ht_capab=[HT40+] indiscriminately here.
If I pick channel 40, for example, it must be [HT40-] or otherwise
hostapd will refuse to start.
Matti
How do you want to proceed to avoid this channel autoconfig from your patch?
Kind regards,
Sven
signature.asc
Description: This is a digitally signed message part.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Fwd: Adding MTU configuration support to n2n package.
The n2n VPN package loses stability if the MTU is configured to be too
large. The current n2n package does not permit the mtu to be adjusted and
thus defaults to 1400 which is not a good level to use as a default
setting. This patch adds the 'mtu' setting option in /etc/config/n2n and
modifies the /etc/init.d/n2n script to look for that setting, defaulting to
1300 if it is not provided.
diff --git a/net/n2n/files/n2n.config b/net/n2n/files/n2n.config
index bf4acfe..5088589 100644
--- a/net/n2n/files/n2n.config
+++ b/net/n2n/files/n2n.config
@@ -5,3 +5,4 @@ config edge
option community ''
option key ''
option route ''
+option mtu ''
diff --git a/net/n2n/files/n2n.init b/net/n2n/files/n2n.init
index 2454de2..b31ca64 100644
--- a/net/n2n/files/n2n.init
+++ b/net/n2n/files/n2n.init
@@ -18,7 +18,9 @@ start_instance() {
config_get key $cfg 'key'
config_get_bool route $cfg 'route' '0'
[ $route = 1 ] args='-r'
- service_start /usr/sbin/edge -f $args -a $ipaddr -c $community -k $key -l
${supernode}:${port}
+config_get key $cfg 'mtu'
+[ -n $mtu ] || mtu='1300'
+ service_start /usr/sbin/edge -f $args -a $ipaddr -c $community -k $key -M
$mtu -l ${supernode}:${port}
;;
supernode)
config_get port $cfg port
--
Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot.
--Sergey Brin, demonstrating the emptiness of the don't be evil mantra.
--
Perhaps people don't believe this, but throughout all of the discussions
of entering China our focus has really been what's best for the Chinese
people. It's not been about our revenue or profit or whatnot.
--Sergey Brin, demonstrating the emptiness of the don't be evil mantra.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
2014-01-31 Felix Fietkau n...@openwrt.org: I think we should probably introduce a new option that avoids the overload of mode and band into one single option. We can keep backwards compatibility for 11n. I am not quite sure what you want to say here. You seem to want to have 11n and band separated, ok. Are you now suggestion that the uci should get a new option to say enable ht/disable ht? Wouldn't it make more sense to just to keep mode_11n as it was before and make the decision whether ieee80211ac=1 can be enabled on the modified htmode wireless option? I think in new configs, the mode should only be 11a or 11g, and 802.11n/802.11ac is enabled through the htmode option. 11na and 11ng would only be supported for compatibility reasons. I can already see people complaining they don't have 802.11n and 802.11ac modes available. GUI would have to be adjuster to hide this internal change (and still show 802.11n as possible choice) to stop that complains. But that would add some hacks in translating GUI (LuCI) - UCI configuration. If you really want to get rid of 802.11an, 802.11n, 802.11ac, what about going into something like 5GHz and 2GHz? Maybe that's a better idea? On the other way, it doesn't make much sense to switch into 5GHz and 2GHz, as this can be determined using just a channel number... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv4] wifi: Introduce 802.11ac support
From: Matti Laakso malaa...@elisanet.fi
This patch introduces 802.11ac support to base-files, mac80211 and hostapd. The
split of VHT160 in two 80 MHz bands is not yet supported, since it requires an
additional user supplied parameter for the channel of the second band.
Signed-off-by: Matti Laakso malaa...@elisanet.fi
Signed-off-by: Simon Wunderlich si...@open-mesh.com
[s...@open-mesh.com: Rebased patch, merged htmode and vhtmode,
removed special hwmode, fixed hostapd integration]
Signed-off-by: Sven Eckelmann s...@open-mesh.com
---
v4: Use autoconfig for HT40-/+ when VHT is activated as reported by Matti Laakso
.../mac80211/files/lib/netifd/wireless/mac80211.sh | 67 +-
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 41 -
.../services/hostapd/files/hostapd-full.config | 3 +
.../services/hostapd/files/hostapd-mini.config | 3 +
4 files changed, 112 insertions(+), 2 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 1896fe0..bb5298d 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -23,6 +23,7 @@ drv_mac80211_init_device_config() {
config_add_int rxantenna txantenna antenna_gain txpower
config_add_boolean noscan
config_add_array ht_capab
+ config_add_array vht_capab
}
drv_mac80211_init_iface_config() {
@@ -55,12 +56,76 @@ mac80211_hostapd_setup_base() {
append base_cfg ieee80211n=1 $N
ht_capab=
- [ -n $htmode ] ht_capab=[$htmode]
+ case $htmode in
+ HT20|HT40-|HT40+) ht_capab=[$htmode];;
+ VHT40|VHT80|VHT160)
+ case $channel in
+
36|44|52|60|100|108|116|124|132|140|149|157) ht_capab=[HT40+];;
+
40|48|56|64|104|112|120|128|136|144|153|161) ht_capab=[HT40-];;
+ esac
+ ;;
+
+ esac
for cap in $ht_capab_list; do
ht_capab=$ht_capab[$cap]
done
[ -n $ht_capab ] append base_cfg ht_capab=$ht_capab $N
+
+ # 802.11ac
+ enable_ac=0
+ json_get_values vht_capab_list vht_capab
+ idx=$channel
+ case $htmode in
+ VHT40)
+ case $channel in
+ 36|40) idx=38;;
+ 44|48) idx=42;;
+ 52|56) idx=54;;
+ 60|64) idx=58;;
+ 100|104) idx=102;;
+ 108|112) idx=110;;
+ 116|120) idx=118;;
+ 124|128) idx=126;;
+ 132|136) idx=134;;
+ 140|144) idx=142;;
+ 149|153) idx=151;;
+ 157|161) idx=159;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=0 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT80)
+ case $channel in
+ 36|40|44|48) idx=42;;
+ 52|56|60|64) idx=58;;
+ 100|104|108|112) idx=106;;
+ 116|120|124|128) idx=122;;
+ 132|136|140|144) idx=138;;
+ 149|153|157|161) idx=155;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=1 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ VHT160)
+ case $channel in
+ 36|40|44|48|52|56|60|64) idx=50;;
+ 100|104|108|112|116|120|124|128)
idx=114;;
+ esac
+ enable_ac=1
+ append base_cfg vht_oper_chwidth=2 $N
+ append base_cfg
vht_oper_centr_freq_seg0_idx=$idx $N
+ ;;
+ esac
+ if [ $enable_ac != 0 ]; then
+ append base_cfg ieee80211ac=1 $N
+
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
* Rafał Miłecki zaj...@gmail.com [31.01.2014 18:20]: On the other way, it doesn't make much sense to switch into 5GHz and 2GHz, as this can be determined using just a channel number... not really. some channels are available in 2 and 5 GHz band. (e.g. channel 7,8,9,11,12) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] bcm6368 + block-mount jffs2 problem.
2014-01-11, José Vázquez ppvazquez...@gmail.com:
2014/1/3, danitool dgcb...@gmail.com:
I'm also having these problems. The bug is very easy to reproduce. Just
using the jffs2 image instead of squashfs, the problems are shown with
the
first boot, and you can see lot of funny names just listing /etc/init.d
root@(none):/# ls -l /etc/init.d/
-rwxr-xr-x1 root root 1993 Jan 2 2014 boot
-rwxr-xr-x1 root root 368 Dec 20 2013 ciciixixmeme
-rwxr-xr-x1 root root 729 Dec 20 2013 cron
-rwxr-xr-x1 root root 3920 Jan 2 2014 dropbear
-rwxr-xr-x1 root root 4173 Jan 2 2014 eleld?d
-rwxr-xr-x1 root root 262 Jan 2 2014 fire
-rwxr-xr-x1 root root 2015 Dec 20 2013 led
-rwxr-xr-x1 root root 926 Dec 20 2013 lnlnet
-rwxr-xr-x1 root root 1694 Jan 2 2014 log
-rwxr-xr-x1 root root 835 Dec 20 2013
lucihchcmimigrate
-rwxr-xr-x1 root root 308 Dec 20 2013 nene
-rwxr-xr-x1 root root 125 Dec 20 2013 scsctl
-rwxr-xr-x1 root root 13640 Jan 2 2014 smsmq?q
-rwxr-xr-x1 root root 718 Dec 20 2013 snsnd?d
-rwxr-xr-x1 root root 945 Jan 2 2014 twtwk?k
-rwxr-xr-x1 root root 3324 Jan 2 2014 uhttpd
-rwxr-xr-x1 root root 106 Jan 2 2014 umount
-rwxr-xr-x1 root root 522 Dec 20 2013 ununndnd
It's like a baby learning to talk.
Since this is happening when using a jffs2 image, overlayfs isn't used,
isn't it?, then the problem shouldn't be related to the overlayfs driver.
Checking Debug object operations (DEBUG_OBJECTS) and its related
options, and Lock debugging: prove locking correctness
(PROVE_LOCKING) the kernel shows this warning in a board based in
BCM6368 (parallel flash), with and without SMP enabled:
[5.854166] hub 2-0:1.0: USB hub found
[5.854166] hub 2-0:1.0: 1 port detected
[5.874999] usbcore: registered new interface driver usb-storage
kmod: ran 1 iterations
[7.041666] jffs2: notice: (251) jffs2_build_xattr_subsystem:
complete building xattr subsystem, 1 of xdatum (0 unchecked,.
[7.062499] [ cut here ]
[7.062499] WARNING: at lib/debugobjects.c:260 debug_print_object+0xb8/0xe4()
[7.062499] ODEBUG: assert_init not available (active state 0)
object type: timer_list hint: stub_timer+0x0/0x10
[7.062499] Modules linked in: usb_storage ohci_hcd ehci_platform
ehci_hcd sd_mod scsi_mod ext4 crc16 jbd2 mbcache usbcoreh
[7.062499] CPU: 0 PID: 251 Comm: block Not tainted 3.10.28 #3
[7.062499] Stack : 8040b842 0032
83a24f10 803248a0 8039a1e3
00fb 8040afe8 83a24f10 8381fa80 0045d65c
7f8b5630 8002dbd4
803a3288 8002afc4 80327888 830ebc8c
830ebc8c 803248a0
830ebc20
...
[7.062499] Call Trace:
[7.062499] [80020e6c] show_stack+0x48/0x70
[7.062499] [8002b0b8] warn_slowpath_common+0x78/0xa8
[7.062499] [8002b114] warn_slowpath_fmt+0x2c/0x38
[7.062499] [8019b0b8] debug_print_object+0xb8/0xe4
[7.062499] [8019bfd4] debug_object_assert_init+0xd0/0x13c
[7.062499] [8003ae04] del_timer+0x20/0x7c
[7.062499] [80047ed4] try_to_grab_pending+0x40/0x1c8
[7.062499] [800495c8] __cancel_work_timer+0x34/0x13c
[7.062499] [801521e8] jffs2_sync_fs+0x20/0x54
[7.062499] [80108550] sync_filesystem+0x60/0xbc
[7.062499] [800dc158] generic_shutdown_super+0x34/0xdc
[7.062499] [801e0468] kill_mtd_super+0x14/0x30
[7.062499] [80152018] jffs2_kill_sb+0x34/0x4c
[7.062499] [800dbf8c] deactivate_locked_super+0x48/0x84
[7.062499] [800fab28] SyS_umount+0x338/0x3ac
[7.062499] [800128e8] stack_done+0x20/0x44
[7.062499]
[7.062499] ---[ end trace 75b840b26e82af40 ]---
[7.229166] INFO: trying to register non-static key.
[7.229166] the code is fine but needs lockdep annotation.
[7.229166] turning off the locking correctness validator.
[7.229166] CPU: 0 PID: 251 Comm: block Tainted: GW3.10.28 #3
[7.229166] Stack : 8040b842 003d
83a24f10 803248a0 8039a1e3
00fb 8040afe8 83a24f10 83bb32a0
8002dbd4
0002 8002af50 80327888 830ebc84
830ebc84 803248a0
830ebc18
...
[7.229166] Call Trace:
[7.229166] [80020e6c] show_stack+0x48/0x70
[7.229166] [80070ab4] __lock_acquire.isra.18+0x1ec/0xcb8
[7.229166] [80071dd4] lock_acquire+0xe0/0x160
[7.229166] [800492dc]
Re: [OpenWrt-Devel] [PATCHv2 1/2] wifi: Introduce 802.11ac support
2014-01-31 Bastian Bittorf bitt...@bluebottle.com: * Rafał Miłecki zaj...@gmail.com [31.01.2014 18:20]: On the other way, it doesn't make much sense to switch into 5GHz and 2GHz, as this can be determined using just a channel number... not really. some channels are available in 2 and 5 GHz band. (e.g. channel 7,8,9,11,12) Oh, I didn't know, thanks! I was sure 36 is the lowest 5GHz channel. Then maybe we should just stick to 5GHz vs. 2GHz choice (as hwmode) instead of 802.11a vs. 802.11g? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Support for USB LTE modems Samsung GT-B3730 / GT-B3710 / GT-B3740
Hi, On Fri, Jan 24, 2014 at 2:27 PM, Stefan Monnier monn...@iro.umontreal.cawrote: I'd like to use a Samsung GT-B3740 USB LTE modem together with OpenWRT. To get it to build just add a declaration to Another option is to compile it directly into your kernel, via make kernel_menuconfig This didn't work. Search using / showed that the driver should be below Device Drivers - Network device support - USB Network Adapters, but I didn't see the USB Network Adapters level. Nonetheless, adding the declaration worked: On Fri, Jan 24, 2014 at 9:57 AM, Matti Laakso malaa...@elisanet.fi wrote: To get it to build just add a declaration to trunk/package/kernel/linux/modules/usb.mk like this: define KernelPackage/usb-net-kalmia TITLE:=Samsung Kalmia based LTE USB modem KCONFIG:=CONFIG_USB_NET_KALMIA FILES:=$(LINUX_DIR)/drivers/net/usb/kalmia.ko AUTOLOAD:=$(call AutoProbe,kalmia) $(call AddDepends/usb-net) endef define KernelPackage/usb-net-kalmia/description Kernel support for Samsung Kalmia based LTE USB modem endef $(eval $(call KernelPackage,usb-net-kalmia)) I must say I'm impressed how easy that was! Can we please add this package to the code base? Can you do that or should I send in a patch for that? Of course, just the package didn't work immediately. Next to the new kmod-usb-net-kalmia package, the modem also required kmod-usb-serial-option. I wasn't sure about usb-modeswitch, so I added it as well. Then the hard part came. According to http://armageddon421.de/?p=165, getting online with the modem involves three steps: 1. Run the chat script and send some AT commands to the modem e.g., to set the APN 2. Get an IP address via DHCP on the wwan0 interface 3. monitor the connection to prevent the serial buffer on the modem from overflowing The third step is tricky. The blog post and also the driver website suggest to run minicom -o -D /dev/ttyUSB0 to achieve this. However, this was not enough in my case. If the connection was idle for more than 15 seconds, the modem froze and only unplugging it did help. A German review of the device mentioned the hang after idle problem as well: http://www.amazon.de/review/RU75XCNJIWI3U/ref=cm_cr_pr_cmt?ie=UTF8ASIN=B004FHW9BWThe reviewer solved it by running a ping every 10 seconds. Not very elegant. Luckily, I found a better solution! I wanted to persist the configuration and therefore I used the LUCI webinterface. To address the first and the second step of the connect process, I created two interfaces in the GUI: a) The first interface is for the wwan0 device. I've set it to DHCP client such that OpenWRT automatically gets the IP address. But before the interface comes up, we have to run the chat script first. b) For the chat script, I set up an UMTS/GPRS/EV-DO interface (/dev/ttyUSB0, APN adjusted). The modem needs a special chat script, so I replaced the content of /etc/chatscripts/3g.chat with the one from http://onny.project-insanity.org/files/chatscript_vodafone.txt and overwrote the APN with the OpenWRT variable. And then it worked! OpenWRT uses interface b) to send the AT commands to the modem and eventually interface a) will come up and provide the connectivity. The downside of this approach is that interface b) wants to setup a PPP connection, but it doesn't succeed with that. Therefore, it keeps retrying all the time and spams the log of the router. On the plus side, thanks to the constant polling of the modem device step 3 from above (monitor the connection + prevent hang after idle by ping) is no longer necessary. The connection is very stable then. Some questions about that: - Are you aware of other UMTS/LTE modems which use the WWAN subsystem and require a chat script for initialization as well? - Can you think of a better way to run the chat script while it's still configurable from the webinterface? - The PPP error messages in the log are a bit annoying and might confuse novices. Can you think of an elegant way to solve this problem? For now, I'd like to make my findings available for others and provide them an easy way to install OpenWRT and set it up. In the long term, I'd like to add support for the modem to the OpenWRT codebase such that no modifications like the replacement of the chat script are necessary and can be set up from the webinterface instead. This leads to several questions: - I'd like to distribute my built image with the kalmia kernel package and the replaced chat script. Are you fine with that? Is there anything I have to take care of? - What's the best way to add device-specific chat scripts and support them in the webinterface? An easy workaround would be to introduce new service types e.g., the user would have to specify a custom service type samsung-gt-b3740. Then, the 3g.sh script could be modified to deal with this type and use the device-specific chat script. The best solution would be if the webinterface detects the modem type and automatically takes care of the
Re: [OpenWrt-Devel] [PATCH 3/3] brcm47xx: new patch adding arch workarounds.c
On 01/29/2014 07:42 PM, Rafał Miłecki wrote:
It was recently sent to linux-mips for comments. It adds workaround for
WNR3500L to enable USB port.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
...X-Add-new-file-for-device-specific-workar.patch | 80
++
...se-fixed-PHY-device-if-we-do-not-find-any.patch | 4 +-
.../brcm47xx/patches-3.10/400-arch-bcm47xx.patch | 2 +-
3 files changed, 83 insertions(+), 3 deletions(-)
create mode 100644
target/linux/brcm47xx/patches-3.10/128-MIPS-BCM47XX-Add-new-file-for-device-specific-workar.patch
diff --git
a/target/linux/brcm47xx/patches-3.10/128-MIPS-BCM47XX-Add-new-file-for-device-specific-workar.patch
b/target/linux/brcm47xx/patches-3.10/128-MIPS-BCM47XX-Add-new-file-for-device-specific-workar.patch
new file mode 100644
index 000..85df79d
--- /dev/null
+++
b/target/linux/brcm47xx/patches-3.10/128-MIPS-BCM47XX-Add-new-file-for-device-specific-workar.patch
@@ -0,0 +1,80 @@
+From ba302722b32f6de4655679a83db1cac63c0ac0ae Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= zaj...@gmail.com
+Date: Wed, 29 Jan 2014 18:06:52 +0100
+Subject: [RFC][PATCH] MIPS: BCM47XX: Add new file for device specific
workarounds
+
+---
+This can calmly wait for 3.15, just wanted to share it.
+---
+ arch/mips/bcm47xx/Makefile | 2 +-
+ arch/mips/bcm47xx/bcm47xx_private.h | 3 +++
+ arch/mips/bcm47xx/setup.c | 1 +
+ arch/mips/bcm47xx/workarounds.c | 25 +
+ 4 files changed, 30 insertions(+), 1 deletion(-)
+ create mode 100644 arch/mips/bcm47xx/workarounds.c
+
+diff --git a/arch/mips/bcm47xx/Makefile b/arch/mips/bcm47xx/Makefile
+index 4688b6a..d58c51b 100644
+--- a/arch/mips/bcm47xx/Makefile
b/arch/mips/bcm47xx/Makefile
+@@ -4,4 +4,4 @@
+ #
+
+ obj-y += irq.o nvram.o prom.o serial.o
setup.o time.o sprom.o
+-obj-y += board.o buttons.o leds.o
++obj-y += board.o buttons.o leds.o
workarounds.o
+diff --git a/arch/mips/bcm47xx/bcm47xx_private.h
b/arch/mips/bcm47xx/bcm47xx_private.h
+index 5c94ace..0194c3b 100644
+--- a/arch/mips/bcm47xx/bcm47xx_private.h
b/arch/mips/bcm47xx/bcm47xx_private.h
+@@ -9,4 +9,7 @@ int __init bcm47xx_buttons_register(void
+ /* leds.c */
+ void __init bcm47xx_leds_register(void);
+
++/* workarounds.c */
++void __init bcm47xx_workarounds(void);
++
+ #endif
+diff --git a/arch/mips/bcm47xx/setup.c b/arch/mips/bcm47xx/setup.c
+index 12d77e9..fdd9692 100644
+--- a/arch/mips/bcm47xx/setup.c
b/arch/mips/bcm47xx/setup.c
+@@ -248,6 +248,7 @@ static int __init bcm47xx_register_bus_c
+
+ bcm47xx_buttons_register();
+ bcm47xx_leds_register();
++bcm47xx_workarounds();
+
+ return 0;
+ }
+diff --git a/arch/mips/bcm47xx/workarounds.c
b/arch/mips/bcm47xx/workarounds.c
+new file mode 100644
+index 000..1644bfc
+--- /dev/null
b/arch/mips/bcm47xx/workarounds.c
+@@ -0,0 +1,25 @@
++#include bcm47xx_private.h
++
++#include linux/gpio.h
++#include bcm47xx_board.h
++#include bcm47xx.h
++
++static void __init bcm47xx_workarounds_netgear_wnr3500l(void)
++{
++/* Set GPIO 12 to 1 to pass power to the USB port */
++gpio_set_value(12, 1);
++}
++
++void __init bcm47xx_workarounds(void)
++{
++enum bcm47xx_board board = bcm47xx_board_get();
++
++switch (board) {
++case BCM47XX_BOARD_NETGEAR_WNR3500L:
++bcm47xx_workarounds_netgear_wnr3500l();
++break;
++
++default:
++pr_debug(No workarounds found (needed?) for this device\n);
Just do nothing in the default case, this would be the case most devices
are using.
++}
++}
diff --git
a/target/linux/brcm47xx/patches-3.10/208-b44-use-fixed-PHY-device-if-we-do-not-find-any.patch
b/target/linux/brcm47xx/patches-3.10/208-b44-use-fixed-PHY-device-if-we-do-not-find-any.patch
index 8974466..94f9875 100644
---
a/target/linux/brcm47xx/patches-3.10/208-b44-use-fixed-PHY-device-if-we-do-not-find-any.patch
+++
b/target/linux/brcm47xx/patches-3.10/208-b44-use-fixed-PHY-device-if-we-do-not-find-any.patch
@@ -43,10 +43,10 @@ Signed-off-by: David S. Miller da...@davemloft.net
static int __init bcm47xx_register_bus_complete(void)
{
switch (bcm47xx_bus_type) {
-@@ -274,6 +283,7 @@ static int __init bcm47xx_register_bus_c
-
+@@ -275,6 +284,7 @@ static int __init bcm47xx_register_bus_c
bcm47xx_buttons_register();
bcm47xx_leds_register();
+ bcm47xx_workarounds();
+fixed_phy_add(PHY_POLL, 0, bcm47xx_fixed_phy_status);
return 0;
diff --git a/target/linux/brcm47xx/patches-3.10/400-arch-bcm47xx.patch
b/target/linux/brcm47xx/patches-3.10/400-arch-bcm47xx.patch
index 24ff064..43aeaf1 100644
--- a/target/linux/brcm47xx/patches-3.10/400-arch-bcm47xx.patch
+++
[OpenWrt-Devel] redis server
Has anyone ported redis server to openwrt? Tried a simple build and it failed... just checking before I spend time tracking down the problem(s) why a simple make didn't work. If not, I'll figure it out next week, and if anyone else is interested in a port let me know. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [REGRESSION] netifd: IPv6 RA on-link route disappearing
Hello great devs, looks like something broke recently on trunk, regarding IPv6 RA handling (proto=dhcpv6) when an interface receives a router advertisement with on-link bit set, it correctly adds the default via, as well as a static route to the local (on-link) network but after some seconds (maybe a minute) that static route disappears, which makes the host use the default via (unnecessarily) to reach other hosts on the local segment. it worked fine with netifd_2013-12-29, albeit the routing table approach was different (it used a separate table) what follows is an insightful log taken from trunk r39428 root@OpenWrt:~# rdisc6 eth1 Soliciting ff02::2 (ff02::2) on eth1... Hop limit : 64 ( 0x40) Stateful address conf.: No Stateful other conf. : No Mobile home agent : No Router preference : medium Neighbor discovery proxy : No Router lifetime : 1800 (0x0708) seconds Reachable time: unspecified (0x) Retransmit time : unspecified (0x) Prefix : 2a00:1508:1:f004::/64 On-link : Yes Autonomous address conf.: Yes Valid time : 3600 (0x0e10) seconds Pref. time : 3600 (0x0e10) seconds MTU : 1500 bytes (valid) Source link-layer address: 90:F6:52:BB:EC:AD Recursive DNS server : 2a00:1508:1:f004::1 DNS server lifetime : 1200 (0x04b0) seconds from fe80::92f6:52ff:febb:ecad root@OpenWrt:~# ip -6 r default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 2a00:1508:1:f004::/64 dev eth1 proto static metric 256 fd03:9cbd:8bca::/60 dev br-lan proto kernel metric 256 unreachable fd03:9cbd:8bca::/48 dev lo proto static metric 2147483647 error -128 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth1 proto kernel metric 256 ### wait a dozen seconds, no more than a minute, and check routing table again: root@OpenWrt:~# ip -6 r default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 fd03:9cbd:8bca::/60 dev br-lan proto kernel metric 256 unreachable fd03:9cbd:8bca::/48 dev lo proto static metric 2147483647 error -128 fe80::/64 dev br-lan proto kernel metric 256 fe80::/64 dev eth1 proto kernel metric 256 root@OpenWrt:~# opkg install /tmp/netifd_2013-12-29-7d79d0a8aa5a5b4c1ed987af119356438d98fe7b_ar71xx.ipk --force-downgrade Downgrading netifd on root from 2014-01-20-88b3e92933925c09cfb6e95e9c8645727654ddf7 to 2013-12-29-7d79d0a8aa5a5b4c1ed987af119356438d98fe7b... Configuring netifd. root@OpenWrt:~# reboot root@OpenWrt:~# rdisc6 eth1 Soliciting ff02::2 (ff02::2) on eth1... [snip] root@OpenWrt:~# ip -6 r s table 1004 default from :: via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 default from 2a00:1508:1:f004::/64 via fe80::92f6:52ff:febb:ecad dev eth1 proto static metric 1024 2a00:1508:1:f004::/64 dev eth1 proto static metric 256 With netifd_2013-12-29, that last rule is never dropped / removed, even after days of uptime Hope that helps chasing the bug, since the bisect window is small: only 3 commits, Add indicator-flags to ubus and hotplug update-events Remove automatically assigned IPv6 routing table # fishy, fishy, fishy fish? ;) Don't add unnecessary NOP policy rules cheers! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
