Tomato ND USB Mod

Discussion in 'Tomato Firmware' started by teddy_bear, Dec 17, 2008.

  1. trevorw

    trevorw LI Guru Member

    Sorry .. I completely forgot to mention this.
    My model is an Asus wl 500gP v1. I believe (but I'm not sure) that the schematics are the same with v2. Probably a similar setup is used by the wl 520 model.
    From what I've read on the internet, the button works fine in dd-wrt and oleg's firmware (if that's any help). Below are some of the links that I've found:

  2. freddyspam

    freddyspam Addicted to LI Member

    Thank you for the reply. The fact that it just works for everyone else is what pisses me off :biggrin:. I set the hostname to nas (this was after I couldn't make it work). For the File Sharing page:

    Yes, no Auth
    root$ -->*default settings*
    share -->*changed to read/write*

    I've attached my log file after a reboot. I'm on a 520gu. I have attached a 30 gig drive formatted to fat32. Not that it should matter but I have it setup as an ethernet bridge. Thanks for taking the time to help.

    Attached Files:

  3. teddy_bear

    teddy_bear Network Guru Member

    Page 36 of this thread... The fix will be in the next build.

    Any particular reason you disabled Dnsmasq? If you're not using the internal nameserver, you probably need to configure Samba a little different. Try to read this article, and see if you any of the additional options will help - you can add them to the Samba Custom Configuration box. Try "dns proxy = yes" first...
    If you figure it out - please let me know what configuration worked for you ;).
  4. trevorw

    trevorw LI Guru Member

    Awesome. Thanks a lot! Would it be possible to include a script which unmounts the usb devices as well (beside wifi toggle, reset and shutdown)?

    Thanks again!
  5. freddyspam

    freddyspam Addicted to LI Member

    I did not disable Dnsmasq knowingly....I think it has to do with the router being set as a wireless bridge. I reset to defaults and almost all the settings are default except for the USB and NAS, and the Basic Networking. Still no cigar. "dns proxy = yes" did not immediately fix it. I will keep reading and post if I do find anything.
  6. teddy_bear

    teddy_bear Network Guru Member

    Yep! Missed that case - will include a fix into the next build :). For now, you should be able to resolve the issue by editing your /etc/hosts file to add a line:
    <Your_router_LAN_IP> <hostname>
    i.e.: nas
    This file is getting recreated on reboot, so you need to populate it in your Init or WanUp script.
  7. SgtPepperKSU

    SgtPepperKSU Network Guru Member

    I just installed TortoiseGit (a Windows explorer shell extension to control git) just to try it out, and it seems very nice. You can clone, change/create/merge branches, commit, pull, push, fetch, view logs/diffs (for the whole project or individual files), etc, all from right-click menus.

    Perhaps you could give that a try. I don't think there'll be much of a learning curve.
  8. teddy_bear

    teddy_bear Network Guru Member

    I'm almost done with integrating your changes. There were some weird issues - nothing that you did wrong, must probably related to kinks of 2.4 kernel... Anyway, most are resolved now. Thanks a lot for detailed comments in your code - they did help to understand your changes!

    The only problem I don't know how to deal with is the logs being flooded with printk output from usb/scsi subsystem. This happens if there are disconnected storage devices that were at some point attached to the router, or if there are attached multi-lun devices with "invalid" luns - i.e. cardreader with some empty slots. I improved the situation a little by optimizing calls to probe_usb_mass() and by processing only attached devices whenever possible. Still - the cardreaders with only one or a few cards in slots are spamming the log, especially if auto-refresh is turned on on the USB page...

    Do you know if there's any way to temporarily disable printk output or redirect it to /dev/null at run-time? I would at least want to suppress printk's during findmntent() calls if possible...
  9. ray123

    ray123 LI Guru Member

    Teddy Bear,
    Since the dogs decided to wake me up at 1:30AM by barking at the rainstorm and I couldn't get back to sleep.........and the business of the web/nas-usb interface was niggling at me.......I fixed it.

    Small patchset to my previous one.
    With this set of mods, the web interface correctly shows all the USB partitions, AND you can unmount (as previously) and dismount (new) from the web interface. So if you have automount turned off, and plug in a USB stick the [newly detected, unmounted] partitions will show up and you can mount what you want with a click. Or you can play around and mount & dismount at whim.

    Plus I removed a bunch of printf's that I accidently left in the last patchset. ;-(

    The one thing I didn't do was get rid of the "Host #" field. I didn't want to take the time to learn enough about js & asp to feel safe in deleting it. (I'm already embarrassed about the hack-and-slash I did to the js & asp to get mounting to work. I'm sure there is a cleaner way to do it.)

    The host # field does not really show any human-usable information. And it's wrong anyway, now that there is support for more than one partition per drive. So it just displays info that is meaningless to people. (It's the inode & r_dev of the device_dev for the partition, used to communicate between the web page and the usb code.) I don't really see anything that might be useful info in that field. The vendor/product/serial# is already shown. Serial# is probably not useful...maybe delete both fields and replace them with "mountpoint" for a mounted device? Seemed possibly interesting, but don't know if the amount of code it would take to do this is worthwhile.

    If you feel motivated to do something about that(those) field(s), go right ahead. Otherwise we'll just let people wonder "What does a host# of 313.2049 mean?"

    Last change from me for now, promise. Next up is improved jffs code--but that'll take a while.
  10. ray123

    ray123 LI Guru Member

    The lack of comments in Linux code has driven me crazy evern since the 0.95 days. Linus & I had an email discussion about it some 14-15 years ago. He doesn't like to comment code, that philosophy permeates the Linux development community, and so generations of people have wasted countless man-hours trying to understand Linux code. I hate it when I go back and re-work some code I wrote 6 months or several years ago, and have to spend time trying to figure out what was in my mind when I wrote it.

    Careful there!!! Be very very sure that you didn't optimize away a situation when it really did need to probe. I figure it's better to force a disc revalidate needlessly than to not revalidate when it is needed. I always ask, "But what if I am wrong?" If I'm wrong in the 1st case, we get extra crap in syslog. If I'm wrong in the other case, the partitions on a newly-inserted drive are not recognized.

    The only way I know of to temporarily syslog output is to modify the level for syslogd. AFAIK there is no way to tell the scsi subsystem to not print. Other that a bit of ugliness, what's the problem with the spewing stuff in /var/log/messages? I don't see where it hurts anything for normal users---just for developers who tail -f it.

    I agree that skipping devices that are on controllers that are not attached is the right way to do things. I considered doing it, but didn't think it was worth the trouble & code. Hence my one comment, "All-in-all, I'm still not too happy with this code." (Aside: These kinds of comments saved me a great deal of embarrassment in my career. Every once in a while, a junior programmer would come up to me and say, "I was making some changes to the XYZ code and I found a problem. -- And somebody had left a comment in the code that said didn't feel 100% sure that all the bugs were out.")
    (Aside 2: In one case, I wrote a particularly complex piece of code and left a comment "I hope that I'm really as clever here as I think I am." Almost 8 years later, one of our new programmers found that comment. She thought it very amusing and undertook to go over that code with a fine-tooth comb to see if I was or not.)

    More and more, I understand why they re-did the USB storage code architecture in 2.6. There's just a whole lot of problems in the 2.4 method.
  11. ray123

    ray123 LI Guru Member

    You can easily do this yourself. Probably. All the hooks are there, just write a hotplug script which will get called when the webcam is plugged in. Then whatever code is necessary to read the webcam. You'll probably need a USB flash drive or USB harddrive for the program(s) to reside on---there's probably not enough space in the router's filesystem for it.

    I'm curious about these webcam requests. Why not just plug it into your main computer? Why the router?
    I can see somebody wanting to plug in a scanner or an all-in-one printer/scanner, though.
  12. teddy_bear

    teddy_bear Network Guru Member

    Ray, you need to slow down - I could not keep up with your changes :)... I just finished mixing the previous patchset with my own changes, still working on some minor adjustments, and will need to do some testing as well before releasing it - and there's already a new update from you ;) !.. And I did took care of extra printf's too...

    As for the host # in the web UI I have a different opinion - sorry, I did not tell you sooner about it... I believe that the sole purpose of "unmount from web" is to provide an easy way to safely disconnect the drives from the router - kinda what Windows does when you click on "Safely remove hardware" icon. For this purpose, and for the sake of keeping it simple for a regular user the list of all disks and partitions is not needed in the UI - list of hosts is enough. For anything more advanced users can issue mount/umount commands via Telnet/SSH session, or in scripts. The same goes for remounting. I agree that sometimes the router can be out of reach, and that's when the web remount can be handy - I just never thought about it as an important enough feature to work on it ;). But that too can be kept on a host level - click "remount" and it remounts all not mounted partitions of all disks of this host. The host #, even if it kept as before - 0, 1, 2, etc - is probably not useful for people and can be removed. I just don't remember if there's way to keep the host # internally without displaying it. The display-only list of existing mountpoints - like a "details" panel for each device - could be interesting addition though... Maybe later...

    Yep, I get this point ;)... That's why I will be doing a lot of testing before releasing the next update, trying to reproduce issues you described in your comments... What I did so far, I reduced the probe calls after mounting to connected hosts only, and after dismounting I only call it for the host dismounted. Hopefully that should work as good as the original version. By the way, I see the obvoius need for probe after attaching a new device (had a workaround in place before probing), but is it really needed after unmounting?

    I made another serious change to your code - I hope you don't mind ;)... That was to solve the "weird issues" I mentioned before - for whatever reason sometimes - not consistently, of course ;( - the hotplug process would just crash (terminate) during the getsem() call... Did you experienced anything like that? It was lile once in a while the device would not mount or unmount, and after adding a bunch of extra logging I found that in these cases the processing stops after the first getsem() call. Not hanging - the hotplug process is not there anymore, it's gone and nothing happened... Well, you also mentioned that the serialization should not be really needed there, so I removed the semaphore usage from hotplugging code, and went back to process mounts/unmounts in the usb_event function called on timer (that was originally designed that way to prevent the same kernel oops'es you tried to solve by serialization). I think I still solved the problem of the old code when some drives will not mount/unmount if you plug/unplug them very quickly - at least I could not reproduce it anymore (and I could before). If you believe I'm breaking anything else by this change - plese let me know...
  13. teddy_bear

    teddy_bear Network Guru Member

    Not really... The kernel modules needed for serial devices support are not included. For scanners too. I added a comment regarding these features to the 1st post.

    Scanners could be useful - but what I read about scanners support in linux 2.4 didn't encourage me to work on enabling it ;). The situation seems to be a lot worse than with storage...
  14. ray123

    ray123 LI Guru Member

    I believe that the sole purpose of "unmount from web" is to provide an easy way to safely disconnect the drives from the router - kinda what Windows does when you click on "Safely remove hardware" icon. For this purpose, and for the sake of keeping it simple for a regular user the list of all disks and partitions is not needed in the UI - list of hosts is enough.

    We differ here. There's really no purpose to a "safe unmount" in Linux. Not really in Windows, either. What people really do is just yank out the USB stick. What's the point of having a feature that is not needed?

    You're right that I didn't understand what function you were trying to provide. It looked to me that your original USB code assumed one partition per drive, and assumed that HOST == USB Controller. Yes, I realize that a later release did handle multiple partitions per drive. But even that later release didn't allow for USB controllers that had multiple drives (which show up as multiple LUNs), each with possible multiple partitions. I fell back to what I am used to in Linux-----that the entity of interest with respect to disks is the partition. Drives and controllers are merely containers that hold the primary entity. It seemed natural that an administrative interface would show partitions, and allow the user to manipulate the partitions, with little regard to the fact of what physical disk/controller they happened to reside on.

    Anyway, for symmetry, if you can umount from the WEB, you should also be able to re-mount. One good guideline I learned about user interfaces is "The Principal of Least Surprise". Whatever the program does when a user types/click something, it should not be a big suprise to him. I ask myself, "What would the user expect to happen when he plugs in a USB stick?" I believe the answer is, "He would expect that all the partitions would be mounted and usable."

    Now, I look at the USB web page. It has one line for each partition, which says "Mounted". The "mounted" is clickable to unmount it. So he clicks one of these buttons and TWO (or 3 or whatever) lines change. Big surprise. To make it a small surprise, you'd have to have only one button per drive. So it'd have one line per drive, perhaps with a column that shows how many partitions are on the drive. Or maybe one line per partition, but only one line would have the botton.

    But then what do do about controllers (like my IOMAGIC box) that has several disks? To keep the philosophy of "click the button so that you can unplug the USB cord", then there should be one clickable button for all drives on the controller.

    All-in-all, it seems both simplest to code, and most natural for the user, to display and treat each partition independently. Which is how I did it.

    By the way, I see the obvoius need for probe after attaching a new device (had a workaround in place before probing), but is it really needed after unmounting?
    Yes. Because otherwise Linux thinks the partitions are still there. So other code that walks either /proc/partitions or /dev/discs/disc# will (or might) have problems. At any rate, the next time that something tickles the scsi subsystem to re-validate the drives, things will get straightened out, anyway. So it's gonna happen. But by doing it myself on a dismount, I know that it gets cleaned up immediately. By waiting until it magically happens all by itself, the system has incorrect information for some unknown period of time. Doing it on a unmount, we remove this period of uncertainty. I forget just what sequence of events led me to doing the probe on dismount, but that was the *original* useage of it. Only later did I include doing it on a plugin.

    ...stops after the first getsem() call. Not hanging - the hotplug process is not there anymore, it's gone and nothing happened
    Ugly. I never saw this happen, myself.
    I suspect that what is happening is that the hotplug program is getting a crash somewhere else, and since there's no console the crashdump info doesn't get printed anywhere. All it takes is trying to de-reference a null pointer. :mad:
    How are you running this stuff to test/debug it? What I do is build by "cd rc; make STATIC=1; cp rc $HOME/cifs2/hotplug". Then on the router, "cp /cifs2/hotplug /tmp/" and then "echo /tmp/hotplug > /proc/sys/kernel/hotplug". This simplifies my build/test turnaround time. If I'm having a mysterious crashing problem, I build the command that the kernel would submit, like "ACTION=add INTERFACE=08/0/0 TYPE=0/0/0 /tmp/hotplug usb" and see what happens. This way, the printf's and crashdump printouts will come to the telnet window. (If I ever get really stumped, I have plans to build a mipsel version of gdb and then run the program(s) under the debugger.)

    ...process mounts/unmounts in the usb_event function called on timer
    Ugly. Doing things in a timer loop is un-natural. Especially in Linux. It's almost always a kludge to try to paper over some other problem. It's vulnerable to subtle timing problems. And that's the real Bad Thing about a timer technique. When multiple events happen very rapidly, it is quite possible for one to be over-written by a later one before the first one has had a chance to be processed. It's fragile. It can be made to work (and I think that it works fine in this instance), but it has a tendency to work until some other change is made, and all of a sudden you have a bug that is very hard to reproduce. I think that the timer method does work okay in this code for hotplugging only. Because the processing code always does a mount/dismount for every device, once it gets triggered. The signal that the processing code gets is, "Hey something got plugged (unplugged)---do all the devices." There's no information passed (the code ignores the PRODUCT field), so if one gets lost it doesn't matter.

    But it does NOT work reliably for web unmount! In this case, the signal passes along the information of what device is to be processed. If you bring up two web pages, and simultaneously click "unmount" on a different host in each window, then there is a timing window where the 1st one will be over-written by the 2nd one, and so the 1st one will be lost. With a 5-second timer, this window is 5 seconds wide.

    I bet it's another bug, not the getsem. But, if it *is* related to the semaphores, I think the best way to fix this, would be to use a lockfile. That's the first way I did it, until I realized that semaphores were available. But I find it really hard to believe that there's a bug in the Linux semaphore code.
  15. freddyspam

    freddyspam Addicted to LI Member

    I cannot believe that that is all it took. Thank you so much. I was starting to think I had a learning disability for not being able to make it work. Now it is up and running.
  16. teddy_bear

    teddy_bear Network Guru Member

    I disagree. If you just yank the drive out of the USB slot, you may loose recent changes you made to your files. I had it happened. That what actually made me to add this feature.
    Yes, that was the problem. It became apparent as soon as I enabled multi-lun devices support in kernel. The changes you made - even though I had a different purpose in mind for this function - helped me to quickly realize what's wrong and fix it - thank you!
    That still works good if only one row per host is present in the UI. "Unmount" tries to unmount all partitions of all drives of the host, so you can disconnect it without loosing your data. "Mount" will remount them all. Taking a single drive out of the controller, or plugging it in could be a bit confusing - but it does not fire off the hotplug event either, so it's already confusing...
    Exactly! Skipping the differences of how I get the "rc" file to the router, I end up with the same "echo" command. I added cprintf (and tried syslog too) calls right before and after each getsem(), and the "pre-getsem" messages were always there, while "after-getsem" were not. I also don't believe that there's a bug in Linux semaphore implementation - probably something else interferes with it making it to fail silently... What is very strange is that you did not have that issue working with the same hardware and almost the same code... Trust me - I like the idea of using a semaphore there for serialization, and will try again to make it work. However, I do not feel like debugging kernel and uclibc code if I keep experiencing weird problems ;) - in that case I'd rather bail out and go back to the code that's working, even though it could be better.
    Agree. But as you noticed yourself - it works in this instance since the product code in nvram is only used as a flag to indicate that there are some changes. The problem with older code was that it sometimes cleared nvram variables right in the hotplug function. Removing that fixed the issue when sometimes a drive would not mount/unmount.
    Agree and disagree at the same time ;). It would be unacceptable in the real multi-user environment, or if this could cause wrong results. However, it works just fine for all practical purposes on the router. Routers are usually administered by one person - from one computer only at the same time. And even if you open multiple browser windows and start clicking on "unmount" link as fast as you can ;), or if another person does it simultaneously with you from another machine, the worst that could happen is one request will succeed, and the other one fail, and you get the "Fail to [un]mount..." error message. Although this is not a perfect behaviour, this is a very rare situation, and the problem is definitely not critical since it doesn't cause the wrong drives to get [un]mounted... If you look through the Tomato and other firmwares code, you'll find out that there are many cases when the web UI assumes that only one person performs the same function at the same time, and would not work correctly otherwise.

    All in all, I think that the timer technique works just fine here. But again - since semaphore serialization is a better design, and worked for you, I'll do another attempt to make it work.
  17. yuzt

    yuzt Guest

  18. davipiero

    davipiero Addicted to LI Member

    Thanks a lot... I wonder if you can develop Tomato into a far more useful firmware..
  19. teddy_bear

    teddy_bear Network Guru Member

    Yay - it worked!.. I tried it again after some voodoo dancing and drumming, and the semaphore worked - on every single plugging or unplugging. Not sure why it did not work for the first time... I was curious, but I spent so much time on this version that I don't care anymore ;) - it works and that's all that matters. Getting close to releasing the next update :)...
  20. absolon

    absolon Addicted to LI Member

  21. teddy_bear

    teddy_bear Network Guru Member

    Definitely not a spam! Nice theme, thank you! Could you also make it to look good in IE :wink:, so it doesn't cut off the text from the bottom in the drop-downs?

    Attached Files:

  22. absolon

    absolon Addicted to LI Member

    Thanks. Theme updated. Anyway I don't want to make mess in this topic anymore. :)
    So everyone interested further information and updates will find in separate topic:

    Now about MOD.
    Can anyone confirm or deny:
    I change settings in wireless network (I enable/disable broadcast ssid for example) then Save it. This cause unmount my pendrive. :confused:
    I tried a few times, always the same.
  23. teddy_bear

    teddy_bear Network Guru Member

    Will be fixed in the next build :).
  24. ray123

    ray123 LI Guru Member

    Y'know, it's a good thing that I'm mostly bald already---otherwise working on this router code would have me tearing it out by the handful. I'll do something like compile & build a program (like busybox or rc), copy it to the router, try it, and the old version would be the one that gets executed. I'm going to rename my router from "Router" to "SPOT", because once it gets its teeth into something it doesn't want to let it go. And the commands that just don't do anything until you execute them twice. cp and tail do it all the time. No messages or anything, just stubborn refusal to do anything except go back to the command prompt.
  25. teddy_bear

    teddy_bear Network Guru Member

    I'm glad that was not me going crazy, as it really happens to someone else too ;-)...
  26. ray123

    ray123 LI Guru Member

    <John Cleese voice> Right then. This is getting ridiculous. Off you go! </John Cleese voice>

    Teddy Bear:
    Okay, I've figured out a way to associate a hotplug event with the affected host (scsi host/controller). This will allow us to get rid of all the crap^h^h^h^h contortions with "probe_usb_mass" and "process_all_usb_partitions" and (i believe) the serialization stuff. The resulting code will be lean and elegant. The only device that will be touched will be the one that got hotplugged. Everything else will be left strictly alone.

    I want to mull it over for a few days and let it ripen before making the mods, though. And I believe that you are hankering to get out the current release.

    So, what'cha think? For the next version?


    With respect to the NAS-USB web admin interface,
    I see two independent questions:
    1) Unmount only, or both unmount & mount.
    2) All disks/partitions on a controller, or each partition independently. (Or both, but that seems to be going to extremes.)

    The code is not much different whichever way, so it's mostly a matter of choice of the functions to be provided, not a matter of size or difficulty of code.

    None of my camera card-to-USB adapters generate a hotplug event when a card is inserted or removed when the adapter is already plugged in---only when the adapter itself is plugged/unplugged. So I lean toward being able to mount from the web interface.

    The other question, I first thought one way, but now I understand your point, and an now undecided.

    If anybody else in this forum has an opinon or preference, please chime in!
  27. teddy_bear

    teddy_bear Network Guru Member

    By parsing /proc/bus/usb/devices and something else? I thought about it, but then decided it's not worth the efforts. Or did you find an easier way? Even though it doesn't seem important functionality wise now (and unfortunately will not solve the problem with logs flooded by sense data for multi-lun devices when autorefresh is enabled in the web GUI), cleaning up the code is always a good thing :)...

    There's no rush with releasing the current build. What I'm really looking forward to is getting some kind of final release out, and forget about it until Jon releases the next official Tomato version ;). Of course, there's no such thing as final release, I know ;)...

    Here's what I ended up now with:
    1) Both - makes sense to me.
    2) Mount/unmount of all partitions of the host. For fine-grained control there's a "mount" command. But the list of all partitions with mountpoints will be displayed in the UI.

    That's how it will be in the v20. After that, we'll see. If anyone convinces me that the other way is really better, I'm open to change it :).
  28. Victek

    Victek Network Guru Member

    v20? I thought after reading these interesting POV for each one of you the release was V40 or V45 already. It's a pity web 2.0 is not in this forum.. ;)
  29. helpless old guy

    helpless old guy Addicted to LI Member

    Over the past several days I've scrupulously read all 460 posts on this thread (many of them several times), and I'm sorry to say 90% of what I've read is completely over my head.

    I apologize if I'm on the wrong forum, but I obviously need some basic, simple help setting up my new WL-520 GU.

    I bought it two weeks ago to replace my WRT54GS (v2) that died suddenly from a voltage surge from a nearby lightening hit (after many years of faithful service).

    The 520GU appealed to me because of the usb support that would allow me to network (as I understood it) my printer, camera, and scanner for use on my three computers.

    I'm and "old guy" with better than average computer knowledge (I actually built my own Media Center computer and got it working after a few weeks of struggling, and successfully turned it into a full-featured dvr to record full-quality HDTV with three video cards and two TB of internal hard drives... ...but anything to do with software programming is totally beyond my understanding. (It took me a week to get my WRT54GS functional when I purchased it, and that was only after nearly 20 hours on the phone with Linksys support before I finally hooked up with a fellow in India who took pity on me and walked me through it step-by-step.

    Before I take up any more space on this wonderful forum, I should ask if I'm in the right place to get some help?

    I'm afraid I need some bulletproof reliable software and a little personal assistance in installing it on my new router.

    Is the "build" discussed here near that stage yet? ...and is there anyone that would be willing to help me out with the extra guidance I need?

    Thanks either way; I'm unbelievably impressed with the knowledge I've seen displayed on this thread.

    Helpless old guy (more commonly known as Buz)
  30. darthboy

    darthboy LI Guru Member

    just a quick query,

    if I install this firmware on a WL520GU, and plug in a flash drive, I can install openvpn (optware?) to the drive and also use it as a Windows share?
  31. TaskMaster

    TaskMaster Guest

    Yes you can. I'd probably setup separate partitions for OPT and SHARE.
  32. teddy_bear

    teddy_bear Network Guru Member

    New update - build 20

    Although there's not much new, this is a major update - it includes a lot of internal improvements, updates and fixes, a lot of code rewritten etc. This build is truly a collective achievement - thanks to ray123 who provided his ideas, code and patches (see the details here, here, and throughout this thread) - there's now more JFFS space available, and working with USB drives should be more convenient and more reliable.

    So here goes the list of changes since v19:
    • Updated MiniUPnPd to the latest ver. 20090214 and recompiled it with support for GENA UPnP events enabled.
    • Updated FTP Server vsftpd to the latest ver. 2.1.0.
    • Removed non-working ipkg to save space - you can still install and use Optware ipkg.
    • Fixed "Unknown Host" Samba error when router is working in Wireless Bridge or Wireless Client mode.
    • Fixed SES button and WLAN LED on Asus WL-520gPv1 and Buffalo WBR2-G54 routers.
    • Mounted USB drives no longer unmount when changing some settings causes router to restart all services.
    • Added support for mounting USB partitions by label, i.e.
      mount LABEL=optware /opt -o noatime,nodiratime.
      Changed the default mountpoint for labeled discs from "/mnt/disc#_partition#" to "/mnt/LABEL".
    • Added support for automounting using /etc/fstab file if it exists. Support for labels and UUIDs in fstab is included. If automounting is disabled, you can still mount your drives using fstab information by issuing "mount -a" command manually. You can create and populate /etc/fstab file in Init script.
    • Expanded "Attached Devices" list in the GUI to display the list of partitions with mountpoints for each storage device.
    • Added "nvram setfile2nvram <filename>" command to save small files in nvram. They will be automatically restored on startup. This is another way to create, for example, /etc/fstab file, and to make it "permanent".
    • Changed the on-flash filesystem from jffs2 to jffs 1.1 with special modifications to the jffs driver so that it would work on a very small filesystem. The "Standard" build with all features now has ~120KB free JFFS space on 4MB flash.
    • Added "NAT Target" setting to "Advanced -> Firewall". You can try changing it from MASQUERADE (default, the same as used in official Tomato) to SNAT - this can speed up routing since SNAT does not seek the external IP every time a chain is traversed.
    • Added support for multi-LUN USB storage devices (like card readers).
    • Updated SCSI Disk Driver to the newer version from kernel 2.4.37. This fixes a memory leak, improves compatibility with certain devices, and eliminates some error messages in the syslog (i.e. when connecting Kingston flash drives).
    • Applied SCSI subsystem patch from kernel 2.4.37 to improve USB hotplugging.
    • Multiple improvements for USB hotplugging to make it more robust.

    The mod now comes in 4 different flavours:
    • Standard: all standard features described in the 1st post are included; 120KB JFFS space (2 blocks) available on 4MB flash routers;
    • Lite: all features of Standard but no Samba; some very minor features are stripped out of Busybox, about 420KB JFFS space (7 blocks) available on 4MB flash routers;
    • No CIFS: all features of Standard but no CIFS Network filesystem support, about 180KB JFFS space (3 blocks) available on 4MB flash routers;
    • Extras: all features of Standard plus Linux Ext2/Ext3 filesystem utilities (fdisk, e2fsck, mke2fs, mkswap), and built-in loop device support, no JFFS space available on 4MB flash. This version is for people who don't need JFFS space, or have 8MB flash routers, and would like to be able to partition/format drives in Linux native Ext2/Ext3 format directly on the router without installing any additional tools.
    If there will be multiple requests for other configurations, I'll consider building them as well.

    Links to the firmware binaries and the git repository with sources are in the 1st post. The complete sources of this build can also be downloaded as a git snapshot in tar format.

    Although this build should be the most reliable and stable so far, there could be new bugs introduced - hopefully not many and easy to fix though ;)...
  33. eRd12

    eRd12 LI Guru Member

    Flashed WL500gP v.2 with extras version - everything works great. I don't use flash or hdd but maybe I'll use in future. I want to buy external (usb 2.0) 1TB hdd and install any torrent client on it and use it to share files in my lan.
    What client do you use? rtorrent, ctorrent? Do you have any links about installing it? I should at first search something named optware?

    and of course thanks for your work with modding original tomato, because adding usb support give much more functionality of our small, low-cost routers :biggrin:
  34. teddy_bear

    teddy_bear Network Guru Member

    The info about optware is in the 1st post. I personally don't use torrents on the router, but search this thread - someone posted something about it here ;).
  35. dadaniel

    dadaniel Network Guru Member

    I am voting for a lite build with filesystem tools (fdisk, ...) included
  36. trevorw

    trevorw LI Guru Member

    Teddy Bear and ray123, great work! I just flushed my Asus wl-500gP v1 with the extras version about 1-2h about through the web interface and everything works just fine. My usb sticks are mounted by label now (which is great) and the AES button finally works (did a quick test by turning off/on the wifi).

    Once thing I've noticed (I think it doesn't relate to the version) is that if the hostname of the router contains multiple names (for example: "router tomato gw"), then the cifs/samba partitions do not work (I get a "daemon.err nmbd[589]: Get_Hostbyname: Unknown host XXX YYY" error in the logs). This is really no big deal - if there is another way to specify aliases for the router, let me know and I'll try it out.
    I've tried both an USB stick and a card reader and things worked out just fine. I have an usb hub as well - if you want me to test/try out something just let me know.

    Thank you for another fine release!
  37. teddy_bear

    teddy_bear Network Guru Member

    Thanks for the report. I knew there will be a bug-fix release soon ;)... So it affects CIFS as well?

    That kind of defeats the purpose of a "lite" build :) - the idea of making it was to provide as much JFFS space as possible... Isn't the separate set of e2fs utilities built by ray123 (and linked from the 1st post) good enough?
  38. trevorw

    trevorw LI Guru Member

    Just to be clear - I don't think this is a newly introduced bug but rather an unsupported case of a hostname (in this case the router's) with spaces. The cifs client on my router is configured with IP rather then hostnames so only the samba shares seem to be affected.
  39. me2az

    me2az Addicted to LI Member

    Some flooding problem with internal memory card slots on my HP aio. This reader also is available for mounting via gui but shouldn't be.
  40. teddy_bear

    teddy_bear Network Guru Member

    That's expected. As this is a storage device, as any other cardreader, it's available for mounting. If you insert a card into a slot, you'll be able to mount and access it.
    Unfortunately, the logs being flooded is a problem with multi-LUN devices - I mentioned it a few pages back. This is in the Linux kernel, and can't really be fixed :-( - or at least I don't see a way to fix it now other than disabling multi-LUN devices completely, as it was in previous builds. But then you won't be able to access cards in cardreaders etc...
  41. freddyspam

    freddyspam Addicted to LI Member

    I don't know if this is a bug or my lack of knowledge as to how to setup the ftp server over a wireless bridge. I have a 520gu running your latest firmware as a wireless bridge with Vsftpd enabled for LAN and WAN. From the LAN side I can connect just fine. If I try to use my WAN IP address, I can log in, but the directories never list, and I get error "500 Illegal Port Command". I have setup my main router to forward the port to the wireless bridge IP, and obviously that portion is working because I can log in (confirmed by looking at my 520gu log). It just never lists the directories. I can fix the issue by adding "port_promiscuous=YES" to the config file on my 520gu, but I'm not sure if this is wise.

    I'm not sure if this is a factor, but the attempts listed above are when I'm located within my LAN. I haven't tried to connect from outside my LAN. I just wanted to test if the WAN side connection would work.
  42. RockT

    RockT Addicted to LI Member

    Dial on demand stops working


    am wondering if anybody has seen this.

    Router: Asus gPV2 - early model with wl0_corerev 9
    and very slow flash time of 5 minutes :)

    Firmware: Teddy's mod V19 and now V20 EXT

    Connection: PPPoE

    Sometimes after 5 days, this time after just one night the dial on demand does not work anymore. Though I can connect with web interface.

    Nothing special I see in the logs; the router does not seem to try to connect so log looks clear.

  43. teddy_bear

    teddy_bear Network Guru Member

    Search the forum for PPPoE issues and solutions - there are a lot of related posts here. I believe what you experience has nothing to do with this mod, so the info on other threads should apply to you as well...

    Do not test WAN FTP connections from your LAN - it may work totally differently... For example, if using PASV mode the FTP server will respond with LAN IP in your case (port forwarding). That will work when you're testing from your LAN since the client will be able to access that LAN address, but won't work for real WAN clients. As for your particular problem, I'm not sure what you should do. WAN access was intended for direct WAN connections - port forwarding may cause various issues. You can probably google some info out regarding using vsftpd from behind the firewall...
  44. trevorw

    trevorw LI Guru Member

    Here is the short story since my previous, long email didn't make it as my token expired.
    The new firmware has been running nicely on my router for over 1 day now. The usb sticks that I've plugged in and out were recognized and made available.
    However, the card reader was problematic. At first it was recognized but the card inside it was not automatically mounted. I've mounted, it worked but then the next card I inserted was impossible to mount. I tried using the UI but it just gave me the 'please wait...' message.
    I've unplugged the reader and used an usb stick but it wasn't recognized - in fact none of the mount/umount commands worked even though one of the sticks was still there. The samba drives were unavailable - I looked through the shell and noticed the unplugged card reader was still marked as mounted. After I've manually umounted the ghost drive things started to work again. I've repeated the process and got the same behaviour.
    Note that over samba I can still see the ghost drives/label and I can even write to them. All of the ghosts have a '.autocreated.dir' file. Appearently everything is written into the router memory. After removing the folder from /tmp/mnt things show nicely over samba as well so it seems to be an out of sync problem.

    These being said, I'm impressed by the fact that I didn't have to reboot the router at all. I'll try tomorrow the usb hub and report back.
  45. teddy_bear

    teddy_bear Network Guru Member

    Interesting... I had similar problems with cardreaders in previous builds, when multi-LUN device support was not enabled. In v20 card readers should work just fine...

    That said, the cardreaders are different from normal drives, and cause some issues anyway. When you insert or remove the card from the reader, the hotplug even is not generated, so the router doesn't "see" it, and you need to manually mount/unmount the drive. Every time another drive is unplugged, or when router web UI refreshes the device list, the USB/SCSI subsystem emits a whole bunch of messages into the system log - for each empty slot of the cardreader - causing some kind of flooding in the logs.

    Apart from these 2 issues, I have not had any other problems with cardreaders in v20 - but maybe because I didn't do all kinds of things you can do with them ;)... I'll do more testing and see if I can reproduce and fix this.
  46. trevorw

    trevorw LI Guru Member

    I'll try tomorrow some tests by mounting/unmounting the card reader drives manually - today I just removed the cards just like the sticks, w/o any interaction with the UI.
  47. Charlie

    Charlie Addicted to LI Member

    USB hub issue on v20 firmware.

    Hi teddy bear.
    First, I can't thanks you more for this firmware. It's truly the greatest firmware I ever seen for Wl-520 with kind of router which has USB port. It's quite useful and powerful to use usb hub to hook USB storage and usb printer together with router. It's really amazing. I really love this feature. Now, I have small ftp server if I need to transfer something when I am outside and I need to do some emergency transfer. I am addict to this thread at the first time I found this forum. I started using teddy_bear's firmware from v6 till now.

    Now, for v20, I would like to share something about what I found. The latest version that I tried before v20 is v19. I have no problem on using usb hub to connect printer and usb storage together. But, for v20, I can't do it anymore. I found if I attach printer's USB cable direct to tomato, it works flawlessly. But, once I attach printer usb cable to usb hub even there is only usb printer on that usb hub without usb storage usb cable plugged in together, I still can't print anything like what I used to. Meanwhile, transfer rate showing in "printers and faxes" is extreme slow and it will show error printing at the end. For eliminating the possible cause, I switched to another better/powered usb hub. But, it still shows the same symptom. I can only print something unless I plug printer usb cable directly to my WL520U on v20. Since you did some improvement on usb side, maybe there is something you missed on v20 but you still have it at v19. So far, I am stick with v19 to make both devices work together by usb hub. Could you check it for possible causes?

    Again, I really appreciate all your work and amazing skill for making all them work.

  48. teddy_bear

    teddy_bear Network Guru Member

    Hmm... There were too many changes made in v20 to easily say which one caused the problem. I'm too using a printer via hub on my 520gu, and have no issues...
    Could you post your logs showing what happens when you attach the printer via hub, and try to print?

    Does anyone else have a similar problem with v20?

    What printer are you using? Does it have a built-in cardreader? Could it be that your printer is USB 1.1, and all hubs you tried to use are USB 2.0? Also, try to turn off usb 2.0 support in the gui, and activate only usb OHCI, and let me know if it changes anything.

    If you're willing to flash your router a few extra times, we can continue troubleshooting by PM and try some test versions...
  49. TheCrow

    TheCrow Addicted to LI Member

    who want to make a tutorial how to install and configure this tomato with torrent client (transmision and rtorrent) .... please... i`m newbie in linux....:((
  50. ray123

    ray123 LI Guru Member

    There's still some "functional anomalies" (AKA bugs) in the USB-storage code. I'm in the final stages of testing reworked code. The kernel 2.4 had a poor design feature that probably seemed like a good idea at the time----but actually is very bad idea and has been pulled out in the 2.6 kernel. It worked okay is simple cases, but falls apart in more complex cases. The unplugged device that still shows up as mounted is a known problem in the current code.

    My new set of mods either fix or works around most of the problems, but not all. It's a heck of a lot better, though.

    Camera cards are a problem. Repeatedly plugging & unplugging cards may or may not work properly.

    There is a gotcha with respect to unplugging mounted devices. Linux will not allow you to unmount a device that is busy (like you have a file open, or have cd'ed to a directory on it). But when you unplug the device, this "failsafe" operation is kinda moot. You can't access the device anyway, since it's unplugged, but there is no way to tell Linux, "Unmount it and I mean it! Don't give me any lip, just do what I told you." So the unmount fails and the cleanup work doesn't (can't) get done.

    The ghost directories you are seeing have the '.autocreated.dir' file, which is the flag to us that we should rmdir the directory when we unmount the device. But we couldn't unmount, so we couldn't clean up. I now do a "lazy unmount", which helps things. In your case, at some later point in time, Linux eventually does the unmount, which exposes the .autocreated.dir' file, but we are long gone. BTW, it shouldn't hurt (he said) to leave that directory there. The next time the device gets plugged in and cleanly unplugged it'll get cleaned up.

    Technical note: Linux will "stack" mounts on mountpoints (i.e., the directory). A few various utilities take advantage of this (like UDF for CD's). At the base is a real directory. When you do a mount, it hides the current layer and only the newly mounted device contents is visible. When you unmount, it peels off a layer and exposed the contents of that layer. That's how we know when we get down to the base directory and see that special file and know that we should remove the directory.

    So, what you are seeing via Samba is a real directory (what you called "ghost directory") and not the device that had previously mounted in that directory. So you are writing to the directory, which resides in /tmp/mnt, which is hosted in the ram.
  51. trevorw

    trevorw LI Guru Member

    Thanks for the explanation ray123. I can imagine that card readers are problematic since they might not properly report the card being unplugged - I can live with manually mounting/unmounting the device. Regarding the samba ghost folders, I personally would prefer not to see them since I might otherwise work with them as if I was working with the stick which would only cause trouble. However I imagine that if you can detect that a folder is a ghost, you know that the associated usb device was unmounted and thus take care of it so it's a catch 22 - it's either all or nothing.

    By the way, once you guys are done with the improvements, I can try them out if you want on my machine (and my cheap, no-name card reader).

  52. freddyspam

    freddyspam Addicted to LI Member

    I was able to fix my ftp issues. Just to recap, I have a 520gu running as a wireless bridge hosting the ftp server. It connects to a Main Router (also running tomato). The only configuration that worked was port forwarding from the main router to port 21 on the 520gu.

    Any Port -->Main Router --> Port 21 --> 520gu

    If I change port 21 to anything else, it breaks down. It lets me log in but the directories fail to load. And yes, when changing the port forwarding, I also changed the listening port on the 520gu vsftpd configuration to match. Just an FYI if anyone else has the same issue as it is a rare setup.

    This time I tested everything from the WAN side. =)

    Seriously though, thank you for all that you have done.
  53. dadaniel

    dadaniel Network Guru Member

    This is not only a tomato related problem.

    I had the following setup:

    WAN --> Thomson Speedtouch Router ---> Linksys NSLU2

    When I change the port forwarding on the speedtouch to WAN 1234 ---> LAN 21, I can connect but no directory listing ...
  54. Charlie

    Charlie Addicted to LI Member

    Hi teddy_bear,
    Thanks for your rapid reply. I don't find to flash it couple times. If you have time and will to give me firmware that you want me to try, I am willing to test it. Let me try the method this weekend that u mentioned previously. Right now, I am tangled with something at work right now. After that, I felt lazy to do anything else after that..:biggrin::biggrin:

    Sure, we can use PM to solve this. It's really weird. It looks like there is no other person having this issue. The printer that I use at home is Samsung ML-2010. The USB hub that I use is D-link DUB-H7. By the way, if I disable usb 2.0 support, the usb drive should be extreme slow I guess.

    Best regards,

  55. wangxx

    wangxx Guest

    It also happens to me, My printer is samsung ml-1740. connects via a usb2.0 hub to 520gu. it works fine on v19. but in v20, i have to plug it directly to the router. otherwise, not able to see the printer.

  56. teddy_bear

    teddy_bear Network Guru Member

    Looks like infamous Linux 2.4 issue with USB 1.1 devices connected via USB 2.0 hub. Samsung ML-2010 is definitely USB 1.1. Not sure about ML-1740 but probably too.

    There are workarounds in this firmware, so it used to work ok with many devices. But it sounds like the latest changes disabled some of them. I think I have an idea what it was - I'll build a test version soon, and let you guys know by PM where to get it from.
  57. stud.beefpile

    stud.beefpile Addicted to LI Member

    Drive formats via web interface?

    Just a request to build in the drive formatting functions into the webif of the "Extras" version of Tomato's USB mod.
  58. freddyspam

    freddyspam Addicted to LI Member

    Why don't you just have the router download ray123's formatting tools to /tmp every time your router starts up? Just make it available somewhere in your network. Or better yet, install optware onto a spare drive with a usb hub. I went with option two, and it's really great having all the extras.
  59. stud.beefpile

    stud.beefpile Addicted to LI Member

    Drive formatting

    The drive formatting scripts are already built into the Extras version of USB mod. I'm just asking that the functions be implemented via the web interface of Tomato, for "neatness'" sake. . .
  60. freddyspam

    freddyspam Addicted to LI Member

    I misread your post. I second your request.
  61. teddy_bear

    teddy_bear Network Guru Member

    Nah, sorry...
    If you need to format/check the drive or setup a swap partition, IMO it's perfectly ok to do that via command line in Telnet/SSH session. Too much work to add the neatness that's not really needed, and won't include all possible options anyway...
  62. ray123

    ray123 LI Guru Member

    Yeah, I agree. If you want to do "real computer things", just telnet/ssh in and do them from the command line. Even big-boy Linux systems like Unubtu don't have a GUI interface for doing stuff like that.

    FWIW, IBM's AIX version of Linux had a GUI interface for all the standard system admin stuff and everybody hated it.
  63. stud.beefpile

    stud.beefpile Addicted to LI Member

    A little help, please?

    Okey doke. . .I'm trying to reformat a flash drive to ext2 using the Extras version of USB mod. . .Here's the telnet conversation between myself and the router. . .

    oot@WL-500gPv1:/tmp/home/root# mount
    rootfs on / type rootfs (rw)
    /dev/root on / type squashfs (ro)
    none on /dev type devfs (rw)
    /proc on proc type rw (0)
    /tmp on ramfs type rw (0)
    usbdevfs on /proc/bus/usb type usbdevfs (rw)
    /dev/discs/disc0/part1 on /tmp/mnt/SANDISK\0401GB type vfat (rw,noatime)
    root@WL-500gPv1:/tmp/home/root# fdisk /dev/scsi/host0/bus0/target0/lun0/disc

    Command (m for help): o
    Building a new DOS disklabel. Changes will remain in memory only,
    until you decide to write them. After that the previous content
    won't be recoverable.

    Command (m for help): n
    Command action
    e extended
    p primary partition (1-4)
    Invalid partition number for type '0'
    Command action
    e extended
    p primary partition (1-4)
    Partition number (1-4): 1
    First cylinder (1-124, default 1): Using default value 1
    Last cylinder or +size or +sizeM or +sizeK (1-124, default 124): Using default value 124

    Command (m for help): t
    Selected partition 1
    Hex code (type L to list codes): 83

    Command (m for help): p

    Disk /dev/scsi/host0/bus0/target0/lun0/disc: 1024 MB, 1024966656 bytes
    255 heads, 63 sectors/track, 124 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot Start End Blocks Id System
    /dev/scsi/host0/bus0/target0/lun0/part1 1 124 995998+ 83 Linux

    Command (m for help): w
    The partition table has been altered!

    Calling ioctl() to re-read partition table
    fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

    dmesg (via Logs) indicates the following:

    Feb 28 23:55:30 WL-500gPv1 user.warn kernel: Device busy for revalidation (usage=2)

    Can you tell me what I'm doing wrong and how to make things work?

  64. teddy_bear

    teddy_bear Network Guru Member

    Did you unmount the drive prior to running fdisk?
  65. ray123

    ray123 LI Guru Member

    /dev/discs/disc0/part1 on /tmp/mnt/SANDISK\0401GB type vfat (rw,noatime)

    fdisk /dev/scsi/host0/bus0/target0/lun0/disc

    You are changing the partition table on a disk that is mounted. That's a no-no.
    [edit] It isn't really obvious that "/dev/discs/disc0/" and "dev/scsi/host0/bus0/target0/lun0/" are the same disk. If you do:
    ls -l /dev/discs/*
    you'd have seen:
    /dev/discs/disc0 -> ../scsi/host0/bus0/target0/lun0
    Which shows that the /dev/discs link is an alias to the real /dev/scsi/.....

    fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy

    dmesg (via Logs) indicates the following:

    Feb 28 23:55:30 WL-500gPv1 user.warn kernel: Device busy for revalidation (usage=2)

    Which is telling you just that. Fdisk is doing a BLKRRPART (reread partition table ioctl), and the kernel driver is refusing to do so because the disk is busy. The usage count of 2 is 1 for the ioctl (which is okay) and one for the disk being mounted (which is not okay).

    A reboot will resolve it. But in the future, make sure all the partitions on a disk are unmounted before doing fdisk. Don't forget that you have to do mkfs after the fdisk.
  66. stud.beefpile

    stud.beefpile Addicted to LI Member

    I'll give it another shot

    I'll have to carefully read what you posted. . .I've got chores to do and will mess with it later. . .What I scanned of the post I think I did. . .I may have had a brain fart somewhere along the way or missed some small, but important step.

    I rebooted with automount un-checked, and then went into telnet to try to format it, and I still ended up with the output I posted. . .It seems to automount even with it unchecked and saved. . .When I did the new flash, I cleared nvram through the webif, so maybe I need to do a hard reset?
  67. teddy_bear

    teddy_bear Network Guru Member

    I just tried with v20, and with automount un-checked the drives are not getting auto-mounted - whether on reboot or plugging in. Are you sure you unchecked automount, and not auto-share setting? If so, you must have something else that does mounting...

    Anyway, you don't have to disable automount to run fdisk. You just need to unmount the drive before starting fdisk, or any other e2fs utility (mke2fs, e2fsck). You can unmount the drive from GUI using "Unmount" link, or by executing "umount" command manually in telnet. When the drive is shown as "Mounted? No" in the GUI, it's safe to run fdisk.
  68. teddy_bear

    teddy_bear Network Guru Member

    Update - build 21.

    This is the bug fix release - it has no new features or functional changes.

    • Fixed problem introduced in build 20 with some USB 1.1 printers not working when connected via USB 2.0 hub.
    • Fixed support for Kyocera Mita FS 820, Brother HL-1440 and Epson M-129C printers.
    • Fixed DDNS update scheduling.
    • Added Hostname validation to the Web GUI.
    • Fixed writing the hosts file when Hostname is changed in the Web GUI.
    • Fixed potential infinite lock in USB hotplugging.
    • Included additional "USB Red" color scheme from Absolon, and it's "USB Blue" variation into the "Extras" build.

    Links to the firmware binaries and the git repository with sources are in the 1st post. The complete sources of this build can also be downloaded as a git snapshot in tar format.
  69. teddy_bear

    teddy_bear Network Guru Member

    Starting from v20, you can use the following command in a custom script to unmount all USB drives:
    INTERFACE=TOMATO/1 ACTION=remove PRODUCT=-1 hotplug usb
  70. trevorw

    trevorw LI Guru Member

    Hi teddy_bear,

    I've updated the router to v21 and so far everything works nicely. I plan to do some more testing with the usb sticks/card reader in the weekend.

    Nice. I was thinking whether a mount option is needed but this is done by default anyway so in the worst case scenario the stick just has to be replugged.

    Thanks again for the work and another fine release!

    P.S. nice of you to include the extra skins - the interface looks slicker :)
  71. borosai

    borosai Addicted to LI Member

    I upgraded to v21 Extra today, and everything is running smoothly (well, the few things I use at least). Again, thanks to all involved: great job.
  72. newsfaq

    newsfaq Addicted to LI Member

    hey, newbie question here: to upgrade from v20 to v21, do you need to rename the *.trx to*bin ? can't find in the detail installation post .

  73. borosai

    borosai Addicted to LI Member

    Nope, there's no need to rename it.
  74. newsfaq

    newsfaq Addicted to LI Member

    Thanks borosai ! I am on V21 now , everything ( NAS + FTP ) seems to working just fine ...

    Anyone knows how to add webcam support ?
  75. ray123

    ray123 LI Guru Member

    Why do people keep asking about webcam support? Why would you put a webcam on your router instead of your main computer? What am I failing to understand?
  76. Victek

    Victek Network Guru Member

    I want to boost my car up to 300HP.. why not?.. the people ask and you can say "I don't understand" .. is up to you to decide about but for sure the people will ask for more and more ;)

  77. Engineer

    Engineer Network Guru Member

    They probably want to be able to do remote monitoring of the premises without leaving a PC powered on.
  78. ray123

    ray123 LI Guru Member

    V21 with new USB mods

    I've just finished up with my latest updates to V21.
    V21-usb5 Based on the V21 release.

    * Improvements to USB storage hotplug code. As in "forklift upgrade". :)
    * Fixed bugs in build options for busybox & layer7.

    They can be downloaded from:

    The files of interest are:
  79. newsfaq

    newsfaq Addicted to LI Member

    There got to be a reason, I guess. For me , I'd like to have a simple monitoring system on Router without turning on the computer. "motion" with optware is an option but I guess if webcam(or any USB video capture device) is supported we can just use some simple CGI script(supported by V21) to capture the picture, I am new to the system and looking for feasible solution.
  80. ray123

    ray123 LI Guru Member

    Teddy Bear, my comments on the v20/v21 update.

    Good job on the new uab-nas web admin interface.

    Good idea on the automatic invocation of "swapon -a" & "mount -a" when the usb-storage is plugged in.

    My previous getsem/semop code was broken. I musta been drunk when I wrote that code! I don't know how it ever worked on my machine--but it did. Thanks for fixing it.

    Good idea on holding back the usb in startup (rc/init.c) in favor of the running user init scripts. But it's slightly broken (timing / sequencing) -- it could accidently miss doing an automount.

    The "execute_with_maxwait" timeout with multiple scripts: My code had the maxtime interval (wtime) encompass all the scripts. This seemed to be in keeping with the original Tomato idea (although that implementation was broken). The v20 revision of that code gave each script the entire maxtime. Was that your intention? That could be a very long time when there are multiple user scripts for an event.

    The "disconnect/reconnect usb from scsi" kernel patch doesn't help
    anything. And it doesn't even disconnect if the device is busy--like
    when you unplug a USB stick with mounted partitions--as I do. I
    would be inclined to pull this patch back out; it just adds one more
    bit of non-deterministic usb action.

    Yikes!!! It's 64KB bigger than my trimmed down v19+usb version. Busybox (un-squashed) is 30% bigger--215KB. :eek: That's a loss of one entire 64K block out of the jffs.

    Ok...spent a few hours tracking it down.
    1) The build command for busybox is wrong. The old way was wrong--it forced BBX to build with wrong options. The new way had no effect. That accounted for 125K.
    2) Extra utilities that I had removed in my last patch (V19 + USB), most of which are un-needed (IMHO). Here's the list & sizes. I've marked with an X the ones that I think we can omit and a ? the ones that I would omit but you might prefer to keep.

    X 1460 coreutils/usleep.o
    X 1912 util-linux/findfs.o
    X 2524 procps/free.o
    X 2572 coreutils/env.o
    X 2752 miscutils/strings.o
    X 3008 editors/cmp.o
    X 3012 coreutils/head.o
    ? 3252 coreutils/wc.o
    ? 4260 coreutils/tr.o
    X 9868 coreutils/printf.o
    X 11560 networking/arping.o
    X 14380 procps/top.o
    ? 15252 networking/telnet.o
    X 19884 archival/libunarchive/decompress_unzip.o
    . 20076 networking/traceroute.o
    X 74408 editors/awk.o
  81. ray123

    ray123 LI Guru Member

    Ah, okay, I now see why someone might want webcam support. I wasn't attacking anybody, just sincerely wanted to know---figured that I must be missing some simple explanation. Remember, everything really needs to fit into 4MB of flash. Plus perhaps a USB drive.

    Please----anyone who wants to tackle this, feel free to submit a patch. Otherwise, perhaps I'll get motivated to look into it. After I've finished up a few more items on my todo list. Provided that nobody else has gotten it working by then.

    Of course, it might get moved up higher in my list if somebody wants to send me a webcam, seeing as I don't even have one to test with. ;-)

    Question: does DD-WRT have webcam support? If so, how well does it work (on a 4MB flash router)? 'cause I'd hate for DD-WRT to be better than Tomato in any respect.
  82. teddy_bear

    teddy_bear Network Guru Member


    Took a quick look at your changes... Great set of improvements as usual! I love the new probe replacement, and clean up in hotplug processing :). Did you also fix the logs flooding problem in case of cardreaders with empty slots while reading the devices list from the Web GUI? That's actually the one that *really* bothers me now...

    But using MS_SYNCHRONOUS is not a good idea, at least for flash drives - it can kill them faster than anything else...
    Gee... Was is really that easy and always there ;)? - EDIT: Never mind, saw a new kernel patch to supply this...
    If it's broken, it has to be fixed. But your current fix doesn't work for me - I need the Init script to be able to access USB drives, so USB has to be initialized before that. Since I did not have any issues with it yet, could you let me know how to make the current code to fail - otherwise I don't know what to fix ;)?
    Hmm... Once you brought it up I'm not sure anymore... I'm trying to minimize changes to original Tomato code to only absolutely necessary to simplify future updates to the next versions - but I think in this case I also wanted to give each script its own timeout. Anyway, doesn't seem to be very important...
    Right, it doesn't disconnect if the device is busy/mounted, but if you unmount the device first it completely disconnects it from scsi cleaning up the /proc/scsi/scsi etc. Which I think is a good thing to do.
    That's a good catch! I see you changed it to compile against shared libgcc. It reduced the stripped but uncompressed busybox by 100K, but unfortunately inflated libc by 60K... Still - 40K uncompressed is a good gain :).
    Heh... usleep, findfs, free, env, cmp, head, tr, top are the ones that I either use from time to time, or have used in some of my scripts. traceroute is used in Tomato GUI. You are not suggesting to remove telnet, are you ;)? Not sure about arping, but people may have use for it (it's already excluded from Lite though). Unzip is only included in Extras build. I think we can easily strip out awk from Lite and Standard versions though. But I'd rather keep everything else on the list. Of course if anyone else has an opinion regarding this - please let us know.
    I think the reason Tomato uses its own locking technique is to be able to break the lock after a timeout. I don't know if your latest changes 100% eliminated a chance for a hotplug process to hang - but I've seen it happening before, so I'd prefer to have the lock that can expire. Of course, it can be done with non-blocking flock() as well, but it would not make much of a difference compare to Tomato implementation, would it?
    I think DD-WRT does not, but Asus Oleg's firmware does. You can load it into 520gu and experiment with it if you're interested.
    Unfortunately we'll need virtually unlimited flash space, and a lot of free time in our hands to outperform DD-WRT and other firmwares in all possible aspects ;)... The time is a problem - at least for me - so after integrating your latest changes I'm going to take a break until Tomato 1.24 comes out. But in terms of storage and printing support we're already better I believe :).
  83. bananaman

    bananaman Guest

    Hi, I'm on a Teksavvy dsl connection in Canada and I need to use a mlppp connection in order to not be throttled by Bell Canada. I just installed v21 std of your firmware on a Asus wl-520gu and so far its working fine as a nas with Samba, thank you.
    Is there a multilink option to pppoecd, or is there a way to have the firmware use pppd with the multilink option instead?
  84. ray123

    ray123 LI Guru Member

    Did you also fix the logs flooding problem in case of cardreaders with empty slots while reading the devices list from the Web GUI?
    Um, don't continually refresh the device list from the gui??

    Seriously, can't really be done. When you try (directly or indirectly) to read information from a non-existant disk you are going to get kernal messages about read failures.

    But using MS_SYNCHRONOUS is not a good idea, at least for flash drives - it can kill them faster than anything else...
    Wrong. You've been believing everything you read in Linux man pages, haven't you? ;-) I read the same thing, took it back out, and then said, "Waitaminute--that couldn't be right!"
    Windows uses SYNC on flash drives. (That's what "Optimize for quick removal" means. Right click on a USB drive, go to hardware/properties/policies and you'll see it.) So does Unubtu Linux.

    When I thought about it, I realized that that claim couldn't possibly be correct.
    Imprimis: All that async does is enable write caching to the drive. But the writes still happen, they are just delayed.
    Secundo: The engineering designers of USB sticks and camera cards have taken great steps to maximise their lifetime. The internal controllers do a great job at wear leveling, etc. When I was googling this topic I came across some engineering documents that spoke of lifetimes of years.
    Heck, even the raw flash chip used in the Asus 520-GL is spec'ed for a minimum of 300,000 erase cycles per block. And claims the typical real number is about 1,000,000. And that's for a raw chip with no wear-leveling or bad-block reassignment.

    No, the option that will kill USB flash drives is atime. And *everything* defaults to noatime on a USB drive.

    I need the Init script to be able to access USB drives, so USB has to be initialized before that.
    A thorny problem, indeed! In my very first document (unpublished) on Tomato startup timings, I discussed the startup script / timing issues with USB drives.

    (Aside: My wife and I have a combined office/craft/computer room, and we generally are in it together. She's watched me plugging & unplugging USb drives & cables for the past few weeks, but didn't say anything, because she's learned that it's not a good idea to ask an engineer/programmer any technical question. Let sleeping dogs lie, as it were. Anyway, three days ago she asked me, "Why are you always jumping up and pulling the power plug from the router?" My answer: "I'm testing something, and when it goes wrong the router locks up solid and I have to pull the power to get it to reset.")

    On a reboot, it can take 5-10 seconds for the USB drives to be mounted, from the time that the first USB device (in my case, the hub) is detected by the kernel. In my (unpublished) write-up, I said, "When the init script is invoked, the USB system is in the process of coming up, but isn't fully up yet." There are related discussions about this on DD-WRT forums and the general consensus is that the script needs to have a sleep for at least 5 seconds before trying to access any disks. There is also a standard recommendation to have your "startup" script run at the WANUP event rather than the STARTUP event--because that is usually delayed enough so that the USB drives are all up.

    So....if the init script needs to set stuff up before drives come up--like maybe setting up /etc/fstab--then the INIT scripts should be run *before* the start_usb(). If the init script needs to access a USB drive, it *must* sleep for 5-10 seconds *after* the start_usb. I said that the V21 code ws broken here because it doesn't accomplish that. As I read that code, it appeared to be attempting to stall the automount processing in order to paper over a timing issue. It turns off automount, starts vlan, lan, wan, services, starts the init script, and then turns automount back on. But all those things will happen in a few microseconds---the longest thing there would be if the init script took its entire 2 second timeout. Also, automount events don't merely get held off (if that was the intent)---they get LOST. When an "add" hotplug event is caught, if the automount flag is off, the drive will *not* get mounted (just whatever happens with "mount -a"). I would guess that the reason this works for you is that automount is off so briefly that no USB hotplug events have been generated in that interval (remember--it's only off for a few microseconds unless the init script has a sleep).

    (Can you guess who had spent the last 2 decades of his career working on real-time systems where timing issues are a major factor, and therefore can spot timing holes quickly?) I really HATE implementation that go, "Let's do this thing really fast and hope that nothing bad happens during that teeny-tiny window." That method often ends up with an emergency trip to a customer site to fix a "Joe says that this message will never print out on the console" problem.

    I actually spent some time noddling this issue, and didn't come up with a solid solution other than "do a sleep(10) in the init script". Or to do the processing in either the hotplug script or the after-automount script. Frankly, doing a sleep in the init script is ugly. It's a by-guess-and-by-god method. A "let's wait a while and hope that what we want to happen has actually happened" method. Ugly and prone to mysterious failure. The heart of the problem is that we simply don't know when the disk will actually get mounted. The only place we know something is when the disk actually does, in fact, get mounted. And that's when one of the afore-mentioned hotplug scripts will be invoked.

    This really needs to be covered in a Tomato Users Manual.

    I'm trying to minimize changes to original Tomato code to only absolutely necessary to simplify future updates to the next versions
    You're joking, right?

    Anyway, doesn't seem to be very important

    I see you changed it to compile against shared libgcc. It reduced the stripped but uncompressed busybox by 100K
    Actually, the orginal version linked against shared libgcc. By accident. It set CFLAGS to "-Os", which completely turned off all the configured compile/link flags for a busybox build. The criptic comment in the makefile said just that---once you realized that setting CFLAGS turned off all the options. 'course a comment that is only meaningful after you already understand what it's saying isn't a very useful comment. :frown: The linker default is to build with shared, and busybox makefile changed it to static. But that was turned off by the presence of CFLAGS. It's really ugly when one bug masks the existance of another bug. You fixed the 1st bug whcn you changed it to CFLAGS_busybox, but that let the 2nd bug (static libgcc) reveal itself.

    ...programs....Sure, why do we need to telnet out of the router? We need telnetd/sshd so we can get IN, but why do we need to telnet out? Of course, sometimes programmers get tired and confused about which system a particular window is on, and telnet back to the system they are telnetting from.......but that's too kinky to waste space for. Since I do all my work on my Windows box, I have windows open on my Linux box (X-Manager sessions), windows open on the router (kitty) and windows open on the, um, WIndows machine. So I sometimes get *very* confused. My wife like to come by and remark on all the little windows open on my monitor, all with different colors.
    Do a man on arping and you'll see that we don't really need it. Awk is huge and we should definitely get rid of it---anybody who needs an awk script on a router really should get familiar with sed and bash.

    think the reason Tomato uses its own locking technique is to be able to break the lock after a timeout.
    I think the reason is that he didn't know of a better way to do locking. And a one second granularity on a lock contention is absurd. I counted at least THREE different lock techniques used in different subsystems in Tomato (both the base Tomato code and the various applications).

    This kernel USB lockup is beginning to piss me off. You may have seen my running commentary in the code---it's definitely a bug in the kernel. I suspect that I've spent more time trying to narrow it down and work around it that it would have taken me to find and fix the actual bug. But this work-around seems to be adaquate for now, and the side-effect is just a few wasted seconds, so I'll not look into it any further at this time. I want to get back to the jffs code.
  85. teddy_bear

    teddy_bear Network Guru Member


    Seriously, can't really be done. When you try (directly or indirectly) to read information from a non-existant disk you are going to get kernal messages about read failures.
    Yes, but if instead of reading directly from a non-existent disk we can read from some other place (/proc/partitions maybe?), than may solve the issue...

    But using MS_SYNCHRONOUS is not a good idea...
    Heh... I know the theory ;)... But there's a bit more to it. For a real-life experiment, I recommend you format your most expensive flash drive as FAT32, mount it with sync option, and copy a large (1GB+) file to it from Windows using Samba. If the drive is still alive after that, do it a few more times - it shouldn't take too long ;). By the way, my desktop Ubuntu always automounts flash drive without the "sync" flag - no matter if it's FAT or Ext2/3.

    I need the Init script to be able to access USB drives, so USB has to be initialized before that.
    As I read that code, it appeared to be attempting to stall the automount processing in order to paper over a timing issue.
    Nope, not the timing issue. Any timing issue that the Init script can have is up to the script to resolve... The only reason to stall automount is to allow Init script to do anything that may affect automount - like writing /etc/fstab, or mounting attached drives manually. No matter how well you document the best way of doing things, people will still be using Init script for all kinds of actions that really should be done somewhere else (and there's nothing wrong with it)... After everything's initialized, all attached drives are forced to get mounted, so nothing gets lost. I don't see anything here close to the "let's hope that nothing bad happens" kind of implementation ;).

    think the reason Tomato uses its own locking technique is to be able to break the lock after a timeout.
    I think the reason is that he didn't know of a better way to do locking.
    He definitely didn't rewrite all the Linksys code and other applications included in the firmware, so multiple different locking techniques are most probably not the Tomato author's idea ;). Anyway, leaving aside the 1 second granularity, his flock() replacement works just fine for what it's used in Tomato...
  86. ray123

    ray123 LI Guru Member

    Seriously, can't really be done. When you try (directly or indirectly) to read information from a non-existant disk you are going to get kernal messages about read failures.
    Yes, but if instead of reading directly from a non-existent disk we can read from some other place (/proc/partitions maybe?), than may solve the issue...

    Dang---my long reply just disappeared into nowhere. I hate computers.

    Yes, with my latest USB mods, I believe that httpd can trust /proc/partitions to be always accurate. You'd have to change the code in is_disc_mounted to do work similar to what usb.c now does. If you use opendir/readdir, that will definitely make the kernel try to read the non-existant disc.

    In fact, maybe the best way is to just go ahead and call exec_for_host! Supply your own func() that just calls find_label to get the label. The "when_to_update" parameter should be zero. Just move exec_for_host up to shared/misc.c, same place as find_label is.

    sync on USB flash drives.
    More on this in another post.

    The only reason to stall automount is to allow Init script to do anything that may affect automount - like writing /etc/fstab, or mounting attached drives manually.
    No need to stall automount for this. Just the correct ordering of operations will do the trick. Run the init script and then start_usb.
    Let me point out again, that the user can NOT mount drives manually in this script. Well, not reliably anyway. The kernel/USB subsystem takes anywhere from 5 to 10 seconds to come up fully, from the time start_usb is called. I think that what you are reaching for is a startup sequence something like this:
    1) run init scripts (allow user to muck with /etc/fstab or whatever.)
    2) start_usb.
    3) wait 10 seconds for USB to come up and stabilize. Don't do any automounting.
    4) run 2'nd part of init scripts. (allow user script to issue mount commands)
    5) Allow automounting to resume.
    6) onward ho!

    In step 2, *something* has to wait those 5-10 seconds before opening up the floodgate in step 5.
    The V20/21 code doesn't work--because it doesn't do any waiting. There are only a few microseconds (maybe milliseconds) between the time it disables automount and the time it re-enables it. This is far shorter than the length of time it takes for the USB subsystem to come up. You've re-enabled automounting while the USB stuff has just barely begun. Try an experiment, change the code to grab the jiffie clock when it disables automount and when it re-enables it, then print those values to syslog. IIRC, a jiffie is 10 msec. I doubt that the elapsed time will be even 1 jiffie.

    I think the reason that your setup works for you is that the disks don't get mounted where you think they are being mounted. I think they are getting mounted in the hotplug event in usb.c and _not_ getting mounted in init.c by the call to mount_all.

    So, do we insert a sleep(10) before re-enabling automount? I doubt we'd like that. If you really want to hold off automounts, then the right way (IMHO) to do it would be to call usb_lock() then spawn off a thread which does speep(10) and calls usb_unlock(), then exits.

    But that *still* doesn't solve the user's init script problem. That script *still* must sleep for 5-10 seconds to allow the USB subsystem to come up, before he can mount any disks. Luckily, the kernel reads the partition tables automatically the very first time it sees a disk, so there are no issues there.

    What's gonna happen is just what happens now. Users will write an init script and wonder why the damn thing doesn't mount his disks. If he knows enough to use google, he'll find a bunch of DD-WRT forum posts that tell you to do a sleep in the init script, or to put the code in a WANUP script instead of INIT. Worse, he'll have unpredictable problems. It'll be working fine when all he has is one USB stick. But then one day he'll add a hub and plug the USB stick and a printer into the hub. That'll change the timing, and it won't work anymore. Worst case, the timing will be on the ragged edge. Sometimes it will work, sometimes it won't. Unpredictable non-repeating problems are the WORST kind of bugs. It's better to fail all the time than to sometimes work and sometimes fail.

    Of course, after reading the DD-WRT forums he'll put a sleep(5) in his script -- after writing /etc/fstab but before the mount command. But while it is sleeping, Tomato has disabled and re-enabled automounting, so all the disks get automounted while his script is still sleeping. The real true Right Way (tm) to do it is forget about all that init script crap. The load_files_from_nvram() will restore his /etc/fstab. The automounting will call "mount -a" to mount the disk according to fstab, or automount if the disk isn't in fstab. Everything just automagically works. No need to put sleep() anywhere; no timing problems like [attempting to] mount a disk before the disk is there. When the disk becomes available, it gets mounted properly all by itself, at just the right time. No having to deal with whiny users bitching that their disks don't mount. This also works Just Right (tm) if the USB drive is a hard drive that somehow didn't get powered up at the same time as the router--like after a power failure. When the external USB hard drive finally gets powered on---it will get mounted slick as a whistle.

    And Tomato will be better tnan DD-WRT. No writing init scripts, no need to sprinkle sleeps anywhere. No screwing with hardcoded mountpoints (I don't think DD-WRT can do mount-by-label, can it?).

    You've got your /opt on a USB drive, and things like webcam software in /opt? No worries. Set it up in fstab, put your webcam software startup commands in the after-mount script... no, scratch that! All you need is the software startup commands on the USB drive itself! Put them in /opt/etc/config/*.usbmount and they'll get automatically executed after the disk mounts. Cool!

    No matter how well you document the best way of doing things, people will still be using Init script for all kinds of actions that really should be done somewhere else

    After everything's initialized, all attached drives are forced to get mounted, so nothing gets lost. I don't see anything here close to the "let's hope that nothing bad happens" kind of implementation
    Alas, I see nothing but "let's hope that nothing bad happens". I have a pretty devilish mind, and a real knack for stress-testnig things and uncovering bugs in people's code. ;-)

    Well, what about the case where the user wants his script to do something with the file(s) on the disk after it gets mounted? Maybe he's runnng folding@home and needs to fire off a wget or something. So, great, Tomato forces all the drives to get mounted. But then what? How does his script know that it can now do its thing with the files on the disk? And heck, the place where the "force all attached disks to get mounted" is, nothing is gonna happen. There are no drives attached yet. The USB subsystem isn't up yet. Try another experiment. Just before init calls that function, put system("cat /proc/scsi/usb-storage-*/* >/tmp/info.txt"). Reboot the router. Then after you can telnet in, look at /tmp/info.txt and see what the conditions were. I'll bet a donut that it'll say: "cat: can't open '/proc/scsi/usb-storage-*/*': No such file or directory"
  87. teddy_bear

    teddy_bear Network Guru Member

    Ray, I think you're missing the point here... There's no doubt that there's a better practice than using Init script for mounting etc. Everything you said is valid - however, even the Init script approach can work reliably.
    In fact - the time between disabling and re-enabling automount is about 5 seconds on my router. But it absolutely doesn't matter. The USB system is initialized and ready by the time Init script is called. There's no need to wait 5-10 sec before you can call "mount" from the Init script - I've experimented before with 3 flash drives and a printer attached to a hub, and 1 sec was more than enough. Since the hotplugging code is serialized, and includes much longer delays, disabling automount is not *really* needed - the Init script will be able to do its work before automount kicks off - but that would be exactly the "let's hope it works" kind of thing. Disabling automount makes sure nothing gets automounted while Init script is running.
    Again - this is irrelevant. What's important is that the attached drives will be mounted no matter what - either by exeplicit mount_all() call, or - if USB subsystem is not fully initialized yet (which is apparently not the case) - by the following hotplug events.
    And by the way - this is not my setup ;). But I'm sure some people may still use the Init script for mounting etc, and don't want to break it. This is the only reason I want usb to initialize prior to running Init script, and disable automount while Init script is running.
  88. trevorw

    trevorw LI Guru Member

    Hi guys,

    Here's my testing report on build v21 (uptime of about 3 days). Everything seems to be running fine - I've downloaded some torrents besides the usual internet traffic (mail, browsing) and things are looking good. I'm not using QoS so my setup is pretty basic (PPPoE connection).
    Regarding the USB connection, the USB sticks run fine. I've tested an usb hub w/ 3 sticks and one external hdd with 4 partitions (2 fat, 2 ntfs). The interface had an auto-refresh of 3 seconds and I could see how first the devices were identified and then mounted - nice!
    Mounting went out okay however unmounting was problematic. I've first u(n)mounted the hdd from the UI and then unplugged from the hub. Once things that I've noticed is that under XP the hdd shuts down but here I could still hear it working.
    To make things more interesting,I've unplugged (w/o umounting) and then plugged in the hdd port, an usb stick. At this point the UI started to be out of sync. The drive just spawed was marked an unmounted but plugged in and so was the hdd that I've replaced. I've tried umounting the stick but I got a 'waiting...' and nothing happened so I just unplugged the usb hub which seemed to have cleaned the UI.
    The file share was out of reach so I had to restart it (from the UI just pressed save on its page) and things went back to normal. However I have another drive showing (probably the stick that got quickly plugged/unplugged) while the new drive is marked as being umounted. I've tried accessing it over samba but it's empty and marked as read-only.
    The thing is that from the logs the kernel still tries to access the old folder (see log2.txt).
    Since I couldn't umount it, I've unplugged it but then I keep getting:
    log1+log2 View attachment

    At this stage I had two ghost mounts but umount just one solved the problem:
    I guess the problem is again the fact that I'm using a usb hub rather then a plain usb device/stick (and probably I plugged/unplugged the devices too fast). I'm not sure whether that's expected or not but I'm not sure why the UI gets confused - maybe a force umount option would help ? (I'm not sure whether all tomato users fancy the command line and logging into the router).
    Below is a log snippet from the manual umount of the ghost drive:
    One thing about the report above, the usb problem wasn't as bad as it sounds and once solved, newly plugged sticks were recognized while the one that was there the whole time worked as expected.

  89. teddy_bear

    teddy_bear Network Guru Member

    Thanks for the report. There's definitely an issue here - that's not the way it should work. I have not tested it much with HDDs though - mostly with flash drives. I'll try to experiment to reproduce the issue.

    The forced (actually, "lazy") umount option is already in place in v21 - but it's only used when you shutdown/reboot the router, or unplug the drive without unmounting it first. Unmount from GUI is purposely not using the lazy option, so the apps that keep the drive busy won't get confused, and you can manually shut them down if you get the error message.

    Please clarify what actually happened here. You unplugged the drive, and then plugged it back in without unmounting first, correct? After that the UI displayed it as "unmounted but plugged in"? So far all looks correct to me, unless I'm missing something. "I've tried umounting the stick but I got a 'waiting...' and nothing happened" - you lost me here - how can you try unmounting the drive which is not mounted, and already marked as unmounted in the UI?
  90. trevorw

    trevorw LI Guru Member

    You're right - I was trying to mount the drive but I got a 'waiting ...' message. To recap, I unmounted the hdd, then from the same usb hub, unplugged a stick (w/o any umounting) and plugged it in the slot used by hdd. I did that on purpose to check whether the router can detect all the events in the proper order.
    After plugging the stick, it was marked as unmounted - I was expecting to see it automatically mounted. The hdd was also in place but umounted. Mounting the stick caused all the drives in the UI to display the 'waiting' message. After a while, since nothing changed I unplugged the whole hub, which was properly reflected in the UI.

    If you'd like me to try something else (w/ or w/o the hdd) I can do that, no problem. I can do some tests myself but in general I'm stress testing the device which might not be very helpful for debugging purposes.

  91. ray123

    ray123 LI Guru Member

    Startup/INIT timing

    Wow, was I ever wrong about the timing! Guess I owe somebody a donut.

    Here's a clip of the instrumented init code, with timestamps. Timestamps are in seconds from Linux startup--the jiffie clock in units of seconds (100 jiffies = 1 second).

    system("cat /proc/uptime >> /tmp/info");		//	7.05
    run_nvscript("script_init", NULL, 2);
    system("cat /proc/uptime >> /tmp/info1");		//	7.46
    system("cat /proc/uptime >> /tmp/info2");		//	11.05
    system("cat /proc/uptime >> /tmp/info3");		//	11.88
    //	First USB hotplug host event rcvd by /sbin/hotplug	12.xx
    system("cat /proc/uptime >> /tmp/info4");		//	13.03
    system("cat /proc/uptime >> /tmp/info5");		//	13.32
    //				First USB disk mounted		19.xx
    system("cat /proc/uptime >> /tmp/info6");		//	21.66
    //				All USB discs are mounted	22.xx
    syslog(LOG_INFO, "Tomato %s", tomato_version);
    syslog(LOG_INFO, "%s", nvram_safe_get("t_model_name"));
    system("cat /proc/uptime >> /tmp/info7");		//	21.87
    system("ls -l /proc/scsi/usb-storage-*/* >>/tmp/info7");
    It takes 3.5 seconds for the start_usb() function to run.
    And 8.3 seconds for start_services().
    Both these are much slower than I would have guessed.

    In this test, I had 3 USB hosts daisy-chained on 2 USB hubs, for a total of 6 mountable partitions.

    The 1st hotplug "add" event is received by /sbin/hotplug 5 seconds after the user's INIT script(s) are started.
    The 1st host is recognized and its partitions mountable about 12 seconds after the INIT scripts are started.
    The 3rd host is recognized and its partitions mountable about 15 seconds after the INIT scripts are started.

    Note that this timing is the same whether auto-mounting is enabled or disabled.

    So, the user script has to wait 12-15 seconds before it can reliably mount or access the USB disks.

    Oh, darnit, I see a bug in my recent patchset.
    Here's the fix.
    --- usb.c.~1~   2009-03-06 11:20:35.000000000 -0600
    +++ usb.c       2009-03-08 18:17:45.000000000 -0500
    @@ -273,7 +273,7 @@
           //cprintf("Label: %s\n", the_label);     //test
           //return; //test
           sprintf(mountpoint,"%s/%s", MOUNT_ROOT, the_label);
    -      if (mount_r(dev_name, mountpoint, type))
    +      if (mount_r(dev_name, mountpoint, type) == 0)
        /* Can't mount to /mnt/LABEL, so mount to /mnt/discDN_PN */
  92. teddy_bear

    teddy_bear Network Guru Member

    Hotplug event can be fired up much later than the drive is actually ready. Try another experiment - move start_usb() in front of init script, store /etc/fstab in nvram with the mount info for the attached drive, and add these lines to your init script:
    sleep 1
    mount -a
    If your drive is not mounted in the init script, you can have your donut back ;).
    Nope, it was correct the first time... mount_r() returns 0 if mount failed.
  93. Low-WRT

    Low-WRT LI Guru Member

    Hey teddy_bear, just wanted to say a quick THANK YOU! I bought a WL-520GU last week and flashed it with your mod. After flashing, I plugged a 8-gig flash drive, and after setting everything up, it works GREAT!
    I no longer need a pc running 24/7 to serve my network music & files!
  94. teddy_bear

    teddy_bear Network Guru Member

    Hi trevorw,

    I'm testing the new version now - it includes the latest ray123' patches, and some additional usb driver updates.

    So far I was unable to reproduce your issue. Plugging and unplugging (both - mounted and unmounted) usb flash drives, hdds and the whole hub works fine all the time. Although possible, I'm not sure whether the latest changes fixed your issue. It could be that I'm simlpy not doing exactly the same things as you did, or it's hardware-specific, or whatever...

    Did you have anything else that may keep trying to access your drives after you unplugged them (still mounted) - other than FTP or Samba?

    EDIT: I was able to reproduce your issue, or at least to get very close to it. That was when I yanked the drive out of the USB port while the other process was actively accessing it (in my case, I was copying a large file to it via WinSCP). After re-plugging the drive back in it was not mountable (and the old "ghost" mount directory was still present) up until I closed WinSCP which was still trying to continue copying. After closing WinSCP, all went back to normal.

    Based on your log messages, some process was probably trying to read from the drive when you unplugged it. I don't think there's something completely out of the line here. Of course, it probably could be implemented better, but that's the way it is now in Linux kernel (at least in 2.4), and only happens when you unplug the drive while something is accessing it - which is not a good thing to do anyway...
  95. ray123

    ray123 LI Guru Member

    For a real-life experiment, I recommend you format your most expensive flash drive as FAT32, mount it with sync option, and copy a large (1GB+) file to it from Windows
    Oddly enough, ever since I got my Philips DVD player with the USB port, that's EXACTLY what I do all the time. On Windows, though, not Linux. I download TV episodes via torrents, copy them to the USB drive, and watch them on the big TV. Each episode is generally 700KB to 1.2GB. Windows does SYNC (no write cache) on USB drives. But maybe Windows does it better than Linux.

    This experiment doesn't make sense to me. Writing a 1GB file to a 4GB flash drive won't cause any EBs on the drive to be erased---and the lifetime of a flash is determined by # erases of EBs.

    This leads to questions about SSD drives that they're putting in small netbook computers. These are flash chips---so how come they don't die in a few hour/dayss? Riddle me that. There's obviously more here than meets the eye.

    I did some google research, and it's all urban legends. Nobody seem to know for sure, just a bunch of people making suppositions. No authoritative answers. No experimental results, just anecdotes, conjecture, and handwaving. However, there is this:
    From: Colin Leroy
    Date: 17 May 2005

    > According to the man pages for mount, FAT and VFAT
    > file systems ignore the "sync" option. It lies. Maybe it use to be
    > true, but it certainly lies now.

    Yes, it does lie. I'm the author of the O_SYNC patch for fat and vfat,
    and I'd like to point out that I did test a few flash drives (and hard
    drives) extensively (during about a week) with this flag, and they did
    not die on me.
    As other people said, I think the O_SYNC handling does exactly what it
    says, and if it doesn't do what you want, tell HAL not to set it (There
    must be a way).


    **** time passes ****
    Hmm, I just did some tests on 2 different USB drives. One very old and one brand new. Test was writing a 784000 byte file to the drive (/bin/busybox was the file).
    Lots of interesting & disturbing info. Stats were retrieved from /proc/stat. SCSI subsystem reported 512-byte sectors.

    Ext2 really and truly sucks absent write-caching. Ext takes 12 times longer than fat. And has 3.5 times a many writes. What the heck is it doing??? If anything, SYNC on flash drives should kill ext2 sooner that it kills fat.

    With SYNC ( == no write caching);
    Write to ext2 partition.
    675 writes, 2504 blocks, 12.12 seconds(!!!)
    784000 / 675 = 1161 bytes per write. (Of course, some of the writes are to directory & inode)
    2504 / 675 = 3.8 blocks per write. 4 * 512 = 2kb per block.

    Write to vfat partition.
    192 writes, 1612 blocks, 0.98 seconds (MUCH faster than ext2)
    I can eyeball the speed by watching the flashing LED on the USB stick. Fat was a couple of quick blinks. Ext2 was flashing that wnen on and on and on.
    784000 / 192 = 4083 bytes per write.
    1612 / 192 = 8.4 blocks per write. 8 * 512 = 4kb per block.

    Without SYNC (that is, with async == write caching)
    to ext2
    11 writes, 1554 blocks
    784000 / 11 = 71272 bytes per write.
    1154 / 11 = 104.9 blocks per write. 105 * 512 = 52.5kb per block.

    to fat
    10 writes, 1537 blocks
    784000 / 10 = 78,400 bytes per write
    1537 / 10 = 153.7 blocks per write. 154 * 512 = 78.8 kb per block.

    But--nothing actually gets written to the USB drive until 30-35 seconds later.

    Around 1997 I did a lot of work on the bdflush code in Linux. So I know what a good job it does as things like coalescing adjacent blocks, etc. I hated to give that up in exchange for avoiding that 30-35 second delay in writing the data to the disk. In my job I did a lot of work on performance tuning in Linux, and the first thing I'd do here is tune the bdflush parameters. Problem is, the defaults may be okay for permanent hard drive, but not for pluggable USB drives. You don't have to worry about a user yanking out a hard drive, but you do have to worry about a user yanking out a USB drive. What people generally do is watch the LED on the USB stick, wait until it stops flickering, and then yank it out.
    Parameter 6 should be 100 instead of 3000. There's no reason to age a buffer for 30 seconds. Ever, even on a hard drive.
    Parameter 8 should be 0. We want all the dirty buffers to get written out.
    Parameter 5 should probably be 100 or even 50 instead of 500.
    With these parameters, a disk block will be written to disk within 2 seconds.

    What we really want is get the data written out to the disk with all deliberate speed, while still keeping all the advantages (merged writes, etc.) of the write-cache. Thinking about this some more, it seems that we mainly want "fsync on close" functionality on files that are written to a USB storage device. Did some research and discovered that the support is already there in the kernel, but nothing activates it. Stealing some existing code and making a simple mod activates it--for ext2/3 and fat. My naive patch activates this for all drives, even IDE/SATA drives. But since these routers only have USB drives, that's not an issue. Both the kernel patch and the bdflush tuning are needed, so that we also handle the case where a file gets continually written without being closed, plus the case where ext2 spits out one last write even after the fclose.

    Now, when you write a file, you can watch the LED on the USB stick and be assured that when the light stops flickering, all the data has made it to the stick.

    Test results:
    Without sync on the mount,
    ext2: 14 writes, 1548 blocks, 1.2 seconds
    fat: 10 writes, 1541 blocks, 0.9 seconds

    The patchset is based on my previous "rvt-v21-usb5.patchset.tgz". It should go in cleanly to any recent Tomato version, though.
    Download it at
    and the firmware binary at
  96. teddy_bear

    teddy_bear Network Guru Member

    I think I like the new solution ;). Maybe a little cleaner (more generic) way would be to provide a new mount option?
    EDIT: Hmm... Apparently "flush" mount option is already implemented in kernel 2.6.28 - but only for FAT...
  97. mememe2345

    mememe2345 Addicted to LI Member

    Thanks for TB and others' great work. As a newbie, the storage and print share have been working flawlessly with my XP desktop and Ubuntu (installed over vista home premium) laptop. It seems Vista works with storage share but had hard time to get printer work through the router (Asus WL520GU, HP laserjet P1006, severa usb flash drive 2-8Mb and few external HD). Tried to load firmware after connect printer, it did not work (loaded the firmware to \tmp\ and cat it to printer and heard some noise afterward). What should I do to solve this Vista problem. May have to replace with XP, but that will be a lot work to reinstall everything. Searched this and other forums, could not find the answer. Thanks again, your hard work made a lot of fun for me to the least.
  98. teddy_bear

    teddy_bear Network Guru Member

    Did you use the firmware from here: ?
    Unfortunately I can't help you with that printer as I don't have one of those. Maybe someone else can provide more info.
  99. ray123

    ray123 LI Guru Member

    I've given the startup sequencing some more thought, considering not only USB disks but also things like webcam services (plus things like folding@home, streaming music from the internet, torrents, etc.) Webcam software will almost certainly reside on a USB drive, because there's no room for it on the router flash or jffs. We've been kinda focusing on the USB sticks per se, and not given much thought to other things that don't care about details of USB drive configuration and automounting, but just need the dang thing to be mounted so that they can access files on it and start up some service(s) when the router boots up.

    The more I think about it, the more it seems that the place most of this stuff belongs in the after-mount script and not the init script. I'm also thinking the we're not passing enough information to the after-mount script. Product & scsi-host & type are not useful. What would be useful would be the disc label and/or mountpoint. Could you add those as environment parameters? I wish I'd thought of that sooner.

    Statement of the problem to be solved:
    1) We want to allow the user init script to set up config files (like /etc/fstab) before Tomato mount processing.
    2) Allow (but not require) the user init script to mount disks before Tomato mount processing.
    3) Not require the user init script to have any specific sleep time(s).
    4) Allow the user init script to know when/that all the mountable discs are mounted, without any special processing in the UIS.
    5) Allow swap-discs to be automatically set to swapon.
    6) Meet the USB-storage serialization & timing delays required by the kernel.

    In order to accomplish #4, we must start_usb very early, since it takes about 15-20 seconds for the disc mount timing & processing.

    To accomplish #1, we must hold off Tomato mount processing.

    To accomplish #6, the UIS must not attempt to mount disks too soon.

    I think we need to have 2 user scripts. One is for setting up config files, etc. and is guaranteed to run BEFORE any Tomato disk mounting.

    The other is guaranteed to run AFTER all connected/mountable disks have been mounted by Tomato, and guaranteed that all the Tomato services (wan/lan/usb/etc.) have been started. No guarantee that the service is actually up, only that it has been started.

    **** Proposed sequencing (in rc/init.c). ****

    								Elapsed time of function.
    start_usb();		    				--	 3.6
    run_nvscript("script_init", NULL, 1);			--	 0.4
    start_vlan();		    				--	 0.8
    start_lan();			     	     		--	 1.2	
    start_wan(BOOT);	    				--	 0.3
    start_services();	    				--	 8.3
    //	First USB hotplug host event			--	 8.x after start_usb
    //	First USB disk mount   	     			--	15.x after start_usb
    //	Last USB disc mount				--	18.x after start_usb
    syslog(LOG_INFO, "Tomato %s", tomato_version);
    run_nvscript("script_startup", NULL, 0);		--	New!
    To satisfy both #1 and #6, we cannot satisfy #3. So we must have a rule for script_init:
    * Jffs is already mounted (if enabled). No other disc is mounted.
    * You have 1 second to make any configuration changes to services like lan, vlan, wan, before Tomato starts those services.
    * You must not do mount commands sooner than about 5 seconds. The USB-storage subsystem has not stabilized until then.
    * You must be finished up with your explicit mount commands after about 10 seconds. After then Tomato will begin its automount processing.

    The rule for script_start is:
    * All connected & mountable USB disks either have been mounted or are being mounted.
    * You may have to wait up to 8 seconds before they are all mounted.

    With the above ordering, all the USB storage stabilization timing has been accomplished by the time the "script_startup" is run. And unless you have a lot of USB disks connected, the discs are probably mounted already. The usb_lock/usb_unlock do the hold-off without having to do something wierd like "mount_all_connected_hosts".

    And now, I'm off to playing with my new webcam and looking into the jffs code.
  100. teddy_bear

    teddy_bear Network Guru Member

    I thought about it before, but actually using existing env vars worked pretty good for me. Once you found out the product ID for the device, it's not going to change, and can be used in post-mount scripts. But I agree that mountpoints could be useful...

    The post-mount or pre-unmount script is called once per host controller. In both cases - mounting or unmounting - there could be several discs/partitions per host. We either need multiple envvars, or a single one with space/pipe/comma/whatever-separated list.

    Also, by the time pre-unmount script is executed the list of partitions to unmount is not known yet, and I don't really want to call exec_for_host twice (1st time to collect a list of mountpoints).

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice