[OpenWrt-Devel] problem with phyX interface
hi, At many times, I set the phy0 interface on the router and on running tcpdump or my sniffer on it, gives me the following error : phy0: That device is not up How should i get rid of this error, for final deployment of my tool, as the interface fails even after creation using iw command. Kindly help, Abhinav ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] combined extended image
Added in r29358, with minor modifications
Thanks,
--
-{Nico}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] hostname setting and network->hostnames are of no consequence
This is the last one for now! I hope I haven't been too annoying! :) 1) Setting the hostname of the router to anything does not actually add an entry to /etc/hosts. This is a problem if one expects the hostname to resolve to something, and on OpenWRT it does not resolve to anything at all! 2) Also adding entries to Network->Hostnames does not add entries to /etc/hosts either, the only consequence are entries in /etc/config/dhcp (which also seems a bit out of place, given that the hostname is not being added in the DHCP/DNS tab). Cheers! Iordan -- The conscious mind has only one thread of execution. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] wireless problems b43 on wl500w and wrt54gs v2
Where would be a good place to report the problems I had with b43 on my Asus wl500w and Linksys wrt54gs v2? The WL500W never worked with b43, and I had errors such as: b43-phy0: Loading firmware version 508.1084 (2009-01-14 01:32:01) b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO. b43-phy0: Loading firmware version 508.1084 (2009-01-14 01:32:01) b43-phy0 ERROR: Fatal DMA error: 0x0400, 0x, 0x, 0x, 0x, 0x b43-phy0 ERROR: This device does not support DMA on your system. It will now be switched to PIO. After loading the driver with pio=1, those errors disappeared, but the radio still wouldn't work properly. The SSID of the AP would appear momentarily and would be "seen" by other wireless devices around. However, it would disappear very quickly, and obviously trying to connect it wouldn't work. The WRT54GS v2 would appear to operate, but after a week or two of uptime, clients would no longer be able to associate with it, and a reboot was necessary. Both devices now operate with the proprietary Broadcom wl driver, but that is not preferable, as you will all agree! Cheers, Iordan -- The conscious mind has only one thread of execution. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] telnet login impossible after setting administrative password
In the same build from trunk, I noticed that after setting an administrative password, it is no longer possible to login with telnet: === $ telnet 192.168.2.1 -l root Trying 192.168.2.1... Connected to 192.168.2.1. Escape character is '^]'. Login failed. Connection closed by foreign host. === This is bad, because if dropbear is not installed or running, and if luci-app-opkg is not installed, then there is no way to get a shell on the machine from that point on. There is no way to set the administrative password to "" again either. Cheers! Iordan -- The conscious mind has only one thread of execution. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] building image from trunk without dropbear causes impaired functionality
Hello, I built an image from trunk, but didn't need dropbear for my testing so I removed it. When I opened up the LuCI config page, and clicked on either "Go to password configuration..." or the "Administration" tab, I got this error: = /usr/lib/lua/luci/dispatcher.lua:449: Failed to execute cbi dispatcher target for entry '/admin/system/admin'. The called action terminated with an exception: /usr/lib/lua/luci/cbi.lua:264: Unable to read UCI data: dropbear stack traceback: [C]: in function 'assert' /usr/lib/lua/luci/dispatcher.lua:449: in function 'dispatch' /usr/lib/lua/luci/dispatcher.lua:195: in function = A quick workaround for this was to touch /etc/config/dropbear. I think this is a bug, because there may be a reason why somebody would like to not have dropbear in their image, and we are assuming that it's installed. Thanks! Iordan -- The conscious mind has only one thread of execution. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openl2tp - finally enable config file option
On 10/22/11 1:28 PM, Bogdan Roman wrote: > On 20-Oct-11 6:03 pm, Philip Prindeville wrote: >> You need to turn off "flowed=true" when posting patches. > I'm not sure what you mean. It's the first time posting patches on > openwrt ... Look at your mailer's setup. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Changeset 29355 - OpenVPN option enable and Luci
I agree. Having the same option represented 2 different ways can break a lot of stuff... and it's just confusing. Why exactly did it need to be changed? Not sure I understand where this came from... On 11/29/11 4:17 PM, Sven Roederer wrote: > Hi, > > in r29355 a patch was made to accept the "option enable" and "option > enabled" in config-file. > Since r29167 the "option enable" was renamed to "option enabled". This > change caused luci-app-openvpn to not show up the correct state (see > ticket #10473). > > I think it's not the smartest way to have two options for the same > parameter. > > I've already written a small patch to fix the luci-issue, will test it now > and can submit tomorrow. > I don't know if there are still more interfaces to other packages > regarding the "option enable(d)", but may be we should cut the tail and do > a clean cut, the building the bridge (r29335). > > So I suggest to revert this patch and include the luci-app-openvpn-patch. > > > King regards > Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Changeset 29355 - OpenVPN option enable and Luci
Hi, in r29355 a patch was made to accept the "option enable" and "option enabled" in config-file. Since r29167 the "option enable" was renamed to "option enabled". This change caused luci-app-openvpn to not show up the correct state (see ticket #10473). I think it's not the smartest way to have two options for the same parameter. I've already written a small patch to fix the luci-issue, will test it now and can submit tomorrow. I don't know if there are still more interfaces to other packages regarding the "option enable(d)", but may be we should cut the tail and do a clean cut, the building the bridge (r29335). So I suggest to revert this patch and include the luci-app-openvpn-patch. King regards Sven signature.asc Description: This is a digitally signed message part. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] update to new version and add init script for udpxy package
This patch obsoletes http://patchwork.openwrt.org/patch/1600/ and
updates udpxy to version 1.0-Chipmunk-build21.
Signed-off-by: Nerijus Baliūnas
Index: packages/net/udpxy/Makefile
===
--- packages/net/udpxy/Makefile (revision 29357)
+++ packages/net/udpxy/Makefile (working copy)
@@ -9,13 +9,13 @@
PKG_NAME:=udpxy
PKG_REV:=1.0
-PKG_TAG:=Chipmunk-20
+PKG_TAG:=Chipmunk-21
PKG_VERSION:=$(PKG_REV)-$(PKG_TAG)
PKG_RELEASE:=1
-PKG_SOURCE:=$(PKG_NAME).$(PKG_REV)-$(patsubst
Chipmunk-%,Chipmunk-BLD%,$(PKG_TAG)).tgz
+PKG_SOURCE:=$(PKG_NAME).$(PKG_REV)-$(patsubst
Chipmunk-%,Chipmunk-build%,$(PKG_TAG)).tgz
PKG_SOURCE_URL:=@SF/udpxy
-PKG_MD5SUM:=da0a587cfc81fb4a501b07ed84237469
+PKG_MD5SUM:=81f43d742e218aeb8c19fdfae5b7403c
PKG_INSTALL:=1
@@ -42,6 +42,8 @@
INSTALLROOT="$(PKG_INSTALL_DIR)/usr"
define Package/udpxy/install
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) ./files/udpxy.init $(1)/etc/init.d/udpxy
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/bin/udpxy $(1)/usr/bin/
ln -sf udpxy $(1)/usr/bin/udpxrec
Index: packages/net/udpxy/files/udpxy.init
===
--- packages/net/udpxy/files/udpxy.init (revision 0)
+++ packages/net/udpxy/files/udpxy.init (revision 0)
@@ -0,0 +1,27 @@
+#!/bin/sh /etc/rc.common
+
+# To open multicast traffic, add the following rule at the end of
+# /etc/config/firewall file:
+#
+# config 'rule'
+# option 'target' 'ACCEPT'
+# option '_name' 'multicast'
+# option 'src' 'wan'
+# option 'proto' 'all'
+# option 'dest_ip' '224.0.0.0/4'
+
+START=99
+STOP=10
+
+SERVICE_DAEMONIZE=1
+SERVICE_WRITE_PID=1
+
+OPTIONS="-T -S -p 4022"
+
+start() {
+ service_start /usr/bin/udpxy $OPTIONS
+}
+
+stop() {
+ service_stop /usr/bin/udpxy
+}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
On Tue, Nov 29, 2011 at 7:44 PM, Mark Mentovai wrote: > Jonathan Bennett wrote: >> This patch seems like a really good idea for the ar71xx family. What >> sorts of problems are preventing this from being implemented? As small >> as it sounds, an extra 192k would be really useful on quite a few >> routers. > > I don't know of any actual problems with the patch. When I originally > proposed the patch on this list, Dave Taht was concerned that it might > not leave enough headroom to field-update the kernel with a larger one > (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012026.html), I withdraw my objections. > although my position is that this is what the configuration-preserving > sysupgrade feature is for > (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012033.html). although I would like the field update feature to become ever more robust. -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: Reclaim unused space in WNDR3700 image
Jonathan Bennett wrote: > This patch seems like a really good idea for the ar71xx family. What > sorts of problems are preventing this from being implemented? As small > as it sounds, an extra 192k would be really useful on quite a few > routers. I don't know of any actual problems with the patch. When I originally proposed the patch on this list, Dave Taht was concerned that it might not leave enough headroom to field-update the kernel with a larger one (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012026.html), although my position is that this is what the configuration-preserving sysupgrade feature is for (https://lists.openwrt.org/pipermail/openwrt-devel/2011-August/012033.html). My patch is specific to WNDR3700 (and derivatives including WNDR3700v2 and WNDR3800), not the entire ar71xx family. I've been keeping the patch up-to-date (https://dev.openwrt.org/ticket/8781) and have been using it in all of my images for nearly a year. I know that others have been using this patch as well, and it's present in at least one community binary build. In current trunk images, the savings is only 128kB. In the time since I originally wrote this patch, the kernel's grown into another erase block. Someone else suggested detecting the beginning of the rootfs as is done on another target (https://dev.openwrt.org/browser/trunk/target/linux/lantiq/patches/201-owrt-mtd_uimage_split.patch), although I'm not very excited about scanning for a magic number in this manner. It's too fragile. It may be possible to determine the kernel size by other means, which would make it possible for the kernel to calculate the kernel-rootfs split at runtime more reliably. Unfortunately, detecting the kernel partition size in this manner would be board-specific, because different boards load the kernel in different ways. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Maintaining multiple Samba version
Hi, I'd like to discuss here what's the best way to maintain multiple versions of Samba in the package feeds. I would do it this way: - net/samba2 - ancient version - net/samba30x - the 3.0.37 version - net/samba36x - the latest version probably not stripped down Also, we also don't have to forget luci-app-samba. Comments are welcome ;-) Oliver ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] CONFIG_EXTERNAL_KERNEL_TREE not taken in account
Hi.
You must pick the target which matches your board, it is used across
various placing, ranging from optimization flag settings to package
architecture fields. The correct one for the LifeBox would be the
brcm63xx target.
As far as I can see it in my local test it does indeed build the
external kernel, but applies the version from target/linux/$arch
/Makefile to it.
Example:
$ cat
/home/jow/devel/openwrt/trunk/build_dir/linux-brcm63xx/linux-2.6.39.4/00-README-FT.txt
To build the linux kernel, extract the archive, and cd
into linux-2.6.15, then run the following commands:
export PATH="/path/to/mips-linux-uclibc/bin:${PATH}"
mkdir build-dir
cd build-dir
cp ../.config .
mkdir -p include/linux
cp ../include/linux/autoconf.h include/linux
make -C .. O="$(pwd)"
make -C .. O="$(pwd)" INSTALL_MOD_PATH="$(pwd)/modules" modules_install
mips-linux-uclibc-objcopy -O binary vmlinux vmlinuz
The resulting kernel is the file vmlinuz, to be found in
the directory build-dir. The modules will be found in the
modules/ sub-directory.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH-v6]samba 3.0.37 update
Hi. > Should we put the option back? Or should this option be placed somewhere > else? > In any case it seems required. Problem with hardcoding br-lan is that it must not always be a bridge (lan can be unbridged by default as well, for example on the Dockstar which ironically is a NAS appliance). I added a change to expose and resolve ifnames in r29354. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
