they do not support large files.Quote:
Originally Posted by petgun
Probably, but I need to check on this first.Quote:
will you change the rsize/wsize limitation of the current kernel/daemon in an upcoming Version of your brilliant Firmware?
Printable View
they do not support large files.Quote:
Originally Posted by petgun
Probably, but I need to check on this first.Quote:
will you change the rsize/wsize limitation of the current kernel/daemon in an upcoming Version of your brilliant Firmware?
..Samba? It was ok with the JOCKYW2001 and original WL-HDD Firmware.Quote:
Originally Posted by Oleg
thank you! I'm sure there will be a little performance boost in r/w speedQuote:
Probably, but I need to check on this first.
cu,
peter
yes, set it to 32768, it normally won't cause any probQuote:
Originally Posted by Oleg
concerning the samba >2GB prob, what samba version did you build?
Quote:
Originally Posted by petgun
You can try to format the drive as another filesystem. I guess you've formatted it as fat32. Because this is a limitation of fat32, depends on how the system uses integers the limit per file can be 2Gb (if the system uses signed integers) or 4Gb (if the system uses unsigned integers). NTFS or linux file system should solve this problem.Quote:
Originally Posted by Oleg
no, it's ext3 formatted!Quote:
Originally Posted by kfaessen
cu,
peter
Then I don't have a solution for your problem sorryQuote:
Originally Posted by petgun
Just nagging a bit:
If you change the NFS setting both radio buttons are selected, see my attachment.
Also Oleg, can you add some info in the webpage in upcoming firmwares on what should be filled in the Export line?
wow, just updated to this firmware.
works nicely here. Thanks Oleg for this masterpiece!
One little thing though, syslog is filled with this:
somehow it keeps on going with the usblpid of my printer. Any way how to stop this (without pulling the plug on the printer :D ) ?Code:Mar 17 19:24:29 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:10;'
Mar 17 19:24:29 kernel: printer.c: Parsing USBLPID...
Mar 17 19:25:12 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:20;'
Mar 17 19:25:12 kernel: printer.c: Parsing USBLPID...
Mar 17 19:25:15 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:20;'
Mar 17 19:25:15 kernel: printer.c: Parsing USBLPID...
Mar 17 19:25:15 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:20;'
Mar 17 19:25:15 kernel: printer.c: Parsing USBLPID...
Mar 17 19:25:18 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:10;'
Mar 17 19:25:18 kernel: printer.c: Parsing USBLPID...
Mar 17 19:34:32 kernel: printer.c: usblp0 Device ID string [102/max 1552]='MFG:Canon;CMD:BJL,BJRaster3,BSCCe;SOJ:TXT01;MDL:iP2000;CLS:PRINTER;DES:Canon iP2000;VER:1.04;STA:20;'
Mar 17 19:34:32 kernel: printer.c: Parsing USBLPID...
Hmmz, it seemed to come to a halt with all this now..., no more entries so far. wierd.
Hi,
I followed your NFS guide and found that I got closer, but still not close enough. Running the following command
John-Yourens-Computer:~ johnyouren$ mount -tnfs -orsize=32768,wsize=32768 192.168.1.1:/tmp/harddisk nfs
mount_nfs: /Users/johnyouren/nfs: Operation not permitted
gives me the error shown, I have search the internet and it looks like it is related to this (http://lists.apple.com/archives/mkli.../msg00020.html) problem.
If you could look into this I would be very grateful!
;-) I think that is not very easy...what do you think about:Quote:
Originally Posted by Styno
Quote:
The /etc/exports file
The /etc/exports file is the NFS server configuration file for Linux systems. It controls which files and directories are exported, which hosts can access them, and what kinds of access are allowed. A sample /etc/exports file might contain these entries:
/usr/man crab(rw) horseshoe(rw) (ro)
/usr/local (ro)
/home/research rodent(rw) crab(rw) horseshoe(rw) jerboas(rw)
This sample file says that:
/usr/man can be mounted by any client, but it can be written to only by crab and horseshoe. Other clients have read-only access.
/usr/local can be mounted by any client, with read-only access.
/home/research can be mounted only by the hosts rodent, crab, horseshoe, and jerboas. These four hosts have read/write access.
The options used in each of the entries in the /etc/exports file determine what kinds of access are allowed. The information derived from the sample file is based on the options specified on each line in the file. The general format of the entries is as follows:
directory [host(option)]...
directory names the directory or file that is available for export. The host is the name of the client granted access to the exported directory, while the option specifies the type of access being granted.
In the sample /etc/exports file shown above, the host value is either the name of a single client or it is blank. When a single hostname is used, access is granted to the individual client. If no host value is specified, the directory is exported to everyone. Like Solaris, Linux also accepts values for domains, networks, and netgroups, although the syntax is slightly different. Valid host values are:
Individual hostnames such as crab or crab.wrotethebook.com.
Domain wildcards such as *wrotethebook.com for every host in the wrotethebook.com domain.
IP address/address mask pairs such as 172.16.12.0/255.255.255.0 for every host with an address that begins with 172.16.12.
Net groups such as @group1.
Notice that in Linux, domain names begin with an asterisk (*), instead of the dot used in Solaris. Also note that the at-sign begins a netgroup name, whereas in Solaris the at-sign is used at the beginning of a network address.
The options used in the sample /etc/exports file are:
ro
Read-only prevents NFS clients from writing to this directory. Attempts by clients to write to a read-only directory fail with the message "Read-only filesystem" or "Permission denied." If ro is specified without a client hostname, all clients are granted read-only access.
rw
Read/write permits clients to read and write to this directory. When specified without hostname, all clients are granted read/write access. If a hostname is specified, only the named host is given read/write permission.
Although specific hosts are granted read/write access to some of these directories, the access granted to individual users of those systems is controlled by standard Unix user, group, and world file permissions based on the user's user ID (UID) and group ID (GID). NFS trusts that a remote host has authenticated its users and assigned them valid UIDs and GIDs. Exporting files grants the client system's users the same access to the files they would have if they directly logged into the server. This assumes, of course, that both the client and the server have assigned exactly the same UIDs and GIDs to the same users, which is not always the case. If both the client and the server assign the same UID to a given user, for example, if Craig is assigned 501 on both systems, then both systems properly identify Craig and grant him appropriate access to his files. On the other hand, if the client assigns Craig a UID of 501 and the server has assigned that UID to Michael, the server will grant Craig access to Michael's files as if Craig owned those files. NFS provides several tools to deal with the problems that arise because of mismatched UIDs and GIDs.
One obvious problem is dealing with the root account. It is very unlikely that you want people with root access to your clients to also have root access to your server. By default, NFS prevents this with the root_squash setting, which maps requests that contain the root UID and GID to the nobody UID and GID. Thus if someone is logged into a client as root, they are only granted world permissions on the server. You can undo this with the no_root_squash setting, but no_root_squash opens a potential security hole.
Map other UIDs and GIDs to nobody with the squash_uids, squash_gids, and all_squash options. all_squash maps every user of a client system to the user nobody. squash_uids and squash_gids map specific UIDs and GIDs. For example:
/pub (ro,all_squash)
/usr/local/pub (squash_uids=0-50,squash_gids=0-50)
The first entry exports the /pub directory with read-only access to every client. It limits every user of those clients to the world permissions granted to nobody, meaning that the only files the users can read are those that have world read permission.
The second entry exports /usr/local/pub to every client with default read/write permission. The squash_uid and squash_gid options in the example show that a range of UIDs and GIDs can be specified in some options.[3] A single UID or GID can be defined with these options, but it is frequently useful to affect a range of values with a single command. In the example we prevent users from accessing the directory with a UID or GID that is 50 or less. These low numbers are usually assigned to non-user accounts. For example, on our Linux system, UID 10 is assigned to uucp. Attempting to write a file as uucp would cause the file to be written with the owner mapped to nobody. Thus the user uucp would be able to write to the /usr/local/pub directory only if that directory had world write permission.
It is also possible to map every user from a client to a specific user ID or group ID. The anonuid and anongid options provide this capability. These options are most useful when the client has only one user and does not assign that user a UID or GID, for example, in the case of a Microsoft Windows PC running NFS. PCs generally have only one user and they don't use UIDs or GIDs. To map the user of a PC to a valid user ID and group ID, enter a line like this in the /etc/exports file:
/home/alana giant(all_squash,anonuid=1001,anongid=1001)
In this example, the hostname of Alana's PC is giant. The entry grants that client read/write access to the directory /home/alana. The all_squash option maps every request from that client to a specific UID, but this time, instead of nobody, it maps to the UID and the GID defined by the anonuid and anongid options. Of course, for this to work correctly, 1001:1001 should be the UID and GID pair assigned to alana in the /etc/passwd file.
A single mapping is sufficient for a PC, but it might not handle all of the mapping needed for a Unix client. Unix clients assign their users UIDs and GIDs. Problems occur if those differ from the UIDs and GIDs assigned to those same users on the NFS server. Use the map_static option to point to a file that maps the UIDs and GIDs for a specific client. For example:
/export/oscon oscon(map_static=/etc/nfs/oscon.map)
This entry says that the /export/oscon directory is exported to the client oscon with read/write permission. The map_static option points to a file on the server named /etc/nfs/oscon.map that maps the UIDs and GIDs used on oscon to those used on the server. The oscon.map file might contain the following entries:
# UID/GID mapping for client oscon
# remote local comment
uid 0-50 - #squash these
gid 0-50 - #squash these
uid 100-200 1000 #map 100-200 to 1000-1100
gid 100-200 1000 #map 100-200 to 1000-1100
uid 501 2001 #map individual user
gid 501 2001 #map individual user
The first two lines map the UIDs and GIDs from 0 to 50 to the user nobody. The next two lines map all of the client UIDs and GIDs in the range of 100 to 200 to corresponding numbers in the range of 1000 to 1100 on the server. In other words, 105 on the client maps to 1005 on the server. This is the most common type of entry. On most systems, existing UIDs and GIDs have been assigned sequentially. Often, several systems have assigned the UIDs and GIDs sequentially from 101 to different users in a completely uncoordinated manner. This entry maps the users on oscon to UIDs and GIDs starting at 1000. Another file might map the 100 to 200 entries of another client to UIDs and GIDs starting at 2000. A third file might map yet another client to 3000. This type of entry allows the server to coordinate UIDs and GIDs where no coordination exists. The last two lines map an individual user's UID and GID. This is less commonly required, but it is possible.
Well, this is your MAC problem. As I do not have MAC I could not help you. You may probably need to read some MAC NFS related info. Do you've /Users/johnyouren/nfs dir? It't probably makes sense, that mount should be performed by power user (i.e. root, Administrator or whatever you have in MAC OS).Quote:
Originally Posted by mr0mega
Looks like a bug. :)Quote:
Originally Posted by Styno
See above post with sample. For further info visit http://nfs.sf.net, use google, etc for "man exports". I will include minimal info on my page, as I do not want to write yet another NFS How-To.Quote:
Also Oleg, can you add some info in the webpage in upcoming firmwares on what should be filled in the Export line?
Well, mentioning that link would help a lot of people I guess and won't cost you too much time. :DQuote:
Originally Posted by Oleg
Hi I followed your instructions but I get the following error when trying to do
ipkg.sh update
Downloading http://wl500g.dyndns.org/ipkg/Packages ...
wget: //opt/tmp/ipkg/Packages: No such file or directory
ipkg_download: ERROR: Failed to retrieve http://wl500g.dyndns.org/ipkg/Packages, returning
ipkg_update: Error downloading http://wl500g.dyndns.org/ipkg/Packages to /opt/lib/ipkg/lists/wl500g
Any Ideas?
has anyone tested the mt-daapd package? any chance that it would work
http://www.nslu2-linux.org/wiki/Unslung/Mt-daapd
and thx for the great work.
Quote:
Originally Posted by Oleg
Add "mkdir -p /opt/tmp/ipkg" to the instructions.Quote:
Originally Posted by mullog
No reason I can think of why mt-daapd won't work ...
-- Rod
Oleg
fw 1.9.2.7 CR4 [Oleg]
!!!reboot issue!!!
Hi,
just installed this firmware to try and get a webcam to work and try as I might whenever I change the webcam driver from pwc 8.8 to OV511 2.10 and do a save and restart its back to pwc 8.8
the webcam is a trust 150 spacecam portable which I believe needs the OV driver?
I have been unable to do this with any firmware I have tried up to now
If the cam revert to a PWC driver, it mean it is not properly reconised. You will need to try another webcam, or to get working drivers for it. I think somebody posted drivers for other webcam, but you will have to search for them. Not sure they will work.
Quote:
Originally Posted by hugo
thanks for that, its my first time trying custom firmware so support is most welcome, tried 3 webcams now and i can see in the status log that they are not recognised, don't know if i can afford to buy to many more :)
To share my experiences with you:
On my set of two WL-500g's WDS does work with WPS-PSK and AES (on Channel 11).
Both are in AP mode and one of them is connected to a router.
Have to say that bigpond "heartbeat" is 100% stable.
Now if only asus could import olegs fixes into their firmware.
thanks oleg
P.S. In upcoming firmware.....i'd like to see the following things.....i'm sure this isn't the right place to post it....but here it is anyway! Do you think any of these things is likely/possible???
1.. OoB packets support (Currently the WL500g ignores them)
2.. QoS support...im about to get VOIP (so this would be helpful)
3.. UPnP ports never closed bug fixed....annoying and a security hole
Hi
You only need to check the Asus Handbook for supported cams. If none fits your needs go into shops near you and see which ones they sell, tehn look up google for the used chipset (ovv5xx or philips). Cheap is the Terracam Pro if you get one, and good are the bigger Logitech ones... or ask ebay ;).Quote:
Originally Posted by hobbes
Greets
Look also for the dedicated tread compatibility in the forum.Quote:
Originally Posted by WlanMan
Quote:
Originally Posted by WlanMan
I read the handbook I think that was why I picked the trust :/ maybe i wasn't wearing my glasses that day :)
I based my latest purchase on that thread :)Quote:
Originally Posted by hugo
[about the gift unslung package]
giftd doesnt give the 'compiled against libc' (or something like that) error anymore, however it doesn't work either. It complains about me not having run gift-setup, which is correct since gift-setup uses perl..Quote:
Originally Posted by Oleg
I have the feeling changing the gift-setup with one that doesn't use perl, or including perl as a package would do the trick.
//edit
It appears perl is not needed, and that the current gift package does contain the correct binary. All that is needed to do to get it to work after using ipkg to install it, is editing the config templates, and copying them to the proper locations.
[Edit: good to hear that gift is now working :-) Kudos to hezik.]
Just to be very clear about these Unslung packages: They were written for, and have been verified on, the Linksys NSLU2 device only. That device is an XScale (armeb) processor (as opposed to the WL500g which is mipsel), and uses Glibc (as opposed to the WL500g which uses uClibc).
"Including Perl as a package" might sound like a simple thing to do, but it took at least three months of significant effort by at least three people in parallel to get Perl compiled and working on the Linksys NSLU2 (we first had to get a native compilation environment working, and then compile all the things you need to compile perl, and then compile perl itself). It would probably take roughly the same amount of time to port it to the WL500g (if it is even possible).
So don't be surprised when a package doesn't work. And don't be surprised if reports of packages (that have not been released into the ipk feed) not working fall upon deaf ears and are not answered :-)
Also, the chance of someone else fixing a package for you is quite small. The wl500g developers will be working on those packages that they individually need, and there is no-one who's job it is to port other packages to the wl500g. We certainly don't want to distract Oleg from producing his fine firmware, so please don't expect him to do it :-)
With that all said, both Oleg and myself welcome patches to the Unslung packages to get them working for the wl500g.
-- Rod
Thanks, but you're thanking the messenger, not the one who created the message :P.. I didn't do anything besides installing it :P So thanks to the unknown fool who repaired it :)Quote:
Originally Posted by rwhitby
I didn't mean to ... eh.. 'step on' the effort needed to do such a thing (can't find the proper english term for it). I apologize if i did so.Quote:
"Including Perl as a package" might sound like a simple thing to do, but it took at least three months of significant effort by at least three people in parallel to get Perl compiled and working on the Linksys NSLU2 (we first had to get a native compilation environment working, and then compile all the things you need to compile perl, and then compile perl itself). It would probably take roughly the same amount of time to port it to the WL500g (if it is even possible).
Just don't tell Oleg they even exist, and chain him to his firmware development machine :PQuote:
We certainly don't want to distract Oleg from producing his fine firmware, so please don't expect him to do it :-)
Ok, I'm willing to fix the gift package so that it works immediatly after installing it. Before i do that, a question about 'unslung'. Is 'unslung' a fork of a package depot for that linksys device, with the sole purpose to be used for the asus, or is it the linksys depot itself?Quote:
With that all said, both Oleg and myself welcome patches to the Unslung packages to get them working for the wl500g.
No need to apologise - you did not offend anyone. :-)Quote:
Originally Posted by hezik
Too late - Oleg was instrumental in getting the wl500g packages started :-)Quote:
Just don't tell Oleg they even exist, and chain him to his firmware development machine :P
The Unslung CVS is meant to be a common source code repository for Unslung packages that started with the NSLU2 and now are designed to be able to support the WL500g too.Quote:
Ok, I'm willing to fix the gift package so that it works immediatly after installing it. Before i do that, a question about 'unslung'. Is 'unslung' a fork of a package depot for that linksys device, with the sole purpose to be used for the asus, or is it the linksys depot itself?
wl500g.dyndns.org/ipkg is Oleg's offical ipk binary repository for non-Unslung packages. wl500g.dyndns.org/unslung is Oleg's ipk binary repository for Unslung packages. ipkg.nslu2-linux.org/feeds/unslung is the nslu2-linux project's ipk binary repository for Unslung packages.
So the source code is meant to be common, but the binary download locations are separate.
-- Rod
Well, great! Could you please write a wiki on how to properly configure it?Quote:
Originally Posted by hezik
*cough* I'm a little embarrassed, but so far it seems as though this firmware has worked perfectly without that darn MN-710. I still don't know why it had such a bad reaction to 1.9.2.7-based firmwares whereas the WL-138g has shown indifference.
Thanks, Oleg!
There is a problem with "Idle Disconnect Time" in this firmware, which wasn't in the previous firmware.
When I set the "Idle Disconnect Time" to "0" it told me that it wasn't valid or something like that (did it a few day ago and cant remember) and it wouldn't connect to the internet, but when I set it to 32 000 it started working.
Did anyone else got this error?
Hello,
I tried Firmware v1.9.2.7 CR4, works well except for one thing. Browsing became much slower.
I tried going back to wg01090207_WL500g_EN.trx and the problem disappeared.
Anything i could do about it? I would like to keep the costum firmware installed but not at the price of slow surfing.
mike777, I don't believe I've noticed anything like that...
Try manually setting the first DNS server (in the web administration) to one of your ISP's.
How?
1. Navigate to Status & Log -> Status
2. Take note (/copy) of one of the listed DNS Servers
3. Navigate to IP Config -> DHCP Server
4. Set DNS Server 1 to the DNS server you took note of (/paste)
5. Finish
6. Save & Restart
See if that speeds it up for you.
I have updated the Unslung CVS repository Makefile so that it is a one-line change to the top-level Makefile (set TARGET=wl500g) to have the packages build for the wl500g instead of the nslu2. There is also a WL500G_PACKAGES variable which lists some packages that have been verified to build (but may not have been tested on the device). The intention is that Oleg will use this variable to identify the packages which get automatically built and uploaded to http://wl500g.dyndns.org/unslung.Quote:
Originally Posted by rwhitby
Note that the Unslung build system is based upon the openwrt build system, so it should be very easy to also port any openwrt packages to the wl500g.
I have also added an "asusoe" distribution to the OpenEmbedded repository, and made that distro use the Asus toolchain directly. OpenEmbedded (which is the build system for OpenZaurus, and OpenSlug, among others) has over 1000 packages available - who knows how many might build and work on the wl500g?
These are two starting points for package developers for the wl500g ...
-- Rod
Rod, thank you for your effort. :)
Jean-Fabrice, you could now try using unslung build system to build wl500g packages. You do not need to wait for Makefile from me anymore. :)
Nothing is changed if you mean 1.9.2.7-3c. Most likely this due to your settings.Quote:
Originally Posted by dejay
Try again and if it does not work, then please post an output (using telnet session or hidden admin page) for these commands (remove your password as well):Quote:
When I set the "Idle Disconnect Time" to "0" it told me that it wasn't valid or something like that (did it a few day ago and cant remember) and it wouldn't connect to the internet, but when I set it to 32 000 it started working.
Did anyone else got this error?
Code:cat /tmp/ppp/options.wan0
nvram get wan_pppoe_idletime
nvram get wan0_pppoe_idletime
This is really hard to help you, as I've no idea of your settings (such as connection type, dns servers, etc.) as well, as I've no idea what does "Browsing became much slower" means for you.Quote:
Originally Posted by mike777
I miss this thread... sorry for being late.Quote:
Originally Posted by Oleg
Will give a look at unslung build system. As soon as I find how to use it (will search...)
Does asusoe use the last uClibc toolchain you patched ?