Re: [LEDE-DEV] [PATCH ubox] cmake: Check for getrandom system call

2017-02-04 Thread Etienne Champetier 
Ack
Thanks Florian

2017-02-04 18:41 GMT-08:00 Florian Fainelli :
> In case we are building against a kernel that is too old and does not
> support SYS_getrandom, error out with a message indicating so.
>
> Signed-off-by: Florian Fainelli 
> ---
>  CMakeLists.txt | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/CMakeLists.txt b/CMakeLists.txt
> index 6cf0c934aac6..9033493c7a3b 100644
> --- a/CMakeLists.txt
> +++ b/CMakeLists.txt
> @@ -16,10 +16,17 @@ IF(DEBUG)
>ADD_DEFINITIONS(-DDEBUG -g3)
>  ENDIF()
>
> -ADD_EXECUTABLE(getrandom getrandom.c)
> -INSTALL(TARGETS getrandom
> -   RUNTIME DESTINATION bin
> -)
> +INCLUDE (CheckSymbolExists)
> +CHECK_SYMBOL_EXISTS(SYS_getrandom sycall.h getrandom)
> +
> +IF(getrandom)
> +  ADD_EXECUTABLE(getrandom getrandom.c)
> +  INSTALL(TARGETS getrandom
> +  RUNTIME DESTINATION bin
> +  )
> +ELSE()
> +  message( FATAL_ERROR "Kernel too old, missing SYS_getrandom system call")
> +ENDIF()
>
>  ADD_EXECUTABLE(kmodloader kmodloader.c)
>  TARGET_LINK_LIBRARIES(kmodloader ubox)
> --
> 2.9.3
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH ubox] cmake: Check for getrandom system call

2017-02-04 Thread Florian Fainelli 
In case we are building against a kernel that is too old and does not
support SYS_getrandom, error out with a message indicating so.

Signed-off-by: Florian Fainelli 
---
 CMakeLists.txt | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/CMakeLists.txt b/CMakeLists.txt
index 6cf0c934aac6..9033493c7a3b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -16,10 +16,17 @@ IF(DEBUG)
   ADD_DEFINITIONS(-DDEBUG -g3)
 ENDIF()
 
-ADD_EXECUTABLE(getrandom getrandom.c)
-INSTALL(TARGETS getrandom
-   RUNTIME DESTINATION bin
-)
+INCLUDE (CheckSymbolExists)
+CHECK_SYMBOL_EXISTS(SYS_getrandom sycall.h getrandom)
+
+IF(getrandom)
+  ADD_EXECUTABLE(getrandom getrandom.c)
+  INSTALL(TARGETS getrandom
+  RUNTIME DESTINATION bin
+  )
+ELSE()
+  message( FATAL_ERROR "Kernel too old, missing SYS_getrandom system call")
+ENDIF()
 
 ADD_EXECUTABLE(kmodloader kmodloader.c)
 TARGET_LINK_LIBRARIES(kmodloader ubox)
-- 
2.9.3


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH] ar71xx: Add support for D-Link EBR-2310 Rev. C

2017-02-04 Thread mr . nuke . me 
On Saturday, February 4, 2017 1:12:57 AM PST Alexandru Gagniuc wrote:
> Add support for the EBR-2310, which is almost identical to the DIR-615
> rev E4, without the wifi.
> 
I've re-submitted as a pull-request, since patchwork loves to butcher my name:

https://github.com/lede-project/source/pull/784

Alex

> Signed-off-by: Alexandru Gagniuc 
> ---
>  target/linux/ar71xx/base-files/etc/board.d/01_leds   | 3
> ++- target/linux/ar71xx/base-files/etc/board.d/02_network|
> 5 + .../ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
>  | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh
> | 3 +++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
>  | 1 + target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c 
> | 3 +++ target/linux/ar71xx/files/arch/mips/ath79/machtypes.h  
>  | 1 + target/linux/ar71xx/image/legacy-devices.mk 
> | 5 + target/linux/ar71xx/image/legacy.mk  
>| 1 + 9 files changed, 22 insertions(+), 1 deletion(-)
> 
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> b/target/linux/ar71xx/base-files/etc/board.d/01_leds index b1ecb02..11f2280
> 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
> +++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
> @@ -238,7 +238,8 @@ dhp-1565-a1)
>   ;;
>  dir-600-a1|\
>  dir-615-e1|\
> -dir-615-e4)
> +dir-615-e4|\
> +ebr-2310-c1)
>   ucidef_set_led_netdev "wan" "WAN" "d-link:green:wan" "eth1"
>   ucidef_set_led_switch "lan1" "LAN1" "d-link:green:lan1" "switch0" "0x02"
>   ucidef_set_led_switch "lan2" "LAN2" "d-link:green:lan2" "switch0" "0x04"
> diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
> b/target/linux/ar71xx/base-files/etc/board.d/02_network index
> 976440e..13649c3 100755
> --- a/target/linux/ar71xx/base-files/etc/board.d/02_network
> +++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
> @@ -305,6 +305,11 @@ ar71xx_setup_interfaces()
>   "0@eth0" "2:lan" "3:lan" "4:lan"
>   ucidef_add_switch_attr "switch0" "enable" "false"
>   ;;
> + ebr-2310-c1)
> + ucidef_set_interfaces_lan_wan "eth0.1" "eth1"
> + ucidef_add_switch "switch0" \
> + "0@eth0" "1:lan:1" "2:lan:2" "3:lan:3" "4:lan:4"
> + ;;
>   el-m150)
>   ucidef_set_interfaces_lan_wan "eth1" "eth0"
>   ucidef_add_switch "switch0" \
> diff --git
> a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migrat
> ion
> b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migrat
> ion index f1b3ae1..0558848 100644
> ---
> a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migrat
> ion +++
> b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migrat
> ion @@ -58,6 +58,7 @@ dir-600-a1|\
>  dir-615-c1|\
>  dir-615-e1|\
>  dir-615-e4|\
> +ebr-2310-c1|\
>  ja76pf|\
>  rb-750|\
>  rb-751|\
> diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> b/target/linux/ar71xx/base-files/lib/ar71xx.sh index 3ca2c0d..0577c34
> 100755
> --- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
> +++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
> @@ -607,6 +607,9 @@ ar71xx_board_detect() {
>   *EAP7660D)
>   name="eap7660d"
>   ;;
> + *"EBR-2310 rev. C1")
> + name="ebr-2310-c1"
> + ;;
>   *EL-M150)
>   name="el-m150"
>   ;;
> diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh index
> cf2aab2..0b3da06 100755
> --- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
> @@ -233,6 +233,7 @@ platform_check_image() {
>   dlan-pro-500-wp|\
>   dr531|\
>   dragino2|\
> + ebr-2310-c1|\
>   epg5000|\
>   esr1750|\
>   esr900|\
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
> b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c index
> 321fdce..5e6134d 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
> @@ -141,6 +141,9 @@ static void __init dir_600_a1_setup(void)
>  MIPS_MACHINE(ATH79_MACH_DIR_600_A1, "DIR-600-A1", "D-Link DIR-600 rev. A1",
> dir_600_a1_setup);
> 
> +MIPS_MACHINE(ATH79_MACH_EBR_2310_C1, "EBR-2310-C1", "D-Link EBR-2310 rev.
> C1", + dir_600_a1_setup);
> +
>  static void __init dir_615_e1_setup(void)
>  {
>   dir_600_a1_setup();
> diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h index
> 12e81db..23ed6dd 100644
> --- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
> +++

[LEDE-DEV] [PATCH v4] ramips: Add support for Sanlinking D240

2017-02-04 Thread Kristian Evensen 
The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Specification:
* CPU: MT7620A
* 1x 10/100Mbps POE (802.3af/802.3at) Ethernet, 4x 10/100Mbps.
* 16 MB Flash.
* 128 MB RAM.
* 1x USB 2.0 port.
* 2x mini-PCIe slots.
* 2x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader.

The device comes pre-installed with an older version of OpenWRT, including Luci.
In order to install LEDE, you need to follow the existing procedure for updating
OpenWRT/LEDE using Luci. I.e., you need to access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to keep
existing settings. The default router address is 192.168.10.1 and
username/password admin/root (at least on my devices).

If you brick the device, the procedure for recovery is the same as for the
WE826. Please see the wiki page for that device for instructions.

v3->v4:
* Fixed formatting of dts file (thanks Piotr Dymacz).

v2->v3:
* Rename Sanlinking-D240 to D240 in order to follow convention that board name
should not contain manufacturer name (thanks Piotr Dymacz).
* Add BSD license to DTS file (thanks Rafał Miłecki).
* Add details on how to install LEDE on the router (thanks Mathias Kresin).

v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen 

blabla
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/D240.dts   | 157 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 175 insertions(+)
 create mode 100644 target/linux/ramips/dts/D240.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 545d6a4..4e6eeb2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -109,6 +109,10 @@ d105)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
set_usb_led "$board:green:usb"
;;
+d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 db-wrt01)
ucidef_set_led_default "power" "power" "$board:orange:power" "1"
;;
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index c001dfe..3ef04e6 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -73,6 +73,7 @@ ramips_setup_interfaces()
3g-6200n|\
ac1200pro|\
ai-br100|\
+   d240|\
db-wrt01|\
dir-300-b7|\
dir-320-b1|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..744ff3c 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -108,6 +108,7 @@ get_status_led() {
w502u)
status_led="$board:blue:wps"
;;
+   d240|\
dap-1350|\
na930|\
pbr-m1|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..3072531 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -112,6 +112,9 @@ ramips_board_detect() {
*"D105")
name="d105"
;;
+   *"D240")
+   name="d240"
+   ;;
*"DAP-1350")
name="dap-1350"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..acdfdaf 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -35,6 +35,7 @@ platform_check_image() {
cf-wr800n|\
cs-qr10|\
d105|\
+   d240|\
dap-1350|\
db-wrt01|\
dcs-930|\
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
new file mode 100644
index 000..2f11ce9
--- /dev/null
+++ b/target/linux/ramips/dts/D240.dts
@@ -0,0 +1,157 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Kristian Evensen .
+ *  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *

Re: [LEDE-DEV] NETSHe mac80211 GPL sources

2017-02-04 Thread Daniel Golle 
Hi Stas,

On Fri, Feb 03, 2017 at 03:58:15PM +0300, Stanislav V. Korsakov wrote:
> Hi Daniel,
> 
> Why do you think that all our TDMA-related modifications must be under
> GPL license?

As you are using cfg80211 and mac80211 I just guessed that chances are
high that you'd also use ath9k and modified it.

> 
> We use cfg80211, mac80211, ath5k and ath9k with very small modifications
> to support new type of interface and to handle some new netlink commands.
> We call own dual licensed module from mac80211 to handle new type of
> interface. Some code to provide new functionality is placed in our
> proprietary licensed driver. This driver does not use any GPL exported
> calls/symbols from the kernel and other drivers. Code from this module
> is used from our dual licensed module only. This module taints kernel.
> 
> In our mind, we do not breach GPL v2 with this architecture.
> Thus, we have two parts of source code:
> 1. GPLed and dual-licensed. We provide this source code to our
> customers. Any customer can open GPLed part if he wish to do it. Why
> should we provide it for everyone (not customers)? Please point me to
> GPL v2 license term which has this requirements. Not your interpretation.
> 2. Closed source for our proprietary module.

Ok, thanks a lot for the clarifications. That's indeed a clean solution
as far as I can judge.


> 
> We do not share our binaries for everyone since v3.2. All GPLed code
> (including patches) is available in a free access for v3.2.

Is that the code on sourceforge.net?

> 
> At least, we try to keep copyrights and software licenses and I do not
> see license breaches now. You can find what we build our firmware, what
> we used and how. E.g. how we use OpenWRT and what is the difference. We
> do not hide it.
> If you found breaches - inform me to cancel.

That's not the road I'm going for ;) I'm just interested in code, I am
not an expert on legal/license things.

> 
> About idealistic...
> I did not see long time and effective working just for fun only...
> Programmers want to eat...

Of course, same here. From a labour perspective FOSS can also be seen
as quite a nightmare -- not long ago, companies needed to hire people
and then educate them while paying them. Today, you're expected to be
self-educated and nobody cares how people are feeding themselves while
studying free software code...

> Open source is very good and helpful thing. Let discuss how we can help
> but keep in mind that we need to earn money too.

Imho this conversation can already be seen as a contribution.
To avoid confusion in future, it'd be great if you made sure that the
GPL'ed part of the sources can be found right next to the binaries as
well as on webpages linking to those binaries.

Another good concept could be to make sure stuff goes public once you
longer have commercial interest in it. That will allow e.g. securiy
audits of outdated gear in the field and also help future generations
to understand history and evolution of software. CodeWeavers and the
wine folks get's that right, imho, but it's a rare thing. Most of the
time, stuff just disappears and future researchers are left in the
dark when the try to figure out what happened 10 years ago.

> 
> Excuse me my bad English. Hope, I explained our point of view...

No worries, your English is good and I didn't have any problems
understanding what you were writing.
Thank you for your time and for explaining things!

> 
> Now about implementation details if it still interesting...
> 
> Our implementation is completely different from Ubiquiti or FreeBSD's.
> In my mind, first uses PCF mode variation. Second is original but i do
> not impress how it works in noisy environment.
> For our implementation, closest mode is AdHoc with own scheduler.
> Scheduler is implemented in software completely.
> Our implementation is well for narrow channels and not big mesh networks
> (and we do own mesh implementation above TDMA) but lost efficiency with
> wide channels. We can not utilize HT/VHT  and have bigger delay by design.

That's indeed quite different from what I expected. But surely makes
sense for long-distance links where QoS and reliability is a most, I
imagine that VoIP should work very well using your solution.
However, for the purpose I had in mind (wireless community ISP in urban
areas) I'd rather have MiMo and more throughput as links are rather
short compared to what you are doing. Nevertheless, I'm impressed by
your report of 30km+ stable links!


Cheers


Daniel



> 
> Regards, Stas
> 
> 
> On 03.02.2017 13:40, Daniel Golle wrote:
> > Hi Stas,
> >
> > thanks for the quick reply!
> >
> > I'm looking for a good way to replace ubiquiti's proprietary TDMA
> > implementation with something which could be vendor-independent and
> > interoperable -- and ideally Free Open Source Software.
> > As TDMA has been implemented for ath9k in FreeBSD, I was wondering if
> > a similar extension to mac80211 has been made -- and found NETSHe's
> > wireless

Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!

2017-02-04 Thread Daniel Golle 
Hi Juergen,

On Sat, Feb 04, 2017 at 08:32:36AM +0100, Juergen Kimmel wrote:
> Hello everyone,
> I'm in the same boat struggeling with  mt7620a WiFi performance,
> namely with the device called   ZBT APE522ii.
> Stock firmware based on Openwrt (has no version number) has no issues
> concerning wifi performance.

That's because ZBT ships their devices with a firmware containing
Mediatek/Ralink's proprietary driver as well as the needed proprietary
user-space tools. However, this driver only supports either (multi-SSID)
AP-mode or Station-mode, but not both at the same time.

> 
> Because I`m focussing on a mesh solution,  I tested Openwrt/Lede based
> qMp (qmp.cat) but having the same issues described here.

That's not surprising, unfortunately.

> IMHO there must be different drivers to be used. My skills are not at
> all  sufficient to clear where the difference could be.

The main problem here is that rt2860_ap driver (which was at least
partially also published under GPLv2 terms, you can find it on github)
cannot do AdHoc mode which is needed for mesh stuff.

> So help is very much appreciated.

I'll be working on sorting things out for MT7620 once the kickstarter
project I created for that purpose reaches its goal.


Cheers


Daniel


> 
> 2017-02-04 2:27 GMT+01:00 Juergen Kimmel :
> > Hello everyone,
> > I'm in the same boat struggeling with  mt7620a WiFi performance, namely with
> > the device called
> >  ZBT APE522ii.
> > Stock firmware based on Openwrt (no version number) has no issues concerning
> > wifi performance.
> >
> > Because I`m focussing on a mesh solution,  I tested Openwrt/Lede based qMp
> > (qmp.cat) but having the same issues described here.
> > IMHO there must be different drivers used. My skills are not at all
> > sufficient to clear where the difference could be.
> > So help is very much appreciated.
> >
> >
> > Weedy  schrieb am Sa., 4. Feb. 2017 01:51:
> >>
> >> On 1 February 2017 at 15:29, Jamie Stuart  wrote:
> >> > Hello LEDE / OpenWRT devs,
> >> >
> >> > I am requesting your help. First a little background…
> >> ...
> >> > This a known issue with the chipset and seems to have been round for
> >> > years.
> >> > We are currently building on LEDE trunk and still the issue persists.
> >> >
> >> > We are not driver developers, so my question is whether anyone with
> >> > knowledge can help and provide a proper fix for this issue?
> >>
> >>
> >> You will probably have the most luck posting a bounty on the linux
> >> wifi mailing list.
> >>
> >> Your root problem is picking a platform that basically uses a client
> >> mode tested driver in AP mode and then hanging a million clients off
> >> of it. I'm honestly surprised it didn't fall over sooner.
> >>
> >> May I suggest when it comes time to refresh the hardware you guys pick
> >> something with NGFF or mini-pcie slots for ALL radios.
> >>
> >> ___
> >> Lede-dev mailing list
> >> Lede-dev@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/lede-dev
> 
> 
> 
> -- 
> Mit freundlichen Grüssen
> 
> Jürgen Kimmel
> 
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [OpenWrt-Devel] MT7620A WiFi issue - with a twist!

2017-02-04 Thread Daniel Golle 
Hi Weedy,

On Fri, Feb 03, 2017 at 07:49:22PM -0500, Weedy wrote:
> On 1 February 2017 at 15:29, Jamie Stuart  wrote:
> > Hello LEDE / OpenWRT devs,
> >
> > I am requesting your help. First a little background…
> ...
> > This a known issue with the chipset and seems to have been round for years.
> > We are currently building on LEDE trunk and still the issue persists.
> >
> > We are not driver developers, so my question is whether anyone with
> > knowledge can help and provide a proper fix for this issue?
> 
> 
> You will probably have the most luck posting a bounty on the linux
> wifi mailing list.

As a response to the many issues and obvious code quality problems in
the patch adding support for MT7620 to rt2x00 I started a kickstarter
project to fund an afternoon or two (depending on the amount people
throw into my hat) of focussing on rt2x00 running on MT7620:

https://www.kickstarter.com/projects/1327597961/better-support-for-mt7620a-n-in-openwrt-lede


> 
> Your root problem is picking a platform that basically uses a client
> mode tested driver in AP mode and then hanging a million clients off
> of it. I'm honestly surprised it didn't fall over sooner.

Well, rt2x00 is used for both AP and Client mode, and afaik there
wasn't a lot of testing for either mode of operation. And AP mode has
recently seen quite a bunch of improvements.
Having seperate drivers for AP and STA is a common strategy of chip
makers to devide-and-conquer QA and also add product differentiation,
ie. sell the same hardware for more if it is used for specific tasks.
Thus Ralink used to give away the station-mode driver for free and used
to charge people for the AP-mode driver (they do share a common
codebase). The bigger issue here is that Ralink's WiFi chip design is
flawed when using the chips in multi-STA modes (AP, Adhoc, Mesh)
because instead of having a way to set parameters for each associated
station it only allows it to be set globally, see [1] for an example of
how rt2x00 thus needs to limit the hardware to use the parameters of
the weakest associated station (the vendor driver does the same).

> 
> May I suggest when it comes time to refresh the hardware you guys pick
> something with NGFF or mini-pcie slots for ALL radios.

+1
Though I personally don't believe it's ever going to get as chaotic
and complex as for the final generation of Ralink's WiFi chips (ie.
which later became MT76x0). Ralink/Mediatek's newer chips are much
cleaner and don't share the same issues.


Cheers


Daniel

[1] 
https://git.kernel.org/cgit/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/drivers/net/wireless/ralink/rt2x00/rt2800lib.c?id=8f03a7c6e7f959edd22e35158fbb9a4087962fae



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] telephony: adding telephony functionality

2017-02-04 Thread Giuseppe Lippolis 
>Dear All,
>after some investigation on my DWR-512 board I discovered the hw
architecture of the telephone voice channel embedded in the router.
>The board embeds one 3g modem plugged on the mini pcie slot and one proslic
device (si3210 - subscriber line interface circuit).
>The hw architecture is shown below.
>
>T   V
>|   |
>  +---+   +---+
>IRQ   |   |  PCM bus  |   | events
>  +---|  si   |<=>|   3g  |-+
>  |   | 3210  |   | modem | |
>  |   +---+   +---+ |
>  | ^ ^ |
>  | | | |
>  | | spidev1.0   | |
>  | | | ttyUSB0/1   |
>  |   +---+   | |
>  |   |   |---+ |
>  +-->|  uP   | |
>gpio1 |   |<+
>  +---+ ttyUSB1
> 

>My next plan is to develop a driver for the si3210 and then one userspace
daemon to enable the telephone voice (and sms) channel functions.

>Have someone some comments about this plan?

I found an interesting tentative to add a telephony class in linux, it was
the phonedev.c class by Alan Cox.
Nevertheless this piece of code has been removed since kernel 3.6
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7
326446c728f633a0d6b3318cf491f71f044dce0
Make sense revert it back?

Bye.




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] LEDE-17.01 Final Release Notes available

2017-02-04 Thread Dave Täht 


On 2/3/17 3:42 AM, Baptiste Jonglez wrote:
> On Tue, Jan 31, 2017 at 10:14:04AM +, David Woodhouse wrote:
>> On Tue, 2017-01-31 at 10:54 +0100, Baptiste Jonglez wrote:
>>>
>>> - IPv6 support: since that was the focus of CC, at least mention that
>>>   nothing was intentionally broken (and maybe there were some
>>>   improvement?)]
>>
>> What was the IPv6 problem?
> 
> Nothing, hopefully :) What I meant is that LEDE should work as well as
> OpenWRT CC with respect to IPv6 support.  This is currently implicit,
> because the release notes do not mention IPv6 at all.  I was wondering if
> it would make sense to mention that IPv6 support remains very good.

If it were only true. Earlier this month I experienced a raft of ipv6
inter-related bugs in an odhcp6c+dhcpv6-pd or 6rd environment, mostly
around timers - both in expiry of and refresh of routes of addresses.

Various bits of improved code has been landing since, and I have not got
back on it (busy on wifi and atf). I think much of the evidence points
at a bug in netifd in pushing out or refeshing routes that expire,
compounded by noprefixroute being added to the kernel in the last 2
years, compounded by a bit of bit-rot on some of the scripting interfaces...

It would be good to have more people get on this, but I would, given the
release schedule, deprioritize mention of ipv6 support, and try to
aggressively attack all the issues in a subsequent round.





___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v3] ramips: Add support for Sanlinking D240

2017-02-04 Thread Kristian Evensen 
The Sanlinking Technologies D240
(http://www.sanlinking.com/en/29-dual-4g-wifi-router.html) is basically the same
device as the ZBT WE826, so adding support for it in LEDE is straight forward.
The differences is that the D240 has two mini-PCIe slots (instead of one), blue
LEDs and supports PoE.

Specification:
* CPU: MT7620A
* 1x 10/100Mbps POE (802.3af/802.3at) Ethernet, 4x 10/100Mbps.
* 16 MB Flash.
* 128 MB RAM.
* 1x USB 2.0 port.
* 2x mini-PCIe slots.
* 2x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.

Wifi, USB, switch and both mini-PCIe slots are working. I have not been able to
test the SD card reader.

The device comes pre-installed with an older version of OpenWRT, including Luci.
In order to install LEDE, you need to follow the existing procedure for updating
OpenWRT/LEDE using Luci. I.e., you need to access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to keep
existing settings. The default router address is 192.168.10.1 and
username/password admin/root (at least on my devices).

If you brick the device, the procedure for recovery is the same as for the
WE826. Please see the wiki page for that device for instructions.

v2->v3:
* Rename Sanlinking-D240 to D240 in order to follow convention that board name
should not contain manufacturer name (thanks Piotr Dymacz).
* Add BSD license to DTS file (thanks Rafał Miłecki).
* Add details on how to install LEDE on the router (thanks Mathias Kresin).

v1->v2:
* Misc. code cleanup (thanks Mathias Kresin)

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   1 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/D240.dts   | 153 +
 target/linux/ramips/image/mt7620.mk|   8 ++
 7 files changed, 171 insertions(+)
 create mode 100644 target/linux/ramips/dts/D240.dts

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds 
b/target/linux/ramips/base-files/etc/board.d/01_leds
index 545d6a4..4e6eeb2 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -109,6 +109,10 @@ d105)
ucidef_set_led_default "power" "POWER" "$board:red:power" "1"
set_usb_led "$board:green:usb"
;;
+d240)
+   set_wifi_led "$board:blue:wifi"
+   set_usb_led "$board:blue:usb"
+   ;;
 db-wrt01)
ucidef_set_led_default "power" "power" "$board:orange:power" "1"
;;
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network 
b/target/linux/ramips/base-files/etc/board.d/02_network
index c001dfe..3ef04e6 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -73,6 +73,7 @@ ramips_setup_interfaces()
3g-6200n|\
ac1200pro|\
ai-br100|\
+   d240|\
db-wrt01|\
dir-300-b7|\
dir-320-b1|\
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 5fb2213..744ff3c 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -108,6 +108,7 @@ get_status_led() {
w502u)
status_led="$board:blue:wps"
;;
+   d240|\
dap-1350|\
na930|\
pbr-m1|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index d9918cc..3072531 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -112,6 +112,9 @@ ramips_board_detect() {
*"D105")
name="d105"
;;
+   *"D240")
+   name="d240"
+   ;;
*"DAP-1350")
name="dap-1350"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index d83e5c1..acdfdaf 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -35,6 +35,7 @@ platform_check_image() {
cf-wr800n|\
cs-qr10|\
d105|\
+   d240|\
dap-1350|\
db-wrt01|\
dcs-930|\
diff --git a/target/linux/ramips/dts/D240.dts b/target/linux/ramips/dts/D240.dts
new file mode 100644
index 000..051204a
--- /dev/null
+++ b/target/linux/ramips/dts/D240.dts
@@ -0,0 +1,153 @@
+/*
+ *  BSD LICENSE
+ *
+ *  Copyright(c) 2017 Kristian Evensen .
+ *  All rights reserved.
+ *
+ *  Redistribution and use in source and binary forms, with or without
+ *  modification, are permitted provided that the following conditions
+ *  are met:

[LEDE-DEV] [PATCH] ar71xx: Add support for D-Link EBR-2310 Rev. C

2017-02-04 Thread Alexandru Gagniuc 
Add support for the EBR-2310, which is almost identical to the DIR-615
rev E4, without the wifi.

Signed-off-by: Alexandru Gagniuc 
---
 target/linux/ar71xx/base-files/etc/board.d/01_leds   | 3 ++-
 target/linux/ar71xx/base-files/etc/board.d/02_network| 5 +
 .../ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration  | 1 +
 target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +++
 target/linux/ar71xx/base-files/lib/upgrade/platform.sh   | 1 +
 target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c  | 3 +++
 target/linux/ar71xx/files/arch/mips/ath79/machtypes.h| 1 +
 target/linux/ar71xx/image/legacy-devices.mk  | 5 +
 target/linux/ar71xx/image/legacy.mk  | 1 +
 9 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index b1ecb02..11f2280 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -238,7 +238,8 @@ dhp-1565-a1)
;;
 dir-600-a1|\
 dir-615-e1|\
-dir-615-e4)
+dir-615-e4|\
+ebr-2310-c1)
ucidef_set_led_netdev "wan" "WAN" "d-link:green:wan" "eth1"
ucidef_set_led_switch "lan1" "LAN1" "d-link:green:lan1" "switch0" "0x02"
ucidef_set_led_switch "lan2" "LAN2" "d-link:green:lan2" "switch0" "0x04"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network 
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 976440e..13649c3 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -305,6 +305,11 @@ ar71xx_setup_interfaces()
"0@eth0" "2:lan" "3:lan" "4:lan"
ucidef_add_switch_attr "switch0" "enable" "false"
;;
+   ebr-2310-c1)
+   ucidef_set_interfaces_lan_wan "eth0.1" "eth1"
+   ucidef_add_switch "switch0" \
+   "0@eth0" "1:lan:1" "2:lan:2" "3:lan:3" "4:lan:4"
+   ;;
el-m150)
ucidef_set_interfaces_lan_wan "eth1" "eth0"
ucidef_add_switch "switch0" \
diff --git 
a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration 
b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
index f1b3ae1..0558848 100644
--- 
a/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
+++ 
b/target/linux/ar71xx/base-files/etc/uci-defaults/03_network-switchX-migration
@@ -58,6 +58,7 @@ dir-600-a1|\
 dir-615-c1|\
 dir-615-e1|\
 dir-615-e4|\
+ebr-2310-c1|\
 ja76pf|\
 rb-750|\
 rb-751|\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 3ca2c0d..0577c34 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -607,6 +607,9 @@ ar71xx_board_detect() {
*EAP7660D)
name="eap7660d"
;;
+   *"EBR-2310 rev. C1")
+   name="ebr-2310-c1"
+   ;;
*EL-M150)
name="el-m150"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index cf2aab2..0b3da06 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -233,6 +233,7 @@ platform_check_image() {
dlan-pro-500-wp|\
dr531|\
dragino2|\
+   ebr-2310-c1|\
epg5000|\
esr1750|\
esr900|\
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c 
b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
index 321fdce..5e6134d 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-dir-600-a1.c
@@ -141,6 +141,9 @@ static void __init dir_600_a1_setup(void)
 MIPS_MACHINE(ATH79_MACH_DIR_600_A1, "DIR-600-A1", "D-Link DIR-600 rev. A1",
 dir_600_a1_setup);
 
+MIPS_MACHINE(ATH79_MACH_EBR_2310_C1, "EBR-2310-C1", "D-Link EBR-2310 rev. C1",
+dir_600_a1_setup);
+
 static void __init dir_615_e1_setup(void)
 {
dir_600_a1_setup();
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h 
b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
index 12e81db..23ed6dd 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
+++ b/target/linux/ar71xx/files/arch/mips/ath79/machtypes.h
@@ -88,6 +88,7 @@ enum ath79_mach_type {
ATH79_MACH_EAP120,  /* TP-LINK EAP120 */
ATH79_MACH_EAP300V2,/* EnGenius EAP300 v2 */
ATH79_MACH_EAP7660D,/* Senao EAP7660D */
+   ATH79_MACH_EBR_2310_C1,