Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
Am 30.10.2014 um 03:36 schrieb Florian Fainelli: Le 28/10/2014 11:46, Heiner Kallweit a écrit : After a little more thinking about it and looking at the code I basically have two questions: 1. Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg? (At least for AR8327 it doesn't get called with an addr != 0 anyway) Else we could remove ar8xxx_phy_config_aneg and directly register genphy_config_aneg as callback for autoneg configuration. Address 0 is special, since this is a MDIO broadcast address that will usually be handled by switches as write to all front-panel ports. 2. Call sequence with regard to ar8216 is: ar8216: ar8xxx_phy_probe phy: phy_attach_direct phy: phy_init_hw ar8216: ar8xxx_phy_config_init ar8216: ar8xxx_phy_config_aneg ar8216 driver handles AR8327/AR8337 different from the other supported switch types. ar8xxx_start incl. more detailed configuration is called from ar8xxx_phy_probe already. For the other switch types it's called from ar8xxx_phy_config_init. I wonder whether doing detailed configuration in the probe stage might be too early. phy_init_hw resets the switch anyway later. Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited however there might be good reason why it's handled the way it is. I suppose that you could re-advertise auto-negotiation by calling genphy_config_advert() in the config_init routine. The actual problem is caused by BMCR_ANENABLE being cleared by the reset in phy_init_hw. As far as I can see genphy_config_advert doesn't bring back this flag. What does genphy_config_aneg mainly do? - call genphy_config_advert - check if BMCR_ANENABLE is set - if it's not, call genphy_restart_aneg Therefore, to bring back BMCR_ANENABLE, we have to call genphy_config_aneg or genphy_restart_aneg. genphy_restart_aneg most likely is sufficient, however I don't see that genphy_config_aneg can do any harm if being called with addr == 0. At least for me it works perfectly fine to call genphy_config_aneg for all addr's. Rgds, Heiner Rgds, Heiner Am 27.10.2014 um 22:00 schrieb Heiner Kallweit: With two different TPLINK routers (both with a AR8327N switch) I faced the issue that with kernel 3.14 certain switch ports used 10MBit/half only. Under kernel 3.10 everything was fine and the same ports used 1000MBit/full. As the ar8216 driver is the same I had a look at the common phy code in drivers/net/phy. In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst 3.10 does not. The issue turned out to be that when resetting only flag BMCR_RESET is set, not BMCR_ANENABLE. (In ar8216.c always both flags are set when the switch is reset) Therefore autoneg was not enabled. Also later in the boot process it doesn't get enabled. Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports use 1000MBit/full. However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this generic phy function. It might not be appropriate for other phy's. After resetting the switch later in the boot process ar8xxx_phy_config_aneg is called with phydev-addr being 0. In this case the function returns immediately. Otherwise it would call genphy_config_aneg. Calling genphy_config_aneg would also solve the problem as it checks for BMCR_ANENABLE being set and sets it if needed. I don't know the reason why genphy_config_aneg isn't called in case of addr 0. Or is this a typo and the check actually should be addr != 0 ? Rgds, Heiner ___ 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] BB: vgv7519: fix profile, this board have a rt2800-pci board
--- target/linux/lantiq/xrx200/profiles/arv.mk |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/lantiq/xrx200/profiles/arv.mk b/target/linux/lantiq/xrx200/profiles/arv.mk index 821884c..9dd8daa 100644 --- a/target/linux/lantiq/xrx200/profiles/arv.mk +++ b/target/linux/lantiq/xrx200/profiles/arv.mk @@ -16,7 +16,7 @@ $(eval $(call Profile,VG3503J_V2)) define Profile/VGV7519NOR NAME:=Experiabox 8 VGV7519 - PACKAGES:=kmod-ath9k wpad-mini \ + PACKAGES:=kmod-rt2800-pci wpad-mini \ kmod-ltq-deu-vr9 kmod-ltq-hcd-vr9 \ kmod-ltq-vdsl-vr9-mei kmod-ltq-vdsl-vr9 \ kmod-ltq-atm-vr9 ltq-vdsl-vr9-fw-installer \ @@ -27,7 +27,7 @@ $(eval $(call Profile,VGV7519NOR)) define Profile/VGV7519BRN NAME:=Experiabox 8 VGV7519 (BRN) - PACKAGES:=kmod-ath9k wpad-mini \ + PACKAGES:=kmod-rt2800-pci wpad-mini \ kmod-ltq-deu-vr9 kmod-ltq-hcd-vr9 \ kmod-ltq-vdsl-vr9-mei kmod-ltq-vdsl-vr9 \ kmod-ltq-atm-vr9 ltq-vdsl-vr9-fw-installer \ -- 1.7.10.4 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] vgv7519: fix profile, this board have a rt2800-pci board
--- target/linux/lantiq/xrx200/profiles/arv.mk |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/lantiq/xrx200/profiles/arv.mk b/target/linux/lantiq/xrx200/profiles/arv.mk index 821884c..9dd8daa 100644 --- a/target/linux/lantiq/xrx200/profiles/arv.mk +++ b/target/linux/lantiq/xrx200/profiles/arv.mk @@ -16,7 +16,7 @@ $(eval $(call Profile,VG3503J_V2)) define Profile/VGV7519NOR NAME:=Experiabox 8 VGV7519 - PACKAGES:=kmod-ath9k wpad-mini \ + PACKAGES:=kmod-rt2800-pci wpad-mini \ kmod-ltq-deu-vr9 kmod-ltq-hcd-vr9 \ kmod-ltq-vdsl-vr9-mei kmod-ltq-vdsl-vr9 \ kmod-ltq-atm-vr9 ltq-vdsl-vr9-fw-installer \ @@ -27,7 +27,7 @@ $(eval $(call Profile,VGV7519NOR)) define Profile/VGV7519BRN NAME:=Experiabox 8 VGV7519 (BRN) - PACKAGES:=kmod-ath9k wpad-mini \ + PACKAGES:=kmod-rt2800-pci wpad-mini \ kmod-ltq-deu-vr9 kmod-ltq-hcd-vr9 \ kmod-ltq-vdsl-vr9-mei kmod-ltq-vdsl-vr9 \ kmod-ltq-atm-vr9 ltq-vdsl-vr9-fw-installer \ -- 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] Ralink ethernet update
Hey, Thanks to everybody involved! Does this also solve the issue discussed at [1] with TCP connections failing when VLAN is disabled? [1] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg19870.html -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
On 30/10/2014 08:49, Paul Fertser wrote: Hey, Thanks to everybody involved! Does this also solve the issue discussed at [1] with TCP connections failing when VLAN is disabled? [1] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg19870.html probably this bugfix - https://dev.openwrt.org/changeset/43104 please verify on your hw if the bug is gone. otherwise ping me so we can have a look at it John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ltq-vdsl-app: use VDSL tone-setup if annex is unset
I had to use a VDSL-only tone-setup to get show-time.
Handle this in uci by checking if annex is unset.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
package/network/config/ltq-vdsl-app/files/dsl_control | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/package/network/config/ltq-vdsl-app/files/dsl_control
b/package/network/config/ltq-vdsl-app/files/dsl_control
index 4bfea97..bededb2 100644
--- a/package/network/config/ltq-vdsl-app/files/dsl_control
+++ b/package/network/config/ltq-vdsl-app/files/dsl_control
@@ -131,6 +131,7 @@ start() {
local tone
local tone_adsl
local tone_vdsl
+ local xtse
local xtse_adsl
local mode
@@ -154,7 +155,12 @@ start() {
esac
eval xtse_adsl=\\${xtse_adsl_$annex}\
- [ -z ${xtse_adsl} ] xtse_adsl=$xtse_adsl_a
+ if [ ${xtse_adsl} ]; then
+ xtse=$xtse_adsl
+ else
+ xtse_adsl=$xtse_adsl_a
+ xtse=$xtse_vdsl
+ fi
eval tone_adsl=\\${tone_adsl_$tone}\
[ -z ${tone_adsl} ] tone_adsl=$tone_adsl_av
@@ -173,7 +179,7 @@ start() {
lowlevel_cfg ${tone_adsl} ${tone_vdsl}
service_start /sbin/vdsl_cpe_control \
- -i `echo $xtse_adsl | sed s/ /_/g` \
+ -i `echo $xtse | sed s/ /_/g` \
-n /sbin/dsl_notify.sh \
-f ${firmware} \
-a /tmp/adsl.scr \
--
2.1.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
John Crispin blo...@openwrt.org writes: On 30/10/2014 08:49, Paul Fertser wrote: Thanks to everybody involved! Does this also solve the issue discussed at [1] with TCP connections failing when VLAN is disabled? [1] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg19870.html probably this bugfix - https://dev.openwrt.org/changeset/43104 please verify on your hw if the bug is gone. otherwise ping me so we can have a look at it I have RT5350 for testing (Hame MPR-A1), not MT7620/MT7530, I'm not sure if the same codepath is used, but it looks like not? I will probably be able to do whatever testing you need over the weekend. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
On 30/10/2014 10:38, Paul Fertser wrote: John Crispin blo...@openwrt.org writes: On 30/10/2014 08:49, Paul Fertser wrote: Thanks to everybody involved! Does this also solve the issue discussed at [1] with TCP connections failing when VLAN is disabled? [1] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg19870.html probably this bugfix - https://dev.openwrt.org/changeset/43104 please verify on your hw if the bug is gone. otherwise ping me so we can have a look at it I have RT5350 for testing (Hame MPR-A1), not MT7620/MT7530, I'm not sure if the same codepath is used, but it looks like not? I will probably be able to do whatever testing you need over the weekend. ok, so on rt5350 tcp fails if vlans are disbaled ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
On 30/10/2014 11:00, Roman Yeryomin wrote: On 30 October 2014 04:01, Mingyu Li igv...@gmail.com wrote: on rt2880 i also use rt-n15. the performance on rt2880 seeks unstable. sometime low. sometime high. i also don't know why. others target are more stable. so the maximum is 12x i got. by datasheet it support tx/rx checksum offload. but ralink sdk disable it. so i also disable it. so the performanc is not so good. i use netperf for test. thanks because i have no rt2880 boards :) Yes, you got 12Mbps maximum _with_ this patch and this is exactly what confuses me because I get 45Mbps _without_ this patch. I don't believe the difference between iperf and netperf could be so dramatic. So this sounds like performance regression to me. I will try this patch on my boards little bit later. on mt7620 i only have fast ethernet ports work version. so the maximum is 94. i also have gigabit port device. but the switch can't work. so i can't test. I have Lenovo router with gigabit ports, I will try to test it there. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] Linux 3.16 support on mvebu
On Wed, Oct 29, 2014 at 01:49:13PM +0100, Rafał Miłecki wrote: Well, I don't think it was public enough then. The 3.16 patches have been around for quite some time, some people actually tested it, sent some feedbacks, we fixed some issues, before getting it merged. I don't think this is really the case for 3.18, is it? No. Testing patches are welcome! We've just ported brcm47xx and bcm53xx patches to be able to actually test it. Ok. I didn't really spend hours working on 3.18 in some non-public way. I just ported most patches in ~2 hours and pushed what I got. Now I need help on cleaning that up. I'm also not sure about other of your patches. My only guess I ppl didn't focus on them since there wasn't 3.16 in the first place. Or maybe you could send separated patch per patch? The other patches were not related to 3.16, and were sent as a separate patch set. Sending these patches one by one wouldn't make much sense. Your 4 mvebu patches were sent fine. I was thinking about v2-0002-mvebu-Add-3.16-kernel-patches-and-configuration.patch v2-0003-mvebu-Switch-to-3.16.patch When working on mvebu target and 3.18 support please kindly send them as e-mail patches. Yeah, I sent them that way because it's actually advertise that way in the documentation, but it felt odd :) Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support
Hi Sami, Using John's version: config interface 'wan' option proto 'wwan' option apn 'opengate' # option device '/dev/cdc-wdm0' (with or without commenting this) Does absolutely nothing, nothing in logread... However now when using config interface 'wan' option proto 'ncm' option apn 'opengate' option device '/dev/ttyUSB1' I believe that device should be /dev/cdc-wdm0 also here, at least when using huawei_cdc_ncm. The /dev/ttyUSBx terminals created by the option driver do not necessarily support all necessary AT-commands. Also, (at least when using proto ncm) you need to specify in addition option ifname wwan0 Missing this could lead to the errors below. Matti I see the Huawei dongle actually connects, as in the light lits up and stays, indicating connection is made, but no wwan0 nor any other interface at openwrt, also some erros still on logread: Wed Oct 29 18:50:34 2014 kern.info kernel: [ 1174.74] usb 1-1.3: new high-speed USB device number 5 using ehci-platform Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.45] usb 1-1.3: USB disconnect, device number 5 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.78] usb 1-1.3: new high-speed USB device number 6 using ehci-platform Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.91] option 1-1.3:1.0: GSM modem (1-port) converter detected Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.92] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.93] option 1-1.3:1.1: GSM modem (1-port) converter detected Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.96] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.97] huawei_cdc_ncm 1-1.3:1.2: MAC-Address: 0c:5b:8f:27:9a:64 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.98] huawei_cdc_ncm 1-1.3:1.2: cdc-wdm0: USB WDM device Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.99] huawei_cdc_ncm 1-1.3:1.2 wwan0: register 'huawei_cdc_ncm' at usb-ehci-platform-1.3, Huawei CDC NCM device, 0c:5b:8f:27:9a:64 (ifup wan here) Wed Oct 29 18:51:00 2014 daemon.notice netifd: Interface 'wan' is setting up now (somewhere close time to the next line the dongles light lits up steady) Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): ncm[5097] Connected, starting DHCP Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command failed: Invalid argument Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command failed: Unknown error Wed Oct 29 18:51:08 2014 daemon.notice netifd: wan (5097): Command failed: Unknown error No interface appears on openwrt... Also after this, ifdown wan doesn't tear the connection down (light stays up). So somethign works to the point dongle itself get's connected, but clearly something doesn't work still... This is on ar71xx platform with 3.14 kernel... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq vdsl2
Hi John, thanks for the straight answers. Interpreting what you just wrote and what I already see from a technical point of view, I get the following picture: The VDSL firmware blob needs to match the driver as Lantiq apparently got several variants depending on who is using it downstream. Probably there are different firmware APIs for different OS (?) or driver versions (?). This is why the dsl_fw flashed e.g. on TL-W8970 cannot be used with the driver we got in OpenWrt, right? In addition to the API-style, maybe different blobs also perform different profiles/band-/tone-setup? Fortunately the blob is aparently not board-specific and works on every VRX2xx hardware/board (?), so the blob from a T-Com or BT device can be used on a TP-LINK device. Did they seriously try to limit/mask hardware features in software? i.e. sell the same chip to some customers as ADSL2+ and have other customers pay extra for a VDSL2 license? I'll have the hexdump or base64 of that firmware blob printed on a shirt then ;) or maybe a huge QR-code would also be nice. Clearly, licensing IP to industry customers (who also pay G.729 patent royalties and so on) is one thing, but trying to enforce things all the way down to consumer markets reminds me of ISDN CAPI stuff in the 90s, just that back then there was no content-addressable globally distributed storage such as BitTorrent... But that's just worst-case speculations. Maybe things are not that bad. This mess we face could also be the result of wild forks of the dsl driver by integrators (?). Or maybe Lantiq themselves are not allowed to unconditionally redistribute this blob as it contains something they licensed from a 3rd party (I'm aware nobody will ever publicly confirm or deny that) Or this blob is not that hardware specific, maybe it's just some MIPS binary they run on the 2nd core of the SoC using MIPS DSP instructions for (de-)modulation, filtering, ... (I couldn't find a DSP block in the VRX chip databrief, back on AR7 these things were done using TMS320C55x DSPs) If that's really the case I'd bet my ass that mtk already had a chance to look at it 5 years ago. It's just impossible to keep that kinda things secret once the hardware is publicly available. Anyway, I can just guess... If this is for technical reasons (driver forks; different fw apis on VxWorks/Linux/IFXOS/...), I supposed Lantiq folks should happily help cleaning the mess (doesn't exactly look like that). Whatever the reason is, I can see that it creates lots of extra headache for both, Lantiq and their clients. Back to the practical side of the story, now that I got things working and found my way through the jungle, let's reduce pain of future users (from unboxing to show-time I spent about 20 hours figuring things out): There are many variants of that blob (a probably incomplete list can be found in ECI Arcadyan VDSL vg3503j-gpl-open-source.tgz) dsl_vr9_firmware_xdsl-05.03.00.08.01.06_05.03.00.0F.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.00.0E.01.06_05.03.01.0C.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.00.0F.01.06_05.03.02.01.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.01.02.01.06_05.03.02.06.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.01.05.01.06_05.03.02.08.01.02.tar.gz dsl_vr9_firmware_xdsl-05.03.01.05.01.06_05.03.02.0B.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.01.0A.01.06_05.03.03.00.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.02.02.01.06_05.03.03.0B.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.02.08.01.06_05.03.03.0B.01.01.tar.gz dsl_vr9_firmware_xdsl-05.03.03.0C.01.06_05.03.03.0B.01.01.tar.gz dsl_vr9_firmware_xdsl-05.04.06.04.01.06_05.04.02.05.01.01.tar.gz (plus the two files they ship in the tarball:) dsl_vr9_firmware_xdsl-05.04.06.13.01.06_05.04.02.09.01.01.tar.gz dsl_vr9_firmware_xdsl-05.04.07.09.01.06_05.04.04.04.01.01.tar.gz All of the above probably target BT's xDSL in the UK, i.e. annex A(/J). btw: anyone knows the version(s) noted in above scheme of the blob found in the T-Com Speedport firmware versions? What about VRX-based AVM devices? I reckon it'd be nice to at least list one of the checksums of an ADSL2+ annex A firmware in vdsl_fw_install.sh as currently, only annex B dsl_fw can be extracted using the fw-cutter. Imho the best would be to recognize if whatever stored in dsl_fw on mtd is useful for us or not and allow installing any known firmware (referenced by version and checksum) into the OpenWrt-style dsl_fw art via vdsl_fw_install.sh, so once stored there users never have to go through that mess again and OpenWrt also won't have to redistribute the blob. Redistributing a list of version+flags+size+checksum(+download-script) should be ok, right? Cheers Daniel On Wed, Oct 29, 2014 at 06:21:13PM +0100, John Crispin wrote: Hi Daniel, i get asked this question regularly. the answer is somewhat complicated as wonky licenses are involved. here are the plain facts, interpret them yourself please. * you are the 4th person to ask this month. * the fw blob has a license that
[OpenWrt-Devel] [PATCH] mtd: Fix trx check after partition rename (linux to firmware)
mtd fixtrk now finds the correct partition but unfortunately in my setup (no rootfs and no lzma-loader) it now bricks my router. I will try and find a cure and post a patch. Stephen Parry ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues with MTD parsing in absence of rootfs - Proposed patch, advice please
I presume this will need to be a patch that creates a numbered patch in either: target/linux/generic/patches-3.14 or: target/linux/brcm47xx/patches-3.14 Any guidance please on which and what number to use? Is the patch you sent me a patch against 3.18? Thanks Stephen On 29/10/14 17:42, Rafał Miłecki wrote: On 29 October 2014 17:56, Stephen Parry sgpa...@mainscreen.com wrote: Thanks, that's close to what I've come up with myself. I'll test this evening. If it works can we commit the patch please? We can *backport* it, sure. Will you provide a patch backporting that... patch? :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Issues with MTD parsing in absence of rootfs - Proposed patch, advice please
On 30 October 2014 13:56, Stephen G. Parry sgpa...@mainscreen.com wrote: I presume this will need to be a patch that creates a numbered patch in either: target/linux/generic/patches-3.14 or: target/linux/brcm47xx/patches-3.14 Any guidance please on which and what number to use? You can use generic, as this code is used by both: brcm47xx and bcm53xx. Two tips: 1) target/linux/generic/PATCHES 2) http://wiki.openwrt.org/doc/devel/patches Is the patch you sent me a patch against 3.18? Go and check. I gave you repo link, see what kernel is it based on. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/4] openssl: disable sslv2, add an option to enable sslv3
Merged with some modifications. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
i checkout the latest code and rebuild for rt-n15 only test 3 times lan to wan tcp performance 60 seconds one thread netperf version 2.6.0 116.33, 116.20, 102.84 (10^6bits/sec) iperf 2.0.5 120, 116, 113 (Mbits/sec) iperf 3.0.7 113, 124, 121 (Mbits/sec) 2014-10-30 18:35 GMT+08:00 Paul Fertser fercer...@gmail.com: John Crispin blo...@openwrt.org writes: I have RT5350 for testing (Hame MPR-A1), not MT7620/MT7530, I'm not sure if the same codepath is used, but it looks like not? I will probably be able to do whatever testing you need over the weekend. ok, so on rt5350 tcp fails if vlans are disbaled ? As far as I can tell, yes, at least it was the case when I was submitting [1]. [1] http://patchwork.openwrt.org/patch/6085/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ 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] dnsmasq strip out the ANswers from the DNS reply.
Hi, While Running tests in an openwrt based IP gateway, we noticed a dns problem running openwrt in a gateway. When DNS proxy ( dnsmasq) forward the DNS reply, the Answer of section was extracted. Please refer to the following tests for the problem description. 192.168.42.135 (192.168.42.1 GATEWAY 10.10.200.2)-- (1.1.1.1 DNS server) 1. The Gateway LAN interface pre-configured as 192.168.42.1. The Gateway LAN section is in 192.168.42.0/255.255.255.0 subnet 2. A LAN Device is assigned IP to 192.168.42.135 from the DHCP server in the gateway. 3. Have Gateway wan link set to network in subnet 10.10.200.xx/255.255.255.0. 4. Set up a DNS Server in WAN with IP:1.1.1.1 5. DHCP server (not in the picture) in the WAN subnet assign Gateway wan IP as 10.10.200.2 6. The LAN client initiates a DNS query. The query has source IP 192.168.42.135 and destination IP 192.268.42.1 (in lan.cap message 1) 7. The Gateway forwards the query to dns server. The forwarded query has the source IP 10.10.200.2 and destination 1.1.1.1 (in wan.cap msg 1) 8. DNS server 1.1.1.1 sends DNS resolution response with resolved dns address. The response sends to the Gateway 10.10.200.2. (in wan.cap msg 2) 9. The Gateway forwards the response to the client; but the forwarded response does not have the Answer.(in lan.cap msg 2) Please review the attached wireshark. Questions: I wonder if this problem is due to: 1. My tested openwrt is an older version; OR 2. A simple config problem 3. The worst case is a S/W problem in dnsmasq that requires code modification Anyone know the solution or ever see this problem, please gives us a reply. Here is the version./release information the openwrt I am using: The etc/banner file Release : 14.3 Version: 14.44 The /etc/openwrt_version file 12.09.1 The /etc/openwrt_release file DISTRIB_REVISION=r42647 ISTRIB_CODENAME=attitude_adjustment DISTRIB_TARGET=brcm63xx-arm-tch/HG1XPROTO DISTRIB_DESCRIPTION=OpenWrt Attitude Adjustment 12.09.1 And the uci show related to the dnsmasq dhcp.@dnsmasq[0]=dnsmasq dhcp.@dnsmasq[0].domainneeded=1 dhcp.@dnsmasq[0].filterwin2k=0 dhcp.@dnsmasq[0].localise_queries=1 dhcp.@dnsmasq[0].rebind_protection=1 dhcp.@dnsmasq[0].rebind_localhost=1 dhcp.@dnsmasq[0].local=/lan/ dhcp.@dnsmasq[0].expandhosts=1 dhcp.@dnsmasq[0].nonegcache=0 dhcp.@dnsmasq[0].authoritative=1 dhcp.@dnsmasq[0].readethers=1 dhcp.@dnsmasq[0].leasefile=/tmp/dhcp.leases dhcp.@dnsmasq[0].resolvfile=/tmp/resolv.conf.auto dhcp.@dnsmasq[0].dhcpscript=/lib/dnsmasq/dhcp-event.sh dhcp.@dnsmasq[0].domain=qacafe.com dhcp.@dnsmasq[0].boguspriv=0 dhcp.@dnsmasq[0].strictorder=1mailto:dhcp.@dnsmasq[0].strictorder=1 wan.cap Description: wan.cap lan.cap Description: lan.cap ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ralink ethernet update
On 30 October 2014 16:20, Mingyu Li igv...@gmail.com wrote: i checkout the latest code and rebuild for rt-n15 only test 3 times lan to wan tcp performance 60 seconds one thread netperf version 2.6.0 116.33, 116.20, 102.84 (10^6bits/sec) iperf 2.0.5 120, 116, 113 (Mbits/sec) iperf 3.0.7 113, 124, 121 (Mbits/sec) Yes, about the same here with rt2880! Nice! But now I don't understand why you've reported 12Mbps maximum before :) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Autoneg problems with ar8216 on kernel 3.14 (related to ticket 17800)
Am 30.10.2014 um 07:22 schrieb Heiner Kallweit:
Am 30.10.2014 um 03:36 schrieb Florian Fainelli:
Le 28/10/2014 11:46, Heiner Kallweit a écrit :
After a little more thinking about it and looking at the code I basically
have two questions:
1.
Is it actually needed to exclude certain phy's in ar8xxx_phy_config_aneg?
(At least for AR8327 it doesn't get called with an addr != 0 anyway)
Else we could remove ar8xxx_phy_config_aneg and directly register
genphy_config_aneg as
callback for autoneg configuration.
Address 0 is special, since this is a MDIO broadcast address that will
usually be handled by switches as write to all front-panel ports.
2.
Call sequence with regard to ar8216 is:
ar8216: ar8xxx_phy_probe
phy: phy_attach_direct
phy: phy_init_hw
ar8216: ar8xxx_phy_config_init
ar8216: ar8xxx_phy_config_aneg
ar8216 driver handles AR8327/AR8337 different from the other supported
switch types.
ar8xxx_start incl. more detailed configuration is called from
ar8xxx_phy_probe already.
For the other switch types it's called from ar8xxx_phy_config_init.
I wonder whether doing detailed configuration in the probe stage might be
too early.
phy_init_hw resets the switch anyway later.
Doing the detailed setup in ar8xxx_phy_config_init seems to be more suited
however
there might be good reason why it's handled the way it is.
I suppose that you could re-advertise auto-negotiation by calling
genphy_config_advert() in the config_init routine.
The actual problem is caused by BMCR_ANENABLE being cleared by the reset in
phy_init_hw.
As far as I can see genphy_config_advert doesn't bring back this flag.
What does genphy_config_aneg mainly do?
- call genphy_config_advert
- check if BMCR_ANENABLE is set
- if it's not, call genphy_restart_aneg
Therefore, to bring back BMCR_ANENABLE, we have to call genphy_config_aneg or
genphy_restart_aneg.
genphy_restart_aneg most likely is sufficient, however I don't see that
genphy_config_aneg
can do any harm if being called with addr == 0.
At least for me it works perfectly fine to call genphy_config_aneg for all
addr's.
Rgds, Heiner
Rgds,
Heiner
Am 27.10.2014 um 22:00 schrieb Heiner Kallweit:
With two different TPLINK routers (both with a AR8327N switch) I faced the
issue that with
kernel 3.14 certain switch ports used 10MBit/half only.
Under kernel 3.10 everything was fine and the same ports used
1000MBit/full.
As the ar8216 driver is the same I had a look at the common phy code in
drivers/net/phy.
In function phy_init_hw in phy_device.c kernel 3.14 resets the phy whilst
3.10 does not.
The issue turned out to be that when resetting only flag BMCR_RESET is
set, not BMCR_ANENABLE.
(In ar8216.c always both flags are set when the switch is reset)
Therefore autoneg was not enabled. Also later in the boot process it
doesn't get enabled.
Adding BMCR_ANENABLE solved the problem and now also under 3.14 all ports
use 1000MBit/full.
However I'm not sure whether it's a poper fix to add BMCR_ANENABLE in this
generic phy function.
It might not be appropriate for other phy's.
After resetting the switch later in the boot process
ar8xxx_phy_config_aneg is called with
phydev-addr being 0.
In this case the function returns immediately. Otherwise it would call
genphy_config_aneg.
Calling genphy_config_aneg would also solve the problem as it checks for
BMCR_ANENABLE
being set and sets it if needed.
I don't know the reason why genphy_config_aneg isn't called in case of
addr 0.
Or is this a typo and the check actually should be addr != 0 ?
Rgds, Heiner
The following rudimentary patch works fine for me with kernel 3.14.18 on
TP-LINK TL-WDR4900 (mpc85xx with AR8327Nv4)
TP-LINK TL-WDR4300 ( ar71xx with AR8327Nv2)
Apart from using genphy_config_aneg also for addr==0 I replaced msleep(1000)
with a polling function inspired by phy_poll_reset in phy_device.c
On AR8327 the reset actually takes less than 20ms. Sleeping for 1000ms
seems to be a waste of time.
Little more work would be needed to make it a proper patch:
- move ar8xxx_phy_poll_reset more to the beginning so that it is defined
before being used in any _hw_init function
- replace msleep(1000) also in the other _hw_init functions
- remove pr_info debug message or make it at least pr_dbg
- insert some comments
- use git format-patch output
Rgds, Heiner
--- ar8216.c.orig 2014-10-30 21:50:19.999723156 +0100
+++ ar8216.c2014-10-30 21:42:11.996481099 +0100
@@ -1591,6 +1591,29 @@
#endif
static int
+ar8xxx_phy_poll_reset(struct mii_bus *bus, int num_phys)
+{
+ unsigned int sleep_msecs = 20;
+ int ret, elapsed, i;
+
+ for(elapsed = sleep_msecs; elapsed = 600; elapsed += sleep_msecs) {
+ msleep(sleep_msecs);
+ for (i = 0; i num_phys; i++) {
+ ret = mdiobus_read(bus, i, MII_BMCR);
+ if (ret 0) return ret;
+
Re: [OpenWrt-Devel] [PATCH] comgt: add ncm proto support
okay: config interface 'wan' option ifname 'wwan0' option proto 'ncm' option apn 'opengate' option device '/dev/cdc-wdm0' Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - -- Error Report -- Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - ^ Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - Error @6, line 1, Can't control /dev/cdc-wdm0, please try again. Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): . (1) Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): Thu Oct 30 21:06:18 2014 user.notice firewall: Reloading firewall due to ifup of lan (br-lan) Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - -- Error Report -- Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - ^ Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): comgt 21:06:18 - Error @40, line 2, Can't control /dev/cdc-wdm0, please try again. Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): . (1) Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2446): ncm[2446] Failed to connect Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2502): Command failed: Permission denied Thu Oct 30 21:06:18 2014 daemon.notice netifd: wan (2502): ncm[2502] Stopping network Thu Oct 30 21:06:19 2014 daemon.notice netifd: wan (2502): Can't open device . Thu Oct 30 21:06:19 2014 daemon.notice netifd: wan (2502): ncm[2502] Failed to disconnect Thu Oct 30 21:06:19 2014 daemon.notice netifd: Interface 'wan' is now down and no connection, then: config interface 'wan' option ifname 'wwan0' option proto 'ncm' option apn 'opengate' option device '/dev/ttyUSB1' (this is correct port when using Oskari Rauta's original code, running on main router) Thu Oct 30 21:09:46 2014 daemon.notice netifd: Interface 'wan' is setting up now Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): ncm[3253] Connected, starting DHCP Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command failed: Invalid argument Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command failed: Unknown error Thu Oct 30 21:09:54 2014 daemon.notice netifd: wan (3253): Command failed: Unknown error Also behaviour is quite similar to mine previous email, Huawei's light stays lit, but no wwan0 etc available... Also, if I then run first ifconfig wwan0 up and then dhclient -i wwan0 I get IP for wwan0 and internet works! can ping and use SSH to remote location... So this must be something small typo or so somewhere deep in scripts?! Sami Olmari On Thu, Oct 30, 2014 at 12:58 PM, Matti Laakso malaa...@elisanet.fi wrote: Hi Sami, Using John's version: config interface 'wan' option proto 'wwan' option apn 'opengate' # option device '/dev/cdc-wdm0' (with or without commenting this) Does absolutely nothing, nothing in logread... However now when using config interface 'wan' option proto 'ncm' option apn 'opengate' option device '/dev/ttyUSB1' I believe that device should be /dev/cdc-wdm0 also here, at least when using huawei_cdc_ncm. The /dev/ttyUSBx terminals created by the option driver do not necessarily support all necessary AT-commands. Also, (at least when using proto ncm) you need to specify in addition option ifname wwan0 Missing this could lead to the errors below. Matti I see the Huawei dongle actually connects, as in the light lits up and stays, indicating connection is made, but no wwan0 nor any other interface at openwrt, also some erros still on logread: Wed Oct 29 18:50:34 2014 kern.info kernel: [ 1174.74] usb 1-1.3: new high-speed USB device number 5 using ehci-platform Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.45] usb 1-1.3: USB disconnect, device number 5 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.78] usb 1-1.3: new high-speed USB device number 6 using ehci-platform Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.91] option 1-1.3:1.0: GSM modem (1-port) converter detected Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.92] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.93] option 1-1.3:1.1: GSM modem (1-port) converter detected Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.96] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.97] huawei_cdc_ncm 1-1.3:1.2: MAC-Address: 0c:5b:8f:27:9a:64 Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.98] huawei_cdc_ncm 1-1.3:1.2: cdc-wdm0: USB WDM device Wed Oct 29 18:50:35 2014 kern.info kernel: [ 1175.99] huawei_cdc_ncm 1-1.3:1.2 wwan0: register 'huawei_cdc_ncm' at usb-ehci-platform-1.3, Huawei CDC NCM device, 0c:5b:8f:27:9a:64
Re: [OpenWrt-Devel] Ralink ethernet update
On Thu, Oct 30, 2014 at 11:04:17PM +0200, Roman Yeryomin wrote: On 30 October 2014 16:20, Mingyu Li igv...@gmail.com wrote: i checkout the latest code and rebuild for rt-n15 only test 3 times lan to wan tcp performance 60 seconds one thread netperf version 2.6.0 116.33, 116.20, 102.84 (10^6bits/sec) iperf 2.0.5 120, 116, 113 (Mbits/sec) iperf 3.0.7 113, 124, 121 (Mbits/sec) Yes, about the same here with rt2880! Nice! But now I don't understand why you've reported 12Mbps maximum before :) I think 12X was meant as an approximation, that is, somewhere between 120 and 129 Mbps :) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel pgp7qyOtppHoD.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How is the current status of support for Ubnt NanoStation Loco M5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The wiki says [0] that for Ubnt NS Loco M5 (build in the year 2014) someone has to use the **xw** firmware like *openwrt-ar71xx-generic-ubnt-nano-m-xw-squashfs-factory.bin*. But this do not work for my model with Test date: 01/24/14, which came with AirOS V 5.5.7. Yes, after flashing there is OpenWRT on the box, but it is not booting properly. Cause of my lacking knowledge I do not know how to debug or offer a better explanation. I found some forum rumors which indicate that OpenWRT will not finish the boot procedure, but there where no explanation why. I was able to flash back to the original ubnt firmware [1] via tftp. At first I had tested BB 14.07 and later found that **xw** support just came with r42549. So I tried the current trunk snapshot, but with the same not working result. Can someone please give me a hint how to debug, or how to get OpenWRT working on a /brand new/ NanoStation Loco M5? Also has someone experience how the apply a serial adapter to the board, I was unable to find any information for these new boards. If someone can say where to put TX, RX and GND I can put an adapter to it, and can provide a boot log - but I'm to scared to just try it ;) This board has no jtag/serial 10 pin thingsy like the Loco M2, but 4 'holes' which look like these on boards like tp-link wr841/wr1043. (Sorry I dont no how to call it in english). Best regards and thanks for any help, Bernd [0] http://wiki.openwrt.org/toh/ubiquiti/nanostationm5 [1] XW.v5.5.10.24238.141001.1641.bin - -- Bernd Naumann be...@kr217.de PGP: 0xA150A04F via pool.sks-keyservers.net XMPP: b...@weimarnetz.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJUUtSEAAoJEEYW3OihUKBP+XIP/iJ92WndyeI+yshp2wSzjkQL 7W9qUFWFgmR/KzSoHWylrDdOdIiq2LJ2CcMAPRxO3wHdCEzixxRsEp9x3aTe2L5Z FumBtQazLymEjESA9segE4ISkL0jUSCpLgtWCKs3gWIlEQjStSyCK5GqYVkDsS3w wNq7E8aL39uF704l91C5FSdGzawD9IxAExxsb7JKj1PYwwjUFi4HOSiRUL96ZvaU MlMqnWajUZyDZ5AsQpbKLwC09BjZfbq3WbT/lvPypzx54BDhAJGtDMVJMqSjp4IK Yt9QpurXhmS2W2CjOV9dzvk+gFFzdDD0y9ZCN9y/pAlnCvdk74oe1QcLL31wHu1S W1luOYev+qGH/jhPCQQarMkfNDNhH4BH1LDtzmBbxiSI1qWf06Jxxyou+1/G+dDm f5J3v7Rs0d5/Wtbbw52z5WLT3H/U1M2rtYnTqJEk1jbk2Jmld4oAKdxMlPDSuiPd rDdaj+nIFSieHu1Tams8i3DQD6HxOAgI2xPaLyLgwCsWybzeWzgy4FaN5XP9uroR Gx6eMq2cTJN5u+EtClJc2qazu22AOLw4xhZvP3EYK8tcbppKT/Ji8uzzVRg2WUML Pepc8YVUEFEfc7yOyoN+/mHkzyM+brzv7K6m/SJokEvy73OnShZOzyxlWxz7ysPK 6wPkObERViHp+BW+NbyX =Kbwq -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] vr9-vdsl-fw: properly write firmware to flash
Using a redirect to a non-empty mtd partition will not erase the
blocks prior to writing to them resulting in broken dsl_fw.
Fix this by piping to mtd write - /dev/mtdX instead.
Signed-off-by: Daniel Golle dan...@makrotopia.org
---
package/kernel/lantiq/ltq-vdsl-fw/src/vdsl_fw_install.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/kernel/lantiq/ltq-vdsl-fw/src/vdsl_fw_install.sh
b/package/kernel/lantiq/ltq-vdsl-fw/src/vdsl_fw_install.sh
index e7baddf..8f0ddd5 100755
--- a/package/kernel/lantiq/ltq-vdsl-fw/src/vdsl_fw_install.sh
+++ b/package/kernel/lantiq/ltq-vdsl-fw/src/vdsl_fw_install.sh
@@ -49,7 +49,7 @@ D=`md5sum -b ${FW_DSL} | cut -d -f1`
MTD=$(find_mtd_index dsl_fw)
if [ $MTD -gt 0 -a -e /dev/mtd$MTD ]; then
echo Storing firmware in flash
- tar cvz ${FW_TAPI} ${FW_DSL} /dev/mtd$MTD
+ tar cvz ${FW_TAPI} ${FW_DSL} | mtd write - /dev/mtd$MTD
/etc/init.d/dsl_fs boot
else
cp ${FW_TAPI} ${FW_DSL} /lib/firmware/
--
2.1.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
