Re: [OpenWrt-Devel] [PATCH] odhcp6c: don't handle certain RA data if the kernel is, configured to take care of it
Hello Heiner, thanks, however overriding the kernel behavior is intentional as its handling of e.g. routes is very limited. Also getting address from both the kernel and through dhcpv6 to netifd to the kernel causes conflicts such as the ones you noted. If you want to use Kernel RA-handling please disable the dhcpv6 protocol handler on said interface. If you really want to do this I suppose I could live with a manual switch for odhcp6c / the dhcpv6 handler to turn of RA-handling altogether. However the results won't be very pretty. Regards, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hello Henning, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. please see: https://dev.openwrt.org/changeset/40422 I added an option weakif which allows you to specify an interface from which we take the local IPv6 address defaulting to lan. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] OpenSSL: update to 1.0.1g
Applied, thanks. Will probably take care of AA later today. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] OpenSSL: update to 1.0.1g
Le 08/04/2014 08:37, Steven Barth a écrit : Applied, thanks. Will probably take care of AA later today. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel Does it mean that ther ewill be a new AA binary release, or just the sources will be updated? -- Michel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] So, how does the 'compat-wireless' package interact with the OpenWRT build scripts and the given Linux Kernel?
It's not difficult. If you want to add an atheros option look into the Makefile the better place for it. This link points to one of the ath sections: https://dev.openwrt.org/browser/trunk/package/kernel/mac80211/Makefile#L494 You see Linux-3.10.34 Kconfig items because it is patched for the kernels supported in trunk. This patch will guide you: http://patchwork.openwrt.org/patch/1960/ Pepe 2014-04-08 0:44 GMT+02:00, John Clark jeclark2...@aim.com: I'm looking at the various Kconfig files in 'compat-wireless-2014-01-23.1' that is part of my current build setup. When I use the command make menuconfig and look at the various options for building the atheros drivers, I see what appears to be the 'standard' Linux-3.10.34 Kconfig items. However, when I look at the equivalent 'compat-wireless-2014-01-23.1/drivers/net/wireless/ath' Kconfig file, there are different options, some of which I want to enable. Does one have to do this by hand, or is there some magic option to 'make menuconfig' to show the 'compat-wireless' Kconfig file. Thanks, John Clark. ___ 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] New package: easycwmp package
2014-04-07 18:04 GMT+02:00 MOHAMED Kallel mohamed.kal...@pivasoftware.com: Add new package. Its name is easycwmp. easycwmp is a GPLv2 open source implementation of the TR069 cwmp standard. easycwmp is a complete cwmp client fully conform with the TR-069 standrad Have you tried to participate in freecwmp project? Were your patches rejected, or something? Could you publish your private svn, so we can see your patches in a nice form (one by one) and see if they can be simply included in freecwmp? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: easycwmp package
Hi Mohamed, On Mon, Apr 07, 2014 at 06:04:56PM +0200, MOHAMED Kallel wrote: Add new package. Its name is easycwmp. easycwmp is a GPLv2 open source implementation of the TR069 cwmp standard. easycwmp is a complete cwmp client fully conform with the TR-069 standrad Can you please provide a git repository (or patches on top of original freecwmp project) for your easycwmp project? I could not find it. I am asking since it looks like easycwmp is a complete fork of freecwmp with some (minor?) changes. I am wondering if the development model looked like this: *) rename of the project (I hope that at least you saved some time and used one-liner like this one sed -i 's/freecwmp/easycwmp/' *) *) add copyright lines (c) of your company *) add additional functionality Even the easycwmp.org looks like it is mostly copied from freecwmp.org site. Regards, Luka ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WiFi / interface-combinations e.g. IBSS + AP
while working with different routers, i recognized that e.g. using adhoc/IBSS + AP on 1 radio is generally supported with mac80211 but limited by driver. e.g. ath9k works, rt2800/rt2x00 does not work (r40352/fonera2.0n). because we have some presets in our community-firmware, it would be good to 'warn' the user if this is not possible. when check 'iw phy phy0 info' there is a field 'Supported', e.g. # on ath9k: Supported interface modes: * IBSS * managed * AP * AP/VLAN * WDS * monitor * P2P-client * P2P-GO # or (on rt2800): Supported interface modes: * IBSS * managed * AP * AP/VLAN * WDS * monitor but it seems, this is not what i'am searching for. is it possible to query valid combinations? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WiFi / interface-combinations e.g. IBSS + AP
On 2014-04-08 12:04, Bastian Bittorf wrote:
while working with different routers, i recognized that
e.g. using adhoc/IBSS + AP on 1 radio is generally supported
with mac80211 but limited by driver. e.g. ath9k works,
rt2800/rt2x00 does not work (r40352/fonera2.0n).
because we have some presets in our community-firmware,
it would be good to 'warn' the user if this is not possible.
when check 'iw phy phy0 info' there is a field 'Supported', e.g.
# on ath9k:
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
* P2P-client
* P2P-GO
# or (on rt2800):
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* WDS
* monitor
but it seems, this is not what i'am searching for. is it possible
to query valid combinations?
root@OpenWrt:/# iw phy0 info
Wiphy phy0
[...]
valid interface combinations:
* #{ managed, WDS } = 2048, #{ AP, mesh point } = 8, #{ IBSS
} = 1, #{ P2P-client, P2P-GO } = 1,
total = 2048, #channels = 1, STA/AP BI must match
* #{ IBSS, AP, mesh point } = 1,
total = 1, #channels = 1, STA/AP BI must match, radar
detect widths: { 20 MHz (no HT), 20 MHz }
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WDS and adhoc support with ath10k
Hi, I recently have been testing some 802.11ac hardware with the ath10k. Could someone confirm if WDS and adhoc mode currently don't have support with this driver? Thanks, Bruno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] Don't try to generate whr-g300n image if it's going to be more than 4M
Signed-off-by: Roman Yeryomin ro...@advem.lv --- target/linux/ramips/image/Makefile | 16 +--- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index c6a42ad..63f7425 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -456,13 +456,15 @@ define BuildFirmware/WHRG300N/squashfs $(call BuildFirmware/Default4M/$(1),$(1),whr-g300n,WHR-G300N) # the following line has a bad argument 3 ... the old Makefile was already broken $(call BuildFirmware/Buffalo,$(1),whr-g300n,whr-g300n) - ( \ - echo -n -e # Airstation FirmWare\nrun u_fw\nreset\n\n | \ - dd bs=512 count=1 conv=sync; \ - dd if=$(call sysupname,$(1),whr-g300n); \ - ) $(KDIR)/whr-g300n-tftp.tmp - buffalo-tftp -i $(KDIR)/whr-g300n-tftp.tmp \ - -o $(call imgname,$(1),whr-g300n)-tftp.bin + if [ -e $(call sysupname,$(1),$(2)) ]; then \ + ( \ + echo -n -e # Airstation FirmWare\nrun u_fw\nreset\n\n | \ + dd bs=512 count=1 conv=sync; \ + dd if=$(call sysupname,$(1),whr-g300n); \ + ) $(KDIR)/whr-g300n-tftp.tmp \ + buffalo-tftp -i $(KDIR)/whr-g300n-tftp.tmp \ + -o $(call imgname,$(1),whr-g300n)-tftp.bin; \ + fi endef BuildFirmware/WHRG300N/initramfs=$(call BuildFirmware/OF/initramfs,$(1),whr-g300n,WHR-G300N) Image/Build/Profile/WHRG300N=$(call BuildFirmware/WHRG300N/$(1),$(1)) -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] radsecproxy: procd conversion and version bump
Ping? :) http://patchwork.openwrt.org/patch/5037/ -Toke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] [ramips] Fix pinmux-rt2880
The last arg to FUNC() is count, not last pin.
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
target/linux/ramips/patches-3.10/0217-pinmux-rt2880.patch | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/target/linux/ramips/patches-3.10/0217-pinmux-rt2880.patch
b/target/linux/ramips/patches-3.10/0217-pinmux-rt2880.patch
index 3cadce7..6821da1 100644
--- a/target/linux/ramips/patches-3.10/0217-pinmux-rt2880.patch
+++ b/target/linux/ramips/patches-3.10/0217-pinmux-rt2880.patch
@@ -46,12 +46,12 @@
- .gpio_last = 71,
- }, {0}
+static struct rt2880_pmx_func i2c_func[] = { FUNC(i2c, 0, 1, 2) };
-+static struct rt2880_pmx_func spi_func[] = { FUNC(spi, 0, 3, 6) };
-+static struct rt2880_pmx_func uartlite_func[] = { FUNC(uartlite, 0, 7, 14)
};
-+static struct rt2880_pmx_func jtag_func[] = { FUNC(jtag, 0, 17, 21) };
-+static struct rt2880_pmx_func mdio_func[] = { FUNC(mdio, 0, 22, 23) };
-+static struct rt2880_pmx_func sdram_func[] = { FUNC(sdram, 0, 24, 39) };
-+static struct rt2880_pmx_func pci_func[] = { FUNC(pci, 0, 40, 71) };
++static struct rt2880_pmx_func spi_func[] = { FUNC(spi, 0, 3, 4) };
++static struct rt2880_pmx_func uartlite_func[] = { FUNC(uartlite, 0, 7, 8) };
++static struct rt2880_pmx_func jtag_func[] = { FUNC(jtag, 0, 17, 5) };
++static struct rt2880_pmx_func mdio_func[] = { FUNC(mdio, 0, 22, 2) };
++static struct rt2880_pmx_func sdram_func[] = { FUNC(sdram, 0, 24, 16) };
++static struct rt2880_pmx_func pci_func[] = { FUNC(pci, 0, 40, 32) };
+
+static struct rt2880_pmx_group rt2880_pinmux_data_act[] = {
+GRP(i2c, i2c_func, 1, RT2880_GPIO_MODE_I2C),
--
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] [ramips] Fix pinctrl in DT for rt2880
This fixes gpio to the state when gpio leds and buttons start to work but
something still broken for ethernet part (mdio?).
Externet switch is detectable and configurable, packet counters change but
looks like there is no connection between rt2880 and external switch.
Wireless appears to be broken also (at least for Asus rt-n15).
Signed-off-by: Roman Yeryomin ro...@advem.lv
---
target/linux/ramips/dts/RT-N15.dts | 18 ++
target/linux/ramips/dts/rt2880.dtsi | 28
2 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/target/linux/ramips/dts/RT-N15.dts
b/target/linux/ramips/dts/RT-N15.dts
index 77e640f..b1a2545 100644
--- a/target/linux/ramips/dts/RT-N15.dts
+++ b/target/linux/ramips/dts/RT-N15.dts
@@ -9,18 +9,20 @@
model = Asus RT-N15;
palmbus@30 {
- sysc@0 {
- ralink,pinmux = uartlite;
- ralink,gpiomux = i2c;
- ralink,uartmux = gpio;
- ralink,wdtmux = 1;
- };
-
gpio0: gpio@600 {
status = okay;
};
};
+ pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = i2c, uartlite, mdio;
+ ralink,function = gpio;
+ };
+ };
+ };
+
cfi@1f00 {
compatible = cfi-flash;
reg = 0x1f00 0x80;
@@ -46,7 +48,7 @@
read-only;
};
partition@5 {
- label = linux;
+ label = firmware;
reg = 0x5 0x3b;
};
};
diff --git a/target/linux/ramips/dts/rt2880.dtsi
b/target/linux/ramips/dts/rt2880.dtsi
index b513148..287d35a 100644
--- a/target/linux/ramips/dts/rt2880.dtsi
+++ b/target/linux/ramips/dts/rt2880.dtsi
@@ -121,6 +121,34 @@
};
};
+ pinctrl {
+ compatible = ralink,rt2880-pinmux;
+
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinctrl0 {
+ sdram {
+ ralink,group = sdram;
+ ralink,function = sdram;
+ };
+ };
+
+ spi_pins: spi {
+ spi {
+ ralink,group = spi;
+ ralink,function = spi;
+ };
+ };
+
+ uartlite_pins: uartlite {
+ uart {
+ ralink,group = uartlite;
+ ralink,function = uartlite;
+ };
+ };
+ };
+
ethernet@40 {
compatible = ralink,rt2880-eth;
reg = 0x0040 1;
--
1.8.3.2
___
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] [ramips] Fix pinctrl in DT for rt2880
Hi Roman, * Roman Yeryomin (leroi.li...@gmail.com) wrote: This fixes gpio to the state when gpio leds and buttons start to work but something still broken for ethernet part (mdio?). I was actually about to submit a fix for this exact problem. Your GPIO fix is identical to mine (I actually submitted the broken rt2880 pinmux patch with the incorrect pin count vs. last pin number mistake). I will clean them up and submit them today. I have Ethernet and the wireless fully working now. -Claudio ___ 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] [ramips] Fix pinctrl in DT for rt2880
On 8 April 2014 14:37, Claudio Leite lei...@staticky.com wrote: Hi Roman, * Roman Yeryomin (leroi.li...@gmail.com) wrote: This fixes gpio to the state when gpio leds and buttons start to work but something still broken for ethernet part (mdio?). I was actually about to submit a fix for this exact problem. Your GPIO fix is identical to mine (I actually submitted the broken rt2880 pinmux patch with the incorrect pin count vs. last pin number mistake). I will clean them up and submit them today. I have Ethernet and the wireless fully working now. Cool! I didn't want to spend much time on it because it's just my smart gigabit switch :) Looking forward to test your patches! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
On 2014-04-08 00:31, Fernando Frediani wrote: Reading all this discussion around WRT1900ac makes me wonder of something: - When Belkin acquired Linksys and announced WRT1900ac they made a big noise (marketing) about OpenWRT compatibility so they are using the project's name for their financial benefit, make people believe in that to buy the hardware (nothing that stops them to do that really). - Anyone here would then expect they engage with developers and submit patches for the work they are doing. They kind of showed up but very briefly and submmited a non-acceptable patch so far. - Therefore they are subscribed to this email list seeing all this discussion around their product and either: - They watch it silently, laugh and ignore it (which is not good). - They are not even aware or following this discussion (which is not good too). Therefore I get confused of what the next steps will be around it and the output of this discussion will end. The code quality issues in the patches are fixable. The biggest problem with this is the fact that right now, the wifi chip (from Marvell) needs a proprietary driver to run. The submitted patches only include a prebuilt .ko for this driver. The response I got from Belkin indicates that they didn't realize that this was going to be a problem and they are now trying to fix it. I've seen this happen to other open source related projects using Marvell hardware as well, so the big question is whether Belkin can put enough pressure on them to get the source code released. Even if that happens, the source code will most likely need a rewrite or an insane amount of cleanup, as is typical for proprietary wifi drivers in the embedded space. There are many signs that if released, the source code to this driver is going to be horrible: weird function names, big module size, use of custom vendor-specific hostapd and wpa_supplicant drivers. This is most likely going to take a long time to resolve. A lot of this mess could have been avoided, if Belkin had talked to the developer community before finalizing the hardware specs. However, this is a lesson that a lot of companies trying to get into the open source market will have to learn the hard way. I'm assuming that the intentions behind creating this device were good, but given the uncertain nature of the wifi driver issue, I would not recommend buying any WRT1900AC devices until we have an open source wifi driver for it. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] AA: OpenSSL: fix CVE-2014-0160
On Tue, Apr 8, 2014 at 4:47 AM, Stijn Tintel st...@linux-ipv6.be wrote:
This patch, taken from upstream commit
96db9023b881d7cd9f379b0c154650d6c108e9a3, fixes the Heartbleed bug
(CVE-2014-0160).
IMHO it would make sense to update to 1.0.1g instead. At least I've done that
in my local tree ...
Helmut
Signed-off-by: Stijn Tintel st...@linux-ipv6.be
---
package/openssl/Makefile| 2 +-
package/openssl/patches/210-CVE-2014-0160.patch | 87
+
2 files changed, 88 insertions(+), 1 deletion(-)
create mode 100644 package/openssl/patches/210-CVE-2014-0160.patch
diff --git a/package/openssl/Makefile b/package/openssl/Makefile
index fa08774..fc3d1cf 100644
--- a/package/openssl/Makefile
+++ b/package/openssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=openssl
PKG_VERSION:=1.0.1e
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://www.openssl.org/source/ \
diff --git a/package/openssl/patches/210-CVE-2014-0160.patch
b/package/openssl/patches/210-CVE-2014-0160.patch
new file mode 100644
index 000..245de18
--- /dev/null
+++ b/package/openssl/patches/210-CVE-2014-0160.patch
@@ -0,0 +1,87 @@
+--- a/ssl/d1_both.c
b/ssl/d1_both.c
+@@ -1452,26 +1452,36 @@ dtls1_process_heartbeat(SSL *s)
+ unsigned int payload;
+ unsigned int padding = 16; /* Use minimum padding */
+
+- /* Read type and payload length first */
+- hbtype = *p++;
+- n2s(p, payload);
+- pl = p;
+-
+ if (s-msg_callback)
+ s-msg_callback(0, s-version, TLS1_RT_HEARTBEAT,
+ s-s3-rrec.data[0], s-s3-rrec.length,
+ s, s-msg_callback_arg);
+
++ /* Read type and payload length first */
++ if (1 + 2 + 16 s-s3-rrec.length)
++ return 0; /* silently discard */
++ hbtype = *p++;
++ n2s(p, payload);
++ if (1 + 2 + payload + 16 s-s3-rrec.length)
++ return 0; /* silently discard per RFC 6520 sec. 4 */
++ pl = p;
++
+ if (hbtype == TLS1_HB_REQUEST)
+ {
+ unsigned char *buffer, *bp;
++ unsigned int write_length = 1 /* heartbeat type */ +
++ 2 /* heartbeat length */ +
++ payload + padding;
+ int r;
+
++ if (write_length SSL3_RT_MAX_PLAIN_LENGTH)
++ return 0;
++
+ /* Allocate memory for the response, size is 1 byte
+* message type, plus 2 bytes payload length, plus
+* payload, plus padding
+*/
+- buffer = OPENSSL_malloc(1 + 2 + payload + padding);
++ buffer = OPENSSL_malloc(write_length);
+ bp = buffer;
+
+ /* Enter response type, length and copy payload */
+@@ -1482,11 +1492,11 @@ dtls1_process_heartbeat(SSL *s)
+ /* Random padding */
+ RAND_pseudo_bytes(bp, padding);
+
+- r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 +
payload + padding);
++ r = dtls1_write_bytes(s, TLS1_RT_HEARTBEAT, buffer,
write_length);
+
+ if (r = 0 s-msg_callback)
+ s-msg_callback(1, s-version, TLS1_RT_HEARTBEAT,
+- buffer, 3 + payload + padding,
++ buffer, write_length,
+ s, s-msg_callback_arg);
+
+ OPENSSL_free(buffer);
+--- a/ssl/t1_lib.c
b/ssl/t1_lib.c
+@@ -2486,16 +2486,20 @@ tls1_process_heartbeat(SSL *s)
+ unsigned int payload;
+ unsigned int padding = 16; /* Use minimum padding */
+
+- /* Read type and payload length first */
+- hbtype = *p++;
+- n2s(p, payload);
+- pl = p;
+-
+ if (s-msg_callback)
+ s-msg_callback(0, s-version, TLS1_RT_HEARTBEAT,
+ s-s3-rrec.data[0], s-s3-rrec.length,
+ s, s-msg_callback_arg);
+
++ /* Read type and payload length first */
++ if (1 + 2 + 16 s-s3-rrec.length)
++ return 0; /* silently discard */
++ hbtype = *p++;
++ n2s(p, payload);
++ if (1 + 2 + payload + 16 s-s3-rrec.length)
++ return 0; /* silently discard per RFC 6520 sec. 4 */
++ pl = p;
++
+ if (hbtype == TLS1_HB_REQUEST)
+ {
+ unsigned char *buffer, *bp;
--
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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] AA: OpenSSL: fix CVE-2014-0160
On Tue, Apr 8, 2014 at 2:14 PM, Helmut Schaa helmut.sc...@googlemail.com wrote: On Tue, Apr 8, 2014 at 4:47 AM, Stijn Tintel st...@linux-ipv6.be wrote: This patch, taken from upstream commit 96db9023b881d7cd9f379b0c154650d6c108e9a3, fixes the Heartbleed bug (CVE-2014-0160). IMHO it would make sense to update to 1.0.1g instead. At least I've done that in my local tree ... Hmm, you already did that in a second patch :) Sorry for the noise. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] To attach ar8236 switch driver to a qca9558 board.Help will be appreciate.
Just got a tplink wr881n couple days ago,which is qca9558 plus ar8236 You can check the inside looks here: http://forum.anywlan.com/thread-271726-1-1.html I want to see openwrt running on this platform. I tried flash wr1043nd-v2 image into it,seeing that wireless is ok. Then I happen to see a guy who did a mod openwrt call rippleOS which can support this machine.But he is not willing to open source. Here is the boot log of his firmware: http://pastebin.com/raw.php?i=mZ21j6mF [0.69] eth0: Atheros AG71xx at 0xb900, irq 4 [1.27] eth0: Atheros AR8236 switch driver attached. [2.42] ag71xx ag71xx.0: eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd043, driver=Atheros AR8216/AR8236/AR8316] I noticed these lines and started to mod wr1043nd-v2's mach,which is a qca9588+ar8237n.And the mach looks like this now: http://notepad.cc/share/Did7a2ZHNQ Here is wr881n's ttl boot log with my mod: http://notepad.cc/share/rMjp6FiCBx ag71xx ag71xx.1: connected to PHY at ag71xx-mdio.1:04 [uid=, driver=Generic PHY] PHY is found at place.But ar8236 driver is not attached. I wish some guru can help me get this freaking driver attached. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] lantiq vdsl driver settings
Hi, i have been playing with the TD8970 the last few days and tried to bring it online on a deutsche telekom adsl annex-b line. unfortunately i have totally failed so far. i managed to get the unit into showtime on my dslam using vdsl however. i also talked to people that have the driver/firmware running on British Telecom, KPN, 11 as vdsl and adsl. for the adsl driver we have a nice list of all the various xtu bits. for the vdsl driver they seem to be different. there are also 2 new options -M 0_1_2 the modes it should try 0 - none ?! 1 - adsl 2 - vdsl i understand this as it will loop over the provided sequence and try to get show time using it. -T 4_0_1 - the tc layer to use -i10_00_10_00_00_04_01_07 -T4_0_1 is confirmed working on the 11 line -i10_00_10_00_00_04_01_07 works on my vdsl dslam -i10_00_10_00_00_04_00_00 is set by the td8970 firmware for annex-b -i05_00_04_00_0C_01_00_00 is set by the td8970 firmware for annex-a has any one managed to get this working on deutsche telekom adsl lines ? does anyone know how to force adsl or vdsl ? i tried -M1 and -M2 but i got no showtime. could those people that managed to get the driver to work post the config they used ? does anyone have access to the docs for the driver so that we can extract a full list and make a sane uci config for this stuff ? Thanks in advance, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 0/4] ramips: Fix rt2880 Ethernet and wireless
These patches fix Ethernet and wireless on rt2880 boards. I have tested
on two systems with success.
The last patch is made against Roman Yeryomin's previously-submitted,
but not yet merged, pinctrl patch.
Note that the board DTS must define the port and PHY to connect to.
Here's an example for a board connecting to a IP175E 100mbit switch
at PHY 0:
ethernet@40 {
status = okay;
mtd-mac-address = factory 0x4;
port@0 {
phy-handle = phy0;
phy-mode = mii;
};
mdio-bus {
status = okay;
phy0: ethernet-phy@0 {
phy-mode = mii;
reg = 0;
};
};
};
If necessary, a fixed-link parameter can be specified instead of
phy-handle/phy-mode:
port@0 {
ralink,fixed-link = 100 1 1 1;
};
Claudio Leite (4):
ramips: enable port init function on RT2880 ethernet
ramips: set wmac clock on rt2880
ramips: squelch mdio debugging info on rt2880 ethernet
ramips: add rt2880 ethernet port device type
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/4] ramips: enable port init function on RT2880 ethernet
This just enables the existing function, allowing port
settings to be made via the board's DTS.
Signed-off-by: Claudio Leite lei...@staticky.com
---
.../patches-3.10/0218-NET-ralink-init_rt2880_port.patch | 12
1 file changed, 12 insertions(+)
create mode 100644
target/linux/ramips/patches-3.10/0218-NET-ralink-init_rt2880_port.patch
diff --git
a/target/linux/ramips/patches-3.10/0218-NET-ralink-init_rt2880_port.patch
b/target/linux/ramips/patches-3.10/0218-NET-ralink-init_rt2880_port.patch
new file mode 100644
index 000..54810b8
--- /dev/null
+++ b/target/linux/ramips/patches-3.10/0218-NET-ralink-init_rt2880_port.patch
@@ -0,0 +1,12 @@
+Index: linux-3.10.34/drivers/net/ethernet/ralink/soc_rt2880.c
+===
+--- linux-3.10.34.orig/drivers/net/ethernet/ralink/soc_rt2880.c
linux-3.10.34/drivers/net/ethernet/ralink/soc_rt2880.c
+@@ -41,6 +41,7 @@ struct fe_soc_data rt2880_data = {
+ .mdio_read = rt2880_mdio_read,
+ .mdio_write = rt2880_mdio_write,
+ .mdio_adjust_link = rt2880_mdio_link_adjust,
++ .port_init = rt2880_port_init,
+ };
+
+ const struct of_device_id of_fe_match[] = {
--
1.8.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/4] ramips: set wmac clock on rt2880
Probing the wireless device will fail without it, as the rt2800-soc
driver needs to check if the device has a 20MHz clock crystal.
The chip on the RT2880 boards uses 40MHz as far as I can tell.
Signed-off-by: Claudio Leite lei...@staticky.com
---
.../patches-3.10/0219-rt2880_wmac_clock.patch | 21 +
1 file changed, 21 insertions(+)
create mode 100644
target/linux/ramips/patches-3.10/0219-rt2880_wmac_clock.patch
diff --git a/target/linux/ramips/patches-3.10/0219-rt2880_wmac_clock.patch
b/target/linux/ramips/patches-3.10/0219-rt2880_wmac_clock.patch
new file mode 100644
index 000..32070a3
--- /dev/null
+++ b/target/linux/ramips/patches-3.10/0219-rt2880_wmac_clock.patch
@@ -0,0 +1,21 @@
+Index: linux-3.10.34/arch/mips/ralink/rt288x.c
+===
+--- linux-3.10.34.orig/arch/mips/ralink/rt288x.c
linux-3.10.34/arch/mips/ralink/rt288x.c
+@@ -52,7 +52,7 @@ static void rt288x_wdt_reset(void)
+
+ void __init ralink_clk_init(void)
+ {
+- unsigned long cpu_rate;
++ unsigned long cpu_rate, wmac_rate = 4000;
+
+ u32 t = rt_sysc_r32(SYSC_REG_SYSTEM_CONFIG);
+ t = ((t SYSTEM_CONFIG_CPUCLK_SHIFT) SYSTEM_CONFIG_CPUCLK_MASK);
+@@ -78,6 +78,7 @@ void __init ralink_clk_init(void)
+ ralink_clk_add(300500.uart, cpu_rate / 2);
+ ralink_clk_add(300c00.uartlite, cpu_rate / 2);
+ ralink_clk_add(40.ethernet, cpu_rate / 2);
++ ralink_clk_add(48.wmac, wmac_rate);
+ }
+
+ void __init ralink_of_remap(void)
--
1.8.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/4] ramips: squelch mdio debugging info on rt2880 ethernet
Use pr_debug rather than pr_info since it is only relevant for debugging. Signed-off-by: Claudio Leite lei...@staticky.com --- .../0220-NET-ralink-squelch_mdio_access.patch | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 target/linux/ramips/patches-3.10/0220-NET-ralink-squelch_mdio_access.patch diff --git a/target/linux/ramips/patches-3.10/0220-NET-ralink-squelch_mdio_access.patch b/target/linux/ramips/patches-3.10/0220-NET-ralink-squelch_mdio_access.patch new file mode 100644 index 000..bc92a02 --- /dev/null +++ b/target/linux/ramips/patches-3.10/0220-NET-ralink-squelch_mdio_access.patch @@ -0,0 +1,22 @@ +Index: linux-3.10.34/drivers/net/ethernet/ralink/mdio_rt2880.c +=== +--- linux-3.10.34.orig/drivers/net/ethernet/ralink/mdio_rt2880.c linux-3.10.34/drivers/net/ethernet/ralink/mdio_rt2880.c +@@ -136,7 +136,7 @@ int rt2880_mdio_read(struct mii_bus *bus + if (err) + return 0x; + +- pr_info(%s: addr=%04x, reg=%04x, value=%04x\n, __func__, ++ pr_debug(%s: addr=%04x, reg=%04x, value=%04x\n, __func__, + phy_addr, phy_reg, fe_r32(FE_MDIO_ACCESS) 0x); + + return fe_r32(FE_MDIO_ACCESS) 0x; +@@ -148,7 +148,7 @@ int rt2880_mdio_write(struct mii_bus *bu + int err; + u32 t; + +- pr_info(%s: addr=%04x, reg=%04x, value=%04x\n, __func__, ++ pr_debug(%s: addr=%04x, reg=%04x, value=%04x\n, __func__, + phy_addr, phy_reg, fe_r32(FE_MDIO_ACCESS) 0x); + + err = rt2880_mdio_wait_ready(priv); -- 1.8.2.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/4] ramips: add rt2880 ethernet port device type
This patch is made against Roman Yeryomin's previously-submitted,
but not yet merged, rt2880 DT pinctrl patch.
Signed-off-by: Claudio Leite lei...@staticky.com
---
target/linux/ramips/dts/rt2880.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/target/linux/ramips/dts/rt2880.dtsi
b/target/linux/ramips/dts/rt2880.dtsi
index 287d35a..68e6652 100644
--- a/target/linux/ramips/dts/rt2880.dtsi
+++ b/target/linux/ramips/dts/rt2880.dtsi
@@ -153,11 +153,19 @@
compatible = ralink,rt2880-eth;
reg = 0x0040 1;
+ #address-cells = 1;
+ #size-cells = 0;
+
interrupt-parent = cpuintc;
interrupts = 5;
status = disabled;
+ port@0 {
+ compatible = ralink,rt2880-port, ralink,eth-port;
+ reg = 0;
+ };
+
mdio-bus {
#address-cells = 1;
#size-cells = 0;
--
1.8.2.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
On Tue, Apr 8, 2014 at 3:34 PM, John Crispin j...@phrozen.org wrote: Hi, i have been playing with the TD8970 the last few days and tried to bring it online on a deutsche telekom adsl annex-b line. unfortunately i have totally failed so far. i managed to get the unit into showtime on my dslam using vdsl however. i also talked to people that have the driver/firmware running on British Telecom, KPN, 11 as vdsl and adsl. for the adsl driver we have a nice list of all the various xtu bits. for the vdsl driver they seem to be different. Afaik the xtu bits are for both ADSL and VDSL - this is basically a big bitfield enabling different modes (Annex A ADSL1, Annex B ADSL1, etc). there are also 2 new options -M 0_1_2 the modes it should try 0 - none ?! 1 - adsl 2 - vdsl i understand this as it will loop over the provided sequence and try to get show time using it. -T 4_0_1 - the tc layer to use -i10_00_10_00_00_04_01_07 -T4_0_1 is confirmed working on the 11 line -i10_00_10_00_00_04_01_07 works on my vdsl dslam -i10_00_10_00_00_04_00_00 is set by the td8970 firmware for annex-b -i05_00_04_00_0C_01_00_00 is set by the td8970 firmware for annex-a has any one managed to get this working on deutsche telekom adsl lines ? Do you have a annex b or annex j line? this makes a diference for the xtu bits to enable. does anyone know how to force adsl or vdsl ? i tried -M1 and -M2 but i got no showtime. Have you tried -M 0_1_0 or -M 0_0_2? Regards Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
does anyone know how to force adsl or vdsl ? i tried -M1 and -M2 but i got no showtime. Have you tried -M 0_1_0 or -M 0_0_2? it is not a matter of trying random values but knowing what they mean and how to build the parameters from uci. what do those parameters do that you listed ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: easycwmp package
Hi Luka In our company we really appreciate the freecwmp project because it has a good source structure. In fact EasyCwmp is derived from freecwmp project (git revision a13ccb5097d5c8445927f85529ec2322ed968852 date 2012/12/23) At the beginning, we tried to contribute to the freecwmp project (http://www.linux-mips.org/archives/freecwmp/2012-12/threads.html#00076) but we found that the contribution process takes time and we found that our way and methods does not correspond to the freecwmp ways and methods. So we choosed to continue the development of freecwmp in a new separate project with the name EasyCwmp in order to be the project maintainer because we wanted to speedup the development of a complete cwmp client under open source license and because we wanted to complete the development of freecwmp in our ways and methods. We really like to be a cwmp open source maintainer in order to be more faster in the evolution, in maintenance, in adding new parameters. So we really appreciate if you add our EasyCwmp project to the OpenWRT packages. Adding EasyCwmp package to the OpenWRT will enrich the OpenWRT package database. And then it's up to the user to choose the package he wants (what ever easycwmp or freecwmp or others) in the compilation phase (like the microxml package and the minixml package) In our easycwmp.org, we copied from freecwmp.org the sentences related to the source structure and the install for other Linux platforms and we putted your freecwmp.org as reference in the main page of easycwmp.org I will send you the changes (patches) to be applied to your freecwmp project in order to be aligned with the EasyCwmp project. The changes contains 65 patches and they include 45 files changed, 6588 insertions(+), 2280 deletions(-). Your freecwmp code contains 6477 lines so the changes are major: 101% insertions(+), 35% deletions(-). In brief, the change descriptions are: - get_parameter_values (GetParameterValues) method supports many parameter names - update inform in order to get parameters from scripts - add GetParameterNames: xml_get_parameter_name handler - change the communication between script and c core with json messages using pipe - add backup file to save events, downloads, ACS URL, TransferComplete in a local file - add ScheduleInform Event - improve BOOT and BOOSTRAP EVENT and save them in backup file - improve events - cancel retry inform if inform is sent before - improve RPC CPE of GetRPCMethods - supporting HoldRequests/NoMoreRequests - improve download RPC - add downloads to backup file, - add TC(transfer complete) and save it in the backup file. - add events 7 Transfer complete and M download and save in backup file - improve the preparing notification for inform - add AddObject and DeleteObject xml handlers - add reboot handler - improve apply config and add apply firmware - connection request should use digest authentication and not basic authentication (as described in the standard) - fix some connection request issues - add fault message for SetParameterValues faults (as described in the standard) - Add Digest authentication and basic authentication to the ACS - periodic interval and periodic enable should be present as options in the freecwmp config. And fix periodic behavior. - Add Add/Delete Object for InternetGatewayDevice.LANDevice.1.WLANConfiguration. in the lan_device script - the change of wan interface should cause an inform with event value change - support of the 3.7.1.6 Method Retry Behavior (From the standard) - Add timeout (30s) when sending http message to the ACS. (as indicated in the standard) - add apply service action in the freecwmp scripts in order to restart services at the end of the session and not in the SPV - Calling fault for all method handlers in case of faults - supporting ?xml tag and new lines in the received soap msgs - factory reset, reboot, service restart and config reload should be executed at the end of the session - supporting username and password in download - supporting value with white spaces in SPV - no need for thread mutexes. the daemon is running in sequential mode - event and TC delete should respect the event remove policy as indicated in the event chapter in the standard - remove dummy mode - remove b64.c and b64.h files - Optimize and clean up all scripts - ConnectionRequest event should not be retried (according to the standard) - ubus notify with parameter attribute = 0 should not be added in the parameter list of the inform - add version option (-v, --version) as argument of the daemon - add some syslog messages in the code. - avoid close stdin and stdout in the non debug mode. closing stdin and stdout will affect the communication with external commands - adapt the code for the Attitude Adjustment building - return 9003 fault code when file type is wrong - notification of added parameters with AddObject should be = to 0 - Deleted parameters with DeleteObject
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
Felix Fietkau n...@openwrt.org writes: I've seen this happen to other open source related projects using Marvell hardware as well, so the big question is whether Belkin can put enough pressure on them to get the source code released. Even if that happens, the source code will most likely need a rewrite or an insane amount of cleanup, as is typical for proprietary wifi drivers in the embedded space. There are many signs that if released, the source code to this driver is going to be horrible: weird function names, big module size, use of custom vendor-specific hostapd and wpa_supplicant drivers. This is most likely going to take a long time to resolve. I know these comments are based on experience, but I still feel you are a bit too pessimistic here :-) After all, we do have the mwl8k driver in mainline and Marvell has commited a lot to that, including the 8764 bits. It's not too unlikely that they will add 8864 support as well, is it? And wrt the size: Some of this is probably due to firmware being built into the module. And some is debugging symbols. The rest is of course bloat mostly caused by unnecessary reimplementation. Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: easycwmp package
Hi Rafal Comparing to freecwmp, EasyCwmp is a complete cwmp client and it's fully conform with the TR069 standard. freecwmp has a good source structure, In fact EasyCwmp is derived from freecwmp project thanks to the source structure. we chose to continue the development of freecwmp in a new separate project with the name EasyCwmp because we wanted to speedup the development of a complete cwmp client under open source license and because we wanted to complete the development of freecwmp in our ways and methods. Adding EasyCwmp package to the OpenWRT will enrich the OpenWRT package database. And then it's up to the user to choose the package he wants (what ever EasyCwmp or freecwmp or others) in the compilation phase (like the microxml package and the minixml package) Regards MOHAMED Kallel Le 08/04/2014 10:19, Rafał Miłecki a écrit : 2014-04-07 18:04 GMT+02:00 MOHAMED Kallel mohamed.kal...@pivasoftware.com: Add new package. Its name is easycwmp. easycwmp is a GPLv2 open source implementation of the TR069 cwmp standard. easycwmp is a complete cwmp client fully conform with the TR-069 standrad Have you tried to participate in freecwmp project? Were your patches rejected, or something? Could you publish your private svn, so we can see your patches in a nice form (one by one) and see if they can be simply included in freecwmp? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
On 2014-04-08 17:02, Bjørn Mork wrote: Felix Fietkau n...@openwrt.org writes: I've seen this happen to other open source related projects using Marvell hardware as well, so the big question is whether Belkin can put enough pressure on them to get the source code released. Even if that happens, the source code will most likely need a rewrite or an insane amount of cleanup, as is typical for proprietary wifi drivers in the embedded space. There are many signs that if released, the source code to this driver is going to be horrible: weird function names, big module size, use of custom vendor-specific hostapd and wpa_supplicant drivers. This is most likely going to take a long time to resolve. I know these comments are based on experience, but I still feel you are a bit too pessimistic here :-) I really do hope to be proven wrong on this one. After all, we do have the mwl8k driver in mainline and Marvell has commited a lot to that, including the 8764 bits. It's not too unlikely that they will add 8864 support as well, is it? I don't know how likely or unlikely it is. I also don't know how likely it is that they will care about the driver enough to keep AP mode support for embedded devices tested and working well, as opposed to just adding it as an afterthought. And wrt the size: Some of this is probably due to firmware being built into the module. And some is debugging symbols. The rest is of course bloat mostly caused by unnecessary reimplementation. Right. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: easycwmp package
2014-04-08 17:29 GMT+02:00 KALLEL Mohamed mohamed.kal...@pivasoftware.com: Comparing to freecwmp, EasyCwmp is a complete cwmp client and it's fully conform with the TR069 standard. freecwmp has a good source structure, In fact EasyCwmp is derived from freecwmp project thanks to the source structure. we chose to continue the development of freecwmp in a new separate project with the name EasyCwmp because we wanted to speedup the development of a complete cwmp client under open source license and because we wanted to complete the development of freecwmp in our ways and methods. Adding EasyCwmp package to the OpenWRT will enrich the OpenWRT package database. And then it's up to the user to choose the package he wants (what ever EasyCwmp or freecwmp or others) in the compilation phase (like the microxml package and the minixml package) Really, we can read, you don't have to repeat the same thing over and over again ;) It's 3rd or 4th time I read the same copy paste text. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
2014-04-08 17:02 GMT+02:00, Bjørn Mork bj...@mork.no: Felix Fietkau n...@openwrt.org writes: I've seen this happen to other open source related projects using Marvell hardware as well, so the big question is whether Belkin can put enough pressure on them to get the source code released. Even if that happens, the source code will most likely need a rewrite or an insane amount of cleanup, as is typical for proprietary wifi drivers in the embedded space. There are many signs that if released, the source code to this driver is going to be horrible: weird function names, big module size, use of custom vendor-specific hostapd and wpa_supplicant drivers. This is most likely going to take a long time to resolve. I know these comments are based on experience, but I still feel you are a bit too pessimistic here :-) Felix is not pessimistic; he knows better than most the high amount of job and problems that generate a wifi driver with such few information and, in addition it seems to use a different API. Take in mind that the Broadcom wireless proprietary driver generate some problems from time to time. After all, we do have the mwl8k driver in mainline and Marvell has commited a lot to that, including the 8764 bits. It's not too unlikely that they will add 8864 support as well, is it? And wrt the size: Some of this is probably due to firmware being built into the module. And some is debugging symbols. The rest is of course bloat mostly caused by unnecessary reimplementation. Bjørn In my opinion you are too confident about the similarities between mwifiex[1], mwl8k[2] and the Avastar 88W8864 drivers. How much wireless ICs aren't supported in linux and how much of them have required a lot of job doing reverse engineering or clean room development? Being optimistic Marvell will release a binary file with some additional code to interface with the OpenWRT wireless subsystem. We will not see a free functional driver in months or ages. Regards: Pepe [1]: http://wireless.kernel.org/en/users/Drivers/mwifiex [2]: http://wireless.kernel.org/en/users/Drivers/mwl8k ___ 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] New package: easycwmp package
2014-04-08 16:43 GMT+02:00 KALLEL Mohamed mohamed.kal...@pivasoftware.com: At the beginning, we tried to contribute to the freecwmp project (http://www.linux-mips.org/archives/freecwmp/2012-12/threads.html#00076) but we found that the contribution process takes time and we found that our way and methods does not correspond to the freecwmp ways and methods. Well, in open source world we often care a lot about quality. It's needed to keep code in a nice shape and allow any developer at any time to join the project. I've quickly checked your commits sent back in 2012 and there were many things correctly pointed out by Luka that you ignored. What you sent as NEW PATCH version: 1) Was incorrectly formatted (no [PATCH] tag, not version number, sequence put at the end, no in-reply-to header) 2) Didn't address most of the comments from Luka 3) Was breaking code formatting So there were good reasons your patches weren't accepted :( So we really appreciate if you add our EasyCwmp project to the OpenWRT packages. Adding EasyCwmp package to the OpenWRT will enrich the OpenWRT package database. And then it's up to the user to choose the package he wants (what ever easycwmp or freecwmp or others) in the compilation phase (like the microxml package and the minixml package) I don't want to end up with two same-base projects developed independently while they both could share improvements. Let's try to play it wisely. I will send you the changes (patches) to be applied to your freecwmp project in order to be aligned with the EasyCwmp project. The changes contains 65 patches and they include 45 files changed, 6588 insertions(+), 2280 deletions(-). Your freecwmp code contains 6477 lines so the changes are major: 101% insertions(+), 35% deletions(-). Changes include a lot of white space changes, indention changes, etc. A lot of code is still the same between the both projects. Please share your repo / patches to the public *first*. I like your list of changes, but we still need a bunch of patches you've developed to work on this in a sane way. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] To attach ar8236 switch driver to a qca9558 board.Help will be appreciate.
Just to check if it is listed on the channel. 2014-04-08 20:57 GMT+08:00 Hero huang hero18...@gmail.com: Just got a tplink wr881n couple days ago,which is qca9558 plus ar8236 You can check the inside looks here: http://forum.anywlan.com/thread-271726-1-1.html I want to see openwrt running on this platform. I tried flash wr1043nd-v2 image into it,seeing that wireless is ok. Then I happen to see a guy who did a mod openwrt call rippleOS which can support this machine.But he is not willing to open source. Here is the boot log of his firmware: http://pastebin.com/raw.php?i=mZ21j6mF [0.69] eth0: Atheros AG71xx at 0xb900, irq 4 [1.27] eth0: Atheros AR8236 switch driver attached. [2.42] ag71xx ag71xx.0: eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd043, driver=Atheros AR8216/AR8236/AR8316] I noticed these lines and started to mod wr1043nd-v2's mach,which is a qca9588+ar8237n.And the mach looks like this now: http://notepad.cc/share/Did7a2ZHNQ Here is wr881n's ttl boot log with my mod: http://notepad.cc/share/rMjp6FiCBx ag71xx ag71xx.1: connected to PHY at ag71xx-mdio.1:04 [uid=, driver=Generic PHY] PHY is found at place.But ar8236 driver is not attached. I wish some guru can help me get this freaking driver attached. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
On Tue, Apr 8, 2014 at 4:42 PM, John Crispin j...@phrozen.org wrote: does anyone know how to force adsl or vdsl ? i tried -M1 and -M2 but i got no showtime. Have you tried -M 0_1_0 or -M 0_0_2? it is not a matter of trying random values but knowing what they mean and how to build the parameters from uci. what do those parameters do that you listed ? I have no idea. This was just a guess on the part that all the other parameters are in this bitfield notion, so I assumed that this one works the same. Shouldn't the cpe-control sources tell you what they are good for? Jonas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] New package: easycwmp package
Hello Rafal I m aware with the source quality issue And as answer to Luka concerning the NEW PATCH version, we have sent a new patches [PATCH v2 00/10] containing 10 patches that take account the Luka remarks but he rejected them (the patches are not merged in the freecwmp project). Regards Le 08/04/2014 17:23, Rafał Miłecki a écrit : 2014-04-08 16:43 GMT+02:00 KALLEL Mohamed mohamed.kal...@pivasoftware.com: At the beginning, we tried to contribute to the freecwmp project (http://www.linux-mips.org/archives/freecwmp/2012-12/threads.html#00076) but we found that the contribution process takes time and we found that our way and methods does not correspond to the freecwmp ways and methods. Well, in open source world we often care a lot about quality. It's needed to keep code in a nice shape and allow any developer at any time to join the project. I've quickly checked your commits sent back in 2012 and there were many things correctly pointed out by Luka that you ignored. What you sent as NEW PATCH version: 1) Was incorrectly formatted (no [PATCH] tag, not version number, sequence put at the end, no in-reply-to header) 2) Didn't address most of the comments from Luka 3) Was breaking code formatting So there were good reasons your patches weren't accepted :( So we really appreciate if you add our EasyCwmp project to the OpenWRT packages. Adding EasyCwmp package to the OpenWRT will enrich the OpenWRT package database. And then it's up to the user to choose the package he wants (what ever easycwmp or freecwmp or others) in the compilation phase (like the microxml package and the minixml package) I don't want to end up with two same-base projects developed independently while they both could share improvements. Let's try to play it wisely. I will send you the changes (patches) to be applied to your freecwmp project in order to be aligned with the EasyCwmp project. The changes contains 65 patches and they include 45 files changed, 6588 insertions(+), 2280 deletions(-). Your freecwmp code contains 6477 lines so the changes are major: 101% insertions(+), 35% deletions(-). Changes include a lot of white space changes, indention changes, etc. A lot of code is still the same between the both projects. Please share your repo / patches to the public *first*. I like your list of changes, but we still need a bunch of patches you've developed to work on this in a sane way. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
On 08/04/2014 19:05, Jonas Gorski wrote: I have no idea. This was just a guess on the part that all the other parameters are in this bitfield notion, so I assumed that this one works the same. Shouldn't the cpe-control sources tell you what they are good for? yes but that takes too long :) i just got an off-list mail expalining things abut vdsl tone sets that i never heard before and also a reason why it fails for me and what i need to do to fix it. i'll push an updated dsl_control once i finished reworking this John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
Hello, I would be interested by that too: I'm currently working on the same TD-W8970, using a annex-a ADSL2+ firmware. However, I lack VDSL2 annex-a firmware , as this standard has been recently allowed in France. I could confirm that , when using my current firmware on a VDSL2 POTS , the synchronisation is established on ADSL2+, not VDSL2. Besides, I still have some problems linked to the Wifi chipset that hang after a while, and with a *very* long boot that seems to be related to the internal switch, which is reseted multiple time during bootup (GPIO-related ? I do not see any driver for this switch). Thanks for sharing your findings, Julien Le 08/04/2014 19:14, John Crispin a écrit : On 08/04/2014 19:05, Jonas Gorski wrote: I have no idea. This was just a guess on the part that all the other parameters are in this bitfield notion, so I assumed that this one works the same. Shouldn't the cpe-control sources tell you what they are good for? yes but that takes too long :) i just got an off-list mail expalining things abut vdsl tone sets that i never heard before and also a reason why it fails for me and what i need to do to fix it. i'll push an updated dsl_control once i finished reworking this John ___ 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] lantiq vdsl driver settings
Make sure you have selected kmod-ltq-ptm-vr9 and kmod-ltq-atm-vr9 deselected in addition to a VR9 vdsl firmware. The firm you need should be into the TD-W8970 source code. Regards. 2014-04-08 19:51 GMT+02:00, obconseil obcons...@gmail.com: Hello, I would be interested by that too: I'm currently working on the same TD-W8970, using a annex-a ADSL2+ firmware. However, I lack VDSL2 annex-a firmware , as this standard has been recently allowed in France. I could confirm that , when using my current firmware on a VDSL2 POTS , the synchronisation is established on ADSL2+, not VDSL2. Besides, I still have some problems linked to the Wifi chipset that hang after a while, and with a *very* long boot that seems to be related to the internal switch, which is reseted multiple time during bootup (GPIO-related ? I do not see any driver for this switch). Thanks for sharing your findings, Julien Le 08/04/2014 19:14, John Crispin a écrit : On 08/04/2014 19:05, Jonas Gorski wrote: I have no idea. This was just a guess on the part that all the other parameters are in this bitfield notion, so I assumed that this one works the same. Shouldn't the cpe-control sources tell you what they are good for? yes but that takes too long :) i just got an off-list mail expalining things abut vdsl tone sets that i never heard before and also a reason why it fails for me and what i need to do to fix it. i'll push an updated dsl_control once i finished reworking this John ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [ramips] Fix wireless eeprom extraction
Broken after 40411 Signed-off-by: Roman Yeryomin ro...@advem.lv --- target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom index 5906e68..d6560fd 100644 --- a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom +++ b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom @@ -25,6 +25,7 @@ FW=/lib/firmware/$FIRMWARE [ -e $FW ] exit 0 . /lib/ramips.sh +. /lib/functions/system.sh board=$(ramips_board_name) -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] is anybody working on supporting Linksys WRT1900ac ?
On 04/08/2014 06:04 PM, Felix Fietkau wrote: On 2014-04-08 17:02, Bjørn Mork wrote: Felix Fietkau n...@openwrt.org writes: I've seen this happen to other open source related projects using Marvell hardware as well, so the big question is whether Belkin can put enough pressure on them to get the source code released. Even if that happens, the source code will most likely need a rewrite or an insane amount of cleanup, as is typical for proprietary wifi drivers in the embedded space. There are many signs that if released, the source code to this driver is going to be horrible: weird function names, big module size, use of custom vendor-specific hostapd and wpa_supplicant drivers. This is most likely going to take a long time to resolve. I know these comments are based on experience, but I still feel you are a bit too pessimistic here :-) I really do hope to be proven wrong on this one. After all, we do have the mwl8k driver in mainline and Marvell has commited a lot to that, including the 8764 bits. It's not too unlikely that they will add 8864 support as well, is it? I don't know how likely or unlikely it is. I also don't know how likely it is that they will care about the driver enough to keep AP mode support for embedded devices tested and working well, as opposed to just adding it as an afterthought. And wrt the size: Some of this is probably due to firmware being built into the module. And some is debugging symbols. The rest is of course bloat mostly caused by unnecessary reimplementation. Right. A driver for the Avastar 88W8764, which seams to be an older version of the driver used by Belkin for their 88W8864 was released under the terms of the GPL on github: https://github.com/kmihelich/wlan-smileplug I checked ~5 function names from this source code and found them in the binary provided by Belkin. This situation looks better than the situation around Broadcom wireless drivers. I hope Belkin gets Marvell to allow them to release at least the source code or better to get them to add support for the 88W8864 into one of their mainline wireless drivers. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] ramips: Fix rt2880 Ethernet and wireless
On 8 April 2014 16:39, Claudio Leite lei...@staticky.com wrote:
These patches fix Ethernet and wireless on rt2880 boards. I have tested
on two systems with success.
The last patch is made against Roman Yeryomin's previously-submitted,
but not yet merged, pinctrl patch.
Note that the board DTS must define the port and PHY to connect to.
Here's an example for a board connecting to a IP175E 100mbit switch
at PHY 0:
ethernet@40 {
status = okay;
mtd-mac-address = factory 0x4;
port@0 {
phy-handle = phy0;
phy-mode = mii;
};
mdio-bus {
status = okay;
phy0: ethernet-phy@0 {
phy-mode = mii;
reg = 0;
};
};
};
If necessary, a fixed-link parameter can be specified instead of
phy-handle/phy-mode:
port@0 {
ralink,fixed-link = 100 1 1 1;
};
Claudio Leite (4):
ramips: enable port init function on RT2880 ethernet
ramips: set wmac clock on rt2880
ramips: squelch mdio debugging info on rt2880 ethernet
ramips: add rt2880 ethernet port device type
___
I can confirm these patches are working with Asus rt-n15.
After these and another one I sent for eeprom extraction are applied
to trunk I will send another one to fix DT for Asus board.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
On 08/04/2014 19:51, obconseil wrote: Hello, I would be interested by that too: I'm currently working on the same TD-W8970, using a annex-a ADSL2+ firmware. However, I lack VDSL2 annex-a firmware , as this standard has been recently allowed in France. http://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/super-fastfibreaccess/landrgnu.do ECI Arcadyan VDSL modem has the a and b fw inside the dl/ folder I could confirm that , when using my current firmware on a VDSL2 POTS , the synchronisation is established on ADSL2+, not VDSL2. try adding -M2 to the vdsl_cpe_control and make the last 2 bytes of the xtu _01_07 i think that will force vdsl. Besides, I still have some problems linked to the Wifi chipset that hang after a while, and with a *very* long boot that seems to be related to the internal switch, which is reseted multiple time during bootup (GPIO-related ? I do not see any driver for this switch). the spi driver fails on this unit and we are using gpio-spi bit banging :) i will look at the spi irq issue when i am done with vdsl John ___ 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] [ramips] Fix pinctrl in DT for rt2880
On 8 April 2014 19:41, Claudio Leite lei...@staticky.com wrote: * Roman Yeryomin (leroi.li...@gmail.com) wrote: On 8 April 2014 14:41, Claudio Leite lei...@staticky.com wrote: Really funny timing-nobody seemed to be interested in rt2880 for a long time, and then we both fix it at the same time! Actually a friend of mine has a whole network based on asus rt-n15 but he uses some old versions (before DTs and pinmux were introduced). And I just decided to check what is going on with it because I saw the pinmux patches. Sorry to bombard you with e-mails, but I noticed in the RT-N15.dts patch, the mdio pins are set to gpio. The old board file from Attitude Adjustment has ony i2c and uart0 pins set to gpio. I think this'll interfere with connecting the PHY even after my patches are applied. I think by default it configures mdio as mdio--I had a mdio_pins group in my rt2880.dtsi, but when I submitted the patches I redid the ethernet port stuff against the one you submitted. It worked fine despite not linking or otherwise configuring the mdio pins. So, just removing that one entry should do the trick. Without mdio pins set the switch driver cannot identify it at all. I know in older versions (pre DTs) the mdio pins were not touched. I'm not sure about the actual reason but it seems strange to me also. Maybe there are some other mistakes in pinmux driver I'm not aware of. Anyway, I've tested your patches and they work fine. Also I've sent another one to fix eeprom extraction which was broken by Felix recently. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] odhcp6c: don't handle certain RA data if the kernel is, configured to take care of it
Am 08.04.2014 08:03, schrieb Steven Barth: Hello Heiner, thanks, however overriding the kernel behavior is intentional as its handling of e.g. routes is very limited. Also getting address from both the kernel and through dhcpv6 to netifd to the kernel causes conflicts such as the ones you noted. If you want to use Kernel RA-handling please disable the dhcpv6 protocol handler on said interface. If you really want to do this I suppose I could live with a manual switch for odhcp6c / the dhcpv6 handler to turn of RA-handling altogether. However the results won't be very pretty. Regards, Steven Steven, appreciate your feedback. My use case: I want to use temporary addresses on an autoconfigured interface and need stateless dhcpv6 for getting name server information. As netifd can't deal with temporary addresses yet I have to let the kernel take care of it. And disabling dhcpv6 is also not an option as I need it for getting the nameserver information. I'm aware that kernel handling of routes is limited and that there is good reason to handle it via a userspace application. However I wonder whether userspace and kernel doing the same thing in parallel and potentially interfering with each other is the best solution. Shouldn't either kernel or userspace do it? If someone decides to let userspace (netifd) handle routes etc. then IMHO the consequence should be that he switches off RA handling in the kernel by sysctl.conf and the respective net.ipv6.conf settings. And that's something we can detect in odhcp6c and react accordingly. Also I wouldn't want to disable RA handling completely in odhcp6c. Even if the kernel takes care of addresses and routes he doesn't recognize (yet) DNS information in RAs as defined in RfC 5006/6106. There might be good reason to let kernel and userspace take care of different parts of the RA information. By the way, as I mentioned temporary addresses: The introduction of the IFA_F_MANAGETEMPADDR flag with kernel 3.13 made it easy for userspace applications to deal with temporary addresses. Adding it to system_addr in netifd should be a minimal extension. I could check and propose a patch .. Kind regards, Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, On Tue, Apr 08, 2014 at 08:22:45AM +0200, Steven Barth wrote: i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgpBKyu5CNqOd.pgp Description: PGP signature ___ 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] [ramips] Fix pinctrl in DT for rt2880
* Roman Yeryomin (leroi.li...@gmail.com) wrote:
On 8 April 2014 19:41, Claudio Leite lei...@staticky.com wrote:
* Roman Yeryomin (leroi.li...@gmail.com) wrote:
I think by default it configures mdio as mdio--I had a mdio_pins group
in my rt2880.dtsi, but when I submitted the patches I redid the
ethernet port stuff against the one you submitted. It worked fine
despite not linking or otherwise configuring the mdio pins. So, just
removing that one entry should do the trick.
Without mdio pins set the switch driver cannot identify it at all. I
know in older versions (pre DTs) the mdio pins were not touched. I'm
not sure about the actual reason but it seems strange to me also.
I see, is that with mdio configured explicitly to be mdio, or gpio?
The rtl8366 is configured differently from the IP175E in my router so
what works for me might not for you.
Also I've sent another one to fix eeprom extraction which was broken
by Felix recently.
It's possible to do that from the dts as well:
wmac@48 {
status = okay;
ralink,mtd-eeprom = factory 0;
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [tools] sparse: add as a new package selectable from the config
This change does multiple things, all related to enable sparse usage as a static analysis tool selectable from the OpenWrt configuration: *add a KERNEL_SPARSE option in the config to add sparse to the kernel build (through the C=1 option usage) *add sparse as a new host tools. It will get selected automatically when the above option will be enabled Signed-off-by: Mathieu Olivari math...@qca.qualcomm.com --- config/Config-kernel.in|4 include/kernel-defaults.mk |4 tools/Makefile |1 + tools/sparse/Makefile | 22 ++ 4 files changed, 31 insertions(+) create mode 100644 tools/sparse/Makefile diff --git a/config/Config-kernel.in b/config/Config-kernel.in index a475e9a..dd83cf9 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -144,6 +144,10 @@ config USE_RFKILL bool Enable rfkill support default RFKILL_SUPPORT +config USE_SPARSE + bool Enable sparse check during kernel build + default n + # # CGROUP support symbols # diff --git a/include/kernel-defaults.mk b/include/kernel-defaults.mk index caaa09d..322aeed 100644 --- a/include/kernel-defaults.mk +++ b/include/kernel-defaults.mk @@ -24,6 +24,10 @@ ifneq (,$(KERNEL_CC)) KERNEL_MAKEOPTS += CC=$(KERNEL_CC) endif +ifdef CONFIG_USE_SPARSE + KERNEL_MAKEOPTS += C=1 CHECK=$(STAGING_DIR_HOST)/bin/sparse +endif + export HOST_EXTRACFLAGS=-I$(STAGING_DIR_HOST)/include # defined in quilt.mk diff --git a/tools/Makefile b/tools/Makefile index 428cf0b..75d2b0d 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -38,6 +38,7 @@ tools-$(CONFIG_TARGET_ar71xx) += lzma-old squashfs tools-y += lzma squashfs4 tools-$(BUILD_B43_TOOLS) += b43-tools tools-$(BUILD_PPL_CLOOG) += ppl cloog +tools-$(CONFIG_USE_SPARSE) += sparse # builddir dependencies $(curdir)/bison/compile := $(curdir)/flex/install diff --git a/tools/sparse/Makefile b/tools/sparse/Makefile new file mode 100644 index 000..6cdeed5 --- /dev/null +++ b/tools/sparse/Makefile @@ -0,0 +1,22 @@ +# +# Copyright (C) 2014 Qualcomm-Atheros Inc. +# + +include $(TOPDIR)/rules.mk + +PKG_NAME:=sparse +PKG_VERSION:=0.5.0 + +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz +PKG_SOURCE_URL:=@KERNEL/software/devel/sparse/dist/ +PKG_MD5SUM:=68bc834c57836251fbee55a7707bab39 + +PKG_BUILD_PARALLEL:=1 + +include $(INCLUDE_DIR)/host-build.mk + +define Host/Install + $(INSTALL_BIN) $(HOST_BUILD_DIR)/sparse $(STAGING_DIR_HOST)/bin +endef + +$(eval $(call HostBuild)) -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. Cheers, Steven ___ 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] [ramips] Fix pinctrl in DT for rt2880
On 8 April 2014 23:00, Claudio Leite lei...@staticky.com wrote:
* Roman Yeryomin (leroi.li...@gmail.com) wrote:
On 8 April 2014 19:41, Claudio Leite lei...@staticky.com wrote:
* Roman Yeryomin (leroi.li...@gmail.com) wrote:
I think by default it configures mdio as mdio--I had a mdio_pins group
in my rt2880.dtsi, but when I submitted the patches I redid the
ethernet port stuff against the one you submitted. It worked fine
despite not linking or otherwise configuring the mdio pins. So, just
removing that one entry should do the trick.
Without mdio pins set the switch driver cannot identify it at all. I
know in older versions (pre DTs) the mdio pins were not touched. I'm
not sure about the actual reason but it seems strange to me also.
I see, is that with mdio configured explicitly to be mdio, or gpio?
mdio pin group function set to gpio
The rtl8366 is configured differently from the IP175E in my router so
what works for me might not for you.
Also I've sent another one to fix eeprom extraction which was broken
by Felix recently.
It's possible to do that from the dts as well:
wmac@48 {
status = okay;
ralink,mtd-eeprom = factory 0;
};
Yes, I know, but then you would have to fix almost every dts.
But for the future I think it's better to use DT approach anyway.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] dslite tunnel setup
I am not an ipv6 expert at all but from what i understand it has to do with the providers configuration that my wan6 does not actually have a routeable ipv6 addr. On a subject related to that dslite setup i found another problem. I am not sure what i am supposed to see on the overview page of luci. But i certainly would like to see the routers current ipv6 addr, which i do not see because my wan6 interface does not have one. I can derive it from the dhcpv6 leas section if dhcpv6 clients are connected, but that is not really what one would expect. /usr/lib/lua/luci/view/admin_status/index.htm does not really seem to allow me to configure another interface for that section. The ipv6 section should show my current prefix, ip and a ticking clock for the current leas. Henning On Tue, 08 Apr 2014 08:22:45 +0200 Steven Barth cy...@openwrt.org wrote: Hello Henning, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. please see: https://dev.openwrt.org/changeset/40422 I added an option weakif which allows you to specify an interface from which we take the local IPv6 address defaulting to lan. 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
Re: [OpenWrt-Devel] dslite tunnel setup
Hi, judging from Gerts mail domain he might well be stuck with the very same provider i unfortunatelly signed a contract with. Small, local German providers seem to be going for native ipv6 with dslite. That allows them to grow even though they own a relatively small ipv4 pool. Most users are probably happy with the high bandwidth connection they get, most likely subsidized by the state ... But if you would like to use any service listening on an ipv4 port in your home, you will react allergic to the term dslite. Henning On Tue, 08 Apr 2014 22:34:21 +0200 Steven Barth cy...@openwrt.org wrote: Hi Gert, i find it very strange that your ISP doesn't offer public addresses on the WAN interface however I think this is actually standards compliant so we have to deal with it. It's called IPv4 exhaustion... DS-Lite is one of the way to deal with it (which effectively gives you only one NAT in the path), the other way is hand out RFC1918 or 100.64.* addresses and double-NAT. Both stinks, but unless someone finds another few billion IPv4 addresses somewhere, this is what large scale providers need to do. I'm sorry but it seems you misunderstood me. We were talking about IPv6 addresses here. It seems that Hennings' ISP only offers a delegated prefix but no global IPv6-address on the WAN-connection (or there is an unknown issue acquiring said address which I don't know of). I know that RFC 7084 requires a CER to actually deal with this (Weak ES model and all) so I added a fix to allow the DS-Lite source endpoint address to be acquired from a downstream interface. 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
Re: [OpenWrt-Devel] lantiq vdsl driver settings
Le 08/04/2014 20:05, José Vázquez a écrit : Make sure you have selected kmod-ltq-ptm-vr9 and kmod-ltq-atm-vr9 deselected in addition to a VR9 vdsl firmware. Thanks for the help. Is kmod-ltq-ptm-vr9 only for the packet transfer mode ? If yes it will not work - even on VDSL, ISP still use ATM as far as I know. The firm you need should be into the TD-W8970 source code. I could not find it anywere. http://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/super-fastfibreaccess/landrgnu.do ECI Arcadyan VDSL modem has the a and b fw inside the dl/ folder Thanks , i'm fetching that now. I could confirm that , when using my current firmware on a VDSL2 POTS , the synchronisation is established on ADSL2+, not VDSL2. try adding -M2 to the vdsl_cpe_control and make the last 2 bytes of the xtu _01_07 i think that will force vdsl. Ok I'll try that as well - once I get the necessary firmware from link above. the spi driver fails on this unit and we are using gpio-spi bit banging :) i will look at the spi irq issue when i am done with vdsl Ok. Thanks, because yes, the flash write look awfully slow. Nothing to worry about though. Thanks for your work. Julien ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl driver settings
Le 08/04/2014 20:05, José Vázquez a écrit : Make sure you have selected kmod-ltq-ptm-vr9 and kmod-ltq-atm-vr9 deselected in addition to a VR9 vdsl firmware. In France I think they sticked on the ATM mode even for VDSL. Is packet transfer mode mandatory for VDSL ? The firm you need should be into the TD-W8970 source code. I got my current ADSL2+ firmware from the french version of the source code. Could not find any VDSL2 stuff - maybe one from germany ? (But I fear it will be annex-b only) Le 08/04/2014 20:18, John Crispin a écrit : http://www.openreach.co.uk/orpg/home/products/super-fastfibreaccess/super-fastfibreaccess/landrgnu.do ECI Arcadyan VDSL modem has the a and b fw inside the dl/ folder Thanks , i'm fetching that now. try adding -M2 to the vdsl_cpe_control and make the last 2 bytes of the xtu _01_07 i think that will force vdsl. I'll try that with a VDSL firmware from above. the spi driver fails on this unit and we are using gpio-spi bit banging :) i will look at the spi irq issue when i am done with vdsl Ok, yes the access to the flash seemed a bit slows... Thanks again for your great work. Julien ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ WRT1900 Patch Submission] Support for Linksys WRT1900AC
On 09/04/14 03:45, Matthew Fatheree wrote: This adds support for Belkin/Linksys WRT1900AC Router Basic functionality Belkin Inc. would like to announce the patch submission release for WRT1900AC which is based on OpenWRT trunk, the detail base revision is specified in each release This is the release version 1.3 of WRT1900AC Openwrt patch submission OpenWRT git base revision: e97be7a104e5c809ae4638cf169823249a505698 OpenWRT svn base revision: 40006 Signed-off-by: Matthew Fatheree matthew.fathe...@belkin.com --- From 1635e36f9854032945cd2a0d2c68600494755064 Mon Sep 17 00:00:00 2001 From: Belkin Inc. Engineering Date: Fri, 14 Mar 2014 23:08:34 +0700 Subject: [PATCH 01/31] Restructure Marvell Armada 370/XP based boards to Generic board, add Mamba board as sub-target Don't want to be overly picky, but I suspect the 31 patches should be split in to 31 mails. This makes it lots easier to track. As an example (though a fix, not a new box, I just pulled it up 'coz it was close at hand), see the thread [OpenWrt-Devel] [PATCH 0/4] ramips: Fix rt2880 Ethernet and wireless https://lists.openwrt.org/pipermail/openwrt-devel/2014-April/024685.html HTH, Pete. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WDS and adhoc support with ath10k
Could someone confirm if WDS and adhoc mode currently don't have support with this driver? adhoc is working but not perfect, such as rate control not working, no HT/VHT rate, and etc. You need to use the firmware version 999.999.0.636. WDS should be working since 4 addresses has fixed by Michal: http://lists.infradead.org/pipermail/ath10k/2014-February/001191.html --- Chun-Yeow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
