Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
* Jo-Philipp Wich x...@subsignal.org [18.06.2009 16:30]: In any case we should keep the stuff compatible with ifconfig/route. for the first time: yes but on the long run we should definitely kick the oldskool-stuff, which is pretty awkward IMHO. (but show a short hint, if somebody types 'ifconfig/router/arp') bye, Bastian Bittorf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New OpenWrt Community Wiki
On 18.06.2009 23:03, David A. Bandel wrote: On Thu, Jun 18, 2009 at 2:34 PM, Matthias Buecher / Germany m...@maddes.net wrote: Hi Kloschi, doesn't work for me: #1 http://wiki.openwrt.org/DropbearPublicKeyAuthenticationHowto should result in http://oldwiki.openwrt.org/DropbearPublicKeyAuthenticationHowto.html so .html is missing #2 slashes have to be converted to (2f) Maddes Folks, Been following this link, and for kicks read the above DropbearPublicKeyAuth... doc. Didn't see an author link, and would like to correct the section Disable password login. Best not to change the startup script, but change the /etc/config/dropbear option PasswordAuth 'on' from on to off and restart dropbear. Ciao, David A. Bandel It's correct for White Russian (still used by a lot of people, e.g. me) and maybe Kamikaze 7. For Kamikaze 8 you are right. Maybe there should be a guideline or document structure to support multiple versions of OpenWrt in the Wiki. Example: explain for current stable version, then explain differences for old versions, at last for unstable versions. Just my two cents Maddes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
On Friday 19 June 2009 09:31:59 Bastian Bittorf wrote: * Vasilis Tsiligiannis b_tsiligian...@silverton.gr [18.06.2009 21:15]: Try removing 'route' too (-ifconfig-route+ip). 'route' can be replaced by 'ip' also, if this function is implemented in busybox. -ifconfig -route -arp +ip arp is already a oneliner in /etc/profile and not compiled into busybox per default. busybox+ip-ipconfig-route: -rwxr-xr-x 1 mss mss 543796 2009-06-19 09:46 busybox -rwxr-xr-x 1 mss mss 632750 2009-06-19 09:46 busybox_unstripped That's only 12k more than busybox-ip+ipconfig+route. I still don't know if busybox' ip can do everything the real one can do. Somebody should test all packages depending on the ip package to see if they work with the busybox variant. I agree that ip is the nicer command, so the ipconfig/route wrapper could go into an own package on which unported packages have to depend and the default image could just have another oneliner in /etc/profile a la arp. Cheers, Malte -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
* Malte S. Stretz m...@apache.org [19.06.2009 11:00]: arp is already a oneliner in /etc/profile and not compiled into busybox per default. this has nothing to do with the real arp command, its just an quick and dirty show the arp table, but you cannot manipulate anything using /proc/net/arp. I agree that ip is the nicer command, so the ipconfig/route wrapper could go into an own package on which unported packages have to depend and the default i think it should be integrated into the core-system, as long it is used so much. the wrapper_scripts are ATM about 10K, but are only sourced if needed... bye, Bastian Bittorf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
Hi! Try removing 'route' too (-ifconfig-route+ip). 'route' can be replaced by 'ip' also, if this function is implemented in busybox. You are right. However I did that a few months ago and ran into problems with Asterisk. For some strange reason it depends on it. Asterisk doesn't connect to other Asterisk servers if 'route' is missing. Cheers, Elektra ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
* elektra onelek...@gmx.net [19.06.2009 12:15]: doesn't connect to other Asterisk servers if 'route' is missing. therefore i implement a route() wrapper. ATM i start at /etc/functions.sh but e.g. asterisk does not use it. maybe it is a good idea to make a symlink for /sbin/route|ifconfig|arp to to wrapper at boottime, to avoid such things? other ideas? bye, Bastian Bittorf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
* Outback Dingo outbackdi...@gmail.com [18.06.2009 16:00]: i have some pretty unique environments here, want to send me the patch i can help with some testing not a clean patch, but easy to install: ssh r...@openwrtbox cd /etc wget -O - http://intercity-vpn.de/files/functions.sh_addon; functions.sh wget http://intercity-vpn.de/files/ip2ifconfig_wrapper.sh wget http://intercity-vpn.de/files/ip2ifconfig_wrapper_function_netmask_to_cidr change the permissions to 'executable', be sure to have 'ip' installed and reboot your box with serial console attached 8-) and send me the log in /www/ifconfigwrapper_log.txt bye, Bastian Bittorf ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] opkg remove ifconfig opkg install 'ip'
* Malte S. Stretz m...@apache.org [19.06.2009 13:15]:
Maybe its just me, but the last few weeks I tried to grok the OpenWrt base-
files scrips (and succeeded [1]) and my impression is that there is already a
lot of stuff crammed into /etc/functions.sh which is sourced by almost
everything but only used by a handful of scripts.
a totally agree. for the firmware in our city-mesh we also
run into that problem. now we have splittet the 500K+scripts
into 'moduls' [1] and source only those, when need like this:
#!/bin/sh /bin/needs
_needs log wifi sanitizer # source parts we need
_sanitizer $(uci get wireless.$WIFIDEV.bssid) mac hex lowercase check || {
func_log check_bssid daemon debug not wellformed
}
only the functions 'needs()' has to know the path/filename of scripts
just for playing with the sanitizer:
http://www.datenkiste.org/cgi-bin/gitweb.cgi?p=fff/.git;a=blob_plain;f=etc/kalua/sanitizer;hb=75e2a2ce08980833e14591f0086c8438a3e8367b
bye, Bastian Bittorf
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [packages] update xtables-addons to 1.17
Hallo Thomas, Le Friday 19 June 2009 17:43:15 thomas.lan...@infineon.com, vous avez écrit : This will update xtables-addons to version 1.17 It fixes some build problems like incompatible arguments for readlink and changes for linux 2.6.30 Signed-off-by: Thomas Langer thomas.lan...@infineon.com It was already done in changeset 16505. Thank you anyway. -- Best regards, Florian Fainelli Email : flor...@openwrt.org http://openwrt.org --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
Le Tuesday 09 June 2009 16:00:47 Michael Buesch, vous avez écrit : On Monday 08 June 2009 21:35:05 matthieu castet wrote: Michael Buesch wrote: On Sunday 07 June 2009 11:28:50 matthieu castet wrote: Hi, I wonder with openwrt for bcm47xx is not build with -msoft-float. The cpu doesn't have fpu and the current floating code get emulated by the kernel emulator instead of using the gcc emulation support (that is cheaper because there is no kernel trap). Well, I guess on a typical bcm47xx setup there's hardly any application that uses floating point math. note that dropbear seems to use some, but that not critical. Does -msoft-float increase the binary/image size? If so, I'd vote for _not_ adding -msoft-float. If it doesn't make a size difference, we should probably add it. That shouldn't increase size of application that don't use float. I did a quick test with dropbear that contain very few float. Here are the results (sfloat means -msoft-float, sgcc mean -shared-libgcc) $size /tmp/dropbear* textdata bss dec hex filename 22692442521744 232920 38dd8 /tmp/dropbear 23471943281744 240791 3ac97 /tmp/dropbear_sfloat 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc 21995641521744 225852 3723c /tmp/dropbear_sgcc As you can see with a static libgcc the size of the softfloat binary increase (8k) because all float emulation code is duplicated in the binary. With a shared libgcc the softfloat binary is smaller, the increase size is less than 1k. I don't know the impact for whole binary. I should try to build a typical bcm47xx setup and see the impact. Ok. It still smells like we're trying to solve a problem that does not exist. Is the performance of any app increased in real life? We can still allow soft-float to be used in the toolchain, and keep the in-kernel FPU emulator for compatibility, but then we will loose some space. -- Best regards, Florian Fainelli Email : flor...@openwrt.org http://openwrt.org --- 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
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
On Friday 19 June 2009 18:20:53 Florian Fainelli wrote: Le Tuesday 09 June 2009 16:00:47 Michael Buesch, vous avez écrit : On Monday 08 June 2009 21:35:05 matthieu castet wrote: Michael Buesch wrote: On Sunday 07 June 2009 11:28:50 matthieu castet wrote: Hi, I wonder with openwrt for bcm47xx is not build with -msoft-float. The cpu doesn't have fpu and the current floating code get emulated by the kernel emulator instead of using the gcc emulation support (that is cheaper because there is no kernel trap). Well, I guess on a typical bcm47xx setup there's hardly any application that uses floating point math. note that dropbear seems to use some, but that not critical. Does -msoft-float increase the binary/image size? If so, I'd vote for _not_ adding -msoft-float. If it doesn't make a size difference, we should probably add it. That shouldn't increase size of application that don't use float. I did a quick test with dropbear that contain very few float. Here are the results (sfloat means -msoft-float, sgcc mean -shared-libgcc) $size /tmp/dropbear* textdata bss dec hex filename 22692442521744 232920 38dd8 /tmp/dropbear 23471943281744 240791 3ac97 /tmp/dropbear_sfloat 22078141921744 226717 3759d /tmp/dropbear_sfloat_sgcc 21995641521744 225852 3723c /tmp/dropbear_sgcc As you can see with a static libgcc the size of the softfloat binary increase (8k) because all float emulation code is duplicated in the binary. With a shared libgcc the softfloat binary is smaller, the increase size is less than 1k. I don't know the impact for whole binary. I should try to build a typical bcm47xx setup and see the impact. Ok. It still smells like we're trying to solve a problem that does not exist. Is the performance of any app increased in real life? We can still allow soft-float to be used in the toolchain, and keep the in-kernel FPU emulator for compatibility, but then we will loose some space. Yeah well. That's my question. Do we actually gain performance or do we only loose some space? If we do _not_ gain performance, it certainly is not a good idea to waste space. -- Greetings, Michael. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] RFC: Adding IPv6 support to uci_firewall
Any comments, ideas, flames? I'm also hanging around on #openwrt as moonflux. Hello Malte, Just a quick flame to have fun ;) I see you are doing IPv4 and IPv6 firewall, it is very nice and I'm a IPv6 supporter as well. However, before using an IPv6 firewall I'd like to be able to assign IPv6 addresses to my router ! But how do you assign IPv6 addresses at boot ? Can you reproduce this bug ? https://dev.openwrt.org/ticket/5356 there is out there some patch not already committed that fixes this problem ?? thank you :) Saverio Proto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] random MAC addresses on TEW-652BRP
I loaded openwrt svn 16516 on my TEW-652BRP and noticed that I was getting
random MAC addresses assigned:
ar71xx: using random MAC address for eth0
ar71xx: using random MAC address for eth1
My investigation of this lead me to examine the following files:
target/linux/ar71xx/files/arch/mips/ar71xx/devices.c
target/linux/ar71xx/files/arch/mips/ar71xx/prom.c
target/linux/generic-2.6/files/arch/mips/fw/myloader/myloader.c
target/linux/generic-2.6/files/include/linux/myloader.h
dmesg reports the following message from prom.c and myloader.c:
prom: fw_arg0=0002, fw_arg1=8006040c, fw_arg2=,
fw_arg3=
MyLoader: sysp=ccc4fdcd, boardp=efbccce7, parts=cdedfcee
From the above, I can determine that myloader_get_info() will return null,
because the magic values read above don't match those in myloader.h:
snip from myloader.h
/* Myloader specific magic numbers */
#define MYLO_MAGIC_SYS_PARAMS 0x20021107
#define MYLO_MAGIC_PARTITIONS 0x20021103
#define MYLO_MAGIC_BOARD_PARAMS 0x20021103
end snip from myloader.h
snip from myloader.c
struct myloader_info * __init myloader_get_info(void)
{
struct mylo_system_params *sysp;
struct mylo_board_params *boardp;
struct mylo_partition_table *parts;
if (myloader_found)
return myloader_info;
sysp = (struct mylo_system_params *)(SYS_PARAMS_ADDR);
boardp = (struct mylo_board_params *)(BOARD_PARAMS_ADDR);
parts = (struct mylo_partition_table *)(PART_TABLE_ADDR);
printk(KERN_DEBUG MyLoader: sysp=%08x, boardp=%08x, parts=%08x\n,
sysp-magic, boardp-magic, parts-magic);
/* Check for some magic numbers */
if (sysp-magic != MYLO_MAGIC_SYS_PARAMS ||
boardp-magic != MYLO_MAGIC_BOARD_PARAMS ||
le32_to_cpu(parts-magic) != MYLO_MAGIC_PARTITIONS)
return NULL;
end snip from myloader.c
Jon
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] use of soft-float on bcm47xx
2009/6/19 Michael Buesch m...@bu3sch.de: On Friday 19 June 2009 18:20:53 Florian Fainelli wrote: Le Tuesday 09 June 2009 16:00:47 Michael Buesch, vous avez écrit : On Monday 08 June 2009 21:35:05 matthieu castet wrote: Michael Buesch wrote: On Sunday 07 June 2009 11:28:50 matthieu castet wrote: Hi, I wonder with openwrt for bcm47xx is not build with -msoft-float. The cpu doesn't have fpu and the current floating code get emulated by the kernel emulator instead of using the gcc emulation support (that is cheaper because there is no kernel trap). Well, I guess on a typical bcm47xx setup there's hardly any application that uses floating point math. note that dropbear seems to use some, but that not critical. Does -msoft-float increase the binary/image size? If so, I'd vote for _not_ adding -msoft-float. If it doesn't make a size difference, we should probably add it. That shouldn't increase size of application that don't use float. I did a quick test with dropbear that contain very few float. Here are the results (sfloat means -msoft-float, sgcc mean -shared-libgcc) $size /tmp/dropbear* text data bss dec hex filename 226924 4252 1744 232920 38dd8 /tmp/dropbear 234719 4328 1744 240791 3ac97 /tmp/dropbear_sfloat 220781 4192 1744 226717 3759d /tmp/dropbear_sfloat_sgcc 219956 4152 1744 225852 3723c /tmp/dropbear_sgcc As you can see with a static libgcc the size of the softfloat binary increase (8k) because all float emulation code is duplicated in the binary. With a shared libgcc the softfloat binary is smaller, the increase size is less than 1k. I don't know the impact for whole binary. I should try to build a typical bcm47xx setup and see the impact. Ok. It still smells like we're trying to solve a problem that does not exist. Is the performance of any app increased in real life? We can still allow soft-float to be used in the toolchain, and keep the in-kernel FPU emulator for compatibility, but then we will loose some space. Yeah well. That's my question. Do we actually gain performance or do we only loose some space? If we do _not_ gain performance, it certainly is not a good idea to waste space. I would be very surprised if we wouldn't. Every kernel emulated floating point operation results in an exception and the appropriate handling (fpu emulation is ugly), while soft-float should stay completely in user space. Also, the mips fpu emulator itself suggests that. Quoting linux/arch/mips/math-emu/cp1emu.c: * Note if you know that you won't have an fpu, then you'll get much * better performance by compiling with -msoft-float! To get some numbers: Perhaps could somebody test with 'sample' from libmpcdec the difference in speed between in-kernel emulation and soft-float? https://dev.openwrt.org/ticket/4715 suggests that the library depends heavily on floating point when not using fixed point math. Regards, Jonas Gorski ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
