Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE
>> - While brands have value, you can change a name without losing all the >> brand recognition. I'm thinking here of cases like XBMC->Kodi or >> OpenOffice-> LibreOffice. > I would point at OpenOffice -> LibreOffice as a failure of name changes. There are several aspects in a name change. E.g. whether someone who hears the new name is likely to know what it is and that it's related to the old name. In the case of LibreOffice, I think this part of the name change worked just fine: all people I know who know OpenOffice also recognize LibreOffice as "the name as some OpenOffice-derivative". So it does carry over the brand recognition. Yes, there are a lot of people who still download OO, but that part of the problem is linked to the fact that the two projects didn't merge, so there was no effort on the OO part to educate people about the new name and redirect them to the LibreOffice web site, doc, etc... Currently, LEDE has the same problem as LibreOffice, but compounded by the fact that most people have no idea what LEDE is, let alone that it's somehow related to OpenWRT. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Talks between OpenWrt and LEDE
> Yocto. If lede were to succeed in meeting its other goals, coherently, > preserving "lede" and moving forward as a separate project does make > sense. I don't have a clear opinion either way, but I think there are several points to take into account: - OpenWRT indeed has a fair bit of positive name recognition, but mostly within a fairly small community. - The OpenWRT name has downsides: - "Open" clearly hints at Open Source, whereas I'd personally appreciate a reference to Free Software. - "WRT" is inherited from the venerable wrt54g, whereas the project has grown past those "wrt" devices. - While brands have value, you can change a name without losing all the brand recognition. I'm thinking here of cases like XBMC->Kodi or OpenOffice->LibreOffice. So maybe it's a good idea to use the (still hypothetical, but hopefully close) merge to advertise a rename which will both aim to carry-over the brand recognition at the same time as it sends the message that it's something "new and better" (i.e. keep the good brand recognition and try to shed the bad one). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH, v2] dnsmasq: prevent forwarding RFC6303 zones
> RFC6303 specifies reverse dns zones that ideally should not be forwarded > to upstream (root) servers and create unnecessary load upon them. Shouldn't this be done upstream (i.e. in dnsmasq directly) rather than in our config? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT support for MPR-A1
AFAICT OpenWRT comes with some support for the Hame MPR-A1 thingy (although its 16MB of RAM and 4MB of flash probably prevent it from being fully supported). I had no trouble building an image for it, but now I'm wondering how to install that image. I went to http://wiki.openwrt.org/toh/hame/mpr-a1 which gives various information, but it doesn't say how to actually install an image on that box. The page for MPR-A2 (whose hardware and firmware seem very similar) says that the image can be installed via the factory web UI. Does someone know if that would work for the MPR-A1 as well? And if it doesn't work, would it just immediately fail, leaving the factory firmware untouched, or would it result in an unbootable machine (and if so would it be recoverable via the serial console)? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] what's the rationale for mixed quotes in Config.in help?
This option group includes the `libanl' library which Back before XFree86 consolidated misc-fixed and other such fonts to cover (a small subset of) Unicode, these two chars where typically rendered under X11 as symmetric quotes (the ' quote was tilted a bit like the accent of é). So the above convention became ugly right around that point, but being very widespread before, it still lives on in various places. Emacs still uses it extensively, for example. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation
Why do you want GitHub to close so bad !!! I don't. There are indeed many other cases where you may want to move to something else. The problems stay the same. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Moving all feeds to OpenWrt GitHub organisation
We use git, the day github closes, or asks for money, or ..., we move. Notice how right after suggesting github, you suggested using its bugtracker. It's only when github closes your access that you realize you didn't stick to just using Git. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v5] ppp: add new protocol PPPoSSH.
you want, using tun devices (ssh -w), without the recursive TCP issues. The -w switch has the exact same TCP-over-TCP issue. But don't worry: TCP-over-TCP is used everyday by lots of people. It's not perfect, but it works well enough for many uses. That's why ssh provides -w and that's also why OpenVPN can work both on UDP and on TCP: the TCP-over-TCP option is never the first choice, but it's pretty convenient at times. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Making sense of OpenWRT / Linksys WRT1900AC collaboration claims
I'm not sure if I can adequately address all of your concerns, but I may be able to clear up some confusion. It seems that there was no confusion at all. The problem is that Belkin/Linksys lied about its involvement with the OpenWRT community and what you're saying confirms it. The reaction here is rather hostile for that reason. The OpenWRT community would actually be thrilled to help along, if Linksys gave it the opportunity. But marketing lies compounded with wording that makes it sound like the problem is all on OpenWRT's side doesn't help with the collaboration. Of course, the hostile reaction here doesn't help with that collaboration either, but it's due in large part to the disappointment. So I suggest to start over: have the marketing department fix those lies, then send some patches over here in manageable chunks, and send some sample units to some of the key developers, maybe make a public Git branch for the ongoing not yet integrated effort. On the other side, the OpenWRT can then show its pleasure by incorporating some of those patches, and maybe publicize the collaboration on its home page. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Changing default Fragmentation Threshold and RTS/CTS Threshold
With new values: 9.1 MB/s Sounds amazingly high for a noisy environment (I'm no specialist, but I've never gotten such high bandwidth over wifi). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Support for USB LTE modems Samsung GT-B3730 / GT-B3710 / GT-B3740
I'd like to use a Samsung GT-B3740 USB LTE modem together with OpenWRT. To get it to build just add a declaration to Another option is to compile it directly into your kernel, via make kernel_menuconfig -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Installing OpenWRT on a Gigaset SX762
[ Previously posted on openwrt-users, but now that it failed halfway, I figure that installing via httpd isn't really an option at all. ] I finally got my Gigaset back, so I can get back at installing OpenWRT on it. I have replaced the secondary bootloader, so I get the HTTP server requesting the firmware image. All seemed to be well. Except that when I submit that firmware, the request never ends. [ See below my sig for the story of what happens in more details. ] So I figure I should try and flash it via tftp, but I have no idea what command to use for that. The webpage (http://wiki.openwrt.org/toh/gigaset/sx76x) shows some commands to use to replace the primary bootloader, but that doesn't give me enough hints to know what commands to use. Any idea? Stefan Regarding flashing over the recovery httpd, after soldering the serial line, I now see that the upload goes *rey* slow, repeating patterns of the form: 214253 / 3145732 215699 / 3145732 .217145 / 3145732 218591 / 3145732 220037 / 3145732 221483 / 3145732 Where every dot is a 1s wait (give or take). At this rate, it would take days before the firmware is uploaded, and when I tried that, the process stopped after transferring a bit more than 2MB. Not sure what's going on: there always seem to be 3 packets sent together, followed by a wait. The first few packets get sent without waiting, but once I get to around 200KB, the wait starts appearing. It appears gradually, with an exponential pattern: first 3 blocks followed by a single ., then 3 blocks followed by .., then 3 blocks followed ..., then ..., then ., ... until hitting the limit seen above. I tried to run a ping at the same time, figuring it might disrupt the wait, but to avail. Any idea what might be going on, or how I can try to fix it? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Installing OpenWRT on a Gigaset SX762
is that danube or amazon based board? Danube. In case that is danube board please use openwrt/v2013.07 branch to get u-boot going: https://github.com/danielschwierzeck/u-boot-lantiq/commits/openwrt/v2013.07 Is that required to install OpenWRT? How do I install that u-boot? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Installing OpenWRT on a Gigaset SX762
Except that when I submit that firmware, the request never ends. [ See below my sig for the story of what happens in more details. ] After trying a few more times with various machines, it finally worked right (without those long waits). So now I managed to install the attitude adjustment image for danube (using the secondary u-boot's httpd server). Next problem: the boot fails to find the root filesystem (see attached bootlog). Is this a known problem? Obviously, I'll need to build my own image, but since the stock one fails to boot, I'm wondering what I should change in the config to try and make sure mine does boot properly. Stefan [0.00] Linux version 3.3.8 (blogic@Debian-60-squeeze-64-minimal) (gcc version 4.6.3 20120201 (prerelease) (Linaro GCC 4.6-2012.02) ) #1 Sat Mar 23 11:36:28 UTC 2013 [0.00] SoC: Danube rev 1.3 [0.00] bootconsole [early0] enabled [0.00] CPU revision is: 00019641 (MIPS 24KEc) [0.00] Determined physical RAM map: [0.00] memory: 0200 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Zone PFN ranges: [0.00] Normal 0x - 0x2000 [0.00] Movable zone start PFN for each node [0.00] Early memory PFN ranges [0.00] 0: 0x - 0x2000 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: console=ttyLTQ1,115200 rootfstype=squashfs,jffs2 machtype=GIGASX76X [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 32 bytes [0.00] Writing ErrCtl register=0003b628 [0.00] Readback ErrCtl register=0003b628 [0.00] Memory: 29216k/32768k available (2413k kernel code, 3552k reserved, 404k data, 176k init, 0k highmem) [0.00] NR_IRQS:256 [0.00] CPU Clock: 333MHz [0.00] Calibrating delay loop... 221.18 BogoMIPS (lpj=442368) [0.036000] pid_max: default: 32768 minimum: 301 [0.04] Mount-cache hash table entries: 512 [0.048000] NET: Registered protocol family 16 [0.056000] gpiochip_add: registered GPIOs 0 to 15 on device: ltq_gpio [0.06] gpiochip_add: registered GPIOs 16 to 31 on device: ltq_gpio [0.064000] MIPS: machine is GIGASX76X - Gigaset SX761,SX762,SX763 [0.068000] gpiochip_add: registered GPIOs 200 to 223 on device: ltq_stp [0.108000] bio: create slab bio-0 at 0 [0.116000] PCI host bridge to bus :00 [0.12] pci_bus :00: root bus resource [mem 0x1800-0x19ff] [0.124000] pci_bus :00: root bus resource [io 0x1ae0-0x1aff] [0.128000] pci :00:0e.0: unsupported PM cap regs version (6) [0.132000] pci :00:0e.0: BAR 0: assigned [mem 0x1800-0x1800] [0.136000] pci :00:0e.1: BAR 1: assigned [mem 0x1801-0x18010fff] [0.14] pci :00:0e.1: BAR 0: assigned [io 0x1ae0-0x1ae7] [0.144000] pci :00:0e.0: SLOT:14 PIN:1 IRQ:30 [0.148000] pci :00:0e.1: SLOT:14 PIN:1 IRQ:30 [0.152000] Switching to clocksource MIPS [0.16] NET: Registered protocol family 2 [0.168000] IP route cache hash table entries: 1024 (order: 0, 4096 bytes) [0.176000] TCP established hash table entries: 1024 (order: 1, 8192 bytes) [0.18] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [0.188000] TCP: Hash tables configured (established 1024 bind 1024) [0.192000] TCP reno registered [0.196000] UDP hash table entries: 256 (order: 0, 4096 bytes) [0.204000] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [0.208000] NET: Registered protocol family 1 [0.216000] gptu: totally 6 16-bit timers/counters [0.22] gptu: misc_register on minor 63 [0.224000] gptu: succeeded to request irq 126 [0.228000] gptu: succeeded to request irq 127 [0.232000] gptu: succeeded to request irq 128 [0.236000] gptu: succeeded to request irq 129 [0.244000] gptu: succeeded to request irq 130 [0.248000] gptu: succeeded to request irq 131 [0.256000] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.26] JFFS2 version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [0.272000] msgmni has been set to 57 [0.276000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [0.284000] io scheduler noop registered [0.288000] io scheduler deadline registered (default) [0.292000] ltq_asc.1: ttyLTQ1 at MMIO 0x1e100c00 (irq = 112) is a ltq_asc [0.30] console [ttyLTQ1] enabled, bootconsole disabled [0.30] console [ttyLTQ1] enabled, bootconsole disabled [
[OpenWrt-Devel] Installing OpenWRT on RA-5350 without serial
Has anyone figured out to install OpenWRT on something like a Hame MPR-A1 without opening the device and connecting a serial line? Most of those devices offer a plain busybox shell via telnet and support for usb-storage, so it should be possible to install OpenWRT via /dev/mtd*, but AFAIK the few that attempted ended up with a device that doesn't boot any more (tho IIUC it can be salvaged via the serial line). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Improve generated ext4 images
NAK. Journaling is disabled on purpose, as it wears out flash based devices faster. I don't know of any non-anecdotal evidence showing that the difference is significant. OTOH the added reliability afforded by journaling (especially for the kind of boxes that typically run OpenWRT where it's often simpler to unplug the box than to loginshutdown) is pretty clear. So I'd strongly vote in favor of enabling journaling, even on flash-based devices. and you installed this on a SD card ?! ext3 with journalling, yes, many times. Haven't tried yet with ext4, but I see no reason why it should be very different. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Initial DSL framework for Lantiq
and allows you to start and start the daemon. (with-smartypants-mode But what if I want to start it instead?) Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /dev/watchdog from shell script
I did this on my boxes, but it does not help. Again a device is _pingable_, but all daemons are not responding anymore: So either: - watchdog was killed and this just disabled the watchdog timer altogether. - watchdog was not killed for some reason (e.g. because the kernel considered that it holds on to some important resource). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] rsyncd: Add description and allow rsyncd.conf to survive sysupgrade
Just a thought. The directory reserved for uci should have been named something like /etc/uci-config. Or maybe just /etc/uci since /etc means config. But it's much too late to change any of it. OTOH maybe sysupgrade should handle /etc differently: instead of only preserving a few specific files, it should preserve all files in /etc except for a few specific files/directories. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Gigaset SX763
I'm curious about this box, it looks very interesting as a replacement for my current ADSL modem/router which is one of the last non-Free computer I use daily. Is the ADSL modem working well under OpenWRT? And what about the FXO/FXS ports? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] split rsyncd into a separate package
Ian Add an initscript to the rsync package for use as a daemon, and a Ian sample rsyncd.conf to show a simple setup. Ian Signed-off-by: Ian Leonard antonla...@gmail.com Split rsyncd into a separate package Make rsyncd a separate config option so that people who don't want an rsync daemon using up RAM can still select the rsync client. Depends on rsync for the binary, the rsyncd package just consists of the init script and configuration files. Doesn't seem worth the trouble: the rsync daemon is not started by default (IIUC), so your patch doesn't save any RAM, all it saves is the rsyncd.conf and rsyncd.init files, which are both small. Maybe you could gain a big more if you made a stripped down rsync binary that did not include support for the --daemon option, but even that won't save you much disk space. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Retaining WAN IP addresses across reboots
I note that the file /tmp/state/network contains the interface, ip address, and expiration time of the WAN DHCP lease... I'm wondering what's involved in writing that information into somewhere persistent where it can be reused on reboot? You may want to start by replacing the /var symlink to /tmp by a real directory. OpenWRT should be using the /var/state/network filename, so after performing the above change, the file will be preserved across reboots. If not, report it as a bug. I'm not sure if OpenWRT will later start udhcpd in such a way as to take advantage of this pre-existing file, but that's a second step. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] block-extroot and firmware updating/flashing
Picky, picky. ;-) No, no, just picky. Well other than binaries that depend on the kernel like iptables you should be right about the uClibc binaries. But the normal case (i.e. not custom) is to load the modules after extroot, so that's what we build extroot for. If you really care and want to submit patches that are suitably generic, we'll of course take a look at them. That's fine. I just wanted to check whether there was some deep reason I wasn't aware of. I don't think it's a big issue since upgrading the firmware already requires several steps anyway, so a few more is not a big deal. I.e. it's a very low-priority annoyance. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] block-extroot and firmware updating/flashing
the disabling is being done deliberately to give users a chance / force them to clean up the overlay after a reflash. So this test is only for the `overlay' case, not the new option target / case, right? No, it's for both because the option target / case still has the same problem, namely incorrect kernel modules and possibly broken uClibc binaries after a firmware flash, so in both cases the user probably needs to update for the system to not brick after a firmware upgrade. I see there's indeed a problem for kernel modules (tho if you insmod all the modules in squashfs+jffs before pivoting to the extroot, this is not an issue), but for uclibc binaries I can't imagine how that can be relevant in the non-overlay case. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] block-extroot and firmware updating/flashing
the disabling is being done deliberately to give users a chance / force them to clean up the overlay after a reflash. So this test is only for the `overlay' case, not the new option target / case, right? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Refactoring base-files
- clean code (not obfuscated) Obviously agreed. But there are likely disagreements about what is clean and what is obfuscated. Turning a oneliner sed into a 10-liner read/while/case/set loop is usually not an improvement in my book (as discussed previously). If you want to avoid forking a sed process while keeping the code clean, you'll probably want to first develop a library of sh functions that let you do things like `map' an operation over a list of things. It does NOT help to make a oneliner and 1000 users asks themself: what does THIS line? [3] sed code can be inscrutable, yes, but a single `s'ubstitution is not, no matter how complex the regexp may be. This doesn't meant that a oneliner sed script is necessarily the best option, just that it's probably not the thing on which to concentrate. But while we are at it: - don't fork, if not needed. examples from /etc/init.d/compache: [ `cat /proc/swaps | grep 'ramzswap0'` != ] swapoff /dev/ramzswap0 That's an obvious one, yes. It's even a great contender for the Useless Use of Cat Award (http://partmaps.org/era/unix/award.html). better use: fgrep -q ramzswap0 /proc/swaps || ... Yes, *much* better. I'd even call it a bug-fix (think of the day where /proc/swaps decides to start lines with a dash). - use function_names to say what you want to do Agreed. - use better shell builtins, instead of invoking another language (e.g. awk, sed, lua) - only if there is no other option No other option is much too strong here: we want the code to be clean, first and foremost, so if the awk code is cleaner I'd much prefer we use it. - using of shell builtins, leads to lower mem usage and are (mostly) faster Yes, but the shell's facilities are very primitive. Sometimes it's a bit like writing assembly code. Hence the need for a good library of shell functions that encapsulate the low-level code. - make an official coding-style (at the moment much is mixed) Fine. Might prove difficult, but it's a worthy experiment. - make an offical way, how to solve typical problems in scripts Seems to say the same as the previous point, so again: fine. - make base-files (experimental) which can be selected in menuconfig and i will maintain it. if people select it, they know the risk I'll let OpenWRT maintainers decide if it's a good idea. But I don't think it's particularly necessary: if you submit a patch which actually improves the code (e.g. the cat|grep thingy above), I see no reason to leave it in an experimental branch rather than in the normal files. OTOH, if there's disagreement over whether it's an improvement, then it just means it needs more work or should be dropped. Then again, maybe some of the changes can't be made incrementally. In that case, maybe a separate branch is in order. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] The future of block-extroot and preinit
1) More space for packages is needed than available flash storage (we may also want more data storage, but generally that doesn't depend on having a larger rootfs, as it can easily go somewhere other than root) I can think of 2 separate cases: a) the extra flash space is owned: it's expected to be handled mostly as a non-removal disk, so for example you can merge their etc/rc.d into /etc/rc.d via symlinks. b) the extra flash space comes and goes and packages may be added/removed from it without our knowledge (e.g. a flash-key with extra maintenance packages which you share among various openwrt devices, or an nfs-mounted /opt, again shared among various devices). 2) We need more space for /etc than there is on flash storage (e.g. for the usbutils package, which downloads the identifiers to /etc) I'd be tempted to say that this should be handled by fixing usbutils to put those identifiers elsewhere (/etc is for configuration, not for auxiliary data). 3) We want to run the system off external storage and just use the flash to do the initial system loading. 4) We want to run some other os, and just want to use OpenWrt as a glorified boot loader. I've used both and I think they can and should be treated identically. * opkg gives out of space when installing to a non-default opkg target, if the default opkg target doesn't have enough room for the package (even though that's not where we're installing) Right, a plain bug. * incomplete support for using packages not in PATH=/bin:/sbin:/usr/bin:/usr/sbin * preinit lets the default PATH be set, we just need to make a slight modification so that the path used by init can be changed on the jffs and not only in a prebuilt image * libraries need to be loaded from non-default locations, probably requiring ldconfig and /etc/ld.so.conf In case `a', we could simply add symlinks from /lib, /bin, etc/rc.d/, ... * we need the device with the extra packages mounted before init For most/all the uses I can think of, this is not really needed: we could do the init for the / packages first, and afterwards call an init routine for the /opt packages that would run their /opt/etc/rc.d. After all, you want the system to be partially functional even when the external storage is not available. * For #2 an alternate /etc would need to be mounted before init As mentioned, I think #2 itself should be considered as a case we need to avoid, rather than as a situation which we want to support better. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] p910nd print server useless without usblp kernel module
The p910nd driver provides a bidirectional network interface to USB connected printers. Actually, it can be either unidirectional or bidirectional. And I don't know of a case where the bidirectional code is useful (I'm partly to blame for its existence, because I thought it would let the driver of my printer get the printer's ink levels, but I was much too naive). As such, it won't work without the 'lp' USB class (implemented in drivers/usb/class/usblp.c). AFAIK it works fine with a parallel port printer. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files/hotplug: refactoring ifup/netstate V2
it is always a bad idea to mix up different languages in one environment. I don't accept this is a valid starting point. I agree that it is useful to limit the number of tools/languages you use, but you should still try and use the right tool/language for the right job. now we use ash-builtins to get uptime_in_seconds() instead of using cryptic sed-style. All those restyle to avoid the use of awk and sed are really useful? I don't believe. The use of sed an awk should not be consider a different languages simple because aren't different languages but just tools like read or cut. Indeed: /bin/sh was designed around the idea that running an external command like `sed' is basically equivalent to a function call to a library function. That's why /bin/sh is very limited in the text-handling functionality it provides directly. So by and large, `sed' is part of the /bin/sh language (I've managed to survive 20 years of unix without ever really learning awk, so I don't feel quite as strongly about awk as about sed). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: refactoring load_modules()
I was never satisfied with the ugly hack, how kernel-modules were loaded in openwrt, but it works since the beginning. here is a proposal to do it clean and also fast with ash-builtins. As an outsider, I'd just like to say that I find this new code more complex for very little benefit. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: refactoring load_modules()
As an outsider, I'd just like to say that I find this new code more complex for very little benefit. really? more lines maybe, but straightforward and not hacky. I guess it's a question of taste, but to me that current code is clean, straightforward, and concise. About as good as it gets. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] extroot not using overlay? (was Re: [OpenWrt] #8542: various hangs with extroot (mini_fo) using ext4)
I want the flexibility of the former. I want my extroot device to be the entire root filesystem of my system and not require a particular flashed image because it relies on files in the flashed image's root filesystem. Exactly like everybody else, indeed. That's why there's no need for extroot to support the `overlay' case. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] extroot not using overlay? (was Re: [OpenWrt] #8542: various hangs with extroot (mini_fo) using ext4)
to make alone. I think pivot_root is better than chroot for the purposes of running init and in general for avoiding gotchas, but that can be done without an overlay, if that is the consensus. As someone who uses an external root (tho using a hand-made patch rather than your extroot, mostly because your extroot came later), I don't want an overlay, but I indeed want a pivot_root rather than a chroot. Also OpenWRT should be careful to perform the pivot_root with a minimum amount of dependencies between the before-pivot and after-pivot code (e.g. at some point OpenWRT's scripts let a hotplugd running during the pivot_root, relying on the after-pivot code to kill the daemon started by the before-pivot code. This creates an undesired dependency between the two which makes upgrades more difficult). At some point I used a Debian install as extroot, using OpenWRT as a kind of kernel+initramfs, and while I do not encourage people to do that, I think it's good to keep this kind of usage in mind: it helps keep the code's behavior clean. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] extroot not using overlay? (was Re: [OpenWrt] #8542: various hangs with extroot (mini_fo) using ext4)
Why not have the implementation look at what's on the extroot device and if it's an overlay filesystem format then execute the overlay codepath(s) and otherwise assume it's a standalone filesystem and mount it and pivot_root to it. I'm not sure there's a way to tell the difference: the overlay filesystem always uses a standard filesystem (e.g. can be ext3), tho you could try and detect the presence of the special meta-files that the overlay system uses. I'm not sure it's worth the trouble: just like the previous poster, I've never seen a real reason why would this be better for extroot. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Anyone interested in porting mailman and postfix to openwrt?
extend the life of the device... in theory. A colleague of mine was using PGP encryption on his SSD boot drive and had it fail after a couple of thousand writes. That's just an early drive failure, unrelated to the fact that flash memory wears out. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Advice needed -- the Avahi package.
Question: How should I do that? Should I create a new set of packages, called, say, avahi-with-dbus...? Or should I just put some kind of a flag in the Makefile of the existing avahi package? How 'bout following the example of hostapd, and rename the current avahi to avahi-mini or some such? Question: Is it best just to leave D-BUS alone completely and change the START number for avahi, say to 70, so that it loads after D_BUS? Don't take my word for it, but I see no particular reason why avahi needs to be started early, so moving it after 70 sounds like a good solution. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] inclusion of adm8668 / WRTU54G-TM
I apoligize ahead of time. I am hardly a developer, but I've been mucking around with the WRTU54G-TM since March. I was told to port to 2.6 to get included in trunk, and I did! I have tarball at http://wrt.scottn.us/openwrt-trunk-adm8668.tar.gz That's very interesting. But I can't find anywhere a clear description of the hardware it provides. Also, does your code support the phone ports (e.g. can they work with asterisk?). What can you do with the SIM thingies? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DHCP and wifi-reconnection
So: how can I configure OpenWRT to always do a DHCP request upon wifi-(re)connection, even when it already has a valid IP-lease? Ping? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] DHCP and wifi-reconnection
When I reboot my AP/router, my print server (running OpenWRT) ends up being unknown: I can still connect to it via its IP address, but its DNS name is lost. This is simply due to the fact that the DNS name comes from the DHCP registration and that when the AP/router is rebooted, OT1H the AP/router loses this DNS info, and OTOH the print server doesn't re-issue a DHCP request upon reconnection, since the IP-lease it has is still valid. I do not have much control over the AP/router sadly, so I can't solve the problem there. OTOH on the print-server side, not only do I have complete control, but re-issuing a DHCP request might be a really good idea: after all, wpa_supplicant can be configured to reconnect to some other network if the primary fails, so after wpa_supplicant connects to a network, I'd want to *always* perform a DHCP-request to get a fresh new IP-lease. So: how can I configure OpenWRT to always do a DHCP request upon connection, even when it already has a valid IP-lease? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Solos 4610 (conexant) adsl router, anyone?
Once you telnet into it try to type uname -a and see if it is Linux ! :) No, the telnet daemon doesn't give me a normal shell. It gives me some kind of text-based interactive configuration system (that somewhat mirrors what the web pages provide). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Solos 4610 (conexant) adsl router, anyone?
I inherited from a DSL modem+router whose firmware describe as a Solos 4610 RD / Solos 461x CSP v1.0, and telnet shows me a big `conexant' banner. Just going from the hardware, this seems to be a Connexant CX96410 based device. There is no OpenWRT port, but there are linux sources for a Linksys device using the same SoC (WAG54G2 v1.0, [1], [2]). Also the Netgear DG834G v5[3] uses it, and there seem to sources available on the netgear ftp [4]. Great, thanks. So there's hope, but there's also a lot of work left to do, Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ohci_hcd: Unknown symbol ssb_ehci_detach
I'm getting the above error message on a WL-500g, with a firmware compiled a couple days ago from a fresh checkout of svn://svn.openwrt.org/openwrt/branches/backfire. It seems to be related to https://dev.openwrt.org/ticket/6425 (and https://dev.openwrt.org/ticket/7059), which claims to be fixed, so it looks like the fix didn't make it to backfire. Is there a fix for it for backfire, or should I use the bleeding-edge, instead? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction patch
OK, if you interpret it like that, one doesn't need to deblob the kernel source. We only need a configuration value that avoids installing the non-free stuff. Of course, that's just my opinion, I don't speak for the LibreWRT guys. I personally would really like it if OpenWRT labelled each non-free part and made it clear which part is free and which isn't (e.g. by placing all the non-free packages (i.e. packages which include some non-free element) in a separate (sub)menu). I would recommend keeping the current menu structure based upon functionality and not free/non-free That might be OK as well, but then the Freeness of a package should be made clear some other way. For non-free packages, would something like DEPENDS=-LIBRE work? If CONFIG_LIBRE is defined, these packages would simply disappear from the menu. That's too black-or-white for me: I generally want to avoid non-Free code, but I'm still willing to use it in some cases. So maybe we could have such a variable to hide/show the non-Free packages, but even if the non-Free packages are shown, I'd like to know which ones are Free. And maybe when exiting the config menu, the stdout could display a summary of the non-Free packages included. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction patch
The user that builds its own firmware from scratch either knowns which packages are free or he/she does not care. How would a user (who cares) know which package is Free and which isn't? I'm fairly well versed in those matters, and yet, even I don't know for sure for all packages. And most users who don't care probably don't even know there's something to care for, so making the difference clear might bring them to learn to appreciate the distinction. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LibreWRT introduction patch
In other words, I wonder why one would like to deblob. As long as you don't install the blobs in the image, you are not using it. So if you already downloaded it, what is the use of removing it above just not installing and using it. IIUC the issue is not whether to download this or not, but whether it gets (installed and) used. So it's mostly a matter of marking the un-free parts and then making them only available upon a very explicit request. The degree to which the request should be explicit is of course something that depends on how much you care about this kind of freedom. I personally would really like it if OpenWRT labelled each non-free part and made it clear which part is free and which isn't (e.g. by placing all the non-free packages (i.e. packages which include some non-free element) in a separate (sub)menu). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WAN brought up after reboot but not after power-on
Did you attach anything to the GPIO? A Capacitor? Do you have a serial cable? Yes, I have a serial cable now? (part of the reason was to debug this problem, as well as some others, but it didn't help) Compare the bootlogs. (reboot hard reset.) Thanks, I'll do that next time (will be a while, tho, since I'll be a few thousand Km away from it for the next 3-4 months). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WAN brought up after reboot but not after power-on
My wrtsl54gs running Backfire 10.03 has the following problem: If I unplug replug the power cable, it boots fine except that the WAN connection (using DHCP) is not up (i.e. I have to log in and say ifup wan, after which it all works fine). Interestingly, rather than iup wan I can also do reboot which will work as well (tho a lot slower ;-). This is fully repeatable (power-cycling never brings up WAN, whereas reboot always does). Any idea what might be the culprit? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] firewall not brought up right at boot
My wrtsl54gs running Backfire 10.03 does not bring up the firewall
correctly at boot. I have to /etc/init.d/firewall restart to make
it work. I.e. the following script works around the problem:
$ cat /etc/rc.d/S97sm-firewall
#!/bin/sh /etc/rc.common
START=97
start () {
# Don't know why, but the firewall doesn't come up in the right
# state until after I restart it.
(: sleep 60; /etc/init.d/firewall restart)
}
$
[ I first thought a delay was needed, but experience shows the sleep can
be commented out, as above. ]
I looked at the iptables -vL output and there's no difference between
the two cases. The only difference is in the nat table (see the diff
after my sig, along with my firewall config).
Any idea what might be the problem?
Stefan
$ diff -u /tmp/iptable-nat-reboot /tmp/iptable-nat-reboot+restart
--- /tmp/iptable-nat-reboot 2010-06-17 11:13:59.314196799 -0400
+++ /tmp/iptable-nat-reboot+restart2010-06-17 11:12:09.639806473 -0400
@@ -1,13 +1,15 @@
-Chain PREROUTING (policy ACCEPT 81 packets, 9517 bytes)
+Chain PREROUTING (policy ACCEPT 628 packets, 78074 bytes)
pkts bytes target prot opt in out source
destination
- 85 9979 prerouting_rule all -- anyany anywhere
anywhere
+ 616 77287 zone_wan_prerouting all -- eth1 any anywhere
anywhere
+ 12 787 zone_lan_prerouting all -- eth0 any anywhere
anywhere
+ 632 78618 prerouting_rule all -- anyany anywhere
anywhere
-Chain POSTROUTING (policy ACCEPT 28 packets, 1892 bytes)
+Chain POSTROUTING (policy ACCEPT 8 packets, 584 bytes)
pkts bytes target prot opt in out source
destination
- 28 1892 postrouting_rule all -- anyany anywhere
anywhere
- 28 1892 zone_wan_nat all -- anyany anywhere
anywhere
+ 30 2204 postrouting_rule all -- anyany anywhere
anywhere
+ 30 2204 zone_wan_nat all -- anyany anywhere
anywhere
-Chain OUTPUT (policy ACCEPT 27 packets, 1852 bytes)
+Chain OUTPUT (policy ACCEPT 28 packets, 2104 bytes)
pkts bytes target prot opt in out source
destination
Chain postrouting_rule (1 references)
@@ -27,10 +29,11 @@
Chain zone_lan_nat (0 references)
pkts bytes target prot opt in out source
destination
+0 0 MASQUERADE all -- anyeth0anywhere anywhere
-Chain zone_lan_prerouting (0 references)
+Chain zone_lan_prerouting (1 references)
pkts bytes target prot opt in out source
destination
-0 0 prerouting_lan all -- anyany anywhere
anywhere
+ 12 787 prerouting_lan all -- anyany anywhere
anywhere
Chain zone_vpn_nat (0 references)
pkts bytes target prot opt in out source
destination
@@ -41,9 +44,10 @@
Chain zone_wan_nat (1 references)
pkts bytes target prot opt in out source
destination
+ 22 1620 MASQUERADE all -- anyeth1anywhere anywhere
-Chain zone_wan_prerouting (0 references)
+Chain zone_wan_prerouting (1 references)
pkts bytes target prot opt in out source
destination
-0 0 prerouting_wan all -- anyany anywhere
anywhere
+ 616 77287 prerouting_wan all -- anyany anywhere
anywhere
0 0 DNAT tcp -- anyany anywhere anywhere
tcp dpt:22 to:192.168.1.211:22
0 0 DNAT tcp -- anyany anywhere anywhere
tcp dpt:21 to:192.168.1.1:22
$ cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Not sure why, but this seems to be needed for the traffic
# to be properly forwarded from VPN to WAN.
iptables -A forwarding_rule -i tun0 -j ACCEPT
# I'm also having trouble forwarding from LAN to WAN, so let's try
# the same rule for LAN.
#iptables -A forwarding_rule -i eth0 -j ACCEPT
$ cat /etc/config/firewall
config defaults
option syn_flood1
option inputACCEPT
option output ACCEPT
option forward REJECT
config zone
option name lan
option inputACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name vpn
option inputACCEPT
option output ACCEPT
option forward
Re: [OpenWrt-Devel] WAN brought up after reboot but not after power-on
Did you attach anything to the GPIO? A Capacitor? Do you have a serial cable? Yes, I have a serial cable now? (part of the reason was to debug this problem, as well as some others, but it didn't help) Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall not brought up right at boot
I think this is directly related to your wan issue. Creation of the missing rules is triggered when wan is brought up. Hmm... good to know. Note that this problem appears regardless if I reboot or if I power-cycle (i.e. the firewall is wrong regardless of whether the WAN is brought up or not). But yes, I guess there could be a common underlying cause. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] backfire and asus wl-500gp v1 with 128MB ram
And now with the new WRT54G3Gv2-VF the box will be bricked if the nvram is *not* fixed up... So *this* particular fixup should be applied without human intervention. Most of the others shouldn't. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] backfire and asus wl-500gp v1 with 128MB ram
- nvram settings are bad, but the machine is still able to boot and we can login remotely. /etc/init.d/nvram would execute here and fix the critical vars. Or it might brick the machine instead. And since remote login is possible, there was no urgency that justified taking such a risk. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] backfire and asus wl-500gp v1 with 128MB ram
The init script mostly reset the cpu clock and the sdram configs. Some idiots over clocked there routers are caused problems, linksys also bumped the clock to 216 in one update to cover up a instability. SDRAM settings have to do with early version of DD-WRT and I think one specific version of the linksys firmware. Asus may have also had a bad version. (nbd made the first nvramcleaner.sh, you can ask him or look into the WR section of the forum) You were not here back when this was first conceived and thus you don't know, it's clear we need better documentation. I don't think the issue is just documentation. I see 4 possible cases: - nvram settings are good: nothing to do. - nvram settings are bad, the machine can't boot: nothing to do. - nvram settings are bad, but the machine is still able to boot and we can login remotely. - nvram settings are bad, the machine boots up to the nvram-cleanup script, but can't do much more (e.g. can't login remotely into the machine). The last case is the only one that justifies modifying the nvram setting without human oversight. If this fourth case doesn't exist, then we'd be better off turning the nvram-fixup into a warning, to avoid taking the risk of bricking the device. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Watchdog on brcm47xx
I.e. it seems the reboot part is failing. Does anybody know this problem or has some idea what it might come from? Has anybody managed to get the watchdog to work on such a machine (or a similar one, maybe wl500gp or some such)? We add an emergency_restart(); I attach a patch Thanks. Does anyone know why this is necessary? If the restart is performed by the kernel, then what's the advantage of using bcm47xx_wdt over softdog? Ping? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Watchdog on brcm47xx
I.e. it seems the reboot part is failing. Does anybody know this problem or has some idea what it might come from? Has anybody managed to get the watchdog to work on such a machine (or a similar one, maybe wl500gp or some such)? We add an emergency_restart(); I attach a patch Thanks. Does anyone know why this is necessary? If the restart is performed by the kernel, then what's the advantage of using bcm47xx_wdt over softdog? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Watchdog on brcm47xx
I've been having non-reproducible hangs with my wrtsl54gs for a while now (after finally installing a serial console I got to see that these are caused by CPU 0 Unable to handle kernel paging request at virtual address Any idea what that can come from?). While trying to track down this problem I discovered that the watchdog doesn't work either. Since I was running a Sep-2009 firmware (2.6.30.7), I figured I'd first try to update it. So I just recompiled and installed a new firmware (from the backfire SVN branch). And the problem stays the same: - the machine boots, which starts the busybox `watchdog' daemon. - I kill pid the watchdog. - I watch the logread -f, which says: May 28 17:28:18 oficina user.crit kernel: bcm47xx_wdt: Unexpected close, not stopping watchdog! May 28 17:29:17 oficina user.crit kernel: bcm47xx_wdtWatchdog will fire soon!!! - the machine is now frozen (including on the serial console). I.e. it seems the reboot part is failing. Does anybody know this problem or has some idea what it might come from? Has anybody managed to get the watchdog to work on such a machine (or a similar one, maybe wl500gp or some such)? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] backfire and asus wl-500gp v1 with 128MB ram
I have added a patch that should fix the problem: https://dev.openwrt.org/changeset/21497 sdram_init was changed because some ASUS WL-500GP showed only 16MB RAM and not 32MB. That script fixed that problem. I really don't think that patching a suboptimal nvram setting is worth the risk to brick a router. Instead, it could simply spit a warning in the syslog explaining the situation and how the setting can be fixed (such that the reader should be able to assess whether the diagnostic is correct before actually performing the dangerous operation). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
Less file system overhead on the flash side and no memory used to manage the structures needed to insmod / rmmod. Exactly. Maybe also a tighter memory layout since each module doesn't have to be in its own set of ELF sections, IIUC. Also, the linkage would be (presumably) static rather than dynamic. I don't think gcc will take much advantage of it, but it could otherwise also enable further code optimizations. Regardless, I would guess that the overhead is quite minimal. Could be. But my OpenWRT router has 48 modules, half of which claim to use 2KB or less. The total of the sizes reported by lsmod is 968928 bytes, whereas the corresponding total of the sizes of the module files in /lib/modules is 1970768. Those numbers don't guarantee anything (I don't know what the lsmod numbers mean, really), but they seem to indicate that there's at least the potential for a significant gain. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
While I have seen the size listed in lsmod and /proc/modules, I don't really know what it represents. I am assuming that it means code size and not memory. I suspect so as well. Still, it may point to an opportunity. Make sure that you are counting the size of the files in /lib/modules only for modules you have loaded, and we might have a better picture of typical flash savings. I was careful to do that (there was only one module in /lib/modules that was not loaded, actually: switch-adm). I still don't think that much RAM will be saved, but the flash savings may be worth it if one has enough modules loaded. My gut feeling is split between waste of time and easy money. Someone will have to try it out. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
but wouldn't the increase in the kernel image actually equal the decrease in the squash image and therefore the size of the rootfs_data stay the same? Both are lzma compressed. I expect that a kernel with some modules built-in will be smaller (both in terms of flash space and in terms of RAM use) than the same kernel plus the same modules compiled as modules. Whether the difference is significant or negligible, I don't know. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [backfire] WRT54G flash space problem
Put all kmods (2) I needed into the kernel. How? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How to create an OpenWrt Package Makefile for source without a Makefile
Tried to create an OpenWrt of a small VoIP proxy for a friend. Unfortunately the source itself does not have a Makefile. It just says Use: gcc -o mjproxy md5.c mjproxy.c. You've had answers to your question, but I'll point out that a better answer might be to provide a Makefile. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update lvm2 to 2.02.63
jdonohue654-openwrt == jdonohue654-openwrt jdonohue654-open...@yahoo.com writes: This proposed patch updates lvm2 build script to 2.02.63 ... the previous version (2.02.60) is no longer available for download. this update also necessitated some minor changes to patches/100-readline-link.patch (Previous attempt bounced ... apologies if you get 2 submissions). Signed-off-by: Jack Donohue jdonohue654-open...@yahoo.com Thanks, installed in r21002. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03 Released
Highlights and changes since last stable release: [...] * New web server uhttpd (busybox httpd now disabled, as default) Other than being different, what does it bring? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openntpd resists arrest
So please do not hesitate to submit patches in the future, it should be quite a bit more pleasurable than it may have been previously. Definitely. I wasn't so much complaining as rejoicing at the fact that patch submission seems to be working now. As Emacs maintainer, I know full well that it's tremendously difficult to give the needed attention to every submission, so when a patch of mine gets ignored, I do get frustrated of course but I also know the other side is equally frustrated at not being able to keep up. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Howto debug init scripts like preinit?
I've never needed to really get into the startup scripts much but now I need to try and understand how the mini_fo union gets set up so I'm trying to learn the startup scripts like preinit. When I ad to fiddle with this part of the code, I'd add some echo blabla /tmp/mydebug in those scripts and then read the /tmp/mydebug file (of course, this only worked in those cases where the boot script did end up setting up my router in such a way that I was able to log in to look at the damn file). Another option might be to send that debug output to the network as is done in preinit_net_echo and read it via tcpdump. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] openntpd resists arrest
When I /etc/init.d/ntpd stop one of the two openntpd processes is still left running. Apparently killall ntpd is not sufficient. So I use the patch below which seems to work. Applied in r20317, thanks! Thank you for finally installing my patches. Many of them were going through their third submission or so (identical, BTW, the first one dating back to at least January 2009). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Typo in dhcp-fwd.init
Simple typo.
Stefan
Index: net/dhcp-forwarder/files/dhcp-fwd.init
===
--- net/dhcp-forwarder/files/dhcp-fwd.init (révision 19649)
+++ net/dhcp-forwarder/files/dhcp-fwd.init (copie de travail)
@@ -4,7 +4,7 @@
LOG_D=/var/log
RUN_D=/var/run
-PID_F=$RUN_D/dhcpd-fwd.pid
+PID_F=$RUN_D/dhcp-fwd.pid
start() {
[ -d $LOG_D ] || mkdir -p $LOG_D
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] openntpd resists arrest
When I /etc/init.d/ntpd stop one of the two openntpd processes is
still left running. Apparently killall ntpd is not sufficient.
So I use the patch below which seems to work.
Stefan
Index: net/openntpd/files/ntpd.init
===
--- net/openntpd/files/ntpd.init(révision 19649)
+++ net/openntpd/files/ntpd.init(copie de travail)
@@ -14,5 +14,6 @@
}
stop() {
- killall ntpd
+# -1 seems insufficient to kill one of the two underlying processes.
+ killall -9 ntpd
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] start mpd normally
The patch below makes /etc/init.d/mpd start the MusicPlayerDaemon in
a more normal way:
1- it stops it from rebuilding the database at every start (which can take
a very very long time on large databases).
2- it stops it from going through the trouble to create the music
database directory (even if it exists, as long as its empty you won't
be able to do much with it anyway).
3- it stops it from messing up the playlist (adding all the songs in the
universe to it) and from starting to play that messed up list
forcefully right away (convenient when your machine happens to reboot
at 3am).
4- it uses `nice' if available to boost `mpd's priority to reduce the
likelihood of skipping. In my experience (using this mpd on a small
home-router box), this is indispensible to avoid skipping, and I have
never noticed it affecting the general performance and responsiveness
of the machine.
Points 1 and 3 are really important for most normal uses I can think of.
Point 2 is not important.
Point 4 is important for my use case, tho maybe less so for others;
Still, within the context of OpenWRT, I expect it's common to run on
slow machines where nice is necessary to avoid skipping, so I think it
deserves to be used by default.
Stefan
Index: sound/mpd/files/mpd.init
===
--- sound/mpd/files/mpd.init(révision 19649)
+++ sound/mpd/files/mpd.init(copie de travail)
@@ -4,27 +4,22 @@
start() {
#create mpd directories
- md=`grep music_directory /etc/mpd.conf | cut -d \ -f 2 | sed
s/~/\/root/g`
- if [ ! -d $md ]; then
- mkdir -p $md
- fi
pld=`grep playlist_directory /etc/mpd.conf | cut -d \ -f 2 | sed
s/~/\/root/g`
if [ ! -d $pld ]; then
mkdir -p $pld
fi
- #create mpd db
- /usr/bin/mpd --stdout --create-db
- #optional export for mpc
- #export MPD_HOST=127.0.0.1
-
+# Set the initial volume to something manageable
+amixer set PCM 40
+
#start mpd
- /usr/bin/mpd
-
- #generate playlist and start to play
- /usr/bin/mpc listall | /usr/bin/mpc add -
- /usr/bin/mpc play
- /usr/bin/mpc repeat
+if [ -x /bin/nice ]; then
+# This has real-time constraints, so let's at least tell the OS
+# that this should have higher priority to avoid skipping
+# when doing other things in the background.
+nice=nice -n -10
+fi
+$nice /usr/bin/mpd
}
stop() {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Backfire 10.03-beta
Binaries can be downloaded at http://downloads.openwrt.org/backfire/10.03-beta/ Is there some equivalent Svn revision, branch, or the trunk rev-number from which it was branched? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured
This patch allows multiple listen ports to be configured for dropbear in /etc/config/dropbear. It renames the 'Port' option to 'Ports', so this will break existing configs. Shouldn't this be sent to the dropbear upstream maintainers? It doesn't seem specific to OpenWRT at all. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dropbear: allow multiple listen ports to be configured
No, as his patch only modifies OpenWrt scripts and uci. The functionality of multiple ports with only one DropBear instance is already in DropBear. Duh... sorry for being so dense, Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Automount enhanced/fixed, also fstab
Certainly a label or uuid is possible, but the problem isn't convincing OpenWRT to boot into a rootfs, but making sure the rootfs has the appropriate binaries. Indeed. Part of the solution is to reduce as much as possible the linkage between the squashfs/jffs2 part of the boot and the rest of the boot after pivoting. E.g. just before pivoting, we should make sure there's no daemon running any more (e.g. udev/hotplug). This makes it easier/possible to upgrade the firmware separately from upgrading the ext-rootfs. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
The Asus WL520GC I just bought is running Linux. It has 2MB of flash. Wow, I assumed that out of the box, these devices with a small amount of flash did not run Linux. That was true in the past at least. Things have changed since I last checked... obviously. DD-WRT micro images also run on 2MB devices, see for contained functionality http://dd-wrt.com/wiki/index.php/What_is_DD-WRT%3F#File_Versions , so why should openwrt fail to do so? I already compiled images smaller than 2MB. Functionality was limited of course. Indeed. The only difference is that there is no predefined config for such small targets, so you have to manually select the part of busybox you want to strip, and similarly for the kernel config. You should be able to get pretty close to DD-WRT's config, while still benefitting from OpenWRT's configurability. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
Still, you need jffs2 there (both the jffs2 partition and the jffs2 modules). That's a lot of flash space for something that's not actually needed. And of course, it's also an added step when installing upgrading the firmware. Having a fallback jffs2 is something most people have said they think is required. Hmm... [my Flash doesn't have space for jffs2 :-( ] I wonder why they think it's required. actually, the squashfs is likely to contain much more than the bare minimum; Why? If your rootfs is on USB or some such, there's little point in including lots of stuff in your squashfs. Again, popular request is for a fallback jffs2. Still: if you do use the jffs2, then having the jffs2 in there is quite compatible with little point in including lots of stuff in your squashfs: are there going to be modules in your squashfs that are not used before mounting the external rootfs, and if so what good are they? Well, I'm looking at it from the point of view of a user who'd like to be able to directly tell make menuconfig that his rootfs is on /dev/hde1, in which case any configuration on top of the rootfs device name is an annoyance. Having an automatic configuration option is something I intend to have, however it won't be the default, because it's not as safe. In which sense is it less safe than your flash firmware after you've set the config file to mount the external rootfs? Also, you can easily make it fallback on squashfs+tmpfs if the partition is not found (after some timeout, let's say) or if the partition is found but without /sbin/init. So at least for USB drives, you can just disconnect the drive while booting to fallback to a safe state. And there's always the failsafe mode as well. [ Still talking from my experience with a WL-700gE where a jffs2 was not an option. And in my case, disconnecting the drive was not really an option since it's IDE. ] Well Felix has suggested a way of dealing with this, so that we don't need the modules, or for that matter a config file separate from /etc/config/fstab Wonderful, tho I missed that email. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] block-extroot: the next iteration
config mount option 'uuid' 'some-uuid-here' OR option 'label' 'fs-label' OR option 'device' '/dev/device' option 'target' '/usb' option 'fstype' 'ext3' option 'enabled' '1' option 'enabled_fsck' '1' option 'is_rootfs' '1' Why not get rid of is_rootfs and just use option 'target' '/' instead? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
As such I think it would be very useful to have a minimum build (just enough to bring up interfaces and install additional packages) Agreed. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] 2mb flash not OpenWRT-Target?
Linux can hardly fit in a 2MB flash device, once you have opened the Yes, but this text was written in the old times (2004?) I've been using OpenWRT on my WL-700gE for a while now. That machine has a 2MB flash, so OpenWRT is quite usable there. But yes, it also has a IDE interface, so the 2MB only serves as a sort of initramfs (indeed, I don't even include a jffs2 partition, only squashfs). Linux is more and more modularized, so it is comfortably possible to run it (customized) with 4MB RAM and 512k of FLASH. This may be true, but I've found that the firmware for my WL-700gE tends to grow overtime, so while it's more and more modularized allowing it to run on ever smaller devices, for a given set of features its size tends to increase over time rather than decrease. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
This has to be manually configured after the first boot (and requires a reboot after a sysupgrade first boot). H... that's a problem. It means that you can't just have squashfs+extroot but need a jffs2 inbetween just for this little cconfig. Actually the squashfs/jffs2 is a fallback full firmware in the event of Inevitable Disaster(tm). Still, you need jffs2 there (both the jffs2 partition and the jffs2 modules). That's a lot of flash space for something that's not actually needed. And of course, it's also an added step when installing upgrading the firmware. config 'modules' 'modules' list 'fs_modules' 'fs-ext3' list 'controller' 'usb-core' list 'controller' 'usb-ohci' list 'controller' 'usb-storage' In my (limited experience), load all the available modules works just dandy: after all, these are only the modules available in the proto-root filesystem, so they're likely to be pretty close to the bare minimum. Could you explain the rationale for the relatively sophisticated config of modules you're proposing here? actually, the squashfs is likely to contain much more than the bare minimum; Why? If your rootfs is on USB or some such, there's little point in including lots of stuff in your squashfs. it's got whatever the user menuconfig selects as their base router configuration and it's harder to do something about things going wrong in preinit, so minimizing the modules loaded is useful. In addition hotplug doesn't coldplug in init. That means hotplug events aren't generated unless the modules are loaded after hotplug (in /etc/init.d/boot). I'll take your word for it on these issues. They haven't affected me, but that's not statistically significant. And, finally, it's really not very sophisticated. It just loads modules if they're listed, the same was as load_modules for the main system does, except it loads specific modules instead of all available. Well, I'm looking at it from the point of view of a user who'd like to be able to directly tell make menuconfig that his rootfs is on /dev/hde1, in which case any configuration on top of the rootfs device name is an annoyance. It's not terribly complicated code in my opinion, so shouldn't be a problem. I meant complex for the user, not for the implementer. I mean, as a user, I've already had to select which modules to include in my squashfs so that my rootfs can be found, so writing this file is an annoyance, and will hold redundant info, except that I additionally have to figure out whether it should say fs_modules or controller or maybe something else. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] External Rootfs (e.g. USB)
Here is the first part of the rootfs on external (i.e. not the squashfs, jffs, or boot root) rootfs (right not just usb, but can easily be extended to others). Thanks, this is a needed feature, indeed. This has to be manually configured after the first boot (and requires a reboot after a sysupgrade first boot). H... that's a problem. It means that you can't just have squashfs+extroot but need a jffs2 inbetween just for this little cconfig. config 'modules' 'modules' list 'fs_modules' 'fs-ext3' list 'controller' 'usb-core' list 'controller' 'usb-ohci' list 'controller' 'usb-storage' In my (limited experience), load all the available modules works just dandy: after all, these are only the modules available in the proto-root filesystem, so they're likely to be pretty close to the bare minimum. Could you explain the rationale for the relatively sophisticated config of modules you're proposing here? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] b43 driver
Note: The brcm47xx still won't work for those of you needing broadcom wifi, stick to brcm-2.4. We will tell you when it does work. I need to know. How much may take time before we can use the b43 driver? One month? Half year? IIUC the above note is conservative: the b43 driver in brcm47xx works fine in many circumstances. And that's been true for a while now. E.g. it works fine in client mode (at least with WPA and without encryption), and IIUC it may also work fine in master mode (i.e. as an AP) without encryption, but not as an AP with WPA (not sure if it just plain doesn't work, or simply suffers from serious performance bugs). Also, last I heard, there is very little hope for improvement in the foreseeable future: the b43 driver is actively maintained and improved, but mostly to support more recent cards. For older cards, there is little interest, especially because it would require a fair bit of reverse engineering (IIUC). The above is mostly hearsay (except I can personally vouch for the fact that the b43 drivers works fine as WPA-client with a WL-700gE) and vague understandings, so take it with a grain of salt. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wanted: Package Maintainers
I will commit your patches later today. I also need the username you want to use, a ssh public key for svn, and the hash created by 'htdigest -c passwdfile openwrt username' for trac and I will get you setup with access to LVM. I also request that you fill in https://dev.openwrt.org/wiki/packages for the package after you get access to trac. My SSH public key: ssh-dss B3NzaC1kc3MAAAEBAM9a2e8W3rBrh1g2ijh4K99sptoeFGt3vr0pS2iRSvcsgrTcVrafzDLCqj+VZZsZFhpayou6AAbverg0129M/e8yM+ec5dstb0Znfvj2Uv1JHpTlyKMusIvN3lezJZVF45qY7bFY+JFxRNDVrsWZcYypF6dhWgLmVKXEoRy21yuIYmFprnJVWpQO1zJJJvBU+lmj6Dc9KU5goprZEV+ZmDIHIp9T3NQaoCndxgmKp5ypLWMIjrQpF5HJ6fSwtFBRsj3P7eE+nTJQhMgsZpJxfIlC517OVMXA8Uo2RDHvmlhteV5LviqftR48rf+RpS7Z+AYaYZTD/9pHnanK5jpyTVUVAKtDEJpR529ps8Sfn0BGZr7Hk0mlAAABABn1Kz+3ZG06rjJvMET+f9cdl/ly2FI16I16weq+f+or3ATQwam5oYCri7zz4HH4D3HfKCTkdJ/0FE9DKkQBJEHVcUstmHOBEyDxH6U/SKw/26gPULnbsZbDgShpBRFXDYXx7Z0wOoA5Qw5EqFrOwaS21k91GIAG0qOroIyGzbR6LeIixS1iE9kYQmmqrvmhHG9xeUEghe0agvh1mS+33jeIZ0emoy1Bmk3QfmH1kdOwcUFsye0UOFYzynZLn72Cctr+S5LuCOE8Lm4gQxl7TmzPoZqhFptFUJJ+vkQhpWEvBuTg5hVpQzkQt9eHhqrPEAcB6AX8Mhvmk/9SZ0MRosUAAAEAUmm3yxP7OeEkpDxXawODbgwqH6tNcU2DvkJcZnGUNLioLg7ElT4CJzXHsRHFQ/wL9nMQ1ouCZd+1xj5sBo9+hoE/aXV0nfye1wmwQeo3QAOpHCk0Ka2LFF+B8kL4CPzjYvAyUFlNMHcgpZD+r5luLtjE2Oach80puutXAzawN/qG6pGSxLDhGLHitdVrnK3o4DZ7VxOfaxNR869NgCaMiVI/kygxmBh16MOCUTwVky nX75enel4iJ//SFYwJM2tU/6Xxs9p2kipYv+JfWQeNBkjO0UldidCHi8D1kCrtQ7wu+81sAzSbieIdG4Q6oW6Y7h//jBIt9OisCgVEZ9Z/cg== monn...@pastel I think that the hash you want from htdigest -c passwdfile openwrt username you want is: monnier:openwrt:4057dacdc558c6929fd9e71d314cfda0 -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wanted: Package Maintainers
Oh, and did I say I *hate* Reply-To? Stefan Stefan == Stefan Monnier monn...@iro.umontreal.ca writes: I will commit your patches later today. I also need the username you want to use, a ssh public key for svn, and the hash created by 'htdigest -c passwdfile openwrt username' for trac and I will get you setup with access to LVM. I also request that you fill in https://dev.openwrt.org/wiki/packages for the package after you get access to trac. My SSH public key: ssh-dss B3NzaC1kc3MAAAEBAM9a2e8W3rBrh1g2ijh4K99sptoeFGt3vr0pS2iRSvcsgrTcVrafzDLCqj+VZZsZFhpayou6AAbverg0129M/e8yM+ec5dstb0Znfvj2Uv1JHpTlyKMusIvN3lezJZVF45qY7bFY+JFxRNDVrsWZcYypF6dhWgLmVKXEoRy21yuIYmFprnJVWpQO1zJJJvBU+lmj6Dc9KU5goprZEV+ZmDIHIp9T3NQaoCndxgmKp5ypLWMIjrQpF5HJ6fSwtFBRsj3P7eE+nTJQhMgsZpJxfIlC517OVMXA8Uo2RDHvmlhteV5LviqftR48rf+RpS7Z+AYaYZTD/9pHnanK5jpyTVUVAKtDEJpR529ps8Sfn0BGZr7Hk0mlAAABABn1Kz+3ZG06rjJvMET+f9cdl/ly2FI16I16weq+f+or3ATQwam5oYCri7zz4HH4D3HfKCTkdJ/0FE9DKkQBJEHVcUstmHOBEyDxH6U/SKw/26gPULnbsZbDgShpBRFXDYXx7Z0wOoA5Qw5EqFrOwaS21k91GIAG0qOroIyGzbR6LeIixS1iE9kYQmmqrvmhHG9xeUEghe0agvh1mS+33jeIZ0emoy1Bmk3QfmH1kdOwcUFsye0UOFYzynZLn72Cctr+S5LuCOE8Lm4gQxl7TmzPoZqhFptFUJJ+vkQhpWEvBuTg5hVpQzkQt9eHhqrPEAcB6AX8Mhvmk/9SZ0MRosUAAAEAUmm3yxP7OeEkpDxXawODbgwqH6tNcU2DvkJcZnGUNLio Lg7ElT4CJzXHsRHFQ/wL9nMQ1ouCZd+1xj5sBo9+hoE/aXV0nfye1wmwQeo3QAOpHCk0Ka2LFF+B8kL4CPzjYvAyUFlNMHcgpZD+r5luLtjE2Oach80puutXAzawN/qG6pGSxLDhGLHitdVrnK3o4DZ7VxOfaxNR869NgCaMiVI/kygxmBh16MOCUTwVky nX75enel4iJ//SFYwJM2tU/6Xxs9p2kipYv+JfWQeNBkjO0UldidCHi8D1kCrtQ7wu+81sAzSbieIdG4Q6oW6Y7h//jBIt9OisCgVEZ9Z/cg== monn...@pastel I think that the hash you want from htdigest -c passwdfile openwrt username you want is: monnier:openwrt:4057dacdc558c6929fd9e71d314cfda0 -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Wanted: Package Maintainers
We are looking for people that want to maintain and update individual packages. If you are interested please contact me with what package you want to maintain. I'd be happy to maintain the LVM package. I guess that presumes it gets accepted first ;-) Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Hotplug automount fixes/enhancements
To be honest I'm not sure how useful the unmount in hotplug really is anyway...usually if it's called it mean the device has already been removed, I think. But if you don't unmount, then you're left with some zombie mount, which still refers to the device name and can lead to problems (minor ones, such as renaming of the device node next time you plug the usb disk, or things like that. Once/if we get LVM hooked into all this, it gets worse because you really need to unmount the device before you can deactive the LVM volume, and without deactivating it, you can't reactivate it when you re-plug the usb disk). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] hotplug.d/block/10-mount script
Swap comes last because I plan to enable swapfile support, which rely on the filesystem to be mounted first. Any idea for a swapfile name? /swapfile, /swap.swp ... Is that really designed for swap on a hotplugged device? Is that a good idea? I use hotplugged swap. It is not a bad idea per se, as long as the administrator knows that the device can not be removed while the system is running. The reason I use hotplug in particular is that the USB subsystem is not initialized until after the fstab init script is run. Hmm... while technically you're using hotplug for your swap, I wouldn't call that swap on a hotplugged device. I wish we could reliably wait for USB to stabilize before fstab, so hotplug doesn't need to be used for such cases. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
As for improving the docs...While docs can always be better, I prefer development, and I think I've already greatly improved the state of documentation compared to what it was, as far as preinit goes. I'm sorry if my posts came thorugh as requests for you to improve the doc. I haven't looked closely at your changes, but they seem great. Next time I built a new firmware, I'll have a chance to check it more closely (I've been using local patches for ide-root on wl-700ge, so hopefully that won't be needed any more, or at least will be done more cleanly). It's on the wiki, so if you feel you understand the code well enough to improve it or the documention, please feel free to do so. I'm pretty Actually the questions in the previous message were truly questions to which I do not know the answer (even though I have spent some time through /sbin/mount_root and friends to figure out where to put my patch to get ide-root working). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
I have just a request from the documentation point of view: can anyone formalize a document with the init sequence, the hooks that can be used and any other useful information to customize the init process. I know that the source code is better a document... but I formal document can be easily reviewed in order to have a standard. Oh, yes, that would be wonderful. The code can be helpful, but it's never clear from it which part is an intended feature and which part is just an accident. So a little document that explains the *design* would be help both users and maintainers/contributors. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preinit fixes
See, http://cshore.is-a-geek.com/openwrt/preinit_mount.html It's fully documented along with an example. Thanks. It's much better, but it still leaves several questions open: - where is the failsafe code (it has its own subsection in the doc, but it doesn't say to which file it corresponds). - same thing for mount root filesystem. - the mount root filesystem paraphrases the code without explaining the underlying design. E.g. it would be helpful to state the preconditions and postconditions, i.e. what is the expected input state and what is the expected output state. - first boot also paraphrases the code. Here again stating the expected input state and resulting output state would help. Some of the relevant state could be for example be whether udev (aka hotplug) is expected to be running before/after. - Actually the fact that firstboot can be called in different ways and behaves differently for each seems terribly odd and confusing, so either it should be split into different files, or there should be some explanation for why it's all kept within that single file. -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /etc and non-config files (like functions.sh)
What do the rest of you think, of making the /lib move for a) functions.sh and b) preinit? 100% agreement. You'll probably want to keep compatibility symlinks in place, tho (and maybe /etc/functions.sh won't be a symlink but a file that loads all the files into which functions.sh has been split). Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] /etc and non-config files (like functions.sh)
What do the rest of you think, of making the /lib move for a) functions.sh and b) preinit? Sounds like a good idea to me. Might as well move /etc/init.d and rc.common while we're at it - but not without compatibility symlinks, both for users and for applications that rely on the old layout. Not sure I agree for /etc/init.d. I see why you'd want that, but there's a long tradition behind it and most GNU/Linux distributions still use /etc/init.d as well. And it's fairly normal for a user to add scripts in there as part of the local customizations. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] FQDN for routes should expand to all IPs
I posted a bug on the sourceforge tracker almost two weeks ago: http://sourceforge.net/tracker/index.php?func=detailaid=2872760group_id=48978atid=454719 and since I haven't seen any answer (although it even contains a patch which seems to work well, at least for me), I'm wondering if that's the right place to post such things. Should I rather send my patches to this list instead? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] FQDN for routes should expand to all IPs
Sorry, wrong list, Stefan Stefan == Stefan Monnier monn...@iro.umontreal.ca writes: I posted a bug on the sourceforge tracker almost two weeks ago: http://sourceforge.net/tracker/index.php?func=detailaid=2872760group_id=48978atid=454719 and since I haven't seen any answer (although it even contains a patch which seems to work well, at least for me), I'm wondering if that's the right place to post such things. Should I rather send my patches to this list instead? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Bug between `list' and `restart' in rc.common
The OpenVPN package uses `list' in its /etc/config/openvpn file.
In most cases, this works just fine.
But when you run /etc/init.d/openvpn restart, the decomposition
of restart into stop and start causes the config file
to be processed twice, so the list elements get added twice.
E.g. if in the openvpn config file you have
list push route aa.bb.cc.dd
you'll end up passing that argument 'push route aa.bb.cc.dd' twice to
the process.
The patch below seems to fix it for my use, but I'm not sure if the bug
is in openvpn.init or in /etc/functions.sh or ...
Stefan
diff --git a/net/openvpn/files/openvpn.init b/net/openvpn/files/openvpn.init
old mode 100644
new mode 100755
index bdf0413..aba8cbb
--- a/net/openvpn/files/openvpn.init
+++ b/net/openvpn/files/openvpn.init
@@ -142,7 +142,9 @@ reload() {
}
restart() {
- stop; sleep 5; start
+# Run `stop' in a subprocess, because otherwise we
+# read the config file twice, so we get the lists doubled up.
+(stop); sleep 5; start
}
up() {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] replace /jffs with usb stick
I am having a hard time to find the place where mounting root / really
happens ..
It's in /sbin/mount_root. And yes, it is not exactly trivial to find
(although in retrospect I had to admit that the name should have made it
pretty obvious).
See below the patch I use on my WL-700gE to mount the IDE drive's partition.
Stefan
Index: mount_root
===
--- mount_root (révision 14605)
+++ mount_root (copie de travail)
@@ -2,15 +2,75 @@
# Copyright (C) 2006 OpenWrt.org
. /etc/functions.sh
+echo mount_root /tmp/stef
+
jffs2_ready () {
mtdpart=$(find_mtd_part rootfs_data)
magic=$(hexdump $mtdpart -n 4 -e '4/1 %02x')
[ $magic != deadc0de ]
}
+### Try to mount some drive.
+mount_drive () {
+# for m in jbd ext3; do
+# echo mount_drive $m /tmp/stef
+# insmod $m /tmp/stef 21
+# done
+
+rootdev=$1
+
+COUNTER=0
+while [ ! -b $rootdev ] [ $COUNTER -lt 10 ]; do
+echo mount sleep for $rootdev /tmp/stef
+sleep 1
+let COUNTER=COUNTER+1
+done
+
+mount $rootdev /mnt [ -x /mnt/sbin/init ] {
+echo mounted $rootdev /tmp/stef
+. /bin/firstboot
+pivot /mnt /rom
+exit
+}
+}
+
+# mount_ide () {
+# echo mount_ide /tmp/stef
+# for m in ide-core aec62xx ide-generic ide-disk; do
+# insmod $m /tmp/stef 21
+# done
+# mount_drive /dev/hde1
+# }
+
+# mount_usb () {
+# echo mount_usb /tmp/stef
+# # ehci-hcd is for USB2, ohci-hcd and uhci-hcd are both for USB1 but only
+# # one of them works. For WRTSL54GS, it's ohci, for WL700gE it's uhci.
+# for m in usbcore ohci-hcd uhci-hcd ehci-hcd scsi_mod sd_mod usb-storage;
do
+# echo mount_usb $m /tmp/stef
+# insmod $m /tmp/stef 21
+# done
+# mount_drive /dev/sda1
+# }
+
+#mount_usb
+#mount_ide
+(cd /etc/modules.d load_modules *)
+# GPIO 6 on WL-700gE is the `copy' button; if the button is released,
+# gpioctl returns 0, and it return 64 if it is pressed.
+# GPIO 4 on WL-700gE is the `ezsetup' button; if the button is released,
+# gpioctl returns 0, and it return 16 if it is pressed.
+if gpioctl get 6 /dev/null gpioctl get 4 /dev/null; then
+ # FIXME: This device name should come from a CONFIG_setting.
+ mount_drive /dev/hde1
+fi
+
+### If no drive, mount the JFFS2 partition or a ramdisk.
grep rootfs_data /proc/mtd /dev/null 2/dev/null {
+echo mount_root-11 /tmp/stef
. /bin/firstboot
mtd unlock rootfs_data
+echo mount_root-12 /tmp/stef
jffs2_ready {
echo switching to jffs2
mount $(find_mtd_part rootfs_data) /jffs -t jffs2 \
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Who handles integration of new packages and what's the state of documentation?
2. How to take part in the development, and how to become an OpenWrt developer? Again, the direction to walk down, is to participate. A good direction is to start maintaining a package, discuss issues on irc #openwrt-devel etc. I've sent several patches here, and I didn't get much feedback (one of the patches got installed without any comment, while another one was commented upon (presumably by a non-developer) but not installed). Is IRC participation really indispensable? Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] Update from hotplug2-0.9 to hotplug2-1.0-beta
Update the hotplug2 package from hotplug2-0.9 to hotplug2-1.0-beta.
hotplug2-1.0 no longer needs the udevtrigger, so remove that
dependency from target.mk.
That would be a welcome upgrade.
Some changes are needed to the rules. Help on that would be appreciated.
Among other things, hotplug-1.0 supports the possibility of setting
envvars in some rule and then use it in another. So we can change the
rules from something like
...
DEVICENAME ~~ (null|full|ptmx|tty|zero|gpio) {
makedev /dev/%DEVICENAME% 0666
next
}
DEVICENAME ~~ (tun|tap[0-9]) {
makedev /dev/net/%DEVICENAME% 0644
next
}
...
to something like
DEVPATH is set {
setenv FILEMODE 0644
setenv FILEGROUP root
}
...
DEVICENAME ~~ (null|full|ptmx|tty|zero|gpio) {
setenv FILEMODE 0666
}
DEVICENAME ~~ (tun|tap[0-9]) {
setenv DEVICENAME net/%DEVICENAME%
}
...
DEVPATH is set, ACTION == add, MAJOR is set, MINOR is set {
makedev /dev/%DEVICENAME% %FILEMODE%
chgrp /dev/%DEVICENAME% %FILEGROUP%
}
DEVPATH is set, ACTION == remove, MAJOR is set, MINOR is set {
remove /dev/%DEVICENAME%
}
The main benefit being of course to cleanly support not only the
creation of the device nodes, but also their removal.
Stefan
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] IDE in 2.6.28 (was: WL700gE with new 2.6.28 kernel?)
Has someone managed to build a kernel for use on the WL-700gE? I tried to update my kernel and first noticed that the aec62xx module was missing. `packages/kernel/modules/block.mk' seemed to explain that some renaming break the kmod-ide-core package. So looking at the files drivers/ide/*.ko, I figured that maybe ide-disk.ko was replaced by ide-generic.ko and aec62xx was moved from one directory to another, just like ide-pci-generic. So after adjusting things this way, the build finishes, but the resulting image doesn't work right: it fails to give me the necessary /dev/hde* devices. It turns out that guess was wrong: the new `ide-generic.ko' is not the replacement for `ide-disk.ko'. Instead, to get back a working system we need to use the new CONFIG_IDE_GD kernel parameter which ends up producing the ide-gd_mod.ko file, which is the proper replacement for ide-disk.ko. I've used the patch below which gave me a working firmware for my WL-700gE. Clearly the patch shouldn't be installed as is since it breaks builds with earlier kernels. But I'm not very good at using those funny `make' statement like `ifeq', not being too sure how and where they can be used, so I haven't yet ventured into cleaning it up. I also have no idea what's the meaning of options of the form OPTION_NAME rather than OPTION_NAME=y or OPTION_NAME=n or OPTION_NAME=m in the KCONFIG setting. Can someone enlighten me (I haven't found anything relevant in the doc)? Stefan Index: block.mk === --- block.mk(révision 14586) +++ block.mk(copie de travail) @@ -131,13 +131,15 @@ $(eval $(call KernelPackage,ata-via-sata)) -# XXX: broken on 2.6.28 due to module name/path changes define KernelPackage/ide-core SUBMENU:=$(BLOCK_MENU) TITLE:=IDE (ATA/ATAPI) device support - DEPENDS:=...@pci_support @LINUX_2_6_28:BROKEN + DEPENDS:=...@pci_support KCONFIG:= \ CONFIG_IDE \ + CONFIG_IDE_GD=y \ + CONFIG_IDE_GD_ATA=y \ + CONFIG_IDE_GD_ATAPI=n \ CONFIG_IDE_GENERIC \ CONFIG_BLK_DEV_GENERIC \ CONFIG_BLK_DEV_IDE \ @@ -146,8 +148,8 @@ CONFIG_BLK_DEV_IDEPCI=y FILES:= \ $(LINUX_DIR)/drivers/ide/ide-core.$(LINUX_KMOD_SUFFIX) \ - $(LINUX_DIR)/drivers/ide/ide-disk.$(LINUX_KMOD_SUFFIX) - AUTOLOAD:=$(call AutoLoad,20,ide-core) $(call AutoLoad,40,ide-disk) + $(LINUX_DIR)/drivers/ide/ide-gd_mod.$(LINUX_KMOD_SUFFIX) + AUTOLOAD:=$(call AutoLoad,20,ide-core) $(call AutoLoad,40,ide-gd_mod) endef define KernelPackage/ide-core/2.4 @@ -157,7 +159,7 @@ ifeq ($(strip $(call CompareKernelPatchVer,$(KERNEL_PATCHVER),ge,2.6.26)),1) define KernelPackage/ide-core/2.6 -FILES+=$(LINUX_DIR)/drivers/ide/pci/ide-pci-generic.$(LINUX_KMOD_SUFFIX) +FILES+=$(LINUX_DIR)/drivers/ide/ide-pci-generic.$(LINUX_KMOD_SUFFIX) AUTOLOAD+=$(call AutoLoad,30,ide-pci-generic) endef else @@ -183,7 +185,7 @@ TITLE:=Acard AEC62xx IDE driver DEPENDS:=...@pci_support +kmod-ide-core KCONFIG:=CONFIG_BLK_DEV_AEC62XX - FILES:=$(LINUX_DIR)/drivers/ide/pci/aec62xx.$(LINUX_KMOD_SUFFIX) + FILES:=$(LINUX_DIR)/drivers/ide/aec62xx.$(LINUX_KMOD_SUFFIX) AUTOLOAD:=$(call AutoLoad,30,aec62xx) endef ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org http://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Support for LVM
Here is LVM support for OpenWRT. It introduces 3 new packages:
- kmod-dm for the device mapper kernel module.
- kmod-libdevmapper for the device-mapper library.
- kmod-lvm2 for the `lvm' tool.
Note that it currently does not create the symlinks for all the lvm
tools, so you have to use lvm pvs rather than just pvs.
Stefan
Index: package/kernel/modules/block.mk
===
--- package/kernel/modules/block.mk (révision 14586)
+++ package/kernel/modules/block.mk (copie de travail)
@@ -287,6 +289,35 @@
$(eval $(call KernelPackage,nbd))
+define KernelPackage/dm
+ SUBMENU:=$(BLOCK_MENU)
+ TITLE:=Device Mapper
+ # All the =n are unnecessary, they're only there
+ # to stop the config from asking the question.
+ # MIRROR is M because I've needed it for pvmove.
+ KCONFIG:= \
+ CONFIG_BLK_DEV_MD=n \
+ CONFIG_DM_DEBUG=n \
+ CONFIG_DM_CRYPT=n \
+ CONFIG_DM_UEVENT=n \
+ CONFIG_DM_DELAY=n \
+ CONFIG_DM_MULTIPATH=n \
+ CONFIG_DM_ZERO=n \
+ CONFIG_DM_SNAPSHOT=n \
+ CONFIG_MD=y \
+ CONFIG_BLK_DEV_DM \
+ CONFIG_DM_MIRROR
+ FILES:=$(LINUX_DIR)/drivers/md/dm-*.$(LINUX_KMOD_SUFFIX)
+ AUTOLOAD:=$(call AutoLoad,30,dm-mod dm-region-hash dm-mirror dm-log)
+endef
+
+define KernelPackage/dm/description
+ Kernel module necessary for LVM2 support
+endef
+
+$(eval $(call KernelPackage,dm))
+
+
define KernelPackage/pata-rb153-cf
SUBMENU:=$(BLOCK_MENU)
DEPENDS:=kmod-ata-core @TARGET_adm5120_router_le
Index: feeds/packages/utils/lvm2/files/lvm2.init
===
--- feeds/packages/utils/lvm2/files/lvm2.init (révision 0)
+++ feeds/packages/utils/lvm2/files/lvm2.init (révision 0)
@@ -0,0 +1,12 @@
+#!/bin/sh /etc/rc.common
+# Copyright (C) 2009 Stefan Monnier
+START=15
+
+start () {
+ /sbin/lvm vgscan --ignorelockingfailure --mknodes || :
+ /sbin/lvm vgchange -aly --ignorelockingfailure || return 2
+}
+
+stop () {
+/sbin/lvm vgchange -aln --ignorelockingfailure || return 2
+}
Index: feeds/packages/utils/lvm2/patches/100-readline-link.patch
===
--- feeds/packages/utils/lvm2/patches/100-readline-link.patch (révision 0)
+++ feeds/packages/utils/lvm2/patches/100-readline-link.patch (révision 0)
@@ -0,0 +1,38 @@
+=== modified file 'LVM2.2.02.43/make.tmpl.in'
+--- LVM2.2.02.43/make.tmpl.in 2009-01-16 15:02:27 +
LVM2.2.02.43/make.tmpl.in 2009-01-16 15:02:45 +
+@@ -84,11 +84,9 @@
+ endif
+
+ LDFLAGS += -L$(top_srcdir)/libdm -L$(top_srcdir)/lib
+-CLDFLAGS += -L$(top_srcdir)/libdm -L$(top_srcdir)/lib
+
+ ifeq (@DMEVENTD@, yes)
+ LDFLAGS += -L$(top_srcdir)/daemons/dmeventd
+- CLDFLAGS += -L$(top_srcdir)/daemons/dmeventd
+ endif
+
+ ifeq (@DM_COMPAT@, yes)
+@@ -202,18 +200,18 @@
+ ifeq (@LIB_SUFFIX@,so)
+ $(LIB_SHARED): $(OBJECTS) $(LDDEPS)
+ $(CC) -shared -Wl,-soname,$(notdir $@).$(LIB_VERSION) \
+- $(CFLAGS) $(CLDFLAGS) $(OBJECTS) $(LIBS) -o $@
++ $(CFLAGS) $(CLDFLAGS) $(LDFLAGS) $(OBJECTS) $(LIBS) -o $@
+ endif
+
+ ifeq (@LIB_SUFFIX@,dylib)
+ $(LIB_SHARED): $(OBJECTS) $(LDDEPS)
+ $(CC) -dynamiclib -dylib_current_version,$(LIB_VERSION) \
+- $(CFLAGS) $(CLDFLAGS) $(OBJECTS) $(LIBS) -o $@
++ $(CFLAGS) $(CLDFLAGS) $(LDFLAGS) $(OBJECTS) $(LIBS) -o $@
+ endif
+
+ %.so: %.a
+ $(CC) -shared -Wl,-soname,$(notdir $@).$(LIB_VERSION) \
+- $(CFLAGS) $(CLDFLAGS) $(LIBS) -o $@ \
++ $(CFLAGS) $(CLDFLAGS) $(LDFLAGS) $(LIBS) -o $@ \
+ @CLDWHOLEARCHIVE@ $ @CLDNOWHOLEARCHIVE@
+
+ $(LIB_STATIC): $(OBJECTS)
+
Index: feeds/packages/utils/lvm2/Makefile
===
--- feeds/packages/utils/lvm2/Makefile (révision 0)
+++ feeds/packages/utils/lvm2/Makefile (révision 0)
@@ -0,0 +1,113 @@
+#
+# Copyright (C) 2009 Stefan Monnier
+#
+# This is free software, licensed under the GNU General Public License v3+.
+# See /LICENSE for more information.
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=LVM2
+PKG_VERSION:=2.02.44
+PKG_RELEASE:=1
+
+PKG_SOURCE:=$(PKG_NAME).$(PKG_VERSION).tgz
+PKG_SOURCE_URL:=ftp://sources.redhat.com/pub/lvm2/
+PKG_MD5SUM:=4ed7b99903a6fc5165b7b0b8def42486
+# 2.02.43 = fc34655706a2aa116b92328b24fad619
+# 2.02.44 = 4ed7b99903a6fc5165b7b0b8def42486
+
+# OpenWRT normally expects the tarball to expand into
+# $(PKG_NAME)-$(PKG_VERSION), and this magic incantation seems to make it
+# understand that LVM2's tarball expands into $(PKG_NAME).$(PKG_VERSION).
+PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION)
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/libdevmapper
+ SECTION:=libs
+ CATEGORY:=Libraries
+ SUBMENU:=disc
+ DEPENDS:=+kmod-dm
+ TITLE:=The Linux Kernel Device Mapper userspace library
+ URL:=http://sourceware.org/dm/
+endef
+
+define Package/libdevmapper/description
+ The Linux Kernel Device Mapper is the LVM (Linux
