Re: [OpenWrt-Devel] Open source open process
Apparently yes, Bruno. Just asking for more communication while at the same time even commending the devs for their hard work, as Etienne did, seems to justify being insulted. Personal sensibilities aside this has been a bone of contention for a long time. Here just a couple of examples: https://lists.openwrt.org/pipermail/openwrt-devel/2012-August/016427.html https://forum.openwrt.org/viewtopic.php?id=27466 Sadly, immature responses like the one to Etienne's simple request puts a sour note on this otherwise great project. On 2 October 2014 22:06, Bruno Randolf b...@thinktube.com wrote: Hi all, While we all agree that the OpenWRT core developers are doing great work, are really busy, and sometimes it's more important to fix a bug that to send an email, I think Etienne raises a valid point here: communication could be better and the project management could be more open... For example, I did not know that BB-final binaries have been online for over a day... is it really too much to ask to send a short note about a major release to the mailing list? bruno On 10/02/2014 05:51 AM, John Crispin wrote: nice rant, what happened at mignight that you got so angry that you feel you needed to vent it out on us ? i would like to point out that the BB-final binaries have been online for over a day. currently the root filesystems only hold a opkg.conf with base and luci. last night we regenerated the files so that the opkg.conf holds all feeds. while you were busy farting we were busy working. but thanks for the nice mail. On 01/10/2014 23:59, Etienne Champetier wrote: Hi, OpenWRT is a wonderfull piece of open source code, and it would be really great if the project management could be as open as the code. BB should be out now but for an unknow reason, it's not, and it's frustating. If some feature are missing, let people know. If some bugs need to be killed, let the community help. If buildbots are broken, let someone provide new ones. Open a TODO list on an etherpad, involve people. Whatever the reasons are, i'm sure some people can help. When you open the process, you get more work done (see new packages feed). Please communicate!!! Thanks Etienne ___ 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 mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Open source open process
Really, John? Personal insults through direct emails? On 2 October 2014 18:14, John Crispin blo...@openwrt.org wrote: until now i considered you one of the reliable crowd and just reasserted to yet another troll On 02/10/2014 07:01, Hanno Schupp wrote: I think this is his point, mate: You work hard (in isolation), but don't communicate. If you want to avoid emails that smell like farts to you, why not tell people what's going on? On 2 October 2014 17:51, John Crispin blo...@openwrt.org mailto:blo...@openwrt.org wrote: nice rant, what happened at mignight that you got so angry that you feel you needed to vent it out on us ? i would like to point out that the BB-final binaries have been online for over a day. currently the root filesystems only hold a opkg.conf with base and luci. last night we regenerated the files so that the opkg.conf holds all feeds. while you were busy farting we were busy working. but thanks for the nice mail. On 01/10/2014 23:59, Etienne Champetier wrote: Hi, OpenWRT is a wonderfull piece of open source code, and it would be really great if the project management could be as open as the code. BB should be out now but for an unknow reason, it's not, and it's frustating. If some feature are missing, let people know. If some bugs need to be killed, let the community help. If buildbots are broken, let someone provide new ones. Open a TODO list on an etherpad, involve people. Whatever the reasons are, i'm sure some people can help. When you open the process, you get more work done (see new packages feed). Please communicate!!! Thanks Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto: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
Re: [OpenWrt-Devel] Uboot 1.3.3 issues on Ralink rt3052 based Skyline SL-R7205 Wireless 3G Router
On 16/01/2014, at 9:43 pm, Michel Stempin michel.stem...@wanadoo.fr wrote: Hi Hanno, Le 16/01/2014 04:18, Hanno Schupp a écrit : Thank you John and Michel for taking the time to explain. Much appreciated. Based on your comments and some research I found a resolution to the issue that in the end is quite simple. Glad you found a solution to your problem! Whether the Ralink extension of UBoot is hackish or not Is not for me to judge but in their defense the issue of the leaking switch during bootloader processing is well covered by them. There is a compile option to lock down the switch during bootloader startup, which, when activated, does exactly what it should so the issue I observed does not occur. I quote: The switch operates in dump switch mode by default when the board powers up. It will cause the clients on the LAN site get the dynamic ip address from the remote DHCP server connected to WAN port. Set LAN/WAN Partition to avoid the Client’s DHCP request forwarded to the WAN side. I simply downloaded the SDK, compiled the bootloader with the parameters shown during the boot process with the default bootloader the manufacturer delivers (plus the switch lock down of course), upload and flash the bootloader with a serial cable and that's that. Not exactly rocket science once I understood what a bootloader actually is and does - thanks again for your guidance. So the issue is not really with Ralink but rather with the device manufacturer who compiles and deploys an inadequately configured Ralink UBoot version. Unfortunately, this is often the case, and probably the reason why John refuses to take this burden on his shoulders. I hear what you say, but OpenWrt is already supplying bootloaders as part of the buildroot process for other platforms, most notably ar71xx. So why not for ramips? From the outside it seems there seems to be no better reason than individual dev's own choice. Happy to be educated otherwise. I can say that with the self-compiled bootloader switch leaking does no longer occur during bootloader processing. Can you be more explicit on what you did, like the exact SDK package you started from, and the name of the parameter you modified? This can be helpful to others having the same problem. I intend to update the wiki accordingly with all details. It struck me that there is no obvious good place to do this though. The bootloader pages in the wiki are too generic, but the device specific page is too specific as what I am showing can be used for any rt3052 based device with such a problem. We do not seem to have platform based pages e.g. ramips, ar71xx, x86 etc. Any suggestions welcome. I found though on AA that about half the time during OpenWrt boot process a leak would occur around the time of network initialisation; the behaviour was not consistent, exactly 50/50 in a dozen boot tests including full power down. On trunk with this patch https://dev.openwrt.org/attachment/ticket/14156/0300-NET-MIPS-rt3052-boot-switch.patch the issue of OpenWrt leaking during boot up did not occur once in a dozen boot ups. I have not tested trunk without that patch, but if trunk without the patch behaves like AA I will submit it formally for your consideration. Is this happening in BB HEAD too? As I said, I will compile BB without the patch and retest and submit the patch if it is proven to be useful. On Wednesday, 15 January 2014, John Crispin wrote: Hi, So what uboot bootloader version am I supposed to use for rt350x? Is the standard Uboot Version for MIPS going to work? And which one? John seemed to be aware of the bug but which UBoot version is the bug actually fixed in? it is not a uboot bug but a bug caused by ralinks hackish esw driver not setting up the vlans properly. this has existed in every sdk uboot they ever released. fixing it involves getting the source of the uboot on your device and then recompiling from scratch with a newly made fix for the issue. it is most likely a matter of a few hours. however i would rather walk through hell and back than explain people how to reflash their bootloader. people would only start to try and find random bootloader blobs and flash them on random boards (that is what you are trying to do) and will brick their boards on the way and then come asking us how to fix it. openwrt has no plans to get involved in building and redistributing ralink uboot trees/blobs because of those reasons John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org javascript:; 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 --- Ce
Re: [OpenWrt-Devel] Uboot 1.3.3 issues on Ralink rt3052 based Skyline SL-R7205 Wireless 3G Router
Thank you John and Michel for taking the time to explain. Much appreciated. Based on your comments and some research I found a resolution to the issue that in the end is quite simple. Whether the Ralink extension of UBoot is hackish or not Is not for me to judge but in their defense the issue of the leaking switch during bootloader processing is well covered by them. There is a compile option to lock down the switch during bootloader startup, which, when activated, does exactly what it should so the issue I observed does not occur. I quote: The switch operates in dump switch mode by default when the board powers up. It will cause the clients on the LAN site get the dynamic ip address from the remote DHCP server connected to WAN port. Set LAN/WAN Partition to avoid the Client’s DHCP request forwarded to the WAN side. I simply downloaded the SDK, compiled the bootloader with the parameters shown during the boot process with the default bootloader the manufacturer delivers (plus the switch lock down of course), upload and flash the bootloader with a serial cable and that's that. Not exactly rocket science once I understood what a bootloader actually is and does - thanks again for your guidance. So the issue is not really with Ralink but rather with the device manufacturer who compiles and deploys an inadequately configured Ralink UBoot version. I can say that with the self-compiled bootloader switch leaking does no longer occur during bootloader processing. I found though on AA that about half the time during OpenWrt boot process a leak would occur around the time of network initialisation; the behaviour was not consistent, exactly 50/50 in a dozen boot tests including full power down. On trunk with this patch https://dev.openwrt.org/attachment/ticket/14156/0300-NET-MIPS-rt3052-boot-switch.patch the issue of OpenWrt leaking during boot up did not occur once in a dozen boot ups. I have not tested trunk without that patch, but if trunk without the patch behaves like AA I will submit it formally for your consideration. On Wednesday, 15 January 2014, John Crispin wrote: Hi, So what uboot bootloader version am I supposed to use for rt350x? Is the standard Uboot Version for MIPS going to work? And which one? John seemed to be aware of the bug but which UBoot version is the bug actually fixed in? it is not a uboot bug but a bug caused by ralinks hackish esw driver not setting up the vlans properly. this has existed in every sdk uboot they ever released. fixing it involves getting the source of the uboot on your device and then recompiling from scratch with a newly made fix for the issue. it is most likely a matter of a few hours. however i would rather walk through hell and back than explain people how to reflash their bootloader. people would only start to try and find random bootloader blobs and flash them on random boards (that is what you are trying to do) and will brick their boards on the way and then come asking us how to fix it. openwrt has no plans to get involved in building and redistributing ralink uboot trees/blobs because of those reasons John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org javascript:; 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] Uboot 1.3.3 issues on Ralink rt3052 based Skyline SL-R7205 Wireless 3G Router
... which is why I would have been happy to ignore their 'restriction' in relation to Uboot as it simply cannot apply to the Uboot part of their SDK. I understand that the link to the SDK I gave is based on UBoot 1.1.3, but I would have thought that Ralink themselves would have done something to fix the issue from their Ralink 3.3 version of Uboot to their version 4.0. OK, I take your counsel that this is not the case, but despite searching far and wide I am still not closer to an answer to my question as to what to do and what to compile. The email you posted earlier in reply to my original email, thank you very much for that, references the Ralink 3.3 ASoC SDK (Ralink_ApSoC_SDK_3301.tar.bz2) which itself is based on the UBoot 1.1.3. so if you say do not use the Wive Uboot version because it is based on UBoot 1.1.3' what is the relevance if the Ralink Uboot version 3.3, which is based on Uboot 1.1.3 just the same? So what uboot bootloader version am I supposed to use for rt350x? Is the standard Uboot Version for MIPS going to work? And which one? John seemed to be aware of the bug but which UBoot version is the bug actually fixed in? As you can probably tell I am not used to deal with bootloaders. Maybe I am overcomplicating things or do not see the wood for the trees but I am left none the wiser as to what to do to upgrade the bootloader on this rt305x device so that there is no leakage of network traffic during boot. On 14/01/2014, at 7:38 pm, Michel Stempin michel.stem...@wanadoo.fr wrote: There is no hard work there at all. From commit messages: Uboot: up from 3.4.0.0 sdk and fix mtd map. So this is just a fresher Ralink SDK 3.4.0 modified U-Boot, still based on the old U-Boot 1.1.3 version. And the Wive license is a pure abuse, since U-Boot is covered by the GPL, which prevents from adding any restriction on the source distribution: WIVE FIRMWARE FREE ONLY FOR NOT COMMERCIAL (INDIVIDUAL) USE. Conditions of commercial use (include preinstall, rebranding and others) are discussed individually by e-mail. -- Michel Le 14/01/2014 00:06, Hanno Schupp a écrit : Somebody seems to have done all the hard work already merging Ralink I boot modifications back into uboot bootloader code for the rt2880/rt305x platform: https://gitorious.org/wive-rtnl-ralink-rt305x-routers-firmware/wive-rtnl-ralink-rt305x-routers-firmware/source/e568932211ea59ff3b09bf2839859de3eb5502f7:Uboot Does that look like the right approach and might that bootloader work? Your thoughts? On 13/01/2014, at 11:52 pm, Michel Stempin michel.stem...@wanadoo.fr wrote: Ralink_ApSoC_SDK_3301.tar.bz2 ___ 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] Uboot 1.3.3 issues on Ralink rt3052 based Skyline SL-R7205 Wireless 3G Router
I am working on improved support for the Skyline SL-R7205 Wireless 3G Router (hence my previously submitted patches)but have struck a dead end on a particular issue. I found that during boot the device acts like dumb switch, allowing traffic to pass through for a short time. I attached serial cable and I have looked at the dhcp traffic using tcpdump in relation to the boot process, and found that right at the beginning of the UBoot managed boot process my PC send DHCP request, which pass through the Skylink router and are responded to by my ADSL modem. This occurs while UBOOT is in control of the boot process, way before even the kernel has been unpacked and OpenWrt begins to boot. The version used of UBoot is '1.1.3 (Apr 29 2009 - 12:08:28)', which is almost 5 years old. Strangely the boot process then states a few lines down that it is 'Ralink UBoot Version: 3.3'. I am not clear what that means in relation to the UBoot version number. Does anyone know whether the traffic leakage during early boot process before firmware booting a common know issue of UBoot ON RALINK/MIPS that has since been addressed? In any case, I would like to replace the bootloader with a more current version, but do not know what version I should use nor how that is done. Yes, I have googled for some hints, but have not found a meaningful how-to that would apply to Ralink. Does anyone have any pointers or advice? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Uboot 1.3.3 issues on Ralink rt3052 based Skyline SL-R7205 Wireless 3G Router
Thank you for the quick reply. What uboot version should I use? Are there recompiled binaries somewhere that would be suitable? Is it just a matter of uploading a new boot loader file using the uboot menu or is additional configuration of environment variables required? Sorry to pester with questions about that but wiki and forum are silent about the specifics around this. On 13/01/2014, at 11:50 pm, John Crispin j...@phrozen.org wrote: Am 1/13/14 11:39 AM, schrieb Hanno Schupp: I am working on improved support for the Skyline SL-R7205 Wireless 3G Router (hence my previously submitted patches)but have struck a dead end on a particular issue. I found that during boot the device acts like dumb switch, allowing traffic to pass through for a short time. I attached serial cable and I have looked at the dhcp traffic using tcpdump in relation to the boot process, and found that right at the beginning of the UBoot managed boot process my PC send DHCP request, which pass through the Skylink router and are responded to by my ADSL modem. This occurs while UBOOT is in control of the boot process, way before even the kernel has been unpacked and OpenWrt begins to boot. The version used of UBoot is '1.1.3 (Apr 29 2009 - 12:08:28)', which is almost 5 years old. Strangely the boot process then states a few lines down that it is 'Ralink UBoot Version: 3.3'. I am not clear what that means in relation to the UBoot version number. Does anyone know whether the traffic leakage during early boot process before firmware booting a common know issue of UBoot ON RALINK/MIPS that has since been addressed? In any case, I would like to replace the bootloader with a more current version, but do not know what version I should use nor how that is done. Yes, I have googled for some hints, but have not found a meaningful how-to that would apply to Ralink. Does anyone have any pointers or advice? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel known issue :) you need to update your uboot. this is due to a bas switch config during boot John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Booting x86 from SATA drive
Hi, I have a fit-pc2-i http://www.fit-pc.com/web/fit-pc/fit-pc2-i/ with a ADATA 32GB SSD w/ a SATA interface drive built in. Kamikaze boots fine and from scratch, but neither backfire nor attitude adjustment. For them the boot process stops while waiting for root device /dev/sda2 in both cases. I assume I need to include some additional modules in my firmware, but am unsure which ones and at which level: Can I compile kernel modules kmod* into the image and expect it to work? I thought that kmod models were stored in rootfs and since the system fails to boot before it can even find rootfs. If my assumption is correct I have to compile support directly into the kernel using make kernel_menuconfig Is that correct? And if so, what do i have to include when configuring make kernel_menuconfig and/or make menuconfig to get SATA drive to be recognised as initial and only rootfs? I consulted the extroot page in wiki, but I understand that approach relies on an initial rootfs in the device's flash drive to be present, which then writes its /overlay or / to the external storage; this is not what happens with this fit-pc2-I, which has no flash drive but but only he SATA drive. Any help and pointers on how to build such a x86 image is appreciated. Thanks Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 001/005][ar71xx] Add Kernel support for MR3420v2
Could this be back ported to AA?
Kind Regards
Hanno Schupp
On 11/03/2013, at 8:23 AM, Dmytro dioptimi...@gmail.com wrote:
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c(revision
35934)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v8.c(working
copy)
@@ -1,5 +1,5 @@
/*
- * TP-LINK TL-WR841N/ND v8 board support
+ * TP-LINK TL-WR841N/ND v8/TL-MR3420 v2 board support
*
* Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
*
@@ -8,6 +8,7 @@
* by the Free Software Foundation.
*/
+#include linux/gpio.h
#include linux/platform_device.h
#include asm/mach-ath79/ath79.h
@@ -18,6 +19,7 @@
#include dev-gpio-buttons.h
#include dev-leds-gpio.h
#include dev-m25p80.h
+#include dev-usb.h
#include dev-wmac.h
#include machtypes.h
@@ -31,8 +33,11 @@
#define TL_WR841NV8_GPIO_LED_SYSTEM14
#define TL_WR841NV8_GPIO_BTN_RESET17
-#define TL_WR841NV8_GPIO_SW_RFKILL16
+#define TL_WR841NV8_GPIO_SW_RFKILL16/* WPS for MR3420 v2 */
+#define TL_MR3420V2_GPIO_LED_3G11
+#define TL_MR3420V2_GPIO_USB_POWER4
+
#define TL_WR841NV8_KEYS_POLL_INTERVAL20/* msecs */
#define TL_WR841NV8_KEYS_DEBOUNCE_INTERVAL (3 *
TL_WR841NV8_KEYS_POLL_INTERVAL)
@@ -78,6 +83,11 @@
.name= tp-link:green:wlan,
.gpio= TL_WR841NV8_GPIO_LED_WLAN,
.active_low= 1,
+}, {
+/* the 3G LED is only present on the MR3420 v2 */
+.name= tp-link:green:3g,
+.gpio= TL_MR3420V2_GPIO_LED_3G,
+.active_low= 1,
},
};
@@ -99,24 +109,33 @@
}
};
-static void __init tl_wr841n_v8_setup(void)
+static struct gpio_keys_button tl_mr3420v2_gpio_keys[] __initdata = {
+{
+.desc= Reset button,
+.type= EV_KEY,
+.code= KEY_RESTART,
+.debounce_interval = TL_WR841NV8_KEYS_DEBOUNCE_INTERVAL,
+.gpio= TL_WR841NV8_GPIO_BTN_RESET,
+.active_low= 1,
+}, {
+.desc= WPS,
+.type= EV_KEY,
+.code= KEY_WPS_BUTTON,
+.debounce_interval = TL_WR841NV8_KEYS_DEBOUNCE_INTERVAL,
+.gpio= TL_WR841NV8_GPIO_SW_RFKILL,
+.active_low= 0,
+}
+};
+
+static void __init tl_ap123_setup(void)
{
u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
-ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr841n_v8_leds_gpio),
- tl_wr841n_v8_leds_gpio);
-
-ath79_register_gpio_keys_polled(1, TL_WR841NV8_KEYS_POLL_INTERVAL,
-ARRAY_SIZE(tl_wr841n_v8_gpio_keys),
-tl_wr841n_v8_gpio_keys);
-
ath79_register_m25p80(tl_wr841n_v8_flash_data);
ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_PHY_SWAP);
-ath79_register_mdio(1, 0x0);
-
ath79_init_mac(ath79_eth0_data.mac_addr, mac, -1);
ath79_init_mac(ath79_eth1_data.mac_addr, mac, 0);
@@ -135,5 +154,43 @@
ath79_register_wmac(ee, mac);
}
+static void __init tl_wr841n_v8_setup(void)
+{
+tl_ap123_setup();
+
+ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr841n_v8_leds_gpio) - 1,
+ tl_wr841n_v8_leds_gpio);
+
+ath79_register_gpio_keys_polled(1, TL_WR841NV8_KEYS_POLL_INTERVAL,
+ARRAY_SIZE(tl_wr841n_v8_gpio_keys),
+tl_wr841n_v8_gpio_keys);
+
+ath79_register_mdio(1, 0x0);
+}
+
MIPS_MACHINE(ATH79_MACH_TL_WR841N_V8, TL-WR841N-v8, TP-LINK
TL-WR841N/ND v8,
tl_wr841n_v8_setup);
+
+static void __init tl_mr3420v2_setup(void)
+{
+tl_ap123_setup();
+
+ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr841n_v8_leds_gpio),
+tl_wr841n_v8_leds_gpio);
+
+ath79_register_gpio_keys_polled(1, TL_WR841NV8_KEYS_POLL_INTERVAL,
+ARRAY_SIZE(tl_mr3420v2_gpio_keys),
+tl_mr3420v2_gpio_keys);
+
+ath79_register_mdio(0, 0x0);
+
+/* enable power for the USB port */
+gpio_request(TL_MR3420V2_GPIO_USB_POWER, USB power);
+gpio_direction_input(TL_MR3420V2_GPIO_USB_POWER);
+
+ath79_register_usb();
+/* END for the USB port */
+}
+
+MIPS_MACHINE(ATH79_MACH_TL_MR3420_V2, TL-MR3420-v2, TP-LINK TL-MR3420 v2,
+ tl_mr3420v2_setup);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] fixes factory image creation for dir-825-c1
Can this please Nd back ported to AA? Kind Regards Hanno Schupp On 14/02/2013, at 4:26 AM, Alexander Stadler sa.open...@univie.ac.at wrote: From: Alexander Stadler sa.mailli...@univie.ac.at fix factory image creation for dir-825-c1 Signed-off-by: Alexander Stadler sa.mailli...@univie.ac.at --- diff -urN a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile --- a/target/linux/ar71xx/image/Makefile2013-02-13 15:02:30.0 +0100 +++ b/target/linux/ar71xx/image/Makefile2013-02-13 15:03:06.0 +0100 @@ -355,7 +355,7 @@ endef define Image/Build/Cameo934x -$(call Image/Build/Cameo,$(1),$(2),$(3),$(cameo934x_mtdlayout),1310720,15007744,$(4)) +$(call Image/Build/Cameo,$(1),$(2),$(3),$(cameo934x_mtdlayout),1310720,15007718,$(4)) endef define Image/Build/Cameo934x/initramfs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] fixes switch-config for dir-825-c1
Can this please be back ported to AA ? Kind Regards Hanno Schupp On 14/02/2013, at 2:33 AM, Alexander Stadler sa.open...@univie.ac.at wrote: From: Alexander Stadler sa.mailli...@univie.ac.at fix switch-config for dir-825-c1 Signed-off-by: Alexander Stadler sa.mailli...@univie.ac.at --- diff -urN a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 2013-02-13 13:59:12.0 +0100 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 2013-02-13 14:10:46.0 +0100 @@ -62,13 +62,6 @@ ucidef_add_switch_vlan switch0 1 0 1 2 3 5t ;; -dir-825-c1) -ucidef_set_interfaces_lan_wan eth0.1 eth0.2 -ucidef_add_switch switch0 1 1 -ucidef_add_switch_vlan switch0 1 0t 2 3 4 5 -ucidef_add_switch_vlan switch0 2 0t 1 -;; - nbg460n_550n_550nh) ucidef_set_interfaces_lan_wan eth0 eth1 ucidef_add_switch switch0 1 1 @@ -181,6 +174,7 @@ ucidef_add_switch_vlan switch0 1 0 1 2 3 5t ;; +dir-825-c1|\ wndr4300) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] fixes switch-config for dir-825-c1
For same of stability, that's why. Kind Regards Hanno Schupp On 14/02/2013, at 6:08 AM, Alexander Stadler sa.open...@univie.ac.at wrote: Hi! Don't know if we backport models for Attitude Adjustment? (Model not supported on attitude adjustment, so its not that specific patch alone which needs to be backported, but the whole model.) Or other question: Why don't use trunk? Alex Am 13.02.2013 17:48, schrieb Hanno Schupp: Can this please be back ported to AA ? Kind Regards Hanno Schupp On 14/02/2013, at 2:33 AM, Alexander Stadler sa.open...@univie.ac.at wrote: From: Alexander Stadler sa.mailli...@univie.ac.at fix switch-config for dir-825-c1 Signed-off-by: Alexander Stadler sa.mailli...@univie.ac.at --- diff -urN a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network --- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 2013-02-13 13:59:12.0 +0100 +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network 2013-02-13 14:10:46.0 +0100 @@ -62,13 +62,6 @@ ucidef_add_switch_vlan switch0 1 0 1 2 3 5t ;; -dir-825-c1) -ucidef_set_interfaces_lan_wan eth0.1 eth0.2 -ucidef_add_switch switch0 1 1 -ucidef_add_switch_vlan switch0 1 0t 2 3 4 5 -ucidef_add_switch_vlan switch0 2 0t 1 -;; - nbg460n_550n_550nh) ucidef_set_interfaces_lan_wan eth0 eth1 ucidef_add_switch switch0 1 1 @@ -181,6 +174,7 @@ ucidef_add_switch_vlan switch0 1 0 1 2 3 5t ;; +dir-825-c1|\ wndr4300) ucidef_set_interfaces_lan_wan eth0.1 eth0.2 ucidef_add_switch switch0 1 1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] [ar71xx] Routerboard 751 Mac Address Offset Fix
Could this be applied to AA as well, please?
On 5/02/2013, at 1:59 PM, David Hutchison dhutchi...@bluemesh.net wrote:
We utilize many Routerboard 751's and discovered that our latest batch
of RB751's would not initialize the wireless radio. We have determined
Mikrotik has changed where the mac address was located inside
hardconfig. As such we utilize routerboot_find_tag to find the
location of the mac address. We should remove
RB751_MAC_ADDRESS_OFFSET as it is ambiguous by machine manufacturing
date. The newer batch of RB751's that we received had a
RB751_MAC_ADDRESS_OFFSET 0x10.
Signed-off-by: Davey Hutchison dhutchi...@bluemesh.net
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
@@ -282,7 +282,6 @@
#define RB751_HARDCONFIG 0x1f00b000
#define RB751_HARDCONFIG_SIZE 0x1000
-#define RB751_MAC_ADDRESS_OFFSET 0xE80
static void __init rb751_wlan_setup(void)
{
@@ -290,6 +289,8 @@
struct ath9k_platform_data *wmac_data;
u16 tag_len;
u8 *tag;
+ u16 mac_len;
+ u8 *mac;
int err;
wmac_data = ap9x_pci_get_wmac_data(0);
@@ -313,8 +314,15 @@
pr_err(rb75x: unable to decode wlan eeprom data\n);
return;
}
+
+ err = routerboot_find_tag(hardconfig, RB751_HARDCONFIG_SIZE,
+ RB_ID_MAC_ADDRESS_PACK, mac, mac_len);
+ if (err) {
+ pr_err(rb75x: no mac address found\n);
+ return;
+ }
- ap91_pci_init(NULL, hardconfig + RB751_MAC_ADDRESS_OFFSET);
+ ap91_pci_init(NULL, mac);
}
static void __init rb751_setup(void)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] cloudcomputing project
Hi, Which skills or services are you looking for? Kind Regards Hanno Schupp On 1/02/2013, at 6:02 AM, Tanya Kotwall tanya.kotw...@njfeurope.com wrote: Hi all, I’m working on a cloudcomputing project for a very well funded company.. not sure if anyone’s free to take on a new project? Tanya Kotwall Senior Consultant NJF Europe Ltd Lyoner Straße 14, 60528 Frankfurt, Germany (+49) 69 6655 4248 Switchboard – Frankfurt (+49) 69 6655 4249 Fax 91-94 Saffron Hill, Clerkenwell, London, EC1N 8QP +44 (0)20 7604 Switchboard – London +44 (0)20 7625 Fax +44 (0)20 3589 3237 Direct line One Raffles Place Tower 2 #20-61, Singapore 048616 +65 6808 5656 Switchboard – Singapore +65 6338 6311 Fax image001.jpg image002.gif image003.png image004.jpg image005.jpg NJF Europe Ltd is a company registered in England Wales with Company Number 7203486. The registered office address is 91-94 Saffron Hill, Clerkenwell, London, EC1N 8QP. This e-mail contains proprietary information some or all of which may be legally privileged. It is for the intended recipient only. If an address or transmission error has misdirected this email, please notify the author by replying to this e-mail. If you are not the intended recipient you must not use, disclose, distribute, copy, print, rely on or retain this e-mail. If you receive this email in error, please contact our postmaster on +44 (0)20 7604 or e-mail i...@njfeurope.com. NJF Europe is in the business of introducing qualified candidates to potential employers. Candidates and employers must assure that trade secrets or confidential information belonging to others are not used or disclosed during interviews, new employment positions, or any other time. They also must be responsible for complying with any potentially valid covenants not to compete or other legal restrictions. They should refer all questions on these matters to their own independent legal counsel. All e-mails including CV's are subject to our standard terms and conditions of business. The acceptance of any CV's constitutes the acceptance of our standard terms and conditions of business unless there has been written prior agreement. image006.gif P Think before you print ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 1/1] atheros: Revert Add leds back after migration to sysfs
Hi Jonathan Will this fix the Engenius boot issue? Will non-Engenius still boot? And what about LEDs? Will they stop working on some or all devices? Please advise Kind Regards Hanno Schupp On 22/11/2012, at 11:29 AM, Jonathan Bither jonbit...@gmail.com wrote: Karl, I remember attitude adjustment not booting as well with flash errors, however I can try to rebuild an older backfire checkout and reflash the device to log the behavior. The revert was intended to be temporary to fix the regression with devices not booting. I plan on submitting additional patches that fix the intended behavior. Care to share the model of your device so that I may get one in to work with? Thanks, Jonathan Bither On 11/21/2012 05:02 PM, Karl P wrote: I'm still against reverting. What's really needed here is support for different atheros devices, not just outright dropping led support. Currently, the gpio setup is fixed for all devices, which clearly isn't ok. Sure, I admit that not booting your device is worse than my leds not working, but tossing it all out doesn't really seem like the right way forward. What was the backfire behaviour on your device? Ours had a working wifi light, and the gpio hasn't changed, so I'm surprised that it's only _just_ started being problems. Cheers, Karl P On 11/21/2012 09:03 PM, Jonathan Bither wrote: v2: explicitly unset CONFIG_LEDS_GPIO It causes flash access errors on devices that use a non-standard gpio line line to control the spi flash chip select. Fixes a handful of open tickets. First resolved in changeset # 16765 Signed-off-by: Jonathan Bither jonbit...@gmail.com --- target/linux/atheros/base-files/etc/uci-defaults/leds | 11 --- target/linux/atheros/config-3.3 |4 ++-- 2 files changed, 2 insertions(+), 13 deletions(-) delete mode 100644 target/linux/atheros/base-files/etc/uci-defaults/leds diff --git a/target/linux/atheros/base-files/etc/uci-defaults/leds b/target/linux/atheros/base-files/etc/uci-defaults/leds deleted file mode 100644 index 076a04b..000 --- a/target/linux/atheros/base-files/etc/uci-defaults/leds +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/sh -# Copyright 2012 OpenWrt.org -# - -. /lib/functions/uci-defaults.sh - -ucidef_set_led_netdev wlan wlan wlan wlan0 - -ucidef_commit_leds - -exit 0 diff --git a/target/linux/atheros/config-3.3 b/target/linux/atheros/config-3.3 index 9f68b4e..39d8716 100644 --- a/target/linux/atheros/config-3.3 +++ b/target/linux/atheros/config-3.3 @@ -35,7 +35,7 @@ CONFIG_GENERIC_ATOMIC64=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_GPIO=y +# CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_PCI_IOMAP=y CONFIG_GPIOLIB=y @@ -70,7 +70,7 @@ CONFIG_INITRAMFS_SOURCE= CONFIG_IP17XX_PHY=y CONFIG_IRQ_CPU=y CONFIG_IRQ_FORCED_THREADING=y -CONFIG_LEDS_GPIO=y +# CONFIG_LEDS_GPIO is not set CONFIG_MDIO_BOARDINFO=y CONFIG_MIPS=y CONFIG_MIPS_L1_CACHE_SHIFT=5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #6202: Atheros AR231x/5312: Engenius (Senao) EOC-1650 hangs after software reboot
The changes never got included but they works fine on 2.6 kernel trunk version. On trunk that means you can only go up to revision 31xxx - up until the point that atheros target was switched to 3.2 kernel. Then these changes do no longer fit and compile. And in backfire there is an earlier 2.6 kernel version which also does not work with these changes. But on the last revision of trunk that ran 2.6 for atheros the changes are working fine. -Original Message- From: OpenWrt [mailto:openwrt-devel@lists.openwrt.org] Sent: Tuesday, 5 June 2012 10:38 a.m. Cc: openwrt-tick...@lists.openwrt.org Subject: Re: [OpenWrt] #6202: Atheros AR231x/5312: Engenius (Senao) EOC-1650 hangs after software reboot #6202: Atheros AR231x/5312: Engenius (Senao) EOC-1650 hangs after software reboot ---+ ---+ Reporter: anonymous | Owner: developers Type: defect | Status: new Priority: normal | Milestone: Attitude Adjustment (trunk) Component: packages | Version: Trunk Keywords: | ---+ ---+ Comment(by nixcamic@…): I noticed that there's further discussion on this here: https://lists.openwrt.org/pipermail/openwrt- devel/2012-February/013866.html But then it just abruptly stops. Have any of these patches made it into trunk yet, or should I just compile my own image? -- Ticket URL: https://dev.openwrt.org/ticket/6202#comment:18 OpenWrt http://openwrt.org Opensource Wireless Router Technology ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCP issue on LAN after router reboot
Hi, I have tested now again with a clean image built from latest snapshot image builder and the issue definitely occurs, while other routers like TL-WR941ND or RB751G, which do not use the rtl8366rb switch are fine. I check the change log and the issue had previously been detected and fixed see https://dev.openwrt.org/ticket/6819). I suspect recent changes to the rtl8366 drivers (30842-30857) introduced this regression. I logged a ticket on https://dev.openwrt.org/ticket/11312 Kind Regards Hanno Schupp On 20/04/2012, at 10:00 AM, Hanno Schupp hanno.sch...@gmail.com wrote: Dear All, I have a curious shop issue in trunk with my tp-link wr1043nd. When I connect my pc to The router it receives a dhcp lease and ip address without issues. If I reboot the pc, the same happens, no issues. When I reboot the router however, the pc does not receive a dhcp lease from the router, it does not receive an ip address and thus fails to connect thought the router to the Internet. Even more curious: if there is a dhcp lease recorded in the modem the openwrt router is connected to, then the pc receives a dhcp lease from the modem on their ip range. Is this behaviour to be expected, a known issue? Any suggestion to debug and analyse the issue? I am at a loss. Kind Regards Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DHCP issue on LAN after router reboot
Dear All, I have a curious shop issue in trunk with my tp-link wr1043nd. When I connect my pc to The router it receives a dhcp lease and ip address without issues. If I reboot the pc, the same happens, no issues. When I reboot the router however, the pc does not receive a dhcp lease from the router, it does not receive an ip address and thus fails to connect thought the router to the Internet. Even more curious: if there is a dhcp lease recorded in the modem the openwrt router is connected to, then the pc receives a dhcp lease from the modem on their ip range. Is this behaviour to be expected, a known issue? Any suggestion to debug and analyse the issue? I am at a loss. Kind Regards Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Compile error - r31299
I am curious as I was not even aware that you could tell the compile process to use one uClib erosion or another. I thought that was fixed through the toolchain compile process. How do you get the buildroot process to use a certain uClib version then? Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 16/04/2012, at 10:18 AM, Felix Fietkau n...@openwrt.org wrote: On 2012-04-16 12:10 AM, Jim Henderson wrote: On Sun, 15 Apr 2012 23:59:15 +0200, Felix Fietkau wrote: OpenWrt has been using uClibc 0.9.33 for a while now, whereas you seem to be using 0.9.32. It looks like 0.9.33 provides that missing function. Awesome, thanks - seems the last time uClibc was updated I had a similar issue, and had forgotten about it. Will reconfigure to use the updated uClibc and let it build with that. If you want to see what changes your .config has compared to the default, just run ./scripts/diffconfig.sh - that's an easy way of spotting such issues. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Should I then? If that is what I 'should do', why does https://dev.openwrt.org/wiki/SubmittingPatches not tell me about it? On 6 April 2012 20:20, Florian Fainelli flor...@openwrt.org wrote: Hi, Le 04/05/12 23:36, Hanno Schupp a écrit : I am at a loss then what to do. I even went to the length of installing alpine on my pc just for the purpose of sending one email. Why is this so hard? This makes porting openwrt to a new router model look easy in comparison. I sent it to myself as a copy and it looked completely normal to me. Where and how can I check it got mangled and how can I avoid it getting it mangled. I followed the instructions in kernel.org for email-clients and apparently the patch still gets mangled. Argh. It is hard because you should be using git-send-email to make sure your patches are not mangled by your mailer in any form. Kind Regards Hanno On 6/04/2012, at 9:24 AM, Jo-Philipp Wichx...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It got line wrapped. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9+DYgACgkQdputYINPTPPmbgCePy75NtkXFACVcCe01xA4Go7G 9uAAn0DGSguFrkM+5U01dbltb4Yg9kbG =k+Hp -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Was that patch now received unmangled? If so, can it be applied, please? Thanks ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
I am at a loss then what to do. I even went to the length of installing alpine on my pc just for the purpose of sending one email. Why is this so hard? This makes porting openwrt to a new router model look easy in comparison. I sent it to myself as a copy and it looked completely normal to me. Where and how can I check it got mangled and how can I avoid it getting it mangled. I followed the instructions in kernel.org for email-clients and apparently the patch still gets mangled. Argh. Kind Regards Hanno On 6/04/2012, at 9:24 AM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 It got line wrapped. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9+DYgACgkQdputYINPTPPmbgCePy75NtkXFACVcCe01xA4Go7G 9uAAn0DGSguFrkM+5U01dbltb4Yg9kbG =k+Hp -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by
the router
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision 31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (working copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,88 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD 750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in) {
+ if(*in 0) {
+ int i = -*in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in++;
+ }
+ } else if(*in 0) {
+ int i = *in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac,
+ hardconfig + RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
+ sizeof(rb751_wmac_data.eeprom_data),
+ hardconfig + RB751_CALDATA_OFFSET) ==
+ sizeof(rb751_wmac_data.eeprom_data)) {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0, rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+rb751g_setup);
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 31152)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy)
@@ -250,6 +250,12 @@
*RouterBOARD 750GL)
name=rb-750gl
;;
+ *RouterBOARD 751)
+ name=rb-751
+ ;;
+ *RouterBOARD 751G)
+ name=rb-751g
+ ;;
*Rocket M)
name=rocket-m
;;
Index: target/linux/ar71xx/base-files/etc/uci-defaults/network
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/network (revision 31152)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/network (working copy)
@@ -63,6 +63,7 @@
;;
rb-750gl |\
+rb-751g |\
wzr-hp-g450h)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
ucidef_add_switch switch0 1 1
@@ -153,6 +154,7 @@
dir-615-e4 |\
ja76pf |\
rb-750 |\
+rb-751 |\
tew-632brp |\
tl-mr3220 |\
tl-mr3420 |\
___
openwrt-devel mailing list
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Apologies fr my frustrated rant ;-)
Thanks everyone for your advice.
One last try in-line. Is that any better?
Please advise
On 6 April 2012 10:01, Hanno Schupp hanno.sch...@gmail.com wrote:
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by
the router
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (working copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,88 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD 750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in) {
+ if(*in 0) {
+ int i = -*in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in++;
+ }
+ } else if(*in 0) {
+ int i = *in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac,
+ hardconfig + RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
+ sizeof(rb751_wmac_data.eeprom_data),
+ hardconfig + RB751_CALDATA_OFFSET) ==
+ sizeof(rb751_wmac_data.eeprom_data)) {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0, rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+ rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+ rb751g_setup);
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh (revision 31152)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh (working copy)
@@ -250,6 +250,12 @@
*RouterBOARD 750GL)
name=rb-750gl
;;
+ *RouterBOARD 751)
+ name=rb-751
+ ;;
+ *RouterBOARD 751G)
+ name=rb-751g
+ ;;
*Rocket M)
name=rocket-m
;;
Index: target/linux/ar71xx/base-files/etc/uci-defaults/network
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/network (revision
31152)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/network (working copy)
@@ -63,6 +63,7
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Great. Thanks. Mental note: Ctrl-R in Alpine is what made the difference. On 6 April 2012 10:02, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, this one is fine... Now we still have to wait fore gabor to review it :) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9+Fn4ACgkQdputYINPTPPd4wCfbvi6Up8VrBxC3JNZa9TG0q0p c30An0hdXrhMVGyIq3t6Y5jx+a9JYaQg =1B2j -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by
the router
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (working
copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,88 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD
750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in) {
+ if(*in 0) {
+ int i = -*in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in++;
+ }
+ } else if(*in 0) {
+ int i = *in++;
+ while(i-- 0) {
+ if(ptr = end)
+ return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac,
+ hardconfig + RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
+ sizeof(rb751_wmac_data.eeprom_data),
+ hardconfig + RB751_CALDATA_OFFSET) ==
+ sizeof(rb751_wmac_data.eeprom_data)) {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0, rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+rb751g_setup);
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 31152)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy)
@@ -250,6 +250,12 @@
*RouterBOARD 750GL)
name=rb-750gl
;;
+ *RouterBOARD 751)
+ name=rb-751
+ ;;
+ *RouterBOARD 751G)
+ name=rb-751g
+ ;;
*Rocket M)
name=rocket-m
;;
Index: target/linux/ar71xx/base-files/etc/uci-defaults/network
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/network (revision
31152)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/network (working
copy)
@@ -63,6 +63,7 @@
;;
rb-750gl |\
+rb-751g |\
wzr-hp-g450h)
ucidef_set_interfaces_lan_wan eth0.1 eth0.2
ucidef_add_switch switch0 1 1
@@ -153,6 +154,7 @@
dir-615-e4 |\
ja76pf |\
rb-750 |\
+rb-751 |\
tew-632brp |\
tl-mr3220 |\
tl-mr3420 |\
___
openwrt-devel
[OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by the
router
Signed-off-by: Hanno Schupp mailto:hanno.sch...@gmail.com
hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c(working copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,88 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD 750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in) {
+ if(*in 0) {
+ int i = -*in++;
+ while(i-- 0) {
+ if(ptr = end)
+
return -1;
+ *ptr++ =
*in++;
+ }
+ } else if(*in 0) {
+ int i = *in++;
+ while(i-- 0) {
+ if(ptr = end)
+
return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac,
+ hardconfig +
RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
+
sizeof(rb751_wmac_data.eeprom_data),
+ hardconfig +
RB751_CALDATA_OFFSET) ==
+
sizeof(rb751_wmac_data.eeprom_data)) {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0,
rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+ rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+ rb751g_setup);
Index: target/linux/ar71xx/base-files/lib/ar71xx.sh
===
--- target/linux/ar71xx/base-files/lib/ar71xx.sh (revision 31152)
+++ target/linux/ar71xx/base-files/lib/ar71xx.sh (working copy)
@@ -250,6 +250,12 @@
*RouterBOARD 750GL)
name=rb-750gl
;;
+ *RouterBOARD 751)
+ name=rb-751
+ ;;
+ *RouterBOARD 751G
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
I sent it with google mail - mangled. I sent it this time with outlook - mangled. How is one supposed to send patches to this mailing list without patches getting mangled? Please advise Kind Regards Hanno On 4/04/2012, at 8:21 AM, Vasilis Tsiligiannis b_tsiligian...@silverton.gr wrote: On Wed 04 of Apr 2012 06:42:24 Hanno Schupp wrote: Great collaboration on these two fantastic routers on the openwrt forum: https://forum.openwrt.org/viewtopic.php?id=32320 https://forum.openwrt.org/viewtopic.php?id=32320 Above all kudos to aryufan. Well done and thank you everyone else who contributed. To-Do: LED for wlan is not yet activated To-Do: TxPower over 20dBm (RB751U) or 22dBm (RB751G) are not accepted by the router Signed-off-by: Hanno Schupp mailto:hanno.sch...@gmail.com hanno.sch...@gmail.com Hi Hanno, the patch you have submitted seems somehow mangled. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Hi, can we get this applied please, before it goes stale?
Thanks
On 31 March 2012 23:22, Hanno Schupp hanno.sch...@gmail.com wrote:
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (working copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,91 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD 750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in)
+ {
+ if(*in 0)
+ {
+ int i = -*in++;
+ while(i-- 0)
+ {
+ if(ptr = end)
+
return -1;
+ *ptr++ =
*in++;
+ }
+ }
+ else if(*in 0)
+ {
+ int i = *in++;
+ while(i-- 0)
+ {
+ if(ptr = end)
+
return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac, hardconfig +
RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
sizeof(rb751_wmac_data.eeprom_data), hardconfig + RB751_CALDATA_OFFSET) ==
sizeof(rb751_wmac_data.eeprom_data))
+ {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0,
rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+ rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+ rb751g_setup);
Index: target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
===
---
target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
(revision 0)
+++ target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
(revision 0)
@@ -0,0 +1,11 @@
+--- a/arch/mips/ath79
[OpenWrt-Devel] [PATCH] Initial support for Mikrotik RB751G-2HnD and RB751U-2HnD
Great collaboration on these two fantastic routers on the openwrt forum:
https://forum.openwrt.org/viewtopic.php?id=32320
Above all kudos to aryufan. Well done and thank you everyone else who
contributed.
To-Do: LED for wlan is not yet activated
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c (revision
31152)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-rb750.c(working copy)
@@ -9,17 +9,24 @@
*/
#include linux/export.h
+#include linux/pci.h
+#include linux/ath9k_platform.h
#include linux/platform_device.h
#include linux/phy.h
#include linux/ar8216_platform.h
#include asm/mach-ath79/ar71xx_regs.h
#include asm/mach-ath79/ath79.h
+#include asm/mach-ath79/pci.h
+#include asm/mach-ath79/irq.h
#include asm/mach-ath79/mach-rb750.h
#include common.h
+#include dev-usb.h
#include dev-eth.h
#include machtypes.h
+#include pci-ath9k-fixup.h
+#include pci.h
static struct rb750_led_data rb750_leds[] = {
{
@@ -270,3 +277,91 @@
MIPS_MACHINE(ATH79_MACH_RB_750G_R3, 750Gr3, MikroTik RouterBOARD 750GL,
rb750gr3_setup);
+
+static struct ath9k_platform_data rb751_wmac_data = {
+ .led_pin = -1,
+};
+
+static u8 rb751_wmac_mac[6];
+
+static int rb751_pci_plat_dev_init(struct pci_dev *dev)
+{
+ switch (PCI_SLOT(dev-devfn)) {
+ case 0:
+ dev-dev.platform_data = rb751_wmac_data;
+ break;
+ }
+
+ return 0;
+}
+
+static int decode_rle(char* output, int len, char* in)
+{
+ char* ptr = output;
+ char* end = output + len;
+ while(*in)
+ {
+ if(*in 0)
+ {
+ int i = -*in++;
+ while(i-- 0)
+ {
+ if(ptr = end)
+
return -1;
+ *ptr++ =
*in++;
+ }
+ }
+ else if(*in 0)
+ {
+ int i = *in++;
+ while(i-- 0)
+ {
+ if(ptr = end)
+
return -1;
+ *ptr++ = *in;
+ }
+ in++;
+ }
+ }
+ return ptr - output;
+}
+
+#define RB751_HARDCONFIG 0x1f00b000
+#define RB751_MAC_ADDRESS_OFFSET 0xE80
+#define RB751_CALDATA_OFFSET 0x27C
+
+static void __init rb751_wlan_and_usb_setup(void)
+{
+ u8 *hardconfig = (u8 *) KSEG1ADDR(RB751_HARDCONFIG);
+
+ ath79_register_usb();
+
+ ath79_pci_set_plat_dev_init(rb751_pci_plat_dev_init);
+ ath79_register_pci();
+
+ rb751_wmac_data.macaddr = memcpy(rb751_wmac_mac, hardconfig +
RB751_MAC_ADDRESS_OFFSET, 6);
+
+ if(decode_rle((char*)rb751_wmac_data.eeprom_data,
sizeof(rb751_wmac_data.eeprom_data), hardconfig + RB751_CALDATA_OFFSET) ==
sizeof(rb751_wmac_data.eeprom_data))
+ {
+ pr_info(rb7xx: calibration data found\n);
+ pci_enable_ath9k_fixup(0,
rb751_wmac_data.eeprom_data);
+ }
+}
+
+static void __init rb751_setup(void)
+{
+ rb750_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751, 751, MikroTik RouterBOARD 751,
+ rb751_setup);
+
+static void __init rb751g_setup(void)
+{
+ rb750gr3_setup();
+ rb751_wlan_and_usb_setup();
+}
+
+MIPS_MACHINE(ATH79_MACH_RB_751G, 751g, MikroTik RouterBOARD 751G,
+ rb751g_setup);
Index: target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
===
--- target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
(revision 0)
+++ target/linux/ar71xx/patches-3.2/614-MIPS-ath79-RB751G-support.patch
(revision 0)
@@ -0,0 +1,11 @@
+--- a/arch/mips/ath79/machtypes.h
b/arch/mips/ath79/machtypes.h
+@@ -51,6 +51,8 @@ enum ath79_mach_type {
+ ATH79_MACH_RB_493G, /* Mikrotik
RouterBOARD 493G */
+ ATH79_MACH_RB_750,/* MikroTik
Re: [OpenWrt-Devel] Mikrotik Routerboard 450G - access to LAN ports broken
Just compiled 31059 and the LAN ports of the rb450g work fine again as far as I can tell. Maybe 31054 fixed it? -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Gregory Finch Sent: Saturday, 24 March 2012 11:04 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Mikrotik Routerboard 450G - access to LAN ports broken On 2012-03-23 8:13 AM, Gregory Finch wrote: On 2012-03-22 8:14 PM, Hanno Schupp wrote: My last good image is on the Mikrotik rb450g is 30857. 31037 no longer works. I have not tested in between. I suspect this is a regression from the changes introduced somewhere in 30994-31011, which extended the 8216 switch chip code (which also supports the 8316 used on the rb450g) to support 8327. I've run into the same problem with a Buffalo WZR-HP-G450H. I've gotten 30993 to work and am going to start rolling through the patches one by one to see where mine breaks today, but I have the same suspicion as you, that the problem lies in the group 30994-31011. I'll report back as soon as I find exactly where it breaks. -Greg Changeset 31028 - update linux 3.2 to 3.2.12 - this causes the problem. The switch is no longer works in my machine. swconfig can still see that a link is up or down, but that's it. Changeset 31026 may cause part of the issue too. Prior to 31026, I get the following in my logs on boot: kern.info kernel: [0.66] ag71xx_mdio: probed kern.info kernel: [0.66] eth0: Atheros AG71xx at 0xb900, irq 4 kern.info kernel: [1.24] eth0: AR8316 switch driver attached. kern.info kernel: [1.24] ar8316: Using port 4 as switch port kern.info kernel: [1.34] ag71xx ag71xx.0: eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd041, driver=Atheros AR8216/AR8236/AR8316] from 31026, I no longer get that information in the logs. I haven't had a chance to stress test it yet, so I'm not sure if there are any implications with the change. -Greg ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] @juhosg Re: 31025 - ar71xx: add initial support for RB750GL
@juhosg I tested the new support for the rb750gl that you implemented in 31025. It worked fine for me and I could not detect any anomalies. You say 'Initia;l support'; why initial? As I say, seems go to go to me. Well done and thank you. What I did notice is that the leds on the rb750 no longer work, they used to in earlier releases. Looks like a regression to me. 30994-31011 did a lot of changes to the 8216 switch family. Maybe this broke something. I had noticed previously that the 450g lan ports where broken, but seems fixed now, possibly after 31054. So maybe another small regression? The changes where quite substantial so this would not be a surprise, really. Last but not leat, as the 751G-2HnD has the same switch chip as the 750GL I tried out the new trunk version on it as well. While it took the ramdisk version of OpenWrt with no issues, the wget2nand loaded the firmware files with no issues, the 751G does not properly boot up, it does not obtain an IP address from the modem it is connected to not does it bring up the lan ports to connect to. I would love to see the 751G-2HnD and 751U-2HnD as they are such brilliant routers at the price. Happy to help with any testing I can be useful with. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Mikrotik Routerboard 450G - access to LAN ports broken
Sure, 450G is supported for a long time. No idea about the 435g, give if a try and let us know... On 23/03/2012, at 7:38 PM, Weedy weedy2...@gmail.com wrote: On 22/03/12 11:14 PM, Hanno Schupp wrote: My last good image is on the Mikrotik rb450g is 30857. 31037 no longer works. I have not tested in between. I suspect this is a regression from the changes introduced somewhere in 30994-31011, which extended the 8216 switch chip code (which also supports the 8316 used on the rb450g) to support 8327. Woah woah back the hell up. You got openwrt to boot in any shape on a rb450g? any chance that image might boot a rb435g? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] wifi detect returns nothing (openwrt trunk with RB411 R52 (lspci lists radio as AR5413 802.11abg)
You can follow the recent changes and discussions here on the developer list. The main issue seems to be how iwinfo does not recognise the physical limitations of the wifi equipment. Everything is 27dBm (possibly from CRDA database?) although in reality it is anywhere between 20dBm and 30dBm depending on the device. Note: I am told this is a limitation of the linux kernel, but I note that madwifi recognised the hardware capabilities correctly. But then again I have written a little extension that just spits out the vendor, id sub-vendor-id and sub-id into dmesg on bootup, I scrape the output and set the device accordingly using a case switch in a custom script. A hack to be sure, but I cannot understand why things are supposedly so hard; I for one do not even code in C properly, I can only write shell scripts and php code. Then the hardware offsets which are now coded into trunk in iwinfo are just simply added to the 27dBm, so you end up with non-sensical power setting and choices up to 37dBm in some cases. Then there are a few other things around the edges, like the recognistion of the Fonera and Meraki devices by MAC addess. Maybe not clean and purist, but it worked like a charm. Now Luci just looks into /proc/cpuinfo by default, which holds no good information for atheros mips devices. I have a nano2, a pico, pico2 HP, an engenius eoc-1650, a fonera plus, a fonera 2.0g, and a dir300a, so I have a reasonable cross-section for testing. And I am sorry to say that device management and power management and display currently in trunk with ath5k is a mess. I am happy to continue to test, as things change but until then I am back to backfire and madwifi. Sorry for the rant, I am grateful someone is taking an interest, and yes I know, we all do that in our spare time (me included). Cheers On 28 February 2012 09:34, Jonathan Bither jonbit...@gmail.com wrote: Hanno, Do we happen to have a list of known issues so that we can work on getting them resolved instead of reverting back to mac80211? On 02/27/2012 03:15 PM, Hanno Schupp wrote: I am not a developer, but I can tell you the ath9k is for b/g/n cards, so that may be the reason. You should use either ath5k or madwifi driver. Personally I found many issues with ath5k integration into openwrt still unresolved in terms of card and device recognition and am consequently in the process to downgrade to madwifi again. Madwifi is no longer developed by the linux open driver project as opposed to ath5k, but the focus and interest of the OpenWrt community has moved on from atheros to ar71xx architecture and thus to ath9k fair and square. As soon as trunk switched one day from madwifi to ath5k on the legacy atheros architecture I started encountering issues - but this is my experience, others may have a different view. On 28 February 2012 09:08, Brian Hutchinsonb.hutch...@gmail.com wrote: Hi, These boxes use to be working but I recently upgraded them to the latest trunk and now my wireless cards are no longer detected. No /etc/config/wireless and trying to generate the file with wifi detect does nothing. Not sure what is going on since everything looks OK. lsmod output is at the end of the email. If I recall, the last build that was working used madwifi and the version I built from trunk uses ath9k. In make menuconfig I remember there was an option for madwifi but I didn't include it as I didn't think it was needed anymore. Did I need that??? Regards, Brian root@OpenWrt:/etc/config# lsmod Module Size Used by Tainted: G ath9k 88800 0 ohci_hcd 15760 0 ledtrig_usbdev 2032 0 nf_nat_irc 784 0 nf_conntrack_irc 2464 1 nf_nat_irc nf_nat_ftp 976 0 nf_conntrack_ftp 4416 1 nf_nat_ftp ipt_MASQUERADE 976 1 iptable_nat 2112 1 nf_nat 9904 4 nf_nat_irc,nf_nat_ftp,ipt_MASQUERADE,iptable_nat xt_conntrack 2048 3 xt_CT 1216 0 xt_NOTRACK 448 0 iptable_raw 560 1 xt_state 608 0 nf_conntrack_ipv4 3872 6 iptable_nat,nf_nat nf_defrag_ipv4 624 1 nf_conntrack_ipv4 nf_conntrack 36624 12 nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4 ehci_hcd 32544 0 pppoe 7472 0 pppox 1152 1 pppoe ipt_REJECT 1808 2 xt_TCPMSS 1824 0 ipt_LOG 6048 0 xt_comment 400 0 xt_multiport 1104 0 xt_mac 528 0 xt_limit 944 1 iptable_mangle 832 1 iptable_filter 624 1 ip_tables 8864 4 iptable_nat,iptable_raw,iptable_mangle,iptable_filter xt_tcpudp 1632 3 x_tables
[OpenWrt-Devel] [PATCH] Adjust txpower offset for Nano and Picostation M2 in iwinfo
Signed-off-by: Hanno Schupp hanno.sch...@gmail.com
Index: src/iwinfo_lib.c
===
--- src/iwinfo_lib.c(revision 30668)
+++ src/iwinfo_lib.c(working copy)
@@ -350,8 +350,8 @@
{ VENDOR_UBNT, SR71, 0x168c, 0x0027, 0x0777,
0x4082, 10, 0 },
#endif
#ifdef USE_NL80211
- { VENDOR_UBNT, PicoStation M2,0x168c, 0x002a, 0x0777,
0xe302, 10, 0 }, /* ToDo: confirm offset */
- { VENDOR_UBNT, NanoStation M2,0x168c, 0x002a, 0x0777,
0xe012, 10, 0 }, /* ToDo: confirm offset */
+ { VENDOR_UBNT, PicoStation M2,0x168c, 0x002a, 0x0777,
0xe302, 12, 0 }, /* ToDo: confirm offset */
+ { VENDOR_UBNT, NanoStation M2,0x168c, 0x002a, 0x0777,
0xe012, 12, 0 }, /* ToDo: confirm offset */
{ VENDOR_UBNT, NanoStation M5,0x168c, 0x002a, 0x0777,
0xe005, 5, 0 }, /* ToDo: confirm offset */
{ VENDOR_UBNT, Bullet M2, 0x168c, 0x002a, 0x0777,
0xe202, 12, 0 },
{ VENDOR_UBNT, Bullet M5, 0x168c, 0x002a, 0x0777,
0xe805, 5, 0 },
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Routerboard 751G and 751U
There is a reasonably far advanced port to these boards on the forum, which is unfortunately based on the 2.9.36 kernel, which now has been wiped. I wanted to port this to 3.2 but cannot find machtype.h file anywhere under 3.2. Any pointers where the machine type definition went from 2.9 to 3.2? Cheers ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Support for Mikrotik 751U and 751G
To clarify : the RB750UP does have a USB port fitted, the RB 750GL does not. Both RB751U and RB751G have USB fitted. Hi this post on the forum https://forum.openwrt.org/viewtopic.php?pid=157075#p157075 describes a fairly well advanced port to these Mikrotik routers. I wanted to test the patches but could not. As 2.6.39 support, on which this port is based has been nuked a couple of weeks ago. By trial and error (I do not speak C) I might be able to transfer the patches to 3.2, however I would prefer the ar71xx maintainers (nbd?) to review the changes (links in the forum post) and apply them as appropriate, as I have some principle questions about the approach. The linked patches introduce ath9k support but not USB, which is therefore missing. The patches add 751 specific code into the 750 machine profile. Given they ate so different, should there not be a separate rb-751 profile? On a related topic, while 750 is supported, which is already retired by mikrotik, is 750GL and 750UP supported by the 750 profile? There were questions about access to the nand storage via the processor gpio pins, but this may be resolved by now? Please advise. PS: happy to supply dmesg and or EEPROM and other dumps if this is helpful. Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Tested Changeset 30605: [package] iwinfo: implement proper hardware detection for ar23xx SoC devices like the NanoStation 2
Done. Does 30dBm mean it has 10dBm power offset? Yes, the Pico 2 and 2 HP is essentially a Bullet 2 or Bullet 2 HP in a case. It even has Bullet 2 or Bullet 2 H printed on the circuitboard. Funny. Does it indeed find no IDs? In this case I'd be interested in a copy of the boardconfig partition. No, it does not yet, but it may not look for them yet either - after all there is nothing in the code for Picos until now. There is also no specific image for the Pico M created - just for Nano M, Rocket M and Bullet M. There is also no image for the Loco M created, although it would be worthwhile, as it has a different maximum power (23dBm) compared to the Nano M (28dBm), and it has only one Ethernet jack (eth0),as opposed to the Nano M, which has two (eth0 and eth1 work), but for the Nano M the default configuration in OpenWrt does not even define eth1 from the start. Something that could be fixed? On 20 February 2012 22:59, Jo-Philipp Wich x...@subsignal.org wrote: Hi. What is not so nice is the txpowerlist. As I had reported last year, the system reports 27dBm regardless which hardware is used. Thats a mac80211 problem though, beyound the scope of iwinfo. It takes the driver reported values and uses them. I can also confirm the following devices which would be nice to add to the list https://dev.openwrt.org/browser/trunk/package/iwinfo/src/iwinfo_lib.c: Ubiquiti Picostation 2: 168C:0013 0777:C302 – max 20dBm Ubiquiti Picostation 2 HP: 168C:0013 0777:C3A2 – max 30dBm Done. Does 30dBm mean it has 10dBm power offset? By the way, the susbsystem Id of the Picostation M2 is 0xe302, which would also be nice to add to the list in https://dev.openwrt.org/browser/trunk/package/iwinfo/src/iwinfo_lib.c Done. Picostation M2 [...] Hardware: unknown [Generic MAC80211] Does it indeed find no IDs? In this case I'd be interested in a copy of the boardconfig partition. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Tested Changeset 30605: [package] iwinfo: implement proper hardware detection for ar23xx SoC devices like the NanoStation 2
Was the below information helpful? Also, I have access to a variety of hardware. I am not sure how to get to the sub-vendor sub-id information on the ar71xx platform when OpenWrt is loaded. The 'lspci' command pciutils reports nothing. I got the Pico M2 value from AirOs (which is not usually loaded on the devices I have access to. Please advise. On 20 February 2012 23:46, Hanno Schupp hanno.sch...@gmail.com wrote: I assume you want mtd5: root@Router002722400:~# cat /proc/mtd dev: size erasesize name mtd0: 0004 0001 u-boot mtd1: 0001 0001 u-boot-env mtd2: 0010 0001 kernel mtd3: 0066 0001 rootfs mtd4: 0041 0001 rootfs_data mtd5: 0004 0001 cfg mtd6: 0001 0001 EEPROM mtd7: 0076 0001 firmware Here goes... On the UBNT images: I have reported the same observation a few weeks ago - with no reaction. How should to best submit the information? On 20 February 2012 23:31, Jo-Philipp Wich x...@subsignal.org wrote: No, it does not yet, but it may not look for them yet either - after all there is nothing in the code for Picos until now. It is supposed to find them, even if there is no entry in the hardware table - so something is broken on this particular model. Would it be possible for you to seen me a copy of the boardconfig partition? (Lookup the mtd index in /proc/mtd and dump it with dd if=/dev/mtdblockX of=/tmp/boardconfig.bin) There is also no specific image for the Pico M created - just for Nano M, Rocket M and Bullet M. There is also no image for the Loco M created, although it would be worthwhile, as it has a different maximum power (23dBm) compared to the Nano M (28dBm), and it has only one Ethernet jack (eth0),as opposed to the Nano M, which has two (eth0 and eth1 work), but for the Nano M the default configuration in OpenWrt does not even define eth1 from the start. Something that could be fixed? It is probably worth fixing but outside of the scope here. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Tested Changeset 30605: [package] iwinfo: implement proper hardware detection for ar23xx SoC devices like the NanoStation 2
Oh yes, and any hint on finding pci information on a ar71xx platform in Openwrt? On 21 February 2012 07:07, Hanno Schupp hanno.sch...@gmail.com wrote: Here goes ... On 21 February 2012 06:56, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I need a copy of /dev/mtdblock5 and /dev/mtdblock6. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9CiTcACgkQdputYINPTPNeaQCfaGnYJiAvRQyxheSgaSJTRmg/ 8rUAnjiA99ZES63BRyOH9oAOpMJ7+1dj =whU1 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Tested Changeset 30605: [package] iwinfo: implement proper hardware detection for ar23xx SoC devices like the NanoStation 2
This change was a definite improvementfor legacy atheros; as one can see below the hardware is now properly detected by iwinfo. What is not so nice is the txpowerlist. As I had reported last year, the system reports 27dBm regardless which hardware is used. Fon, Ubiquiti, Engenius on atheros platform - as soon as the ath5k driver is used everything shows with 27dBm (see some Ubiquiti devices below) Add to that a 10dBm txpower offset you get a 37dBm txpower range (Manostation2). As I no longer use madwifi I just adjusted the list in https://dev.openwrt.org/browser/trunk/package/iwinfo/src/iwinfo_lib.c with negative and positive values for the devices I support to create a valid txpowerlist . Not nice but hey, it works. I can also confirm the following devices which would be nice to add to the list https://dev.openwrt.org/browser/trunk/package/iwinfo/src/iwinfo_lib.c: Ubiquiti Picostation 2: 168C:0013 0777:C302 - max 20dBm Ubiquiti Picostation 2 HP: 168C:0013 0777:C3A2 - max 30dBm Interestingly the system works different on ar71xx. The M2 devices like Nano, Bullet, and Pico have a maximum power of 28dBm, the M5 a maximum of 28 dBm, the Loco a maximum of 23dBm. Still, the list comes up with 27dBm as on legacy ahteros, but this time the offset works properly, as the maximum shown value is 23dBm (which must consider a 5dBm offset lifting it to the correct 28dBm) . By the way, the susbsystem Id of the Picostation M2 is 0xe302, which would also be nice to add to the list in https://dev.openwrt.org/browser/trunk/package/iwinfo/src/iwinfo_lib.c Picostation M2 root@Router8111215:~# iwinfo wlan0 txpowerlist 0 dBm ( 1 mW) 1 dBm ( 1 mW) 2 dBm ( 1 mW) 3 dBm ( 1 mW) 4 dBm ( 2 mW) 5 dBm ( 3 mW) 6 dBm ( 3 mW) 7 dBm ( 5 mW) 8 dBm ( 6 mW) 9 dBm ( 7 mW) 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) 21 dBm ( 125 mW) 22 dBm ( 158 mW) * 23 dBm ( 199 mW) 24 dBm ( 251 mW) 25 dBm ( 316 mW) 26 dBm ( 398 mW) 27 dBm ( 501 mW) root@Router8111215:~# iwinfo wlan0 info wlan0 ESSID: Chillifire Hotspot Access Point: F8:D1:11:2F:15:AE Mode: Master Channel: 3 (2.422 GHz) Tx-Power: 23 dBm Link Quality: 0/70 Signal: unknown Noise: -95 dBm Bit Rate: unknown Encryption: none Type: nl80211 HW Mode(s): 802.11bgn Hardware: unknown [Generic MAC80211] TX power offset: unknown Frequency offset: unknown Supports VAPs: yes Nanostation2: root@Router0015610:~# iwinfo wlan0 txpowerlist 10 dBm ( 10 mW) 11 dBm ( 12 mW) 12 dBm ( 15 mW) 13 dBm ( 19 mW) 14 dBm ( 25 mW) 15 dBm ( 31 mW) 16 dBm ( 39 mW) 17 dBm ( 50 mW) 18 dBm ( 63 mW) 19 dBm ( 79 mW) 20 dBm ( 100 mW) 21 dBm ( 125 mW) 22 dBm ( 158 mW) 23 dBm ( 199 mW) 24 dBm ( 251 mW) 25 dBm ( 316 mW) 26 dBm ( 398 mW) 27 dBm ( 501 mW) * 28 dBm ( 630 mW) 29 dBm ( 794 mW) 30 dBm (1000 mW) 31 dBm (1258 mW) 32 dBm (1584 mW) 33 dBm (1995 mW) 34 dBm (2511 mW) 35 dBm (3162 mW) 36 dBm (3981 mW) 37 dBm (5011 mW) root@Router0015610:~# iwinfo wlan0 info wlan0 ESSID: Chillifire Hotspot Access Point: 00:15:6D:DA:E1:A0 Mode: Master Channel: 3 (2.422 GHz) Tx-Power: 28 dBm Link Quality: 0/70 Signal: unknown Noise: -110 dBm Bit Rate: unknown Encryption: none Type: nl80211 HW Mode(s): 802.11bg Hardware: 168C:0013 0777:C002 [Ubiquiti NanoStation2] TX power offset: 10 dB Frequency offset: none Supports VAPs: yes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] UBNT PicoStation M2 and M5 Available?
That is correct, but I could imagine he (and others) are confused by the fact that the buildroot does not generate a pico-m image, just a bullet-, nano-m, and a rocket-m. The bullet-m image will work on the pico-m, but there is nothing that tells users. Another 'not-so-nice-thing' by the way is the nano-m image is generated as a 1-port network device. Unlike the b/g nano the nano-m is a two port device and should be equipped with an eth0 and eth1 interface out of the box. The firmware only sets up the eth0 interface (see https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/base-files/etc/uci -defaults/network - all ubnt devices other than routerstations are set up as bullet-m). -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Outback Dingo Sent: Wednesday, 15 February 2012 4:22 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] UBNT PicoStation M2 and M5 Available? On Tue, Feb 14, 2012 at 10:21 AM, Yeoh Chun-Yeow yeohchuny...@gmail.com wrote: Hi, all Support for UBNT PicoStation M2 and M5 available now? It has been for at least a year or more Regards, Chun-Yeow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
@Jonathan OK, great. Thanks for the confirmation. Next step is to test the patch. The 2.6.37 kernel may be enough; some commentary in the OpenWrt trunk suggest the 2.6.38 kernel may be experimental and as such not used. I will test your patch on the 1650 and 2611P which, looking at the if statements in your code, should confirm two of your code paths. @ jow I copied you into this as this patch successfully determines board type via radio in a ath5k usage situation, the situation we have found it difficult for iwinfo to produce some meaningful output, when used in conjunction with ath5k rather than madwifi. The variables and structures used in this patch are quite different from the ones used in iwinfo. Might this be a better approach to determine the device/board in a th5k scenario? Also, the current iwinfo only recognises Ubiquiti and some Fonera devices (from memeory) here are some useful vendor and device ids for Engenius which would be great to add. Your thoughts? Cheers Hanno Schupp -Original Message- From: Jonathan Bither [mailto:jonbit...@gmail.com] Sent: Monday, 6 February 2012 3:39 p.m. To: Hanno Schupp; openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support Hano, Thank you for reviewing the patch, especially since it was my first submission. This patch was based off of the trunk branch. I have tested this patch with both Madwifi as well as ath5k. Since this patch was my first submission I only submitted the version for 2.6.37. I was hoping for feedback or suggestions so that I could clean it up and submit a V2 with 2.6.38. I have tested this patch with the following boards: ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P. EnGenius had provided me with one of each to test with. The radio information can be actually be pulled from the boardconfig, so that the device can be checked in the kernel regardless of radio driver. Unfortunately the ECB-3500, EAP-3660, EOA-3630, EOC-2611P all share the same radio information while having different GPIO outputs for their leds. As of yet I have not found a way to identify them apart as to properly register the correct GPIOs to leds. If you are interested I am happy to try to clean up the patch for a resubmission. On 02/05/2012 12:26 AM, Hanno Schupp wrote: Hi Jonathan, Thank you for this patch. I am currently using a simplified version of what you are doing in an approach that relies on compiling a specific version of the firmware for the different models (https://dev.openwrt.org/attachment/ticket/6202/100-board-trunk-b18541 .patch ) as it hard codes the different value. Your patch is of course much more elegant, but I wonder what OpenWrt version and what wireless driver you are using, as in my experience the radio information is only available when using the madwifi driver, not with ath5k. Q: Which wireless river are you using, ath5k or madwifi? Q: Are you compiling in trunk or with backfire? Also, the Atheros platform seems to hold patches both for 2.6.37 and 2.6.38 kernels. It is not clear to me when what kernel is used. Q: Your patch addresses 2.6.37 kernel only; is that sufficient? Last but not least, my patch works with 1650 only. 2611p still does not recover from soft reboot and hangs although AR2315_RESET_GPIO is set to 0 just as much as for EOC-1650. Q: Which of the units ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P have you actually tested? Q: In particular, can you confirm your patch works with EOC-2611P? Thanks very much in advance for your input. Hanno -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jonathan Bither Sent: Friday, 23 December 2011 9:32 a.m. To: openwrt-devel@lists.openwrt.org Subject: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support Attached is a patch for trunk which fixes gpio assignments for EnGenius devies on the ar231x platform. This patch fixes rebooting as well the reset button for the following devices: ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P Signed-off-by: Jonathan Bither jonbit...@gmail.com Index: target/linux/atheros/patches-2.6.37/400-engenius-support.patch === --- target/linux/atheros/patches-2.6.37/400-engenius-support.patch (revision 0) +++ target/linux/atheros/patches-2.6.37/400-engenius-support.patch (revision 0) @@ -0,0 +1,159 @@ +--- a/arch/mips/include/asm/mach-ar231x/ar231x_platform.h b/arch/mips/include/asm/mach-ar231x/ar231x_platform.h +@@ -66,6 +66,15 @@ + + /* radio calibration data */ + const char *radio; ++ ++/* Reset GPIO */ ++u32 resetGpio; ++ ++/* Reset Button GPIO */ ++u32 resetButtonGpio; ++ ++/* EnGenius AP Workaround */ ++int EnGenius; + }; + + /* +--- a/arch/mips/ar231x/ar2315.c b
Re: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
Hi Jonathan,
Thank you for this patch. I am currently using a simplified version of what
you are doing in an approach that relies on compiling a specific version of
the firmware for the different models
(https://dev.openwrt.org/attachment/ticket/6202/100-board-trunk-b18541.patch
) as it hard codes the different value.
Your patch is of course much more elegant, but I wonder what OpenWrt version
and what wireless driver you are using, as in my experience the radio
information is only available when using the madwifi driver, not with ath5k.
Q: Which wireless river are you using, ath5k or madwifi?
Q: Are you compiling in trunk or with backfire?
Also, the Atheros platform seems to hold patches both for 2.6.37 and 2.6.38
kernels. It is not clear to me when what kernel is used.
Q: Your patch addresses 2.6.37 kernel only; is that sufficient?
Last but not least, my patch works with 1650 only. 2611p still does not
recover from soft reboot and hangs although AR2315_RESET_GPIO is set to 0
just as much as for EOC-1650.
Q: Which of the units ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650,
EOC-5611P have you actually tested?
Q: In particular, can you confirm your patch works with EOC-2611P?
Thanks very much in advance for your input.
Hanno
-Original Message-
From: openwrt-devel-boun...@lists.openwrt.org
[mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jonathan
Bither
Sent: Friday, 23 December 2011 9:32 a.m.
To: openwrt-devel@lists.openwrt.org
Subject: [OpenWrt-Devel] [PATCH] Add EnGenius ar231x support
Attached is a patch for trunk which fixes gpio assignments for EnGenius
devies on the ar231x platform. This patch fixes rebooting as well the reset
button for the following devices:
ECB-3500, EAP-3660, EOA-3630, EOC-2611P, EOC-1650, EOC-5611P
Signed-off-by: Jonathan Bither jonbit...@gmail.com
Index: target/linux/atheros/patches-2.6.37/400-engenius-support.patch
===
--- target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
+++ target/linux/atheros/patches-2.6.37/400-engenius-support.patch
(revision 0)
@@ -0,0 +1,159 @@
+--- a/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
b/arch/mips/include/asm/mach-ar231x/ar231x_platform.h
+@@ -66,6 +66,15 @@
+
+ /* radio calibration data */
+ const char *radio;
++
++ /* Reset GPIO */
++ u32 resetGpio;
++
++ /* Reset Button GPIO */
++ u32 resetButtonGpio;
++
++ /* EnGenius AP Workaround */
++ int EnGenius;
+ };
+
+ /*
+--- a/arch/mips/ar231x/ar2315.c
b/arch/mips/ar231x/ar2315.c
+@@ -554,8 +554,8 @@
+ ar2315_led_data.num_leds = 0;
+ for(i = 1; i 8; i++)
+ {
+- if((i == AR2315_RESET_GPIO) ||
+- (i == ar231x_board.config-resetConfigGpio))
++ if((i == ar231x_board.resetGpio) ||
++ (i == ar231x_board.resetButtonGpio))
+ continue;
+
+ if(i == ar231x_board.config-sysLedGpio) @@ -610,11 +610,11
@@
+ /* Cold reset does not work on the AR2315/6, use the GPIO reset bits
a workaround.
+* give it some time to attempt a gpio based hardware reset
+* (atheros reference design workaround) */
+- gpio_direction_output(AR2315_RESET_GPIO, 0);
++ gpio_request(ar231x_board.resetGpio, );
++ gpio_direction_output(ar231x_board.resetGpio, 0);
+ mdelay(100);
+
+- /* Some boards (e.g. Senao EOC-2610) don't implement the reset logic
+- * workaround. Attempt to jump to the mips reset location -
++ /* Attempt to jump to the mips reset location -
+* the boot loader itself might be able to recover the system */
+ mips_reset_vec();
+ }
+--- a/arch/mips/ar231x/reset.c
b/arch/mips/ar231x/reset.c
+@@ -13,12 +13,12 @@
+ #include ar231x.h
+ #include devices.h
+
+-#define AR531X_RESET_GPIO_IRQ
(AR531X_GPIO_IRQ(ar231x_board.config-resetConfigGpio))
++#define AR531X_RESET_GPIO_IRQ
(AR531X_GPIO_IRQ(ar231x_board.resetButtonGpio))
+
+ struct event_t {
+ struct work_struct wq;
+ int set;
+- unsigned long jiffies;
++ unsigned long jiffies, jiffies_prev;
+ };
+
+ static struct timer_list rst_button_timer; @@ -68,8 +68,14 @@
+ add_msg(skb, PATH=/sbin:/bin:/usr/sbin:/usr/bin);
+ add_msg(skb, SUBSYSTEM=button);
+ add_msg(skb, BUTTON=reset);
+- add_msg(skb, (event-set ? ACTION=pressed : ACTION=released));
+- sprintf(buf, SEEN=%ld, (event-jiffies - seen)/HZ);
++
++ /* EnGenius input level is reversed */
++ if (ar231x_board.EnGenius)
++ add_msg(skb, (event-set ? ACTION=released :
ACTION=pressed));
++ else
++ add_msg(skb, (event-set ? ACTION=pressed :
ACTION=released));
++
++ sprintf(buf, SEEN=%lu, (event-jiffies - event-jiffies_prev)/HZ);
+ add_msg(skb, buf);
+ snprintf(buf, 128, SEQNUM=%llu, uevent_next_seqnum());
+ add_msg(skb, buf);
+@@ -103,6
Re: [OpenWrt-Devel] collectd-mod-iwinfo
Thanks Jow, I had a look at /trunk/package/iwinfo/Makefile and the IWINFO_BACKENDS section seems to define wl driver as required target if a Broadcom kernel module is loaded. I do not understand Makefile at all, so I do not understand what else needs to be done to 'wl must be enabled at build time of libiwinfo to get enabled as backend' Sorry to be a pest, but some help would bs greatly appreciated. Thanks Hanno On Wednesday, 25 January 2012, Jo-Philipp Wich x...@subsignal.org wrote: Hey. I cannot get collectd-mod-iwinfo to work for the proprietary wl0 drivers. They work fine on ath5k and ath9k. Make sure iwinfo was compiled with wl support (wl must be enabled at build time of libiwinfo to get enabled as backend) Before I try further, does collectd-mod-iwinfo support wl0 Yes. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] collectd-mod-iwinfo
Hi jow, Thanks for following up. Here the outputs: root@Router00177962:/tmp# iwinfo wl0 info wl0 ESSID: Chillifire Hotspot Access Point: 00:1D:7E:E7:96:D4 Type: wl HW Mode(s): 802.11bg Mode: Master Channel: 3 (2.422 GHz) Tx-Power: 24 dBm Link Quality: 5/5 Signal: 1 dBm Noise: -92 dBm Bit Rate: 54.0 MBit/s Encryption: none Supports VAPs: yes root@Router00177962:/tmp# cat /etc/collectd.conf # Please read collectd.conf(5) for a list of options. # http://collectd.org/ # BaseDir /var/lib/collectd PIDFile /var/run/collectd.pid Interval60 ReadThreads 1 LoadPlugin cpu LoadPlugin load LoadPlugin network LoadPlugin memory LoadPlugin ping LoadPlugin processes LoadPlugin iwinfo Plugin network Server 120.138.19.134 265 /Plugin Plugin ping Host login02.chillifire.net /Plugin Plugin processes Process chilli /Plugin No errors on manual start as you had requested. When starting daemon normally with /etc/init.d/collectd start collectd does run fine: root@Router00177962:/tmp# ps PID USER VSZ STAT COMMAND 1 root 1432 Sinit 2 root 0 SW [keventd] 3 root 0 RWN [ksoftirqd_CPU0] 4 root 0 SW [kswapd] 5 root 0 SW [bdflush] 6 root 0 SW [kupdated] 8 root 0 SW [mtdblockd] 94 root 0 SWN [jffs2_gcd_mtd4] 120 root 1432 Sinit 147 root 1440 Ssyslogd -C16 149 root 1420 Sklogd 856 root 888 S/usr/sbin/nas -P /var/run/nas.wl0.1.pid -H 34954 -l b 930 root 1436 Sudhcpc -t 0 -i eth0.1 -b -p /var/run/dhcp-eth0.1.pid 1239 root 948 Sedge -d tun9 -f -r 0 -a 0.0.0.0 -s 255.255.255.255 -m 1270 root 1436 Sudhcpc -i tun9 -b -p /var/run/tun9.pid -R -t 3 1284 root 1440 Scrond -c /etc/crontabs -l 5 1299 root 1112 S/usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 1402 root 940 S/usr/sbin/uhttpd -f -h /www -r Router00177962 -x /cgi 1425 nobody 868 S/usr/sbin/dnsmasq -K -D -y -Z -b -E -s lan -S /lan/ - 1511 root 2256 S/usr/sbin/chilli --conf=/etc/chilli.conf --pidfile /v 1547 root 1048 S/usr/sbin/ffwatchd 1649 root 1432 S/usr/sbin/ntpd -n -p 0.openwrt.pool.ntp.org -p 1.open 2022 root 1188 S/usr/sbin/dropbear -P /var/run/dropbear.1.pid -p 22 2024 root 1436 S-ash 2235 root 2476 S/usr/sbin/collectd -f 2237 root 2476 S/usr/sbin/collectd -f 2238 root 2476 S/usr/sbin/collectd -f 2239 root 2476 S/usr/sbin/collectd -f 2245 root 1428 Rps No /tmp data file is created: root@Router00177962:/tmp# ls -l -rw-r--r--1 root root4 Jan 25 06:05 TZ -rw-r--r--1 root root 79 Jan 25 05:59 dhcp.leases -rw-r--r--1 root root 400 Sep 8 15:55 hs.conf drwxr-xr-x3 root root 60 Sep 8 15:56 lib drwxr-xr-x2 root root 40 Jan 25 06:04 lock drwxr-xr-x2 root root 80 Sep 8 15:55 log -rw-r--r--1 root root 773 Sep 8 15:55 main.conf drwxr-xr-x2 root root 60 Jan 25 06:04 opkg-lists drwxr-xr-x2 root root 40 Jan 1 2000 overlay -rw-r--r--1 root root 32 Sep 8 15:55 resolv.conf -rw-r--r--1 root root 77 Sep 8 15:55 resolv.conf.auto drwxr-xr-x2 root root 380 Jan 25 06:05 run -rw-r--r--1 root root 14 Sep 8 15:55 settings drwxr-xr-x3 root root 60 Sep 8 15:55 spool drwxr-xr-x2 root root 100 Sep 8 15:55 state drwxr-xr-x3 root root 60 Jan 25 06:04 usr -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Wednesday, 25 January 2012 1:43 p.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] collectd-mod-iwinfo -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So if you install the iwinfo cli frontend and run iwinfo wl0 info, does it output anything useful, does it identify the hw as type wl ? Is LoadPlugin iwinfo in the enerated collectd.conf ? Is killall -9 collectd; collectd -f reporting any errors ? Are there iwinfo *.rrd files generated in /tmp/$hostname/ ? ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8fUBwACgkQdputYINPTPPt1QCfb8VxBljgoJ8As00b87RUPlz3 UgQAniLL1LV4M3QUPxUHc7AH0ztzRcMe =XTkI -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] iwinfo hardware_name
Hi jow I just upgraded to latest trunk 29871 and discovered that the iwinfo improvements introduced in 29421 which display hardware name, and txpower offset apparently still only apply to the atheros platform if the outdated madwifi driver is used. If using ath5k the standard wireless driver for atheros platform the Hardware name is still not determined. All I get is this: # iwinfo wlan0 info wlan0 ESSID: MyNetwork Access Point: 00:15:6D:DA:E1:A0 Mode: Master Channel: 3 (2.422 GHz) Tx-Power: 27 dBm Link Quality: 0/70 Signal: unknown Noise: -109 dBm Bit Rate: unknown Encryption: none Type: nl80211 HW Mode(s): 802.11bg Hardware: unknown [Generic MAC80211] TX power offset: unknown Frequency offset: unknown Supports VAPs: yes Of course this is disappointing. Is there really nothing that can be done? I raised this in an email before, but had hoped this improvement had solved the issue - apparently not. After all it is the same kernel version, the same bootloader (which is aware which Ubnt device is running on, on the different Ubnt devices). All that is different is the wireless driver. Madwifi was able to determine the hardware very reliably; I cannot understand why this is so hard for the ath5k platform. If someone could update the iwinfo code to reflect qth5k vendor and device detection, I am happy to do the testing; I have a number of Ubnt devices, Fon+ and Fon2, a Dir 300A1 and an Engenius device to test with. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] collectd-mod-iwinfo
Hi, I cannot get collectd-mod-iwinfo to work for the proprietary wl0 drivers. They work fine on ath5k and ath9k. Before I try further, does collectd-mod-iwinfo support wl0 or do I need to fall back to collectd-mod-wireless? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: enhance routine for getting MAC address from flash
Thank you for the order. The P2P filter is installed by default but not activated. You can do that within the firmware. Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 6/12/2011, at 1:30 PM, Nerijus Baliunas neri...@users.sourceforge.net wrote: On Mon, 5 Dec 2011 20:36:47 +0200 Nerijus Baliunas neri...@users.sourceforge.net wrote: Then modified target/linux/ramips/base-files/lib/preinit/06_set_iface_mac as written above, make clean, make and flashed firmware. Any ideas why didn't it work? My board is ZyXEL NBG-419N. Latest svn fixes it, I have both WAN and LAN MACs correctly now (although I had to clear config when flashing firmware in order to get correct LAN MAC addr). Thanks! Regards, Nerijus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Iw info hardware detection
Hi, I see with great interest Jow's extension of iwinfo to detect hardware more accurately. It covers many ubiquiti models but not the Picostation models. I have a few different models plus a couple of engenius routers and othe atheros b/g kit and could find out the relevant vendor and hardware codes, if some one could give me line of c code that logs the relevant I'd ( vendor Id, sub-id, hardware Id, and sub-Id) to logread or just echoes the values when iwinfo is run. I know Php, JavaScript and shell programming but am helpless with c. A line of code would be appreciated Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] wndr3800 machine name patch
Hi Mark, that is interesting. I am battling with some device recognistion issues myself. What is that ' art/caldata area' you mention? Can you access the data from the command line after Boot? I guess I am asking how can you access the data in 'userland', i.e. in shell scripts? Cheers Hanno -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Mark Mentovai Sent: Saturday, 26 November 2011 7:14 a.m. To: Petri Rosenström Cc: OpenWrt Development List Subject: Re: [OpenWrt-Devel] [PATCH] wndr3800 machine name patch Petri Rosenström wrote: I think it is useful because it adds the specific board information about WNDR3800 (e.g. the name WNDR3800 on status page or /proc/cpuinfo show correct board name). I think that this information is important and it should be available. Since you can flash a WNDR3700v2 with a WNDR3800 image and vice-versa, and the name is simply baked into the image you chose to flash with no other differences between the two, it seems pointless. btw. Do you (Mark) own the both devices? Have you (Mark) checked that they are the same (only RAM diff)? I have *only* seen claims on some forums and I only own a wndr3800 so I can't say for sure. It seems like they are. But it would be nice to know for sure. If it's terribly important, you can detect the difference between 3700v2 and 3800 at runtime. The data's in the art/caldata area. The WNDR3800 U-Boot source has the details. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ZyXEL NBG-419N wrong MAC
Interesting. The exact same thing is occurring on my D-link DIR600 B2, a ramips based router. Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 25/11/2011, at 11:35 AM, Nerijus Baliunas neri...@users.sourceforge.net wrote: Hello, Wifi MAC is correct, corresponds to one of the MACs written on the box, but all other MAC addresses (br-lan, eth0, eth0.1, eth0.2) are 00:11:22:33:44:55. Regards, Nerijus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Nanostation external antenna on ath5k
Hi, Can anyone advise how to switch to the external antenna on a Nanostation 2 when using the ath5k selected as standard wireless driver in trunk? The old option antenna external in the wireless config file which was available in Madwifi is no longer supported in ath5k. The sysctl and gpios to command as given in the wiki do not work anymore either. Any advice welcome. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Device identification and machine on /proc/cpuinfo for atheros platform
Hi, is there really no answer to this? Device detection has taken a real hit from madwifi to ath5k, and since the latter is the default in trunk, I woul have thought there is some way forward or workaround. No thoughts at all? Cheers Hanno Dear all, I have recently switched from backfire to trunk. This forced a change from madwifi to ath5k for atheros platforms. I also compile and test firmware on ar71xx, ramips and brcm47xx. I notice that on ar71xx and ramips the actual router/board is identified in /proc/cpuinfo. Luci in trunk is using this file almost exclusively to determine the router information (refer to http://luci.subsignal.org/trac/browser/luci/trunk/libs/sys/luasrc/sys.lua#170) Unfortunately on the atheros platform and brcm47xx the field 'machine' on /proc/cpuinfo is not set. The system then uses system type, which is not defining the router, but give a generic processor name such as BCM47XX (see https://dev.openwrt.org/attachment/ticket/7604/openwrt-cpuinfo) or AR2315 (http://www.zoobab.com/engenius-ecb3500). Interestingly when madwifi was used by atheros, the information about the board was not taken from /proc/cpuinfo, but from /proc/sys/dev/$device/dev_name. Ath5k does not generate that file, but obviously if madwifi had a way of getting to the information without /proc/cpuinfo, so OpenWrt must be able to as well, right? What I am certain of is that the devices I tested with a serial such as Fon+, Nano2, Bullet2, Pico2 and Pico2HP are all aware of their identity during the Redboot boot process; they all say something like 'Board: Ubiquiti NanoStation 2' so the information what the board actually is is certainly known to the device and it should be possible to bring it to the fore to userland and ultimately to Luci. The current situation with atheros and ath5k is certainly a regression fro madwifi as far as device identification is concerned. Any suggestions how that can be achieved? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Polarisation and External Antenna on Nanostation with ath5k/ath9k
I am not sure at all, hence my question how this to be done for routers with this capability on ath9k without these parameters being available. On ath5k setting the gpio values and the tx and rx antenna values manually as the madwifi code would, seems to achieve the desired result; issue is that piece of code does not exist in mac80211 and as I said ar71xx cannot even differentiate between nano and nano loco and bullet. Cheers Hanno Schupp On 15/11/2011, at 1:47 AM, Daniel Golle dgo...@allnet.de wrote: Hi Hanno! I'm working on that for the ALL0258N, going to post a draft later today on ath9k-devel. Probably this will get us one step closer to support similar functionality on similar hardware as well. Are you sure setting the antenna switch is working through GPIO on ath9k hardware as well? Regards Daniel On 11/13/2011 08:57 PM, Hanno Schupp wrote: Previosly on madwifi using a special uci config parameter the polarisarion on Nanostation and Nano Loco plus polarisation on Loco could be set easily (refer to lines 138 to 196 in https://dev.openwrt.org/browser/trunk/package/madwifi/files/lib/wifi/madwifi.sh) Trunk selects ath5k for atheros and ath9k for ar71xx by default in trunk, but the corresponding code does not include an antenna config parameter (refer to https://dev.openwrt.org/browser/trunk/package/mac80211/files/lib/wifi/mac80211.sh) How then do we set polarization for ubiquiti device where available (Nano, Nano Loco, Nano M, Nano Loco M) and how do we target the external antenna where a connector is available (Nano, Nano M)? The code extract from Madwifi shows the antenna uci config is just a front end to txantenna, rxantenna and diversity, which is easy enough to replicate in /etc/config/wireless, but what about the gpios that are set? As far as I read the mac80211.sh code this cannot be configured from there. The situation is further complicated by the fact that the device recognition with mac80211.sh in not as fine grained as was with Madwifi; with the latter you knew whether you had a bullet, a pico, a nano or loco. With mac80211.sh it is all the same, they all are identified as Bullet or Bullet M (depending on architecture). Any thoughts and hints welcome. I have a number of different Ubiqiti Picostations and Nanostations and am happy to test any suggested patches. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Polarisation and External Antenna on Nanostation with ath5k/ath9k
Previosly on madwifi using a special uci config parameter the polarisarion on Nanostation and Nano Loco plus polarisation on Loco could be set easily (refer to lines 138 to 196 in https://dev.openwrt.org/browser/trunk/package/madwifi/files/lib/wifi/madwifi.sh ) Trunk selects ath5k for atheros and ath9k for ar71xx by default in trunk, but the corresponding code does not include an antenna config parameter (refer to https://dev.openwrt.org/browser/trunk/package/mac80211/files/lib/wifi/mac80211.sh ) How then do we set polarization for ubiquiti device where available (Nano, Nano Loco, Nano M, Nano Loco M) and how do we target the external antenna where a connector is available (Nano, Nano M)? The code extract from Madwifi shows the antenna uci config is just a front end to txantenna, rxantenna and diversity, which is easy enough to replicate in /etc/config/wireless, but what about the gpios that are set? As far as I read the mac80211.sh code this cannot be configured from there. The situation is further complicated by the fact that the device recognition with mac80211.sh in not as fine grained as was with Madwifi; with the latter you knew whether you had a bullet, a pico, a nano or loco. With mac80211.sh it is all the same, they all are identified as Bullet or Bullet M (depending on architecture). Any thoughts and hints welcome. I have a number of different Ubiqiti Picostations and Nanostations and am happy to test any suggested patches. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] busybox ntpd vs rdate (r28612)
Hi Felix, I understand the rationale of the change from busybox to ntpd in standard. Does that mean though that the ntpd package has to be chosen in the .config file or is ntpd really integrated into busybox, making the ntpd client package obsolete? Please advise. Regards Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Board identification and machine on /proc/cpuinfo for atheros platform
Dear all, I have recently switched from backfire to trunk. This forced a change from madwifi to ath5k for atheros platforms. I also compile and test firmware on ar71xx, ramips and brcm47xx. I notice that on ar71xx and ramips the actual router/board is identified in /proc/cpuinfo. Luci in trunk is using this file almost exclusively to determine the router information (refer to http://luci.subsignal.org/trac/browser/luci/trunk/libs/sys/luasrc/sys.lua#170) Unfortunately on the atheros platform and brcm47xx the field 'machine' on /proc/cpuinfo is not set. The system then uses system type, which is not defining the router, but give a generic processor name such as BCM47XX (see https://dev.openwrt.org/attachment/ticket/7604/openwrt-cpuinfo) or AR2315 (http://www.zoobab.com/engenius-ecb3500). Interestingly when madwifi was used by atheros, the information about the board was not taken from /proc/cpuinfo, but from /proc/sys/dev/$device/dev_name. Ath5k does not generate that file, but obviously if madwifi had a way of getting to the information without /proc/cpuinfo, so OpenWrt must be able to as well, right? What I am certain of is that the devices I tested with a serial such as Fon+, Nano2, Bullet2, Pico2 and Pico2HP are all aware of their identity during the Redboot boot process; they all say something like 'Board: Ubiquiti NanoStation 2' so the information what the board actually is is certainly known to the device and it should be possible to bring it to the fore to userland and ultimately to Luci. The current situation with atheros and ath5k is certainly a regression fro madwifi as far as device identification is concerned. Any suggestions how that can be achieved? Cheers Hanno ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
Hi Felix, What is this netifd and ubus business appearing in trunk? What is it implementing or replacing? Will it affect all platforms and be included firmware images by default or does it have to be specifically compiled into an image? How can we help you testing this new package, what should we be looking for in terms of regression testing? Please advise Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details
Thank you for the fast response. For sake of clarification: When you mention 'network configuration scripts' are you talking about scripts like the old brcm-2.4 init.d netconfig script and things like target profile specific network configuration defaults stored in target/linux/atheros/base-files/etc/uci-defaults/network and target/linux/ar71xx/base-files/etc/defconfig/* for example? Please advise Regards Hanno -Original Message- From: Felix Fietkau [mailto:n...@openwrt.org] Sent: Saturday, 22 October 2011 12:08 p.m. To: OpenWrt Development List Cc: Hanno Schupp Subject: Re: [OpenWrt-Devel] Netifd and ubus in trunk - Please provide some details On 2011-10-22 12:59 AM, Hanno Schupp wrote: Hi Felix, What is this netifd and ubus business appearing in trunk? What is it implementing or replacing? Will it affect all platforms and be included firmware images by default or does it have to be specifically compiled into an image? How can we help you testing this new package, what should we be looking for in terms of regression testing? ubus simply implements an RPC service, making it easy for C programs to export an API that can easily be accessed from other C code or even shell scripts. netifd is going to replace the network configuration scripts at some point. right now it's experimental and disabled by default, as not all network proto handlers have been converted yet (so far, static, ppp, pppoe, pppoa, dhcp are supported). What would be useful is not just testing what has been ported, but also review of the code and porting more of our protocol handler scripts. When all the existing features have been ported over, this will be enabled by default and the old scripts will be removed. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] update usb-modeswitch to 1.1.19
Pleasure. While you are at it, could you please also release the upgrade of coova-chilli from 1.2.5 to 1.2.8 I submitted about the same time as the USB-modeswitch patches? Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 29/08/2011, at 12:12 AM, Florian Fainelli flor...@openwrt.org wrote: On Tuesday 16 August 2011 03:05:16 Hanno Schupp wrote: Signed-off-by: Your name hanno.sch...@gmail.com Applied in r28104, thanks! -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] where is pcdata coming from
In the status overview I see the statement %=pcdata(model or ?)% which displays the detected router model, if detected. So far so good. Three questions: 1) How can I access the same model data from the bash shell? 2) What other useful data is accessible under pcdata? 3) Which program does this model detection ( I assume it is part of the start up sequence )? - I would like to know from which point in the /etc/init.d sequence of start up programs the information is available. Any pointers welcome. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] where is pcdata coming from
After I sent the question I remembered that pcdata is not providing any data - it is just formatting data for output. And the variable model, that is being formatted is coming from luci.sys.sysinfo That function's code makes it all too clear: function sysinfo() local cpuinfo = fs.readfile(/proc/cpuinfo) local meminfo = fs.readfile(/proc/meminfo) local memtotal = tonumber(meminfo:match(MemTotal:%s*(%d+))) local memcached = tonumber(meminfo:match(\nCached:%s*(%d+))) local memfree = tonumber(meminfo:match(MemFree:%s*(%d+))) local membuffers = tonumber(meminfo:match(Buffers:%s*(%d+))) local bogomips = tonumber(cpuinfo:match([Bb]ogo[Mm][Ii][Pp][Ss].-: ([^\n]+))) or 0 local system = cpuinfo:match(system type\t+: ([^\n]+)) or cpuinfo:match(Processor\t+: ([^\n]+)) or cpuinfo:match(model name\t+: ([^\n]+)) local model = cpuinfo:match(machine\t+: ([^\n]+)) or cpuinfo:match(Hardware\t+: ([^\n]+)) or luci.util.pcdata(fs.readfile(/proc/diag/model)) or nixio.uname().machine or system return system, model, memtotal, memcached, membuffers, memfree, bogomips end Remaining question: I have not checked the nixio code but I assume nixio.uname().machine would be uname -m in a bash shell script, right? On 16 August 2011 08:55, Hanno Schupp hanno.sch...@gmail.com wrote: In the status overview I see the statement %=pcdata(model or ?)% which displays the detected router model, if detected. So far so good. Three questions: 1) How can I access the same model data from the bash shell? 2) What other useful data is accessible under pcdata? 3) Which program does this model detection ( I assume it is part of the start up sequence )? - I would like to know from which point in the /etc/init.d sequence of start up programs the information is available. Any pointers welcome. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Update coova-chilli to 1.2.8
Signed-off-by: Your name hanno.sch...@gmail.com Index: Makefile === --- Makefile(revision 27980) +++ Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=coova-chilli -PKG_VERSION:=1.2.5 +PKG_VERSION:=1.2.8 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://ap.coova.org/chilli -PKG_MD5SUM:=1b890cb043b4340e1f15c2b2cff742d3 +PKG_MD5SUM:=e8fa70a52d9c9f4e8addbe8df09c56db PKG_FIXUP:=libtool PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update usb-modeswitch-data to make it compile again
The update is required as the old filename usb-modeswitch-data-20110705.tar.bz2 is no longer hosted on http://www.draisberghof.de/usb_modeswitch/ BTW, the two openwrt.org backup servers do not hold either the old usb-modeswitch-data-20110705.tar.bz2 nor the new usb-modeswitch-data-20110805.tar.bz2 In effect there is a dependency on one external server. If they decide to change to a new version and not continue hosting the old, the compilation breaks. The sources on the openwrt,org servers should therefore be urgently updated. Signed-off-by: Your name hanno.sch...@gmail.com Index: Makefile === --- Makefile(revision 27980) +++ Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=usb-modeswitch-data -PKG_VERSION:=20110705 +PKG_VERSION:=20110805 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://www.draisberghof.de/usb_modeswitch/ -PKG_MD5SUM:=5046e7be8d10d2fe699f9af21a0c3769 +PKG_MD5SUM:=0ed8a28f8efd3177a128ecd46fc8bf9f include $(INCLUDE_DIR)/package.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update usb-modeswitch to 1.1.19
Signed-off-by: Your name hanno.sch...@gmail.com Index: Makefile === --- Makefile(revision 28007) +++ Makefile(working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=usb-modeswitch -PKG_VERSION:=1.1.8 +PKG_VERSION:=1.1.9 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://www.draisberghof.de/usb_modeswitch -PKG_MD5SUM:=145e0465843e4973d7778bfbafbb +PKG_MD5SUM:=76f6978f18cac41f269a346a5d0f1052 include $(INCLUDE_DIR)/package.mk ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] PostInst delayed to real system
Hi, In the current approach there is an inherent limitation in that the uci-default scripts run before the application init.d scripts are run. While this is desirable for many situations, it is an issue in those cases you need to have the network up, switch recognised, wifi driver identified etc. To overcome we have used the uci-default approach and copied into a uci-postconfig directory in our firmware compilation. All scripts in there are also just run once, but AFTER all other scripts have been run before the last finished script that marks the end of the boot process. The scripts in uci-postconfig directory are called and then removed after execution by an ordinary init.d script with S99 timing. While that all works well, it would be nice to have such a postconfig or postboot mechanism (whatever you want to call it) in standard OpenWrt as much as the uci-default mechansim. Just a thought... Hanno On 11 August 2011 20:40, Ithamar R. Adema ithamar.ad...@team-embedded.nlwrote: Hi Lukas, On Thu, 2011-08-11 at 08:13 +0200, Lukas Macura wrote: So, I really do not want to SPAM on this conference, but my question is: - Should OpenWrt take care of this scenarios? Or it is package specific and every package which needs things like this should do it by itself? There are four scenarios and we want to choose best one: - implement it in application by its way - implement some delayed postinst in opkg (sounds like bigger hack) - implement using hook to firstboot() (but in that case, it will not work as module) - create some /lib/postinst.sh with functions like was_run() , [snip] Again, any script in /etc/uci-defaults gets executed on bootup before any of the packages installed are started. After the scripts in /etc/uci-defaults are finished, they are deleted, never to be run again. This seems like what you are proposing here in your 3rd item in the list above, but it is already there :) These scripts can perform anything you like, including starting up another process that you require during that script. There's nothing specific to UCI there, except that the boot process is far enough to be able to use uci but has not started anything further yet. So, is your problem that you want stuff to get triggered after ipkg install, on an already running system, or what is the problem (sorry if I'm too dense to pick it up from your mail :$) Regards, Ithamar. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] freifunk-p2pblock not working properly since firewall change in
Dear All,
Below the freifunk p2pblock script, which used to work like a charm,
however, works no longer as expected in backfire.
I read on http://wiki.openwrt.org/doc/uci/qos?s[]=qos
http://wiki.openwrt.org/doc/uci/qos?s%5b%5d=qos that 'As of r25641
https://dev.openwrt.org/changeset/25641/trunk qos-scripts dropped the use
of IMQ (package iptables-mod-imq - Intermediate Queueing Device). It's
successor is IFB (Intermediate Functional Block device)
http://www.linuxfoundation.org/collaborate/workgroups/networking/ifb ,
(needed packages kmod-ifb and act_connmark).' These packages do not exist on
backfire and act_connmark does not exist in trunk either. Odd. Still, the
changelog would seem to indicate this affects trunk only, but can someone
confirm this is irrelevant for backfire?
I also understand from ' https://dev.openwrt.org/changeset/25352 [25352]:
[backfire] drop firewall v1' and ' https://dev.openwrt.org/changeset/25353
[25353]: [backfire] merge dual stack firewall' that the firewall userland
programmes have been changed. Could this affect the ipp2p based iptbales
rules?
Be it as it may, the script that used to work great now cannot establish the
ipp2p firewall rules anymore on either atheros or ar71xx. The two lines:
ipt_add p2pblock -m ipp2p --$proto -m
recent --rdest --set --name P2PBLOCK
ipt_add p2pblock -m ipp2p --$proto -m limit
--limit 1/minute -j LOG --log-prefix P2PBLOCK-seen-$proto:
lead to a 'iptables: No chain/target/match by that name.' errors like so:
root@Router0023133:~# /etc/init.d/freifunk-p2pblock enable
root@Router0023133:~# /etc/init.d/freifunk-p2pblock start
freifunk-p2pblock: starting p2pblock...
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.
freifunk-p2pblock: Done.
Given the recent significant changes in the firewall scripts my best guess
is the changes have rendered the iptable commands in the p2p scripts
unworkable.
My iptables skills are not sufficient to analyse this further, so I turn to
this group for review and council - and ideally for a suggestion for a fix.
Cheers
Hanno
Auckland, New Zealand
Appendix
Here the freifunk-p2pblock script for reference:
#!/bin/sh /etc/rc.common
START=82
ME=freifunk-p2pblock
LOCK='/var/run/p2pblock.lock'
# helper-scripts
ipt_add() {
logger -t $ME set 'iptables -I $1'
iptables -I $1
echo iptables -D $1 $LOCK
}
start() {
/etc/init.d/freifunk-p2pblock enabled || return
if [ ! -s $LOCK ]; then
logger -s -t $ME 'starting p2pblock...'
config_load network
config_get wan wan ifname
if [ -n $wan ]; then
config_load freifunk_p2pblock
config_get layer7 p2pblock layer7
config_get ipp2p p2pblock ipp2p
config_get portrange p2pblock portrange
config_get blocktime p2pblock blocktime
# load modules
insmod ipt_ipp2p 2-
insmod ipt_layer7 2-
insmod ipt_recent ip_list_tot=400 ip_pkt_list_tot=3
2-
# create new p2p-chain
iptables -N p2pblock
# pipe all incomming FORWARD with
source-/destination-port 1024-65535 throu p2p-chain
ipt_add FORWARD -i $wan -p tcp --sport $portrange
--dport $portrange -j p2pblock
ipt_add FORWARD -i $wan -p udp --sport $portrange
--dport $portrange -j p2pblock
# if p2p-traffic blocked 3 packages to a destination
ip then block all traffic within the next 180 sec (port 1024-65535)
ipt_add p2pblock -m recent --rdest --rcheck --name
P2PBLOCK --seconds $blocktime --hitcount 3 -j DROP
ipt_add p2pblock -m recent --rdest --rcheck --name
P2PBLOCK --seconds $blocktime --hitcount 3 -m limit --limit 1/minute -j LOG
--log-prefix P2PBLOCK-DROP:
# create
Re: [OpenWrt-Devel] freifunk-p2pblock not working properly since firewall change in
Hi soma, Are you sure about kmod-ipp2p? There is no such package to upload and install for opkg, just kmod-ipt-ipp2p. But then again the package repository hosted on openwrt.org is still rc4 and thus a few months old. As a consequence backfire r26799 which I am testing with is already on 2.6.32.27 while rc4 is on 2.6.32.25. I could still install with opkg install kmod-ipt-compat-xtables --force-downgrade but this did not bring improvements. I will recompile the firmware after updating the dependencies for freifunk-p2pblock as per your suggestion and report back. Thanks for the help so far. As I said, happy in user land but at a loss on kernel level. Hopefully it is just a non-updated dependencies as you suggest and I suspected. Cheers Hanno -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Manuel Munz Sent: Saturday, 14 May 2011 2:44 p.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] freifunk-p2pblock not working properly since firewall change in On 14.05.2011 03:48, Hanno Schupp wrote: iptables: No chain/target/match by that name. Hi Hanno the problem was that xt_ipp2p could not be loaded because some symbols were missing: xt_ipp2p: Unknown symbol xtnu_register_match xt_ipp2p: Unknown symbol xtnu_unregister_match xt_ipp2p: Unknown symbol HX_memmem The solution for me on backfire (26851) was to install kmod-ipt-compat-xtables. I added this and also kmod-ipp2p to the depencies list for freifunk-p2pblock. Please let us know if it works now, i just verified it starts now without errors. Regards, soma ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] freifunk-p2pblock not working properly since firewall change in
I am onto something. There seems to be a few missing kernel symbols since the firewall was upgraded about three months ago. I have been given some advice by an openwrt decl team member, will test and report back. On Saturday, 14 May 2011, Hanno Schupp hanno.sch...@gmail.com wrote: Hi soma, Are you sure about kmod-ipp2p? There is no such package to upload and install for opkg, just kmod-ipt-ipp2p. But then again the package repository hosted on openwrt.org is still rc4 and thus a few months old. As a consequence backfire r26799 which I am testing with is already on 2.6.32.27 while rc4 is on 2.6.32.25. I could still install with opkg install kmod-ipt-compat-xtables --force-downgrade but this did not bring improvements. I will recompile the firmware after updating the dependencies for freifunk-p2pblock as per your suggestion and report back. Thanks for the help so far. As I said, happy in user land but at a loss on kernel level. Hopefully it is just a non-updated dependencies as you suggest and I suspected. Cheers Hanno -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Manuel Munz Sent: Saturday, 14 May 2011 2:44 p.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] freifunk-p2pblock not working properly since firewall change in On 14.05.2011 03:48, Hanno Schupp wrote: iptables: No chain/target/match by that name. Hi Hanno the problem was that xt_ipp2p could not be loaded because some symbols were missing: xt_ipp2p: Unknown symbol xtnu_register_match xt_ipp2p: Unknown symbol xtnu_unregister_match xt_ipp2p: Unknown symbol HX_memmem The solution for me on backfire (26851) was to install kmod-ipt-compat-xtables. I added this and also kmod-ipp2p to the depencies list for freifunk-p2pblock. Please let us know if it works now, i just verified it starts now without errors. Regards, soma ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] wpad/hostapd got compiled for the wrong driver
I have a TP-Link MR3220 with trunk 25818 installed all is going well but wifi is not coming up. There seems to be an issue with th driver. wifi up triggers the following output: # wifi up Configuration file: /var/run/hostapd-phy0.conf Line 2: invalid/unknown driver 'nl80211' Line 43: unknown configuration item 'ieee80211n' Line 44: unknown configuration item 'ht_capab' 3 errors found in configuration file '/var/run/hostapd-phy0.conf' Failed to start hostapd for phy0 /etc/config/wireless is the standard configuration produced by /etc/init.d/network boot (with wifi enabled of course): # cat /etc/config/wireless config wifi-device radio0 option type mac80211 option channel 11 option macaddr 74:ea:3a:cd:59:3c[[BR]] option hwmode 11ng option htmode HT20 list ht_capab SHORT-GI-40 list ht_capab TX-STBC list ht_capab RX-STBC1 list ht_capab DSSS_CCK-40 # REMOVE THIS LINE TO ENABLE WIFI: option disabled 0 config wifi-iface option device radio0 option network lan option mode ap option ssid https://dev.openwrt.org/wiki/OpenWrt OpenWrt option encryption none Both kmod ath9k and wpad-mini are installed: # opkg list |grep kmod kmod-ath - 2.6.37.1+2011-02-25-1 kmod-ath9k - 2.6.37.1+2011-02-25-1 kmod-button-hotplug - 2.6.37.1-3 kmod-cfg80211 - 2.6.37.1+2011-02-25-1 kmod-crc-ccitt - 2.6.37.1-1 kmod-crypto-aes - 2.6.37.1-1 kmod-crypto-arc4 - 2.6.37.1-1 kmod-crypto-core - 2.6.37.1-1 kmod-input-core - 2.6.37.1-1 kmod-input-gpio-buttons - 2.6.37.1-1 kmod-input-polldev - 2.6.37.1-1 kmod-ipt-conntrack - 2.6.37.1-1 kmod-ipt-conntrack-extra - 2.6.37.1-1 kmod-ipt-core - 2.6.37.1-1 kmod-ipt-extra - 2.6.37.1-1 kmod-ipt-filter - 2.6.37.1-1 kmod-ipt-ipopt - 2.6.37.1-1 kmod-ipt-ipp2p - 2.6.37.1+1.31-1 kmod-ipt-nat - 2.6.37.1-1 kmod-ipt-nathelper - 2.6.37.1-1 kmod-ipt-ulog - 2.6.37.1-1 kmod-leds-gpio - 2.6.37.1-1 kmod-mac80211 - 2.6.37.1+2011-02-25-1 kmod-ppp - 2.6.37.1-1 kmod-pppoe - 2.6.37.1-1 kmod-sched - 2.6.37.1-1 kmod-textsearch - 2.6.37.1-1 kmod-tun - 2.6.37.1-1 # opkg list |grep wpad wpad-mini - 20110117-1 I had opened a ticket for that, and I got advice that Looks like your wpad/hostapd got compiled for the wrong driver. This would indicate that something must have gone wrong with the compilation, but how could this go wrong? I am not even aware how to change a driver so would not have touched the relevant menuconfig parts. What could cause the firmware to be compiled with a wrong driver? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Clean way of adding custom scripts and firstrun
@ Ithamar Thank you. That is well understood. However, when you write a script to automate a router configuration that should be working cross platform, then you cannot preconfigure the wireless configuration with a static file. First you cannot make assumptions about the hardware present, it could be anything, so you have to allow the system to go through the process of discovery it goes through, when first writing the /etc/config/wireless file. You would also loose router specific configuration, as for the nanostation, or for the various profiles for the ar71xx chipset. You actually want to take up what was preconfigured there, and add, but not remove as you would loose the benefit of the device specific configuration. Consequently a process running after /etc/config/network boot is what is required. @ Jo-Philip The process triggered in /etc/init.d/boot is a great pointer. Thank You. I am toying with the thought of adding a boot command in one of my own start-up scripts, like /etc/init.d/xyz boot Could I just confirm when the init scripts triggered by boot are running: Does the system first run through all boot commands and then through all start commands or does the system run through all scripts in the order given in /etc/rc.d running the boot command first and then the start command for each init script in turn? Please advise. Thank You -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Ithamar R. Adema Sent: Saturday, 29 January 2011 1:47 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Clean way of adding custom scripts and firstrun On Fri, 2011-01-28 at 11:28 +1300, Hanno Schupp wrote: I am asking as some configuration like network and wireless may be set by the system on boot, so if one would like to add to the /etc/config/wireless configuration (i.e. by setting the power to max possible or, setting diversity etc.) then this is not possible, as the /etc/config/wireless file does not exist before /etc/init.d scripts are fired. So this means one would be looking for a first-boot-script facility that is triggered after /etc/init.d is all completed. Does this facility exist? For the example of the wireless configuration file, it will not be generated if it already exists. So if you need to preconfigure it, you could write it out in the uci-defaults script and have the network init.d script pick the generated configuration up and use it. HTH, Ithamar. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Clean way of adding custom scripts and firstrun
Re the /etc/uci-defaults/ scripts: That is a very interesting feature. Two follow up[ questions: 1) do these scripts require the same /etc/rc.common format as the files in /etc/init.d folder or are they just straight shell scripts? 2) when are they called exactly? before or after the init.d scripts, or can this be configured? I am asking as some configuration like network and wireless may be set by the system on boot, so if one would like to add to the /etc/config/wireless configuration (i.e. by setting the power to max possible or, setting diversity etc.) then this is not possible, as the /etc/config/wireless file does not exist before /etc/init.d scripts are fired. So this means one would be looking for a first-boot-script facility that is triggered after /etc/init.d is all completed. Does this facility exist? Thank You. On 28 January 2011 06:59, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. What's the clean way of: 1) adding custom configuration (running custom scripts) on first boot. /etc/uci-defaults/foo.sh, a script which can contain arbritary commands, its deleted by the system after it was invoked once. 2) adding custom files to the openwrt tree on compile. in the toplevel dir: files/, e.g. files/etc/passwd ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1BsoEACgkQdputYINPTPNq3gCfcuU1GR2EhgvzqcLjJX2tjD2Q 0F0AnjW8BKUmwDb7LhmoJpKrCzEBH6Ai =yAdv -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Could 6779 please be backported to Luci 0.10 - still affecting Backfire. Thank You
Thank you for that. As I said, changing to luci 0.10 is a major step change. Is it worth while introducing a rc5 for OpenWRT? Your thoughts? Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 24/01/2011, at 9:23 AM, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Done with http://luci.subsignal.org/trac/changeset/6785 . DynLists now also have buttons again (keyboard based actions still work) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk08ji0ACgkQdputYINPTPOQ5gCdH9DhDwRJSke/RE7lcPzGd0IF +uoAniXZPsSWH1r02Bujju5xzw/rXYOm =J9vY -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Error when adding additional wifi network in Luci 0.10
When pressign the add wifi network buton in Network- wifi I get the following error on a WRT54GL: /usr/lib/lua/luci/model/cbi/admin_network/wifi.lua:219: bad argument #1 to 'ipairs' (table expected, got nil) stack traceback: [C]: in function 'ipairs' /usr/lib/lua/luci/model/cbi/admin_network/wifi.lua:219: in function 'func' /usr/lib/lua/luci/cbi.lua:89: in function 'load' /usr/lib/lua/luci/dispatcher.lua:684: in function 'target' /usr/lib/lua/luci/dispatcher.lua:789: in function 'target' /usr/lib/lua/luci/dispatcher.lua:384: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:146: in function /usr/lib/lua/luci/dispatcher.lua:145 After that the index of the wireless network is confused, so when I update the SSID of one wifi entry, the other one is updated as well to the same SSID. PS: Is this the right forum for Luci error reports? The Luci's Trac is closed for reporting tickets, but open for view only. Please advise. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DynamicList not working in Backfire 10.03.1rc4 0.10 after upgrade from 0.9
Apologies, previously posted in wrong list: In Luci 0.9 something like: s1:option( DynamicList, ... got you a nice filed list with add and delete buttons. In Luci 0.10 this has regressed to just a plain input field. Remember, I am am using a custom header based on 0.9 version of header.htm. And yes, there is a cbi.js, whci needs to be loaded in the htm header. I added that to the header.htm, but still not luck. Suggestion: - Add a hint to cbi.js to the documentation like for xhr.js. Question: - What else needs to chnage to make list fields work again. Something in the lua code that needs to chnage? Please advise. Note: I begin to question to wisdom to ad 0.10 into the 10.03.1rc4 maintenance release of OpenWrt. The style of the version (rc4) suggests incremental bug fixes in preparation for a .1 maintenance release for 10.03, not step change in functionality. Your thoughts? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DynamicList not working in Backfire 10.03.1rc4 0.10 after upgrade from 0.9
Thank you for your reply. I was aware that pressing Return works. However, my point is that it is not immediately obvious that multiple values can be entered on different lines. In the previous solution with plus and minus buttons this was immediately obvious. No, I am not talking about a technical defect here, but about user friendliness. Since in Luci 0.10 a lot of focus was put on graphical support of the GUI, taking the supporting buttons away for Dynamic lists seems like a step back to the point I assumed something was broken. If you tell me this is how it is supposed to be, then my honest and open feedback is that I look at the 0.10 solution for Dynamic lists as inferior to the 0.9 one. Having said that, this should not distract from the overall very positive impression I get from the direction Luci is taking and the strong development support it has. Thank You. On 23 January 2011 02:05, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In Luci 0.10 this has regressed to just a plain input field. Try pressing enter. Remember, I am am using a custom header based on 0.9 version of header.htm. And yes, there is a cbi.js, whci needs to be loaded in the htm header. I added that to the header.htm, but still not luck. No need to. Suggestion: - Add a hint to cbi.js to the documentation like for xhr.js. Not needed. Question: - What else needs to chnage to make list fields work again. Nothing. Something in the lua code that needs to chnage? Nope. Note: I begin to question to wisdom to ad 0.10 into the 10.03.1rc4 maintenance release of OpenWrt. The style of the version (rc4) suggests incremental bug fixes in preparation for a .1 maintenance release for 10.03, not step change in functionality. Your thoughts? Fixing luci-0.9 for backfire is more work than migrating to luci-0.10. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk061iQACgkQdputYINPTPOl0wCfcTm8pkvfa/hwtVlNcwqYBl36 LZUAn3K47XPX2zTqorwSKmcMzdIXJ2NK =OszY -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Luci XML error
When adding a wifi network interface in backfire I get the fllowing XML error in Luci with Firefox: XML Parsing Error: not well-formed Location: http://192.168.2.209/cgi-bin/luci/;stok=3142c2413efe706d6b58d124c48866e2/admin/network/wireless/ Line Number 132, Column 138:lia href=/cgi-bin/luci/;stok=3142c2413efe706d6b58d124c48866e2/admin/uci/saveapply/?redir=/cgi-bin/luci/admin/network/wirelessSave Apply/a/li -^ The arrow is pointing to after the Should the not be converted to amp; by the system ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Luci XML error
Here goes. Nothing to fancy, just added a few more status field in the
header. Worked like a charm in 0.9
Saw your new documentation for 0.10 by the way. Very useful. Much
appreciated.
%#
LuCI - Lua Configuration Interface
Copyright 2008 Steven Barth ste...@midlink.org
Copyright 2008 Jo-Philipp Wich x...@leipzig.freifunk.net
Licensed under the Apache License, Version 2.0 (the License);
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
$Id: header.htm 4891 2009-06-22 10:23:21Z jow $
-%
%
require(luci.sys)
local load1, load5, load15 = luci.sys.loadavg()
local request = require(luci.dispatcher).context.path
local category = request[1]
local tree = luci.dispatcher.node()
local cattree = category and luci.dispatcher.node(category)
local node = luci.dispatcher.context.dispatched
local hostname = luci.model.uci.cursor():get(chilliconfig, router,
hostname)
local secs = math.floor( luci.sys.uptime() % 60 )
local mins = math.floor( luci.sys.uptime() / 60 ) % 60
local hours= math.floor( luci.sys.uptime() / 3600 ) % 60
local days = math.floor( luci.sys.uptime() / 86400 ) % 24
local version = luci.model.uci.cursor():get(chilliconfig, version,
release)
local device = luci.model.uci.cursor():get(chilliconfig, version,
device)
local c = tree
for i,r in ipairs(request) do
if c.nodes and c.nodes[r] then
c = c.nodes[r]
c._menu_selected = true
end
end
require(luci.i18n).loadc(default)
require(luci.http).prepare_content(application/xhtml+xml)
-%
?xml version=1.0 encoding=utf-8?
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Strict//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xml:lang=%=luci.i18n.context.lang% lang=%=luci.i18n.context.lang%
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
meta http-equiv=Content-Script-Type content=text/javascript /
link rel=stylesheet type=text/css media=screen
href=%=media%/cascade.css /
!--[if lt IE 7]link rel=stylesheet type=text/css media=screen
href=%=media%/ie6.css /![endif]--
!--[if IE 7]link rel=stylesheet type=text/css media=screen
href=%=media%/ie7.css /![endif]--
% if node and node.css then %link rel=stylesheet type=text/css
media=screen href=%=resource%/%=node.css% /
% end -%
script type=text/javascript src=%=resource%/VarType.js/script
script type=text/javascript src=%=resource%/XHTML1.js/script
script type=text/javascript src=%=resource%/Dropdowns.js/script
script type=text/javascript src=%=resource%/xhr.js/script
link rel=shortcut icon href=%=media%/resources/favicon.ico /
link rel=icon type=image/ico href=%=media%/resources/favicon.ico /
title%=striptags( hostname .. ( (node and node.title) and ' - ' ..
node.title or '')) % - LuCI/title
/head
body class=lang_%=luci.i18n.context.lang%
p class=skiplink
span id=skiplink1a href=#navigation%:skiplink1 Skip to
navigation%/a/span
span id=skiplink2a href=#content%:skiplink2 Skip to
content%/a/span
/p
div id=header_top
img id=logo src=%=media%/resources/logo.gif /
div id=header
p%=luci.model.uci.cursor():get(chillifire, config, account)%
Firmware Version:
%=version%br /
%:load%: %=%.2f % load1% %=%.2f % load5% %=%.2f % load15%br
/
%:hostname%: %=hostname%br /
Device: %=device%br /
Uptime: %=days%d %=hours%h %=mins%m %=secs%s
/p
/div
/div
div id=divider /div
div id=menubar
h2 class=navigationa id=navigation name=navigation%:navigation
Navigation%/a/h2
ul id=mainmenu class=dropdowns
%-
local function submenu(prefix, node)
if not node.nodes or node.hidden then
return false
end
local index = {}
local count = 0
for k, n in pairs(node.nodes) do
if n.title and n.target then
table.insert(index, {name=k, order=n.order or 100})
count = count + 1
end
end
table.sort(index, function(a, b) return a.order b.order end)
if count 0 then
%
ul id=submenu_%=string.gsub(string.gsub(prefix, /, _), ^_(.-)_$,
%1)%
%-
for j, v in pairs(index) do
if #v.name 0 then
local nnode = node.nodes[v.name]
local href = controller .. prefix .. v.name
.. /
href = (nnode.query) and href ..
luci.http.build_querystring(nnode.query) or href
%
lia% if nnode._menu_selected then % class=active%end%
href=%=luci.util.pcdata(href)%%=nnode.title%/a%-
submenu(prefix .. v.name .. /, nnode)
%/li
%-
end
end
%
/ul
%
end
end
if cattree and cattree.nodes then
local index = {}
for k, node in pairs(cattree.nodes) do
table.insert(index, {name=k, order=node.order or 100})
end
Re: [OpenWrt-Devel] Luci XML error
That does the trick. Is pcdata a new formatting function? Something for the new documentation? Thank you for your help. -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Saturday, 22 January 2011 8:45 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Luci XML error -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Try replacing %=nnode.title% with %=pcdata(nnode.title)% ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk054isACgkQdputYINPTPMF1QCfb87PNtHocLer1FkVGqlWIBHN zQQAoKgzSnYAf8TqJtEnrU1jjkzDjoG7 =Hgog -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire
Not for these web pages specifically. I have some custom controller, cbi and views, that all work fine. I use the standard openwrt.org theme, but have replaced the header and footer with my own .htm files and replaced the css file with my own. Is that what you refer to by templates? -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Thursday, 20 January 2011 9:20 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Do you use custom templates or something? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk03R4QACgkQdputYINPTPMPEwCfTsm3kx57nomLiG138tHXfiJP 1P0AoJOeaJiGPrwOeQ9XuafVFFdKfhH1 =Okgd -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire
Fantastic. That was it. The header.htm was based on the header.htm of luci 0.9, which had other js files included like the dropdown, but not xhr. Suggestion: add some documentation to the luci page that gives required elements ( the create your own theme page ) Offer: I volunteer updating that page, but need edit access to do so. The trac is closed unlike openwrt -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Thursday, 20 January 2011 9:28 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, make sure that your own header.htm contains this: script type=text/javascript src=%=resource%/xhr.js/script ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk03SVQACgkQdputYINPTPOw8QCgndqa2Z3JqDJkdGfnPlO6E11r NvcAnArTfkdgNNuvZdWV5wpNf11umS+H =cqga -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire
While the page seems to work, the js alert is still fire in Chrome, but in Chrome only -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Jo-Philipp Wich Sent: Thursday, 20 January 2011 9:42 a.m. To: OpenWrt Development List Subject: Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 There is a short migration guideline here: http://luci.subsignal.org/trac/wiki/Documentation/LuCI-0.10 I'll add the JS stuff shortly. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk03TH8ACgkQdputYINPTPOFdgCgiRmzNpOg0DmrRDH+UKmkd8p1 r10AoJsdIAfV5RxvUdujaCBNTFJ6syJU =uMU4 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Luci 0.10 issues in Backfire
Google Chrome 8.0.552.237 That is a Linux build Yes, clearing browser cache does not resolve the issue. On 20 January 2011 10:29, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Which chrome build/release exactly? Can you rule out any caching issues? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk03V7cACgkQdputYINPTPPwrACeM4bLzyxGBuzHgSCKn1/F5a6Z xq0AoIEhXpH26aIJjSXRhJoNNqcHQHR4 =qg7J -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Luci 0.10 creates additional network interface 'eth'
Luci seems to assume that there has to be one ethx kind of inderface declaration and tries to 'fix it' when none is found. However, consider this standard /etc/config/network file ofr tp-link 914nd v3 config interface loopback option ifname lo option protostatic option ipaddr 127.0.0.1 option netmask 255.0.0.0 config interface lan option ifname 'lan1 lan2 lan3 lan4' option type bridge option protostatic option ipaddr 192.168.1.1 option netmask 255.255.255.0 config interface wan option ifname wan option protodhcp Yes, wan is wan and lan is lanX in this configuration file - against anything you would expect 'out of the book'. But it works. And you try replace was with eth0, guess what, breaks the wan. So this is obviously intended, but Luci then adds an eth interface in networks and a dhcp entry for eth in /etc/config/dhcp. Maybe something else I did not find? While it does not seem to break anything it is confusing as when you first open the router and the interface goes off creating stuff without the users input or even confirmation. On another note: This is a bug bear in my mind of OpenWrt and must frustrate you as Luci developer without end. With ever more switches being supported it seems that every developer picks and chooses his/her own vlan notation in /etc/config/network. I am aware of at least 4 now. While I appreciate that the drivers all have to be addressed differently, the way the config is noted should be the same. after all it they all enable the same things: - activates vlans or switches it off, - declare your vlans, - assign ports to vlans. Is there not a case to prescribe a standard /etc/config/network notation for vlans and expect all maintainers of the respective driver codes to implement their interface accordingly? The current situation seems to be a too close reflection of the respective switches neeeds for technical notation and needs to be more abstracted. I know we are all special, but this is getting out of hand. Just as thought. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] openwrt-devel post acknowledgement
On closer look, it only added the dhcp configuration automatically. Still, this is odd and should happen without confirming wiuth the user. Also, I noticed that without this dhcp configuration for eth the network pages produce an xml error. On 20 January 2011 12:10, openwrt-devel-boun...@lists.openwrt.org wrote: Your message entitled Luci 0.10 creates additional network interface 'eth' was successfully received by the openwrt-devel mailing list. List info page: https://lists.openwrt.org/mailman/listinfo/openwrt-devel Your preferences: https://lists.openwrt.org/mailman/options/openwrt-devel/hanno.schupp%40gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Hardcoded txpower for wl0 (broadcom devices in Luci 0.10
The new iwinfo funtion gives me the following power output options for my WRT54GL: # iwinfo wl0 txpowerlist 0 dBm ( 1 mW) 6 dBm ( 3 mW) 8 dBm ( 6 mW) 10 dBm ( 10 mW) 12 dBm ( 15 mW) 14 dBm ( 25 mW) 16 dBm ( 39 mW) 18 dBm ( 63 mW) This list is not read from the chip's capabilities but has been arbitrarily hardcoded in iwinfo_wl.c function wl_get_txpwrlist However, the WRT54GL has the capability to go up to 251mW power output, which the new interfaces takes away. Now I do not want to get into arguments about sense and nonsense of the max power output (never managed to fry one in all those years, summer and sun or not, never loose signals so noise is not an issue), I just do not want the software to 'pre-emptively' curb the router's capability artificially. If there is a concenr the default value could be set to 100mW, which I beliee is a very resonbable value. To limit the router to 63mW however, does not make sense to me. Your thoughts? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Backfore 10.03.1rc4 with Luci 0.10 has empty button on main menu pointing to 'servicectl' - code
here the relevant code in the header of the page: ul id=modemenu lia class=active href=/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/mini/ view-source:http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/mini/Essentials/a/li lia href=/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/admin/ view-source:http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/admin/Administration/a/li lia href=/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/servicectl/ view-source:http://192.168.12.1/cgi-bin/luci/;stok=494bf87cbc2529258e1e7d0c793f6567/servicectl//a/li /ul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfore 10.03.1rc4 with Luci 0.10 has empty button on main menu pointing to 'servicectl' - code
Thanks, it appears simple enough to fix: ul id=modemenu% for k,node in pairs(tree.nodes) do - if node.title and not node.hidden then % +if node.title and not node.hidden and k ~= 'servicectl' then % lia% if request[1] == k then % class=active%end% href=%=controller%/%=k%/%=node.title%/a/li% end end % /ul On 18 January 2011 23:36, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, its an oversight. I'll fix it today. ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk01bRcACgkQdputYINPTPPsNgCbBXUQoO8XsSlQwfEm0aOHC2jh slIAnA1Su8H9h/+SR/GJL8+G5jSHxucb =qWnP -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] How to make mini (Essentials) default menu as opposed to admin (Administration)
In the default collection for Luci in trunk and now since 24955 also in backfire the mini (Essentials) menu has gone. I have are requirement for it and have brought it back by adding the dependency in the luci Makefile and adding the package back into the.config file. Easy enough. However, what I cannot figure out is how to make the mini (Essental) menu the default one to show after login. The system seems to default to admin, which is not want I need. Please advise. Thank You ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to make mini (Essentials) default menu as opposed to admin (Administration)
You are right. My apologies. On 19 January 2011 06:54, Jo-Philipp Wich x...@subsignal.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I just tried it in the SDK and mini is still default if present. Are you sure you didn't just clear the cache in /tmp ? ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk010+YACgkQdputYINPTPNEpwCgoyHwME+belU2jy6kRH6aFLqh 6koAn1oTfCFsM/Z01W3WXqSBrGrn4WKL =1XuM -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] URGENT: svn 6749 breaks luci compile in backfire
As per heading. See below. make distclean did not fix it last known revision tested positive: r6745, although looking at track *6749 is the culprit itself, as it deletes luci/branches/luci-0.10/build/ i18n-po2lua.pl in backfire, which is needed for compilation* PS: is there a possibility to pull an earlier version of luci from the repositories as there is with openwrt core with the svn command? make[5]: Entering directory `/home/hanno/backfire/build_dir/target-mipsel_uClibc-0.9.30.1/luci-0.10+svn6749/i18n/english' make[5]: Nothing to be done for `compile'. make[5]: Leaving directory `/home/hanno/backfire/build_dir/target-mipsel_uClibc-0.9.30.1/luci-0.10+svn6749/i18n/english' *mkdir -p host/lua-po* *./build/i18n-po2lua.pl ./po host/lua-po* *make[4]: ./build/i18n-po2lua.pl: Command not found* make[4]: *** [i18nbuild] Error 127 make[4]: Leaving directory `/home/hanno/backfire/build_dir/target-mipsel_uClibc-0.9.30.1/luci-0.10+svn6749' make[3]: *** [/home/hanno/backfire/build_dir/target-mipsel_uClibc-0.9.30.1/luci-0.10+svn6749/.built] Error 2 make[3]: Leaving directory `/home/hanno/backfire/feeds/luci/luci' make[2]: *** [package/feeds/luci/luci/compile] Error 2 make[2]: Leaving directory `/home/hanno/backfire' make[1]: *** [/home/hanno/backfire/staging_dir/target-mipsel_uClibc-0.9.30.1/stamp/.package_compile] Error 2 make[1]: Leaving directory `/home/hanno/backfire' make: *** [world] Error 2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Backfore 10.03.1rc4 with Luci 0.10 has empty button on main menu pointing to 'servicectl'
Since the linkage of Luci 0.10 to 10.03.1rc4 there is now an empty button (no text in it) which points to cgi-bin/luci/servicectl. When clicked a white page appears with the word 'finished' Why is it there and how can I make it go away? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] n2n update to release 3875
Anything wrong with this? I thought this was pretty trivial change. Could this be released, if there is no issue, please? On 29 October 2010 23:03, Hanno Schupp hanno.sch...@gmail.com wrote: Updating n2n to this release allows the inclusion of the mac address to the edge command, which in turns allows the linking of a dhcp server to the supernode, and thus IP address assignment. (For background see http://wiki.freifunk.net/N2n) Tested in bakfire, trunk brcm-2.4., ar71xx and atheros. Signed-off-by: hanno.sch...@gmail.com Index: Makefile === --- Makefile (revision 23702) +++ Makefile (working copy) @@ -9,7 +9,7 @@ PKG_BRANCH:=trunk PKG_SOURCE_URL:=https://svn.ntop.org/svn/ntop/trunk/n2n -PKG_REV:=3667 +PKG_REV:=3875 PKG_NAME:=n2n PKG_VERSION:=$(PKG_REV) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [patch] n2n update to release 3875
Yes? Kind Regards Hanno Schupp Connect Consulting Services Chillifire is a trademark owned by CCS On 30/10/2010, at 10:14 PM, Roger Hardiman ro...@rjh.org.uk wrote: From: Hanno Schupp hanno.sch...@gmail.com Sent: 29 October 2010 11:03 To: OpenWrt Development List openwrt-devel@lists.openwrt.org Subject: [OpenWrt-Devel] [patch] n2n update to release 3875 Updating n2n to this release allows the inclusion of the mac address to the edge command, which in turns allows the linking of a dhcp server to the supernode, and thus IP address assignment. (For background see http://wiki.freifunk.net/N2n) Tested in bakfire, trunk brcm-2.4., ar71xx and atheros. Signed-off-by: hanno.sch...@gmail.com Index: Makefile === --- Makefile (revision 23702) +++ Makefile (working copy) @@ -9,7 +9,7 @@ PKG_BRANCH:=trunk PKG_SOURCE_URL:=https://svn.ntop.org/svn/ntop/trunk/n2n -PKG_REV:=3667 +PKG_REV:=3875 PKG_NAME:=n2n PKG_VERSION:=$(PKG_REV) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] n2n update to release 3875
Updating n2n to this release allows the inclusion of the mac address to the edge command, which in turns allows the linking of a dhcp server to the supernode, and thus IP address assignment. (For background see http://wiki.freifunk.net/N2n) Tested in bakfire, trunk brcm-2.4., ar71xx and atheros. Signed-off-by: hanno.sch...@gmail.com *Index: Makefile* *===* *--- Makefile (revision 23702)* *+++ Makefile (working copy)* *@@ -9,7 +9,7 @@* * * * PKG_BRANCH:=trunk* * PKG_SOURCE_URL:=https://svn.ntop.org/svn/ntop/trunk/n2n* *-PKG_REV:=3667* *+PKG_REV:=3875* * * * PKG_NAME:=n2n* * PKG_VERSION:=$(PKG_REV)* ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [patch] update coova-chilli to version 1.2.5
This brings coova up to speed - tested in backfire and trunk. Signed by: hanno.sch...@gmail.com remove root/packages/net/coova-chilli/patches/001-readd-macauth.patch Index: Makefile === --- Makefile (revision 23710) +++ Makefile (working copy) @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=coova-chilli -PKG_VERSION:=1.2.2 +PKG_VERSION:=1.2.5 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=http://ap.coova.org/chilli -PKG_MD5SUM:=44042e26c3b3c6e64a9a8769328b437d +PKG_MD5SUM:=1b890cb043b4340e1f15c2b2cff742d3 PKG_FIXUP:=libtool PKG_INSTALL:=1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Release 10.03.1 stuck on rc3
@ Alexandros One word: Stability. But look, I have no intention debating the merits of trunk versus stable releases. The developers obviously agree with the philosophy of stable releases; that is why they have established them over time. My inquiry aimed at the apparent impasse to move 10.03.1 from rc3 to final, and associated an offer of support (yet to be responded to). Regards Hanno Schupp -Original Message- From: Alexandros C. Couloumbis [mailto:a...@aventurine.gr] Sent: Wednesday, 27 October 2010 2:44 a.m. To: Hanno Schupp Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] Release 10.03.1 stuck on rc3 On 10/25/10 04:40, Hanno Schupp wrote: Dear OpenWrt Lead Developers, The 10.03.1 development seems to be stuck on 10.03.1 rc3 for a while now. No, I am not going to ask for a release date and I also understand that all openwrt development is based on individuals giving up their own private time. However, I fear that a succession of rc1, rc2 and rc3 within a matter of 2-3 weeks which is then followed by several months of silence is not doing anything to enhance the projects credibility in tems of being alive and well. And looking at the changes that have come through over the last few weeks, well they have receeded to a trickle and are hardly earth shattering. Most importantly the known issue outlined when rc3 was announced has been closed. So what are we waiting for? So here is an appeal to the developers to eitherrelease 10.03.1 as it stands or alternatively, if indeed we are struggling with one or more particular issues to get it released, let the community know what these issues are so we can contribute to an effort to resolve this. I trust this is taken how it is meant, an offer of support to move things along in everyone's interest. Kind Regards Hanno Schupp what's wrong with trunk? -- Alexandros C. Couloumbis Network Operations Center http://www.aventurine.gr/ +30-210-6897-513 #208 Aventurine SA Apostolou Pavlou 10B Marousi 15233 Greece ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Release 10.03.1 stuck on rc3
Dear OpenWrt Lead Developers, The 10.03.1 development seems to be stuck on 10.03.1 rc3 for a while now. No, I am not going to ask for a release date and I also understand that all openwrt development is based on individuals giving up their own private time. However, I fear that a succession of rc1, rc2 and rc3 within a matter of 2-3 weeks which is then followed by several months of silence is not doing anything to enhance the projects credibility in tems of being alive and well. And looking at the changes that have come through over the last few weeks, well they have receeded to a trickle and are hardly earth shattering. Most importantly the known issue outlined when rc3 was announced has been closed. So what are we waiting for? So here is an appeal to the developers to eitherrelease 10.03.1 as it stands or alternatively, if indeed we are struggling with one or more particular issues to get it released, let the community know what these issues are so we can contribute to an effort to resolve this. I trust this is taken how it is meant, an offer of support to move things along in everyone's interest. Kind Regards Hanno Schupp ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt] #7478: add support for Senao EAP7660D board
Hi, Which Senao router/board are you referring to? Lookign either at the Senao or the EnGenius product, there is no reference to an EAP7660D router or board. Did you mean the EAP3660 by any chance? That is the closest product code I could find. Could you respond with a link, please? Thanks. -Original Message- From: openwrt-devel-boun...@lists.openwrt.org [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Daniel Golle Sent: Tuesday, 12 October 2010 4:58 a.m. To: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [OpenWrt] #7478: add support for Senao EAP7660D board all left to have working images in backfire 10.03.1 is backporting changesets 21837, 22187, 22189, 22190 and 22644 (22188 already got backported in r22391 and reformated in r23107) if everybody is ok with that, I'll do that work tomorrow. cheers daniel On Mon, Oct 11, 2010 at 4:06 PM, OpenWrt openwrt-devel@lists.openwrt.org wrote: #7478: add support for Senao EAP7660D board +--- Reporter: daniel.go...@ | Owner: juhosg Type: enhancement | Status: accepted Priority: normal | Milestone: Kamikaze Component: kernel | Version: Trunk Keywords: senao engenius ar71xx | +--- Comment(by daniel.go...@ ): as all needed changes are in trunk now, could we backport stuff into backfire and to be released with 10.03.1? -- Ticket URL: https://dev.openwrt.org/ticket/7478#comment:5 OpenWrt http://openwrt.org Opensource Wireless Router Technology ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
