Re: [OpenWrt-Devel] iproute2 / macvlan-problem [SOLVED]
* Weimarnetz e.V., Vorstand/Vereinsvorsitzender: Bastian Bittorf [07.10.2014 17:38]: > since some weeks i have problems using 'macvlan'. > it works with r41037 / kernel 3.10.36 and does > not work with r42830 / kernel 3.10.49 or .55 > > what i do is this: > > brctl addbr br-test > brctl addif br-test $WIFIDEV > ip link set dev br-test up > insmod macvlan > ip link add link br-test subdev0 address 02:ca:ff:ee:00:02 type macvlan just for reference: the new iproute2 is a bit more strict about the syntax: will NOT work: ip link add link $PHYDEV $NEWDEV type macvlan works: ip link add link $PHYDEV name $NEWDEV type macvlan sorry for confusion, hope it helps somebody. bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
On Thu, Oct 09, 2014 at 01:01:48AM +0200, Stephan Günther wrote: > Hi, > > On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman wrote: > > Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: > >> So I don't know where to go. Certainly I'd like to see the battle hardened > >> sqm scripts (which are more flexible than the C code above) get more widely > >> used and in BB. > > > > SQM seems to work ok with the current Chaos Calmer trunk. > > Works for mee too, and performs much better than the old luci-app-qos. > I would love to see this as part of OpenWrt. OK. I don't see it feasible to retire qos-scripts as that has less dependencies than sqm does - sqm needs "ip" and tc to function. But I'd certainly like to see it available in the main openwrt repo by default. And: I'd like the next version to do what sqm does, in pure c, at line rate OR software rate limited, faster, better, smaller... > I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE > link and it looks good in the graphs. I also have an 6in4 tunnel I always love it when people post their results and the .json.gz files for the various netperf-wrapper tests somewhere. It has been good to build an ever increasing database of valid tests and valid setups, given that things like speedtest.net are so lame. Examples: http://burntchrome.blogspot.com/2014_05_01_archive.html http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html While I'm at it there were a couple manefestos along the way. This explains exactly where and why wondershaper was flawed: http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die And this talks to the need for fq + aqm on *everything* http://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/ (I was unhappy qos-scripts just disabled ecn entirely. ECN is looking safely deployable in a fq'd system IMHO). Last manefesto above does not go into the (slight) remaining need for a few levels of classification, one reason is here: http://perso.telecom-paristech.fr/~drossi/paper/rossi13tma-b.pdf It is my hope that by explaining the "why" of sqm we could come up with something better before making it available at larger scale. > inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL fq_codel dissects the headers for ipip, ipv6, gre and another protocol I forget, correctly, and fq's them correctly. However my head explodes as to what happens or which device should be used when that is further encapsulated. > looks good at IPv6. Had this running at home for some days now, with > moderate traffic and no issues so far. Well loading it up is the only way to tell if you're winning. > But I was wondering which interface to select luci-app-sqm, as no > tunnel intefaces are shown here. So i used the ethernet interface > instead of the PPPoE link. Is this fine? Minutes ago, I did a quick > test and applied SQM to the PPPoE link by fixing luci-base to return > also the virtual interfaces in net:get_interfaces(). But i didn't > notice any difference or my test was too sloppy. Well, sebastian just made a few SQM changes also in the ceropackages repo and PPPoe over atm makes my head hurt. See cerowrt-devel for more list. I'm a huge believer in measurements, and netperf-wrapper has been the closest thing the Internet has ever had to one that accurately measures latency under load. Recently it was proven to scale all the way to 40GigE. Things like speedtest are increasingly inaccurate above 20mbits, and doesn't measure induced latency at all... and netalyzer, being written in java, doesn't get past 20mbits either. > > -- > Stephan > ___ > 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] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
On Wed, Oct 08, 2014 at 11:10:46PM +0300, Hannu Nyman wrote: > Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: > > So I don't know where to go. Certainly I'd like to see the battle > hardened sqm scripts (which are more flexible than the C code above) > get more widely used and in BB. > > SQM seems to work ok with the current Chaos Calmer trunk. Well, for now... I'd expect the delta to break eventually... > > I have included your SQM in my trunk WNDR3700/3800 community build ( > https://forum.openwrt.org/viewtopic.php?id=28392 ) and it works ok. > Arokh has also picked it up for his build ( > https://forum.openwrt.org/viewtopic.php?id=50914 ). So you might get > more feedback sooner or later, if users of our builds really do try > it. Excellent. I'd *really* like to get some testers doing ingress shaping at above 60-80mbits, which seems to be a brick wall we've hit on the ar71xx and octeon, on other platforms like the arm and x86. A tool we use a lot is netperf-wrapper. > I feel that the best way to get wider testing and real-life usage > for SQM would be to create a pull request in the new packages feed > in Github, to get both the SQM itself and the Luci frontend included > there. Being available in the packages feed would create more > interest for the package. If it proves to work ok, the devs might > then import it into the core Openwrt repo (where the old qos-scripts > is). I went to sleep pre BBrc1. I woke up, and everything was in github. It's still not clear to me how I'd build cero from frozen BB sources, rather than the evolving github packages. > > > Ps. For my own build I made a slight modification to the Luci menu> item, as > pure "SQM" does not say much. I changed it to "SQM QoS". > Yes, SQM by itself doesn't mean enough. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: qihoo-c301: reset imageNtrynum after each successful boot.
On 7 October 2014 02:33, John Crispin wrote:
>
> On 14/09/2014 02:27, Yousong Zhou wrote:
>> Qihoo C301 has 2 flash chips of which one is used as primary and the
>> other is used as backup. OEM U-Boot will try to boot an activeregion N
>> with imageNstatus=0 and imageNtrynum <= imagemaxtry. If such a region
>> is found, bootloader will try to increment imageNtrynum and boot it.
>>
>> This patch tries to reset imageNtrynum after each successful boot (if
>> the boot process reaches the execution of /etc/init.d/done).
>>
>> root@OpenWrt:/# hexdump -C -n 128 /dev/mtdblock9
>> 9e f3 63 91 61 63 74 69 76 65 72 65 67 69 6f 6e
>> |..c.activeregion|
>> 0010 3d 31 00 69 6d 61 67 65 31 73 74 61 74 75 73 3d
>> |=1.image1status=|
>> 0020 30 00 69 6d 61 67 65 32 73 74 61 74 75 73 3d 30
>> |0.image2status=0|
>> 0030 00 69 6d 61 67 65 32 74 72 79 6e 75 6d 3d 30 00
>> |.image2trynum=0.|
>> 0040 69 6d 61 67 65 6d 61 78 74 72 79 3d 33 00 69 6d
>> |imagemaxtry=3.im|
>> 0050 61 67 65 31 74 72 79 6e 75 6d 3d 30 00 00 00 00
>> |age1trynum=0|
>> 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> ||
>>
>> Signed-off-by: Yousong Zhou
>
> do we need this patch and the one made by swigger ? it seems his patch
> write the crc32 somewhere and your patch resets the uboot-env.
>
Two patches are supposed to serve the same purpose, i.e. reseting
imageNtrynum to zero. Both of them needs to erase and rewrite
uboot-env partition on every reboot. It is a design decision by
Qihoo. fw_{get,set}env are the tools for this job. We always have
uboot-envtools installed for all ar71xx boards, and now finally it
finds its use in Qihoo-C301 board...
regards.
yousong
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On 9 October 2014 01:27, Robert P. J. Day wrote: > i can't even get to the page in [1], and the router in [2] is listed > as based on AR9331, not MT7620A, so i'm fairly sure that can't be it. > i'll keep trying the first link. Yes, HC6361 is AR9331 based. It is said that HiWiFi switched to MediaTek chips because of supply problems with Qualcomm Atheros. Well, surely that is another story. HC5661 is the board name for J1S, and HC5761 for J2. They are 3 different routers by HiWiFi. The latter two use MT7620A with HC5761 having 5GHz available. regards. yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: gpio: pca953x: backport gpio input fix
This fix is for anyone on 3.10 using the pca953x driver. A regression was introduced when this driver was converted to using 8-bit reads/writes the bitmask in pca953x_gpio_get_value wasn't adjusted with the modulus BANK_SZ and consequently looks at the wrong bits in the input register. This backports the following commit from the mainline linux kernel: 40a625daa88653d7942dc85483f6f289cd687cb7 Signed-off-by: Pushpal Sidhu --- .../350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch | 13 + 1 file changed, 13 insertions(+) create mode 100644 target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch diff --git a/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch b/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch new file mode 100644 index 000..654fccf --- /dev/null +++ b/target/linux/generic/patches-3.10/350-gpio-pca953x-fix_gpio_input_on_gpio_offsets.patch @@ -0,0 +1,13 @@ +Index: linux-3.10.49/drivers/gpio/gpio-pca953x.c +=== +--- linux-3.10.49.orig/drivers/gpio/gpio-pca953x.c 2014-07-17 15:58:15.0 -0700 linux-3.10.49/drivers/gpio/gpio-pca953x.c 2014-10-08 14:49:46.974913692 -0700 +@@ -308,7 +308,7 @@ + return 0; + } + +- return (reg_val & (1u << off)) ? 1 : 0; ++ return (reg_val & (1u << (off % BANK_SZ))) ? 1 : 0; + } + + static void pca953x_gpio_set_value(struct gpio_chip *gc, unsigned off, int val) -- 1.9.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Hi, On Wed, Oct 8, 2014 at 10:10 PM, Hannu Nyman wrote: > Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: >> So I don't know where to go. Certainly I'd like to see the battle hardened >> sqm scripts (which are more flexible than the C code above) get more widely >> used and in BB. > > SQM seems to work ok with the current Chaos Calmer trunk. Works for mee too, and performs much better than the old luci-app-qos. I would love to see this as part of OpenWrt. I did some RRUL test using netperf-wrapper on my ADSL 15/1Mbps PPPoE link and it looks good in the graphs. I also have an 6in4 tunnel inside PPPoE and IIRC fq_codel should detect these ipv6 flows. RRUL looks good at IPv6. Had this running at home for some days now, with moderate traffic and no issues so far. But I was wondering which interface to select luci-app-sqm, as no tunnel intefaces are shown here. So i used the ethernet interface instead of the PPPoE link. Is this fine? Minutes ago, I did a quick test and applied SQM to the PPPoE link by fixing luci-base to return also the virtual interfaces in net:get_interfaces(). But i didn't notice any difference or my test was too sloppy. -- Stephan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] BB 14.07 and extroot on md-raid1
Hi there, I just managed to hack block-mount (without recompiling!) and obtain extroot on /dev/md0 md-raid array on TP-Link WR1043ND. My idea shows the way how to insert a script running just before mounting extroot. More details may be found at: http://eko.one.pl/forum/viewtopic.php?id=9633 (in Polish, use translators if necessary). -- Pozdrawiam Grzesiek Wysłane z kompa wolnego od wirusów Billa Gatesa. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Hyper-V Support for X86 or X86_64
Hi, On 08.10.2014 14:08, Ning Ye wrote: > Sorry for the late reply. To answer your questions, first I am trying to > save the hassle with another target, but hyper-v supports are enabled either > by manually selecting the hyper-v modules under virtualization or build VHD > disk output. If you are using default x86 or x86_64 target, it wouldn't > added hyper-v unless you turned them on. > > I couldn't make hyper-v module support work, especially the disk module. It > hangs if it is kernel module only. My guess is that it needs the disk > support in order to load other modules. Because the hyper-v is only enabled > for hyper-v environment, building it into the kernel doesn't seem to waste > any resources. I think its better to create a seperate subtarget for x86_64? Do you have any test images for hyper-v that I could test? > Best, > > Ning cheers thomas > > -Original Message- > From: Hauke Mehrtens [mailto:ha...@hauke-m.de] > Sent: Saturday, September 13, 2014 4:05 PM > To: Ning Ye; 'OpenWrt Development List' > Subject: Re: [OpenWrt-Devel] Hyper-V Support for X86 or X86_64 > > On 07/28/2014 12:37 AM, Ning Ye wrote: >> Hi All, >> >> Hyper-V support for X86 or X86_64 were noticeably missing. There is a > previous patch for Kernel 3.3 but never maintained or merged into trunk. > Here's my take on adding the Hyper-V support for the current kernel. No new > sub targets or profiles are created, as long as the target is x86 or x86_64. > The generic works well or any other profiles. >> Also added a new VHD target image menu . The latest stable qemu-img > supports Hyper-V vhd and vhdx. The old & current qemu 0.14.1 builds invalid > vhd images. I am working on updating it to 2.0.0. Currently I am > converting vmdk into vhd using third party tools. >> Ning Ye >> Signed-off-by: Ning Ye >> >> >> diff --git a/config/Config-images.in b/config/Config-images.in old >> mode 100644 new mode 100755 index 39e51e4..7020f84 >> --- a/config/Config-images.in >> +++ b/config/Config-images.in >> @@ -239,6 +239,16 @@ menu "Target Images" >> select TARGET_IMAGES_PAD >> select PACKAGE_kmod-e1000 >> >> +config VHD_IMAGES >> +bool "Build Hyper-V image files (VHD)" >> +depends on TARGET_x86 || TARGET_x86_64 >> +select GRUB_IMAGES >> +select TARGET_IMAGES_PAD >> +select PACKAGE_kmod-hyperv-balloon >> +select PACKAGE_kmod-hyperv-net-vsc >> +select PACKAGE_kmod-hyperv-util >> +select PACKAGE_kmod-hyperv-storage >> + >> config TARGET_IMAGES_PAD >> bool "Pad images to filesystem size (for JFFS2)" >> depends on OLPC_BOOTSCRIPT_IMAGES || GRUB_IMAGES diff --git >> a/package/kernel/linux/modules/virtual.mk >> b/package/kernel/linux/modules/virtual.mk >> old mode 100644 >> new mode 100755 >> index 190d844..a67d71c >> --- a/package/kernel/linux/modules/virtual.mk >> +++ b/package/kernel/linux/modules/virtual.mk >> @@ -186,3 +186,85 @@ define KernelPackage/xen-pcidev/description >> endef >> >> $(eval $(call KernelPackage,xen-pcidev)) >> + >> +# >> +# Hyper-V Drives depends on x86 or x86_64. >> +# >> +define KernelPackage/hyperv-balloon >> + SUBMENU:=$(VIRTUAL_MENU) >> + DEPENDS:=@(TARGET_x86||TARGET_x86_64) >> + TITLE:=Microsoft Hyper-V Balloon Driver >> + KCONFIG:= \ >> +CONFIG_HYPERV_BALLOON \ >> +CONFIG_HYPERVISOR_GUEST=y \ > This adds some code to the kernel. I think it should be better to just > extend the kvm_guest subtarget and the x86_64 target with support for > Hyper-V. > >> +CONFIG_PARAVIRT=n \ >> +CONFIG_HYPERV=y > It is possible to build this as a module why is it build into the kernel? > >> + FILES:=$(LINUX_DIR)/drivers/hv/hv_balloon.ko >> + AUTOLOAD:=$(call AutoLoad,06,hv_balloon) endef >> + >> +define KernelPackage/hyperv-balloon/description >> + Microsofot Hyper-V balloon driver. >> +endef >> + >> +$(eval $(call KernelPackage,hyperv-balloon)) >> + >> +define KernelPackage/hyperv-net-vsc >> + SUBMENU:=$(VIRTUAL_MENU) >> + DEPENDS:=@(TARGET_x86||TARGET_x86_64) >> + TITLE:=Microsoft Hyper-V Network Driver >> + KCONFIG:= \ >> +CONFIG_HYPERV_NET \ >> +CONFIG_HYPERVISOR_GUEST=y \ >> +CONFIG_PARAVIRT=n \ >> +CONFIG_HYPERV=y >> + FILES:=$(LINUX_DIR)/drivers/net/hyperv/hv_netvsc.ko >> + AUTOLOAD:=$(call AutoLoad,35,hv_netvsc) endef >> + >> +define KernelPackage/hyperv-net-vsc/description >> + Microsoft Hyper-V Network Driver >> +endef >> + >> +$(eval $(call KernelPackage,hyperv-net-vsc)) >> + >> +define KernelPackage/hyperv-util >> + SUBMENU:=$(VIRTUAL_MENU) >> + DEPENDS:=@(TARGET_x86||TARGET_x86_64) >> + TITLE:=Microsoft Hyper-V Utility Driver >> + KCONFIG:= \ >> +CONFIG_HYPERV_UTILS \ >> +CONFIG_HYPERVISOR_GUEST=y \ >> +CONFIG_PARAVIRT=n \ >> +CONFIG_HYPERV=y >> + FILES:=$(LINUX_DIR)/drivers/hv/hv_util.ko >> + AUTOLOAD:=$(call AutoLoad,10,hv_util) endef >> + >> +define Kern
Re: [OpenWrt-Devel] [RFC PATCH] packages: Smart Queue Management for AQM Packet Scheduling and Qos from CeroWrt
Dave Taht wrote on Thu Oct 2 03:49:15 CEST 2014: > So I don't know where to go. Certainly I'd like to see the battle hardened sqm scripts (which are more flexible than the C code above) get more widely used and in BB. SQM seems to work ok with the current Chaos Calmer trunk. I have included your SQM in my trunk WNDR3700/3800 community build ( https://forum.openwrt.org/viewtopic.php?id=28392 ) and it works ok. Arokh has also picked it up for his build ( https://forum.openwrt.org/viewtopic.php?id=50914 ). So you might get more feedback sooner or later, if users of our builds really do try it. I feel that the best way to get wider testing and real-life usage for SQM would be to create a pull request in the new packages feed in Github, to get both the SQM itself and the Luci frontend included there. Being available in the packages feed would create more interest for the package. If it proves to work ok, the devs might then import it into the core Openwrt repo (where the old qos-scripts is). Ps. For my own build I made a slight modification to the Luci menu item, as pure "SQM" does not say much. I changed it to "SQM QoS". ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
Am 08.10.2014 um 21:07 schrieb Justin Vallon:
> On 10/8/14 4:47 AM, Christian Schoenebeck wrote:
>> Inside
>> [buildroot]/feeds/luci/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
>> you find the definition hostname.placeholder = luci.sys.hostname().
>> It's not "default" so its never written/used to configuration.
>> From the LuCI point of view placeholder is a sample. (light grey)
>> If it's a default (also used be the system behind LuCI) then its written
>> into the field as if the user write something into the field.
>
> Now I see what you mean. It is confusing, though, from a UI because
> sometimes the "ghost" values are defaults and sometimes samples. I
> don't think your last statement is accurate, because there are default
> values that are not saved in uci.
>
> 1) DHCP & DNS / General Settings: DNS forwardings
> "/example.org/10.1.2.3" is clearly a sample.
> 2) ... / Advanced Settings: DNS server port "53", but
> dhcp.@dnsmasq[0].port is unset. 53 is the default DNS port. Setting it
> causes dhcp.*.port to be set.
> 3) ... / Advanced Settings : Max concurrent queries "150", but no
> dhcp.@dnsmasq[0].* value. 150 is the default value (app default)
>
> The only way to tell the difference between a sample and a default would
> be to know whether the value is reasonable. In the case of DHCP
> hostname, the default seems reasonable, so it is confusing when udhcpc
> does not send $HOSTNAME.
>
> In <5434f9ac.3050...@openwrt.org>, Jow said that some dhcp servers choke
> on dhcp hostnames. Then, if >99% of OpenWRT configurations are probably
> where the upstream dhcp server is "external", sending a hostname will do
> more harm than good.
>
> Then, back to the UI. Since it is hard to distinguish between "default
> value" and "example value" in DHCP client hostname, can it be changed to
> empty-string? I tried the following:
>
> [[[ git://git.openwrt.org/project/luci.git
> diff --git a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
> b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
> index fe3fec6..62047b5 100644
> --- a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
> +++ b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
> @@ -20,7 +20,6 @@ local bcast, defaultroute, peerdns, dns, metric,
> clientid, vendorclass
> hostname = section:taboption("general", Value, "hostname",
> translate("Hostname to send when requesting DHCP"))
>
> -hostname.placeholder = luci.sys.hostname()
> hostname.datatype= "hostname"
>
>
> ]]]
>
About the need or not of a hostname for dhcp I can't say anything.
Missing knowledge.
About LuCI and the applications/scripts behind I can say that the "default"
is normally not set in the config because it's done in the scripts/apps as
default.
As stated by Jow something like "none" doesn't work.
The placeholder is a good thing to show the user what kind of entry is needed
to put in.
It's completely removed (no longer displayed) if you start to edit the field.
The "default" is written to the field and you can edit it as you like because
it's a text field.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On Wed, 8 Oct 2014, Felix Fietkau wrote: > On 2014-10-08 21:05, Robert P. J. Day wrote: > > On Wed, 8 Oct 2014, Felix Fietkau wrote: > > > >> On 2014-10-08 20:44, Robert P. J. Day wrote: > >> > On Wed, 8 Oct 2014, Felix Fietkau wrote: > >> > > >> >> On 2014-10-08 19:51, Robert P. J. Day wrote: > >> >> > > >> >> > tried a "make V=s DUMP=1" and encountered precisely this bug: > >> >> > > >> >> > https://dev.openwrt.org/ticket/14697 > >> >> > > >> >> > this is on a fully-updated, fedora rawhide system for which all my > >> >> > non-DUMP openwrt makes have been working pretty well so far. > >> > > >> >> This is not a bug - overriding a random internal build system > >> >> variable on the command line isn't exactly a good idea. :) Where did > >> >> you get the idea of putting DUMP=1 on the command line? > >> > > >> > it's mentioned in the old kamikaze documentation here: > >> > > >> > https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 > >> > > >> > and an admittedly ancient openwrt users mailing list post here: > >> > > >> > https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html > > > >> Ah okay, so you just took a small part of that command without > >> checking the context. By the way, if you use the DUMP=1 command as > >> described in that old document, it still works. > > > > fair enough ... it's just not clear from that doc what part of the > > context is actually *required*. > It's a specific command for a specific use (checking why a particular > package does not show up in menuconfig), not something that's in any way > meant to be run globally. > > It says: > > If you find your package doesn’t show up in menuconfig, try the > following command to see if you get the correct description: > > TOPDIR=$PWD make -C package/ DUMP=1 V=99 > > Which part of this is unclear, and how could we change the wording to > make it more clear? no, that was my mistake in generalizing inappropriately, unaware of how specific that command had to be. but i'm not sure there's value in updating that document since it clearly refers to the "kamikaze" release, so a lot of people are going to ignore it anyway, no? rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On 2014-10-08 21:05, Robert P. J. Day wrote: > On Wed, 8 Oct 2014, Felix Fietkau wrote: > >> On 2014-10-08 20:44, Robert P. J. Day wrote: >> > On Wed, 8 Oct 2014, Felix Fietkau wrote: >> > >> >> On 2014-10-08 19:51, Robert P. J. Day wrote: >> >> > >> >> > tried a "make V=s DUMP=1" and encountered precisely this bug: >> >> > >> >> > https://dev.openwrt.org/ticket/14697 >> >> > >> >> > this is on a fully-updated, fedora rawhide system for which all my >> >> > non-DUMP openwrt makes have been working pretty well so far. >> > >> >> This is not a bug - overriding a random internal build system >> >> variable on the command line isn't exactly a good idea. :) Where did >> >> you get the idea of putting DUMP=1 on the command line? >> > >> > it's mentioned in the old kamikaze documentation here: >> > >> > https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 >> > >> > and an admittedly ancient openwrt users mailing list post here: >> > >> > https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html > >> Ah okay, so you just took a small part of that command without >> checking the context. By the way, if you use the DUMP=1 command as >> described in that old document, it still works. > > fair enough ... it's just not clear from that doc what part of the > context is actually *required*. It's a specific command for a specific use (checking why a particular package does not show up in menuconfig), not something that's in any way meant to be run globally. It says: If you find your package doesn’t show up in menuconfig, try the following command to see if you get the correct description: TOPDIR=$PWD make -C package/ DUMP=1 V=99 Which part of this is unclear, and how could we change the wording to make it more clear? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
On 10/8/14 4:47 AM, Christian Schoenebeck wrote:
> Inside
> [buildroot]/feeds/luci/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
> you find the definition hostname.placeholder = luci.sys.hostname().
> It's not "default" so its never written/used to configuration.
> From the LuCI point of view placeholder is a sample. (light grey)
> If it's a default (also used be the system behind LuCI) then its written into
> the field as if the user write something into the field.
Now I see what you mean. It is confusing, though, from a UI because
sometimes the "ghost" values are defaults and sometimes samples. I
don't think your last statement is accurate, because there are default
values that are not saved in uci.
1) DHCP & DNS / General Settings: DNS forwardings
"/example.org/10.1.2.3" is clearly a sample.
2) ... / Advanced Settings: DNS server port "53", but
dhcp.@dnsmasq[0].port is unset. 53 is the default DNS port. Setting it
causes dhcp.*.port to be set.
3) ... / Advanced Settings : Max concurrent queries "150", but no
dhcp.@dnsmasq[0].* value. 150 is the default value (app default)
The only way to tell the difference between a sample and a default would
be to know whether the value is reasonable. In the case of DHCP
hostname, the default seems reasonable, so it is confusing when udhcpc
does not send $HOSTNAME.
In <5434f9ac.3050...@openwrt.org>, Jow said that some dhcp servers choke
on dhcp hostnames. Then, if >99% of OpenWRT configurations are probably
where the upstream dhcp server is "external", sending a hostname will do
more harm than good.
Then, back to the UI. Since it is hard to distinguish between "default
value" and "example value" in DHCP client hostname, can it be changed to
empty-string? I tried the following:
[[[ git://git.openwrt.org/project/luci.git
diff --git a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
index fe3fec6..62047b5 100644
--- a/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
+++ b/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
@@ -20,7 +20,6 @@ local bcast, defaultroute, peerdns, dns, metric,
clientid, vendorclass
hostname = section:taboption("general", Value, "hostname",
translate("Hostname to send when requesting DHCP"))
-hostname.placeholder = luci.sys.hostname()
hostname.datatype= "hostname"
]]]
--
-Justin
justinval...@gmail.com
smime.p7s
Description: S/MIME Cryptographic Signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On Wed, 8 Oct 2014, Felix Fietkau wrote: > On 2014-10-08 20:44, Robert P. J. Day wrote: > > On Wed, 8 Oct 2014, Felix Fietkau wrote: > > > >> On 2014-10-08 19:51, Robert P. J. Day wrote: > >> > > >> > tried a "make V=s DUMP=1" and encountered precisely this bug: > >> > > >> > https://dev.openwrt.org/ticket/14697 > >> > > >> > this is on a fully-updated, fedora rawhide system for which all my > >> > non-DUMP openwrt makes have been working pretty well so far. > > > >> This is not a bug - overriding a random internal build system > >> variable on the command line isn't exactly a good idea. :) Where did > >> you get the idea of putting DUMP=1 on the command line? > > > > it's mentioned in the old kamikaze documentation here: > > > > https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 > > > > and an admittedly ancient openwrt users mailing list post here: > > > > https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html > Ah okay, so you just took a small part of that command without > checking the context. By the way, if you use the DUMP=1 command as > described in that old document, it still works. fair enough ... it's just not clear from that doc what part of the context is actually *required*. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On 2014-10-08 20:44, Robert P. J. Day wrote: > On Wed, 8 Oct 2014, Felix Fietkau wrote: > >> On 2014-10-08 19:51, Robert P. J. Day wrote: >> > >> > tried a "make V=s DUMP=1" and encountered precisely this bug: >> > >> > https://dev.openwrt.org/ticket/14697 >> > >> > this is on a fully-updated, fedora rawhide system for which all my >> > non-DUMP openwrt makes have been working pretty well so far. > >> This is not a bug - overriding a random internal build system >> variable on the command line isn't exactly a good idea. :) Where did >> you get the idea of putting DUMP=1 on the command line? > > it's mentioned in the old kamikaze documentation here: > > https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 > > and an admittedly ancient openwrt users mailing list post here: > > https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html Ah okay, so you just took a small part of that command without checking the context. By the way, if you use the DUMP=1 command as described in that old document, it still works. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] hostapd: vlan bridge naming inconsistent
On 2014-09-28 14:37, Jon Agland wrote: > VLAN bridge naming is inconsistent when using LuCI and trying to do > dynamic VLANs with OpenWRT (hostapd). > > hostapd tries to use brvlanyyy but LuCI only creates br-vlanyyy (when > you use vlanyyy and select bridge) > > This minor patch resolves this issue, so that you can use Dynamic VLAN > support with VLAN Naming disabled. I've also just submitted a patch for > LuCI to support dynamic VLANs - > https://lists.subsignal.org/pipermail/luci/2014-September/001570.html > > This needs to be applied to > trunk/package/network/services/hostapd/files/netifd.sh > > Signed-off-by: Jon Agland > > --- src/netifd.sh2014-09-28 13:18:54.246081887 +0100 > +++ vlan/netifd.sh2014-09-28 13:20:30.114085964 +0100 > @@ -262,6 +262,11 @@ > [ -n "$vlan_tagged_interface" ] && \ > append bss_conf > "vlan_tagged_interface=$vlan_tagged_interface" "$N" > } > + > +if [ "$dynamic_vlan" -gt 0 ] && [ > "$vlan_naming" -eq 0 ]; then > +append bss_conf "vlan_bridge=br-vlan" "$N" > +fi > + Several issues with that patch: - The path is wrong, you should use git or svn to generate the diff. - the vlan_bridge value should be defined in the config, not hardcoded - Your mail client has messed up the patch through line wrapping and whitespace mangling. Please fix and resend. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On Wed, 8 Oct 2014, Felix Fietkau wrote: > On 2014-10-08 19:51, Robert P. J. Day wrote: > > > > tried a "make V=s DUMP=1" and encountered precisely this bug: > > > > https://dev.openwrt.org/ticket/14697 > > > > this is on a fully-updated, fedora rawhide system for which all my > > non-DUMP openwrt makes have been working pretty well so far. > This is not a bug - overriding a random internal build system > variable on the command line isn't exactly a good idea. :) Where did > you get the idea of putting DUMP=1 on the command line? it's mentioned in the old kamikaze documentation here: https://downloads.openwrt.org/kamikaze/docs/openwrt.html#x1-490002.1.5 and an admittedly ancient openwrt users mailing list post here: https://lists.openwrt.org/pipermail/openwrt-users/2008-May/000316.html rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [package] hostapd: vlan bridge naming inconsistent
Hello. Just wondered if I needed to do anything more to get this submitted into the openwrt code? Is there something wrong with my patch? (My corresponding LuCI patches seems to be in a similar state - https://lists.subsignal.org/pipermail/luci/2014-September/001570.html) Any feedback appreciated. Thanks Jon On 28/09/14 13:37, Jon Agland wrote: VLAN bridge naming is inconsistent when using LuCI and trying to do dynamic VLANs with OpenWRT (hostapd). hostapd tries to use brvlanyyy but LuCI only creates br-vlanyyy (when you use vlanyyy and select bridge) This minor patch resolves this issue, so that you can use Dynamic VLAN support with VLAN Naming disabled. I've also just submitted a patch for LuCI to support dynamic VLANs - https://lists.subsignal.org/pipermail/luci/2014-September/001570.html This needs to be applied to trunk/package/network/services/hostapd/files/netifd.sh Signed-off-by: Jon Agland --- src/netifd.sh2014-09-28 13:18:54.246081887 +0100 +++ vlan/netifd.sh2014-09-28 13:20:30.114085964 +0100 @@ -262,6 +262,11 @@ [ -n "$vlan_tagged_interface" ] && \ append bss_conf "vlan_tagged_interface=$vlan_tagged_interface" "$N" } + +if [ "$dynamic_vlan" -gt 0 ] && [ "$vlan_naming" -eq 0 ]; then +append bss_conf "vlan_bridge=br-vlan" "$N" +fi + ;; wep) local wep_keyidx=0 --- ___ 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] [package] dropbear: enable sha2-based hmac by default.
On Friday, October 03, 2014 01:55:29 PM Weedy wrote: > Based off failed ciphers/macs > no matching cipher found: client rijndael-...@lysator.liu.se server > aes128-ctr,3des-ctr,aes256-ctr,aes128-cbc,3des-cbc,aes256-cbc > no matching mac found: client hmac-ripemd160-...@openssh.com server > hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5 > > for cipher in 3des-cbc 3des-ctr aes128-cbc aes256-cbc aes128-ctr > aes256-ctr; do for mac in hmac-md5 hmac-sha1 hmac-sha2-256 > hmac-sha2-512; do echo ""; echo "cipher: $cipher"; echo "mac: $mac"; for > bah in 1 2 3; do dd if=/dev/zero bs=1M count=25 | ssh -c "$cipher" -m > "$mac" -o "Compression no" r...@openwrt.lan 'time cat - >/dev/null'; > echo ""; sleep 2; done; done; done > > OpenSSH_6.6.1 connecting to TP-Link 4300, time to transfer 26MiB of junk > to null. Best of three, my router is in use and not idle. > > 3des-cbc > +-+--+--+--+--+ > |time\hmac|md5 | sha1 | sha256 | sha512 | > +-+--+--+--+--+ > | real| 0m27.65s | 0m27.98s | 0m29.47s | 0m31.93s | > | user| 0m 0.05s | 0m 0.04s | 0m 0.02s | 0m 0.04s | > | sys | 0m 0.25s | 0m 0.22s | 0m 0.24s | 0m 0.22s | > +-+--+--+--+--+ > > aes128-cbc > +-+--+--+--+--+ > |time\hmac|md5 | sha1 | sha256 | sha512 | > +-+--+--+--+--+ > | real| 0m12.07s | 0m12.62s | 0m13.61s | 0m16.05s | > | user| 0m 0.02s | 0m 0.03s | 0m 0.00s | 0m 0.02s | > | sys | 0m 0.27s | 0m 0.23s | 0m 0.21s | 0m 0.22s | > +-+--+--+--+--+ > > aes256-cbc > +-+--+--+--+--+ > |time\hmac|md5 | sha1 | sha256 | sha512 | > +-+--+--+--+--+ > | real| 0m13.32s | 0m13.61s | 0m14.97s | 0m17.71s | > | user| 0m 0.02s | 0m 0.03s | 0m 0.03s | 0m 0.03s | > | sys | 0m 0.27s | 0m 0.23s | 0m 0.22s | 0m 0.28s | > +-+--+--+--+--+ > > aes128-ctr > +-+--+--+--+--+ > |time\hmac|md5 | sha1 | sha256 | sha512 | > +-+--+--+--+--+ > | real| 0m12.64s | 0m12.80s | 0m13.74s | 0m16.19s | > | user| 0m 0.04s | 0m 0.02s | 0m 0.02s | 0m 0.01s | > | sys | 0m 0.18s | 0m 0.24s | 0m 0.17s | 0m 0.23s | > +-+--+--+--+--+ > > aes256-ctr > +-+--+--+--+--+ > |time\hmac|md5 | sha1 | sha256 | sha512 | > +-+--+--+--+--+ > | real| 0m13.40s | 0m13.84s | 0m15.20s | 0m18.11s | > | user| 0m 0.01s | 0m 0.03s | 0m 0.02s | 0m 0.00s | > | sys | 0m 0.17s | 0m 0.16s | 0m 0.18s | 0m 0.24s | > +-+--+--+--+--+ > > > We should dump 3des-* and pick up arcfour* Thanks for performing cipher speed test in addition with hmac test. I realize that there is no need to enable stronger hash function for hmac. The md5 collision attacks and 'predicted' sha1 collision attacks are just affecting `pure` digest function. There is no known attack affecting hmac-md5 or hmac-sha1, because hmac is not as simple as digest. It's an advanced operation to verify deciphered message, operating blocks by blocks repeatedly. It's sure hard to perform collision attack on hmac, because the underlying layer is already encrypted, for example by aes128-ctr cipher. Currently, there is no formal advice to enable stronger digest for hmac. The well known OpenSSH is still using hmac-md5 as default message authentication algorithm, although it has added support for sha2-based hmac since 5.9. To be specified, OpenSSH is using hmac-md5-...@openssh.com - a special extension added by OpenSSH to add more security to hmac-md5 - if the server supports it. IETF says that hmac-md5 isn't broken, although the md5 hash function is considered weak to collision attacks. https://www.ietf.org/mail-archive/web/cfrg/current/msg01202.html There is no need to rush. I know that when the time comes, OpenWrt developers will enable hmac-sha2 by default. Maybe years from now, or when the dropbear upstream enables hmac-sha2 by default. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] just tripped over defect #14697
On 2014-10-08 19:51, Robert P. J. Day wrote: > > tried a "make V=s DUMP=1" and encountered precisely this bug: > > https://dev.openwrt.org/ticket/14697 > > this is on a fully-updated, fedora rawhide system for which all my > non-DUMP openwrt makes have been working pretty well so far. This is not a bug - overriding a random internal build system variable on the command line isn't exactly a good idea. :) Where did you get the idea of putting DUMP=1 on the command line? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] just tripped over defect #14697
tried a "make V=s DUMP=1" and encountered precisely this bug: https://dev.openwrt.org/ticket/14697 this is on a fully-updated, fedora rawhide system for which all my non-DUMP openwrt makes have been working pretty well so far. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
Hi, On the MediaTek site, I found information about MT7620A+MT7610E, but not MT7610EN. There are several other routers with these same chipsets [1]. So, I guess, MT7610E and MT7610EN are the same chips. As you have mentioned that the board is from hiwifi, you should take a look at the following link for the source code - https://github.com/hynnet/hiwifi-openwrt-HC5661-HC5761 You will find the configurations under target/linux/ralink, not target/linux/ramips (unlike the recent openwrt source tree). I can see at least two different configurations, HB5881, and HB750ACH (under mt7620a-custom). AFAIK, HC5761 has MT7610E as well [2], but it's not mentioned in the configuration from the link above. I hope it helps. :) Regards, Md Mahbubur Rasheed [1] https://wikidevi.com/wiki/MediaTek_MT7620 [2] http://z.zol.com.cn/4725215.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Wed, 8 Oct 2014, Yousong Zhou wrote: > > > On Oct 8, 2014 4:33 PM, "Robert P. J. Day" > > i'm looking at this page: > > > > http://www.cleanrouter.com/home/product > > > > and the processor is shown as an atheros AR7161, though. also, the > > pandoras hope router apparently has 4 wired ports, and this board has > > only two. at the risk of abusing this mailing list a bit more, i took > > a pic of the top of the board and attached it, if that helps > > maybe you are looking at the router at link [1]. it has 802.11ac capability > but i guess padora > firmware uses wireless drivers from ralink, not the mac80211 based one. > > for your information, j2 is for pinyin of 极贰 in Chinese. we > already have j1 supported in opnewrt trunk. well, the official name > for that board is hiwifi hc6361 [2]. they also have j1s which is > mt7620a based without 5ghz capability. > > [1] http://www.hiwifi.com/j2-specs > [2] http://wiki.openwrt.org/toh/hiwifi/hc6361 i can't even get to the page in [1], and the router in [2] is listed as based on AR9331, not MT7620A, so i'm fairly sure that can't be it. i'll keep trying the first link. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Unable to compile libnl-tiny [stdio.h not found]
On Wednesday, October 08, 2014 07:02:33 PM Felix Fietkau wrote: > Try running make dirclean and rebuild. Thanks. I'll try this workaround. I'll check if this will fix the problem. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
On 2014-10-08 15:54, Michel Stam wrote:
> Signed-off-by: Michel Stam
> ---
> package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> index a3b2199..a1ed6f6 100644
> --- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> +++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
> @@ -19,9 +19,11 @@ lookup_phy() {
>
> local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
> [ -n "$macaddr" ] && {
> - for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
> - [ "$macaddr" = "$(cat
> /sys/class/ieee80211/${_phy}/macaddress)" ] || continue
> - phy="$_phy"
> + for _phy in /sys/class/ieee80211/*; do
> + [ -e "$_phy" ] || continue
> +
> + phy="${_phy##*/}"
> + [ "$macaddr" = "$(cat
> /sys/class/ieee80211/${phy}/macaddress)" ] || continue
This ends up setting $phy, even if the mac address does not match.
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Unable to compile libnl-tiny [stdio.h not found]
On 2014-10-08 18:58, Alive4Ever wrote: > Hello openwrt devs! > > Since I moved the openwrt build directory to another partition on > another external hard-drive, I'm unable to compile openwrt. Everytime I > run openwrt build process, the following error occurs and compilation > stopped prematurely. Try running make dirclean and rebuild. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Unable to compile libnl-tiny [stdio.h not found]
Hello openwrt devs! Since I moved the openwrt build directory to another partition on another external hard-drive, I'm unable to compile openwrt. Everytime I run openwrt build process, the following error occurs and compilation stopped prematurely. Here is the error message produced by `make V=s` ``` mips-openwrt-linux-uclibc-gcc -Wall -c -o nl.o -Iinclude -Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves -fhonour-copts -Wno-error=unused-b ut-set-variable -msoft-float -mips16 -minterlink-mips16 -fpic nl.c In file included from nl.c:84:0: include/netlink-local.h:16:19: fatal error: stdio.h: No such file or directory #include ^ compilation terminated. make[4]: *** [nl.o] Error 1 ``` For your information, the old openwrt build directory is on ~/OpenWrt/openwrt, which is located in the same partition as / (root fs) which is /dev/sda3 The new openwrt build directory is on /media/username/developer/home/project/openwrt on /dev/sdb2 I've tried deleting all files, then restoring the openwrt working directory with `git checkout master origin/master`. I've updated the feeds directory with `./script/feeds update -a` and installed the feeds with `./script/feeds install -a`. I've done `make clean`, `make distclean`, `make defconfig`, and `make menuconfig` several times, but none of the effort gives a hope. Your advices and suggestions are appreciated. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Netgear DGN2200v4 / 963281TAN4
Hi all, Is anyone currently working on the broadcom 963281TAN4 board ? I've got one here. it's my first attempt at a new board so forgive my ignorance, but can anyone give me some pointers ? I'm about to try the image builder and just tweaking the board ID, spec is very similar to a DGN2200v3 I have with board ID 963281TAN. different wifi controller and that's all, I think. cheers, Dan ___ 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 conor On 08/10/2014 17:27, Conor O'Gorman wrote: > > > On 08/10/14 11:00, John Crispin wrote: >> the e3267 that sami sent me works with this proto, but i am >> failing to get a DHCP addr. could someone with a ncm dongle >> please try this patch on top of latest trunk please and tell me >> if they are getting a dhcp addr ? > > I had a similar problem with a Huawei device. It worked after > removing some zero padding in the ncm driver. > > In cdc_ncm.c, cdc_ncm_fill_tx_frame(), towards the end there is > handling for Zero Length Packets (ZLP) and padding short packets. I > removed the padding, and it worked. Are you testing 3.10 or 3.14? > It's changed ever so slightly between them. > 3.14, will have a look at it tomorrow. > I am somewhat confused by the comment. It won't pad out short > packets, but does make shortish packets long. sounds weird indeed John > > FYI: /* * If collected data size is less or equal > CDC_NCM_MIN_TX_PKT bytes, * we send buffers as it is. If we get > more data, it would be more * efficient for USB HS mobile device > with DMA engine to receive a full * size NTB, than canceling DMA > transfer and receiving a short packet. */ if (skb_out->len > > CDC_NCM_MIN_TX_PKT) /* final zero padding */ > > > Conor ___ 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] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Oct 8, 2014 4:33 PM, "Robert P. J. Day" > i'm looking at this page: > > http://www.cleanrouter.com/home/product > > and the processor is shown as an atheros AR7161, though. also, the > pandoras hope router apparently has 4 wired ports, and this board has > only two. at the risk of abusing this mailing list a bit more, i took > a pic of the top of the board and attached it, if that helps maybe you are looking at the router at link [1]. it has 802.11ac capability but i guess padora firmware uses wireless drivers from ralink, not the mac80211 based one. for your information, j2 is for pinyin of 极贰 in Chinese. we already have j1 supported in opnewrt trunk. well, the official name for that board is hiwifi hc6361 [2]. they also have j1s which is mt7620a based without 5ghz capability. [1] http://www.hiwifi.com/j2-specs [2] http://wiki.openwrt.org/toh/hiwifi/hc6361 regards yousong ___ 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
On 08/10/14 11:00, John Crispin wrote: the e3267 that sami sent me works with this proto, but i am failing to get a DHCP addr. could someone with a ncm dongle please try this patch on top of latest trunk please and tell me if they are getting a dhcp addr ? I had a similar problem with a Huawei device. It worked after removing some zero padding in the ncm driver. In cdc_ncm.c, cdc_ncm_fill_tx_frame(), towards the end there is handling for Zero Length Packets (ZLP) and padding short packets. I removed the padding, and it worked. Are you testing 3.10 or 3.14? It's changed ever so slightly between them. I am somewhat confused by the comment. It won't pad out short packets, but does make shortish packets long. FYI: /* * If collected data size is less or equal CDC_NCM_MIN_TX_PKT bytes, * we send buffers as it is. If we get more data, it would be more * efficient for USB HS mobile device with DMA engine to receive a full * size NTB, than canceling DMA transfer and receiving a short packet. */ if (skb_out->len > CDC_NCM_MIN_TX_PKT) /* final zero padding */ Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
Hi. > -Original Message- > From: Michel Stam [mailto:m.s...@fugro.nl] > Sent: Wednesday, October 08, 2014 15:54 PM > To: openwrt-devel@lists.openwrt.org > Cc: j...@openwrt.org; blo...@openwrt.org; Stam, Michel [FINT] > Subject: [PATCH v2] mac80211: remove error from detect script > > Signed-off-by: Michel Stam Acked-by: Jo-Philipp Wich ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
After looking at the ticket with the rejected patch, I reimplemented the
patch using the for loop Jow suggested.
I found another line in the same file doing the ls /sys/class/ieee80211
2>/dev/null which I had used, so I rewrote that one as well.
Kind regards,
Michel Stam
-Original Message-
From: Michel Stam [mailto:m.s...@fugro.nl]
Sent: Wednesday, October 08, 2014 15:54 PM
To: openwrt-devel@lists.openwrt.org
Cc: j...@openwrt.org; blo...@openwrt.org; Stam, Michel [FINT]
Subject: [PATCH v2] mac80211: remove error from detect script
Signed-off-by: Michel Stam
---
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index a3b2199..a1ed6f6 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -19,9 +19,11 @@ lookup_phy() {
local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
[ -n "$macaddr" ] && {
- for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
- [ "$macaddr" = "$(cat
/sys/class/ieee80211/${_phy}/macaddress)" ] || continue
- phy="$_phy"
+ for _phy in /sys/class/ieee80211/*; do
+ [ -e "$_phy" ] || continue
+
+ phy="${_phy##*/}"
+ [ "$macaddr" = "$(cat
/sys/class/ieee80211/${phy}/macaddress)" ] || continue
return
done
}
@@ -65,7 +67,12 @@ detect_mac80211() {
[ -n "$type" ] || break
devidx=$(($devidx + 1))
done
- for dev in $(ls /sys/class/ieee80211); do
+
+ for _dev in /sys/class/ieee80211/*; do
+ [ -e "$_dev" ] || continue
+
+ dev="${_dev##*/}"
+
found=0
config_foreach check_mac80211_device wifi-device
[ "$found" -gt 0 ] && continue
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] mac80211: remove error from detect script
Signed-off-by: Michel Stam
---
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index a3b2199..a1ed6f6 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -19,9 +19,11 @@ lookup_phy() {
local macaddr="$(config_get "$device" macaddr | tr 'A-Z' 'a-z')"
[ -n "$macaddr" ] && {
- for _phy in $(ls /sys/class/ieee80211 2>/dev/null); do
- [ "$macaddr" = "$(cat
/sys/class/ieee80211/${_phy}/macaddress)" ] || continue
- phy="$_phy"
+ for _phy in /sys/class/ieee80211/*; do
+ [ -e "$_phy" ] || continue
+
+ phy="${_phy##*/}"
+ [ "$macaddr" = "$(cat
/sys/class/ieee80211/${phy}/macaddress)" ] || continue
return
done
}
@@ -65,7 +67,12 @@ detect_mac80211() {
[ -n "$type" ] || break
devidx=$(($devidx + 1))
done
- for dev in $(ls /sys/class/ieee80211); do
+
+ for _dev in /sys/class/ieee80211/*; do
+ [ -e "$_dev" ] || continue
+
+ dev="${_dev##*/}"
+
found=0
config_foreach check_mac80211_device wifi-device
[ "$found" -gt 0 ] && continue
--
1.7.12.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: add support for Nexx WT1520
From: Roger Pueyo Centelles
---
target/linux/ramips/base-files/etc/board.d/01_leds | 3 +
.../linux/ramips/base-files/etc/board.d/02_network | 3 +-
target/linux/ramips/base-files/etc/diag.sh | 3 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/WT1520.dts | 83 ++
target/linux/ramips/image/Makefile | 8 +++
target/linux/ramips/rt305x/profiles/nexx.mk| 17 +
8 files changed, 120 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/WT1520.dts
create mode 100644 target/linux/ramips/rt305x/profiles/nexx.mk
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index b07c96a..26f384d 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -210,6 +210,9 @@ case $board in
set_usb_led "wr8305rt:usb"
set_wifi_led "wr8305rt:wifi"
;;
+ wt1520)
+ set_wifi_led "rt2800pci-phy0::radio"
+ ;;
y1 |\
y1s)
ucidef_set_led_default "power" "power" "lenovo:blue:power" "1"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index c462fd8..7ecec5f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -110,7 +110,8 @@ ramips_setup_interfaces()
dir-615-h1 | \
hlk-rm04 | \
mzk-w300nh2 | \
- mzk-750dhp)
+ mzk-750dhp | \
+ wt1520)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 6t"
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 9752eb2..aed7d6a 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -167,6 +167,9 @@ get_status_led() {
wnce2001)
status_led="netgear:green:power"
;;
+ nexx-wt1520)
+ status_led="nexx-wt1520:white:power"
+ ;;
mzk-w300nh2)
status_led="mzkw300nh2:green:power"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 68ff509..08c5dff 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -181,6 +181,9 @@ ramips_board_detect() {
*"NexAira BC2")
name="bc2"
;;
+ *"Nexx WT1520")
+ name="wt1520"
+ ;;
*"NW718")
name="nw718"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 4aec780..52f3f0a 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -90,6 +90,7 @@ platform_check_image() {
wnce2001 | \
wli-tx4-ag300n | \
whr-g300n |\
+ wt1520 |\
ur-326n4g |\
ur-336un |\
wr512-3gn |\
diff --git a/target/linux/ramips/dts/WT1520.dts
b/target/linux/ramips/dts/WT1520.dts
new file mode 100644
index 000..dc0ad32
--- /dev/null
+++ b/target/linux/ramips/dts/WT1520.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+/include/ "rt5350.dtsi"
+
+/ {
+ compatible = "NEXXWT1520", "ralink,rt5350-soc";
+ model = "Nexx WT1520";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x200>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS1,57600";
+ };
+
+ palmbus@1000 {
+ uart@500 {
+ status = "okay";
+ };
+
+ spi@b00 {
+ status = "okay";
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "w25q32";
+ reg = <0 0>;
+ linux,modalias = "m25p80", "s25fl064k";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-onl
Re: [OpenWrt-Devel] Hyper-V Support for X86 or X86_64
Sorry for the late reply. To answer your questions, first I am trying to save the hassle with another target, but hyper-v supports are enabled either by manually selecting the hyper-v modules under virtualization or build VHD disk output. If you are using default x86 or x86_64 target, it wouldn't added hyper-v unless you turned them on. I couldn't make hyper-v module support work, especially the disk module. It hangs if it is kernel module only. My guess is that it needs the disk support in order to load other modules. Because the hyper-v is only enabled for hyper-v environment, building it into the kernel doesn't seem to waste any resources. Best, Ning -Original Message- From: Hauke Mehrtens [mailto:ha...@hauke-m.de] Sent: Saturday, September 13, 2014 4:05 PM To: Ning Ye; 'OpenWrt Development List' Subject: Re: [OpenWrt-Devel] Hyper-V Support for X86 or X86_64 On 07/28/2014 12:37 AM, Ning Ye wrote: > Hi All, > > Hyper-V support for X86 or X86_64 were noticeably missing. There is a previous patch for Kernel 3.3 but never maintained or merged into trunk. Here's my take on adding the Hyper-V support for the current kernel. No new sub targets or profiles are created, as long as the target is x86 or x86_64. The generic works well or any other profiles. > > Also added a new VHD target image menu . The latest stable qemu-img supports Hyper-V vhd and vhdx. The old & current qemu 0.14.1 builds invalid vhd images. I am working on updating it to 2.0.0. Currently I am converting vmdk into vhd using third party tools. > > Ning Ye > Signed-off-by: Ning Ye > > > diff --git a/config/Config-images.in b/config/Config-images.in old > mode 100644 new mode 100755 index 39e51e4..7020f84 > --- a/config/Config-images.in > +++ b/config/Config-images.in > @@ -239,6 +239,16 @@ menu "Target Images" > select TARGET_IMAGES_PAD > select PACKAGE_kmod-e1000 > > + config VHD_IMAGES > + bool "Build Hyper-V image files (VHD)" > + depends on TARGET_x86 || TARGET_x86_64 > + select GRUB_IMAGES > + select TARGET_IMAGES_PAD > + select PACKAGE_kmod-hyperv-balloon > + select PACKAGE_kmod-hyperv-net-vsc > + select PACKAGE_kmod-hyperv-util > + select PACKAGE_kmod-hyperv-storage > + > config TARGET_IMAGES_PAD > bool "Pad images to filesystem size (for JFFS2)" > depends on OLPC_BOOTSCRIPT_IMAGES || GRUB_IMAGES diff --git > a/package/kernel/linux/modules/virtual.mk > b/package/kernel/linux/modules/virtual.mk > old mode 100644 > new mode 100755 > index 190d844..a67d71c > --- a/package/kernel/linux/modules/virtual.mk > +++ b/package/kernel/linux/modules/virtual.mk > @@ -186,3 +186,85 @@ define KernelPackage/xen-pcidev/description > endef > > $(eval $(call KernelPackage,xen-pcidev)) > + > +# > +# Hyper-V Drives depends on x86 or x86_64. > +# > +define KernelPackage/hyperv-balloon > + SUBMENU:=$(VIRTUAL_MENU) > + DEPENDS:=@(TARGET_x86||TARGET_x86_64) > + TITLE:=Microsoft Hyper-V Balloon Driver > + KCONFIG:= \ > +CONFIG_HYPERV_BALLOON \ > +CONFIG_HYPERVISOR_GUEST=y \ This adds some code to the kernel. I think it should be better to just extend the kvm_guest subtarget and the x86_64 target with support for Hyper-V. > +CONFIG_PARAVIRT=n \ > +CONFIG_HYPERV=y It is possible to build this as a module why is it build into the kernel? > + FILES:=$(LINUX_DIR)/drivers/hv/hv_balloon.ko > + AUTOLOAD:=$(call AutoLoad,06,hv_balloon) endef > + > +define KernelPackage/hyperv-balloon/description > + Microsofot Hyper-V balloon driver. > +endef > + > +$(eval $(call KernelPackage,hyperv-balloon)) > + > +define KernelPackage/hyperv-net-vsc > + SUBMENU:=$(VIRTUAL_MENU) > + DEPENDS:=@(TARGET_x86||TARGET_x86_64) > + TITLE:=Microsoft Hyper-V Network Driver > + KCONFIG:= \ > +CONFIG_HYPERV_NET \ > +CONFIG_HYPERVISOR_GUEST=y \ > +CONFIG_PARAVIRT=n \ > +CONFIG_HYPERV=y > + FILES:=$(LINUX_DIR)/drivers/net/hyperv/hv_netvsc.ko > + AUTOLOAD:=$(call AutoLoad,35,hv_netvsc) endef > + > +define KernelPackage/hyperv-net-vsc/description > + Microsoft Hyper-V Network Driver > +endef > + > +$(eval $(call KernelPackage,hyperv-net-vsc)) > + > +define KernelPackage/hyperv-util > + SUBMENU:=$(VIRTUAL_MENU) > + DEPENDS:=@(TARGET_x86||TARGET_x86_64) > + TITLE:=Microsoft Hyper-V Utility Driver > + KCONFIG:= \ > +CONFIG_HYPERV_UTILS \ > +CONFIG_HYPERVISOR_GUEST=y \ > +CONFIG_PARAVIRT=n \ > +CONFIG_HYPERV=y > + FILES:=$(LINUX_DIR)/drivers/hv/hv_util.ko > + AUTOLOAD:=$(call AutoLoad,10,hv_util) endef > + > +define KernelPackage/hyperv-util/description > + Microsoft Hyper-V Utility Driver > +endef > + > +$(eval $(call KernelPackage,hyperv-util)) > + > +# > +# Hyper-V Storage Drive needs to be in kernel rather than module to load the root fs. > +# > +define KernelPackage/hyperv-storage > + SUBMENU:=$(VIRTUAL_MENU) > +
Re: [OpenWrt-Devel] [PATCH] cns3xxx: Adopt irq_domain support for cns3xxx gpio driver
On 2014-10-08 02:25, Pushpal Sidhu wrote: > Have gpio driver adopt irqdomain support so that there are > non-overlapping allocations of irq numbers mapped to gpio's. > > Signed-off-by: Pushpal Sidhu Committed in r42844, thanks. - Felix ___ 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
the e3267 that sami sent me works with this proto, but i am failing to
get a DHCP addr. could someone with a ncm dongle please try this patch
on top of latest trunk please and tell me if they are getting a dhcp addr ?
On 08/10/2014 05:17, John Crispin wrote:
> From: Matti Laakso
>
> Signed-off-by: Matti Laakso
> ---
> package/network/utils/comgt/Makefile | 15 ++
> package/network/utils/comgt/files/3g.usb |2 +-
> package/network/utils/comgt/files/ncm.json| 49 +++
> package/network/utils/comgt/files/ncm.sh | 156
> +
> package/network/utils/comgt/files/runcommand.gcom | 26
> 5 files changed, 247 insertions(+), 1 deletion(-)
> create mode 100644 package/network/utils/comgt/files/ncm.json
> create mode 100644 package/network/utils/comgt/files/ncm.sh
> create mode 100644 package/network/utils/comgt/files/runcommand.gcom
>
> diff --git a/package/network/utils/comgt/Makefile
> b/package/network/utils/comgt/Makefile
> index 11a1a49..5fccd94 100644
> --- a/package/network/utils/comgt/Makefile
> +++ b/package/network/utils/comgt/Makefile
> @@ -40,6 +40,12 @@ $(call Package/comgt/Default)
>DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless
> +kmod-usb-net +kmod-usb-net-sierrawireless
> endef
>
> +define Package/comgt-ncm
> +$(call Package/comgt/Default)
> + TITLE+=NCM 3G/4G Support
> + DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-option +kmod-usb-net
> +kmod-usb-net-cdc-ncm +kmod-usb-net-huawei-cdc-ncm
> +endef
> +
> define Package/comgt/description
> comgt is a scripting language interpreter useful for establishing
> communications on serial lines and through PCMCIA modems as well as GPRS
> @@ -86,5 +92,14 @@ define Package/comgt-directip/install
> $(INSTALL_BIN) ./files/directip.sh $(1)/lib/netifd/proto/directip.sh
> endef
>
> +define Package/comgt-ncm/install
> + $(INSTALL_DIR) $(1)/etc/gcom
> + $(INSTALL_DATA) ./files/ncm.json $(1)/etc/gcom/ncm.json
> + $(INSTALL_DATA) ./files/runcommand.gcom $(1)/etc/gcom/runcommand.gcom
> + $(INSTALL_DIR) $(1)/lib/netifd/proto
> + $(INSTALL_BIN) ./files/ncm.sh $(1)/lib/netifd/proto/ncm.sh
> +endef
> +
> $(eval $(call BuildPackage,comgt))
> $(eval $(call BuildPackage,comgt-directip))
> +$(eval $(call BuildPackage,comgt-ncm))
> diff --git a/package/network/utils/comgt/files/3g.usb
> b/package/network/utils/comgt/files/3g.usb
> index fd6837e..ac8326b 100644
> --- a/package/network/utils/comgt/files/3g.usb
> +++ b/package/network/utils/comgt/files/3g.usb
> @@ -8,7 +8,7 @@ find_3g_iface() {
>
> local proto
> config_get proto "$cfg" proto
> - [ "$proto" = 3g ] || return 0
> + [ "$proto" = 3g ] || [ "$proto" = ncm ] || return 0
>
> # bypass state vars here because 00-netstate could clobber .device
> local dev=$(uci_get network "$cfg" device)
> diff --git a/package/network/utils/comgt/files/ncm.json
> b/package/network/utils/comgt/files/ncm.json
> new file mode 100644
> index 000..b9b15cd
> --- /dev/null
> +++ b/package/network/utils/comgt/files/ncm.json
> @@ -0,0 +1,49 @@
> +{
> + "huawei": {
> + "initialize": [
> + "AT",
> + "ATZ",
> + "ATQ0",
> + "ATV1",
> + "ATE1",
> + "ATS0=0"
> + ],
> + "modes": {
> + "preferlte":
> "AT^SYSCFGEX=\\\"030201\\\",3fff,2,4,7fff,,",
> + "preferumts":
> "AT^SYSCFGEX=\\\"0201\\\",3fff,2,4,7fff,,",
> + "lte":
> "AT^SYSCFGEX=\\\"03\\\",3fff,2,4,7fff,,",
> + "umts":
> "AT^SYSCFGEX=\\\"02\\\",3fff,2,4,7fff,,",
> + "gsm":
> "AT^SYSCFGEX=\\\"01\\\",3fff,2,4,7fff,,",
> + "auto":
> "AT^SYSCFGEX=\\\"00\\\",3fff,2,4,7fff,,"
> + },
> + "connect":
> "AT^NDISDUP=1,1,\\\"${apn}\\\"${username:+,\\\"$username\\\"}${password:+,\\\"$password\\\"}${auth:+,$auth}",
> + "disconnect": "AT^NDISDUP=1,0"
> + },
> + "SAMSUNG": {
> + "initialize": [
> + "AT",
> + "AT+CGREG=2",
> + "AT+CFUN=5",
> + "AT+MODESELECT=3",
> + "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\""
> + ],
> + "modes": {
> + "umts": "AT+CHANGEALLPATH=1"
> + },
> + "connect": "AT+CGATT=1",
> + "disconnect": "AT+CGATT=0"
> + },
> + "Sony": {
> + "initialize": [
> + "AT+CFUN=1",
> + "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\"",
> +
> "AT*EIAAUW=1,1,\\\"${username}\\\",\\\"${password}\\\",${auth:-00111}"
> + ],
> + "m
[OpenWrt-Devel] [PATCH] comgt: add ncm proto support
From: Matti Laakso
Signed-off-by: Matti Laakso
---
package/network/utils/comgt/Makefile | 15 ++
package/network/utils/comgt/files/3g.usb |2 +-
package/network/utils/comgt/files/ncm.json| 49 +++
package/network/utils/comgt/files/ncm.sh | 156 +
package/network/utils/comgt/files/runcommand.gcom | 26
5 files changed, 247 insertions(+), 1 deletion(-)
create mode 100644 package/network/utils/comgt/files/ncm.json
create mode 100644 package/network/utils/comgt/files/ncm.sh
create mode 100644 package/network/utils/comgt/files/runcommand.gcom
diff --git a/package/network/utils/comgt/Makefile
b/package/network/utils/comgt/Makefile
index 11a1a49..5fccd94 100644
--- a/package/network/utils/comgt/Makefile
+++ b/package/network/utils/comgt/Makefile
@@ -40,6 +40,12 @@ $(call Package/comgt/Default)
DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-sierrawireless
+kmod-usb-net +kmod-usb-net-sierrawireless
endef
+define Package/comgt-ncm
+$(call Package/comgt/Default)
+ TITLE+=NCM 3G/4G Support
+ DEPENDS:=+comgt +kmod-usb-serial +kmod-usb-serial-option +kmod-usb-net
+kmod-usb-net-cdc-ncm +kmod-usb-net-huawei-cdc-ncm
+endef
+
define Package/comgt/description
comgt is a scripting language interpreter useful for establishing
communications on serial lines and through PCMCIA modems as well as GPRS
@@ -86,5 +92,14 @@ define Package/comgt-directip/install
$(INSTALL_BIN) ./files/directip.sh $(1)/lib/netifd/proto/directip.sh
endef
+define Package/comgt-ncm/install
+ $(INSTALL_DIR) $(1)/etc/gcom
+ $(INSTALL_DATA) ./files/ncm.json $(1)/etc/gcom/ncm.json
+ $(INSTALL_DATA) ./files/runcommand.gcom $(1)/etc/gcom/runcommand.gcom
+ $(INSTALL_DIR) $(1)/lib/netifd/proto
+ $(INSTALL_BIN) ./files/ncm.sh $(1)/lib/netifd/proto/ncm.sh
+endef
+
$(eval $(call BuildPackage,comgt))
$(eval $(call BuildPackage,comgt-directip))
+$(eval $(call BuildPackage,comgt-ncm))
diff --git a/package/network/utils/comgt/files/3g.usb
b/package/network/utils/comgt/files/3g.usb
index fd6837e..ac8326b 100644
--- a/package/network/utils/comgt/files/3g.usb
+++ b/package/network/utils/comgt/files/3g.usb
@@ -8,7 +8,7 @@ find_3g_iface() {
local proto
config_get proto "$cfg" proto
- [ "$proto" = 3g ] || return 0
+ [ "$proto" = 3g ] || [ "$proto" = ncm ] || return 0
# bypass state vars here because 00-netstate could clobber .device
local dev=$(uci_get network "$cfg" device)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
new file mode 100644
index 000..b9b15cd
--- /dev/null
+++ b/package/network/utils/comgt/files/ncm.json
@@ -0,0 +1,49 @@
+{
+ "huawei": {
+ "initialize": [
+ "AT",
+ "ATZ",
+ "ATQ0",
+ "ATV1",
+ "ATE1",
+ "ATS0=0"
+ ],
+ "modes": {
+ "preferlte":
"AT^SYSCFGEX=\\\"030201\\\",3fff,2,4,7fff,,",
+ "preferumts":
"AT^SYSCFGEX=\\\"0201\\\",3fff,2,4,7fff,,",
+ "lte":
"AT^SYSCFGEX=\\\"03\\\",3fff,2,4,7fff,,",
+ "umts":
"AT^SYSCFGEX=\\\"02\\\",3fff,2,4,7fff,,",
+ "gsm":
"AT^SYSCFGEX=\\\"01\\\",3fff,2,4,7fff,,",
+ "auto":
"AT^SYSCFGEX=\\\"00\\\",3fff,2,4,7fff,,"
+ },
+ "connect":
"AT^NDISDUP=1,1,\\\"${apn}\\\"${username:+,\\\"$username\\\"}${password:+,\\\"$password\\\"}${auth:+,$auth}",
+ "disconnect": "AT^NDISDUP=1,0"
+ },
+ "SAMSUNG": {
+ "initialize": [
+ "AT",
+ "AT+CGREG=2",
+ "AT+CFUN=5",
+ "AT+MODESELECT=3",
+ "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\""
+ ],
+ "modes": {
+ "umts": "AT+CHANGEALLPATH=1"
+ },
+ "connect": "AT+CGATT=1",
+ "disconnect": "AT+CGATT=0"
+ },
+ "Sony": {
+ "initialize": [
+ "AT+CFUN=1",
+ "AT+CGDCONT=1,\\\"IP\\\",\\\"${apn}\\\"",
+
"AT*EIAAUW=1,1,\\\"${username}\\\",\\\"${password}\\\",${auth:-00111}"
+ ],
+ "modes": {
+ "umts": "AT+CFUN=6",
+ "gsm": "AT+CFUN=5"
+ },
+ "connect": "AT*ENAP=1,1",
+ "disconnect": "AT*ENAP=0"
+ }
+}
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
new file mode 100644
index 000..14e421f
--- /dev/null
+++ b/package/network/utils
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On 08/10/2014 11:46, Robert P. J. Day wrote: > > at this point, i have to run off for the day where i will be > unable to reply to emails, but i'll still be able to read this > list. given that i did a build and have, among other things, a > squashfs image named: > > openwrt-ramips-mt7620a-mt7620a_mt7610e-squashfs-sysupgrade.bin try building an initramfs image and boot it using option 1) in the uboot menu. > > i'm tempted to simply reflash this board and take my chances. feel > free to give me any other advice. and thanks muchly for the info > so far. as a reminder, i documented a bunch of board info here: > > http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora > > if there's any other info that would be useful to add to that > page, let me know and i can do that. > > rday > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
at this point, i have to run off for the day where i will be unable to reply to emails, but i'll still be able to read this list. given that i did a build and have, among other things, a squashfs image named: openwrt-ramips-mt7620a-mt7620a_mt7610e-squashfs-sysupgrade.bin i'm tempted to simply reflash this board and take my chances. feel free to give me any other advice. and thanks muchly for the info so far. as a reminder, i documented a bunch of board info here: http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora if there's any other info that would be useful to add to that page, let me know and i can do that. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Wed, 8 Oct 2014, Arjen de Korte wrote: > Citeren "Robert P. J. Day" : > > >On Wed, 8 Oct 2014, Arjen de Korte wrote: > > > > >Citeren "Robert P. J. Day" : > > > > > > >On Tue, 7 Oct 2014, Aaron Z wrote: > > > > > > > > >On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day > > > > > > > > > >wrote: > > > > > > finally, given that this board looks like *someone's* dev board, > > > > > > would anyone know where it might have come from? there's no > > > > > > manufacturer name on it anywhere. in the ramips dts file > > > > > > MT7620a.dts, > > > > > > i can see a reference to a "Ralink MT7620a + MT7610e evaluation > > > > > > board". might that be it? i'd post a pic but i signed an NDA, > > > > > > although > > > > > > since no one has any idea where the board came from, i'm not sure > > > > > > what > > > > > > i'd be disclosing by posting a pic. > > > > > > > > > > > > i'm open to any information i can get, particularly support for > > > > > > that > > > > > > MT7610EN radio chip. thanks muchly. > > > > >Any chance that it has an FCC ID, chip model numbers or other > > > > >regulatory body unique number on it that you could share? > > > > >I realize that you are in Canada and its a off brand board but you > > > > >never know, the OEM might have used the same FCC number when they > > > > >cloned the board... > > > > > > > > ah, just noticed that /proc/cpuinfo identifies this as a "HiWiFi JI2 > > > >Board", whatever the heck that is. google is not being particularly > > > >helpful. > > > > > > > >rday > > > > > > > >p.s. just for the heck of it, i started a wiki page and recorded a > > > >bunch of board info: > > > > > > > >http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora > > > > > >Looking at the image posted earlier, it has several approval > > >markings, so that I wouldn't expect this to be a development board > > >(you don't spend time and money on approvals for development > > >boards). Isn't this just the internals of the Pandora's Hope router > > >(Pro version) marketed by http://www.cleanrouter.com/? The > > >screenshots from the manual on their site seem to confirm that it is > > >running some version of OpenWRT. > > > > i'm looking at this page: > > > >http://www.cleanrouter.com/home/product > > > >and the processor is shown as an atheros AR7161, though. also, the > >pandoras hope router apparently has 4 wired ports, and this board has > >only two. at the risk of abusing this mailing list a bit more, i took > >a pic of the top of the board and attached it, if that helps. > > Nevermind my babbling. You probably have a Baidu PandoraBox device in your > hands. i'd already run across references to that, eg, here: https://forum.openwrt.org/viewtopic.php?id=49938 but that page refers to a MT7620N, whereas my board has a MT7620A, but perhaps it's just a variation. i will keep reading ... rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
Am 08.10.2014 um 07:07 schrieb Justin Vallon:
> On 10/7/14 8:46 PM, Aaron Z wrote:
>> On Tue, Oct 7, 2014 at 7:02 PM, Justin Vallon wrote:
>>> So either:
>>>
>>> 1) The dhcp hostname option should be blank to indicate no default value
>>> (maintain current behavior)
>>> 2) When udhcpc is invoked, it should pass "-H $(hostname)" in case of
>>> default (make backend behave as Luci implies)
>>> IMO: I find it nice that many hosts pass their hostname automatically,
>>> so that the DHCP active lease list is useful, versus a lot of "?"
>>> entries and ethernet addresses. So, I would vote for 2.
>>> Opinions? Where would this bug get posted? (wiki.openwrt.org is down,
>>> so I cannot check the wiki)
>> The wiki is working for me now... That info is stored on a per
>> interface basis in /etc/config/network (see Link[1]) and is not set by
>> default, although it may pull from /etc/config/system (see Link[2]) if
>> unset in /etc/config/network.
>> The default value in /etc/config/system is 'OpenWrt'
>>
>> Link[1]: http://wiki.openwrt.org/doc/uci/network#protocol.dhcp
>> Link[2]: http://wiki.openwrt.org/doc/uci/system
>>
> The docs for uci network.${iface}.hostname say that there is no default
> hostname submitted in the DHCP request. However, Luci seems to imply
> that the default is $HOSTNAME because it shows $HOSTNAME if the field is
> unset. Your guess ("it may pull from ...") appears to be incorrect, and
> is/was my confusion as well.
>
> Fixing Luci would seem to be straightforward (default is ""). Fixing
> the backend (default is "$HOSTNAME") would be a change of behavior. I
> will look into both options.
>
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
Inside
[buildroot]/feeds/luci/modules/base/luasrc/model/cbi/admin_network/proto_dhcp.lua
you find the definition hostname.placeholder = luci.sys.hostname().
It's not "default" so its never written/used to configuration.
>From the LuCI point of view placeholder is a sample. (light grey)
If it's a default (also used be the system behind LuCI) then its written into
the field as if the user write something into the field.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Default dhcp (client) hostname is unset - Luci implies $(hostname)
Hi, I think there are two problems which prevented any definitive decision so far: 1) Some DHCP servers (cable modems, etc.) have problems with clients sending any hostname 2) As soon as we treat an empty hostname as defaulting to /proc/sys/kernel/hostname we have no clean way to express "send no hostname" anymore. Picking values like "none" for that will not work as these are valid hostnames too. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
Citeren "Robert P. J. Day" : On Wed, 8 Oct 2014, Arjen de Korte wrote: Citeren "Robert P. J. Day" : >On Tue, 7 Oct 2014, Aaron Z wrote: > > >On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day > >wrote: > > > finally, given that this board looks like *someone's* dev board, > > > would anyone know where it might have come from? there's no > > > manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, > > > i can see a reference to a "Ralink MT7620a + MT7610e evaluation > > > board". might that be it? i'd post a pic but i signed an NDA, although > > > since no one has any idea where the board came from, i'm not sure what > > > i'd be disclosing by posting a pic. > > > > > > i'm open to any information i can get, particularly support for that > > > MT7610EN radio chip. thanks muchly. > >Any chance that it has an FCC ID, chip model numbers or other > >regulatory body unique number on it that you could share? > >I realize that you are in Canada and its a off brand board but you > >never know, the OEM might have used the same FCC number when they > >cloned the board... > > ah, just noticed that /proc/cpuinfo identifies this as a "HiWiFi JI2 >Board", whatever the heck that is. google is not being particularly >helpful. > >rday > >p.s. just for the heck of it, i started a wiki page and recorded a >bunch of board info: > >http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora Looking at the image posted earlier, it has several approval markings, so that I wouldn't expect this to be a development board (you don't spend time and money on approvals for development boards). Isn't this just the internals of the Pandora's Hope router (Pro version) marketed by http://www.cleanrouter.com/? The screenshots from the manual on their site seem to confirm that it is running some version of OpenWRT. i'm looking at this page: http://www.cleanrouter.com/home/product and the processor is shown as an atheros AR7161, though. also, the pandoras hope router apparently has 4 wired ports, and this board has only two. at the risk of abusing this mailing list a bit more, i took a pic of the top of the board and attached it, if that helps. Nevermind my babbling. You probably have a Baidu PandoraBox device in your hands. Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday smime.p7s Description: S/MIME Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
Citeren "Robert P. J. Day" : On Tue, 7 Oct 2014, Aaron Z wrote: On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day wrote: > finally, given that this board looks like *someone's* dev board, > would anyone know where it might have come from? there's no > manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, > i can see a reference to a "Ralink MT7620a + MT7610e evaluation > board". might that be it? i'd post a pic but i signed an NDA, although > since no one has any idea where the board came from, i'm not sure what > i'd be disclosing by posting a pic. > > i'm open to any information i can get, particularly support for that > MT7610EN radio chip. thanks muchly. Any chance that it has an FCC ID, chip model numbers or other regulatory body unique number on it that you could share? I realize that you are in Canada and its a off brand board but you never know, the OEM might have used the same FCC number when they cloned the board... ah, just noticed that /proc/cpuinfo identifies this as a "HiWiFi JI2 Board", whatever the heck that is. google is not being particularly helpful. rday p.s. just for the heck of it, i started a wiki page and recorded a bunch of board info: http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora Looking at the image posted earlier, it has several approval markings, so that I wouldn't expect this to be a development board (you don't spend time and money on approvals for development boards). Isn't this just the internals of the Pandora's Hope router (Pro version) marketed by http://www.cleanrouter.com/? The screenshots from the manual on their site seem to confirm that it is running some version of OpenWRT. Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel smime.p7s Description: S/MIME Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] desperately seeking info on this weird MT7620A/MT7610EN dev board
On Tue, 7 Oct 2014, Aaron Z wrote: > On Tue, Oct 7, 2014 at 7:06 PM, Robert P. J. Day > wrote: > > finally, given that this board looks like *someone's* dev board, > > would anyone know where it might have come from? there's no > > manufacturer name on it anywhere. in the ramips dts file MT7620a.dts, > > i can see a reference to a "Ralink MT7620a + MT7610e evaluation > > board". might that be it? i'd post a pic but i signed an NDA, although > > since no one has any idea where the board came from, i'm not sure what > > i'd be disclosing by posting a pic. > > > > i'm open to any information i can get, particularly support for that > > MT7610EN radio chip. thanks muchly. > Any chance that it has an FCC ID, chip model numbers or other > regulatory body unique number on it that you could share? > I realize that you are in Canada and its a off brand board but you > never know, the OEM might have used the same FCC number when they > cloned the board... ah, just noticed that /proc/cpuinfo identifies this as a "HiWiFi JI2 Board", whatever the heck that is. google is not being particularly helpful. rday p.s. just for the heck of it, i started a wiki page and recorded a bunch of board info: http://www.crashcourse.ca/wiki/index.php/OpenWrt_Pandora -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
