Posted: Fri Mar 28, 2008 8:27 Post subject: Sme pesky little bugs in dd-wrt on my WRT350N
Hi there,
I recently flashed my WRT350N with the "DD-WRT v24 RC-7 (03/26/0 mega - build 9346M Eko" build of dd-wrt. I was previously using Sveasoft/Talisman but jumped ship because of problems with their firmware, at least on my router. I had the following issues with the above release on my WRT350N:
1) It permanently changed my LAN MAC address to 00:88:88:88:00:2A! No matter what I do I cant get the old address (on my sticker) back. I have tried many many hardresets, flashed numerous firmwares, tried "erase nvram;reboot" from the linux prompt but the new MAC adress remains. The only way I have gotten my original address back was to flash an original Linksys firmware *and* reload a saved config-file from that firmware. But a hard-reset and/or a new flash brings back the 888888 address. I didn't think this was possible, what is goind on here and what can I do about it?
2) I have no control with my wireless channels. No matter what channel I choose the result is that the router is stuck in channel 1. The only exception is if I set it to "Auto", the result then is always channel 6. Both channels are bad choices for me as they are both pretty crowded where I live. What can be done with regards to this?
3) It is not possible to set a "Wide" (40 MHz) channel like it is in the Linksys firmware. That means it's limited to 130Mbps instead of 270Mbps as with the "Wide" channel. Of corse real-life speeds are much lower. Will this be fixed in a future build?
4) The DDNS service is not working, period! At least not for me. I am living in Singapore at the moment and the government here feel they need to have some sort of "control" (over what I don't know), the result is that all ISPs here are using transparent proxy servers. I suspect that the problem with inadyn has to do with this. I get a error message similar to this:
Fri Mar 28 03:45:14 2008: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
Fri Mar 28 03:45:14 2008: INADYN:IP: Error 0x83 in recv()
Fri Mar 28 03:45:14 2008: W: DYNDNS: Error 'RC_IP_RECV_ERROR' (0x15) when talking to IP server
Fri Mar 28 03:45:14 2008: W:'RC_IP_RECV_ERROR' (0x15) updating the IPs. (it 0)
I get this error no matter what service I try and I've tried them all, including the custom. I have also checked out /tmp/ddns/inadyn.conf on the box and it looks correct. Running inadyn from the linux prompt gives the same error message.
Can something be done to fix this?
I really really really need a working ddns service and the one in my NAS does not work (picks up the address of the transparent proxy and not the one from my WAN adapter). Running a ddns client on one of my PCs is only an option when they are on! When I google "RC_IP_RECV_ERROR" I get very few hits, some from Singapore (which confirmed are behind transparent proxy servers) and some in a language that probably also could be behind a transparent proxy server. That's whay that is my first guess as the cause of the problem. Could someone please help me debug this? In the mean time I guess I'll write script that updates my ddns ip and run it by cron on the router.
5) Better QoS
Not really a bug and maybe just wishful thinking. But I would like some of the nice options that Sveasoft/Talisman has, more spesific:
* The ability to define groups of "services" that can be used in the different rules instead of specifying each service separately.
* The ability to use traffic counters as part of the rule. In Talisman you can set up a rule that gives http a low priority once it has downloaded X kb of data. The next rule will typically give http a high priority. The result is smooth surfing while http filetransfers are given a lower priority. The possibilities are nedless
* The option to reserve a certain bandwith for a spesific service/rule. That means the bandwith is reseved/allocated and other traffic will not be able to touch that bandwidth (will remain unused if no traffic match the rule regardless of the background traffic).
Any chance of geting an improved QoS in dd-wrt?
I also experienced something odd. I enabled the PPTP server and because I had read in some forum somewhere that it was necessary to get the PPTP server to work I also disabled "Loopback". As soon as I disabled "Loopback" then all my wireless clients started acting up and my VoIP (SIP) adapter were no longer able to make or receive calls (or even connect to the SIP server) through the router. And by "acting up" I mean that the wireless clients would loose packets and/or drop their WLAN connections. This bizarre behaviour was constant and would happen instantly every time i disabled "Loopback" and go away every time I enabled it again.
Can anyone explain this? A bug - or maybe there is a natural explanation for this?
I would still like comments/feedback/help/bugfixes on the above issues. :)
As a temporary solution to inadyn DDNS client in dd-wrt not working (at least not for me - see above) I wrote a script to take care of the dyndns updating.
I put the script on my dd-wrt using Administration ->A Commands -> Custom Script.
I then scheduled a cron job to run the script every 10 minutes. I put this line in Administration -> Management -> Additional Cron Jobs:
Apart from the problems I encountered in the above post I am very very impressed with dd-wrt. I did not realise until a couple of weeks ago how powerful these small routers can be once you get rid of the manufacturers firmware. This is my kind of fun.
I have also downloaded the sources for the inadyn DDNS client. When I do find the cause of the problem and fix it, where can I request that the fix is included in an upcoming build of dd-wrt?
Here is the script in case someone else need something similar:
Code:
#!/bin/sh
#
# Christer Johansen - March 28th 2008
# Simple and hopefully failsafe script to update your dyndns.org account
# Written for routers with dd-wrt firmware and only testet on dd-wrt
# Should be run by cron as often as you want to check for an ip address change
# Will only update your domain on dyndns.org when an ip address change is detected
# or when a number of days as specified by FORCEUPDATE has passed since the last update
#
# Edit the variables below to suit your setup
# USERNAME = Your username at dyndns.org
# PASSWORD = Your password at dyndns.org
# DYNHOST = Your domain at dyndns.org
# FORCEUPDATE = After this number of days an update will be forced even if your ip address has not changed
#
USERNAME=yourusername
PASSWORD=yourpassword
DYNHOST=yourdomain.dyndns.org
FORCEUPDATE=10
# By editing below this line you agree that you know what you're doing :)
#
# Some logfiles that is used by this script
IPFILE=/tmp/dyndns.ip
LOGFILE=/tmp/dyndns.log
LASTUPDATE=/tmp/dyndns.lastupdate
if [ "$DATE" -ge "$DATEEXPIRE" ]
then
# Time for a forced update
wget -q -O $LOGFILE \
http://$USERNAME:$PASSWORD@members.dyndns.org/nic/update?hostname=$DYNHOST&myip=$IP
date +%s > $LASTUPDATE
elif [ "$OLDIP" != "$IP" ]
then
# Our IP has changed, do the update
wget -q -O $LOGFILE \
http://$USERNAME:$PASSWORD@members.dyndns.org/nic/update?hostname=$DYNHOST&myip=$IP
date +%s > $LASTUPDATE
fi
Posted: Fri Apr 25, 2008 4:32 Post subject: DDNS Issue
The DDNS Issue is not new to v24rc7 and clearly it is not fixed in rc7. It starts from v23sp2 when idndyn is first used for resolving the WAN IP for DDNS reporting. The problem is due to the use of port 80 to checkip.dyndns.org for your WAN IP and it will report IP address of the transparent proxy of your ISP instead of your real WAN IP. In fact, checkip.dyndns.org provided another port (port 8245) and the IP address reported will be correct. I encountered exactly the problem you have got. The workaround is to use the Custom DNS. I can provide the exact script needed for the dynamic DDNS provided by dyndns.org after work.
Ok, great if you can do that. I wrote my own custom script as a workaround but getting ddns to work would be better.
I haven't had time yet to look at inadyn to see what happens but judging from your explanation this is a very very easy issue to fix. Maybe I'll just send a "diff" for the inadyn code to eko and BrainSlayer then maybe they'll include the fix.
Here is a way to change the MAC address of you router.http://www.scorpiontek.org/portal/content/view/82/32/
I personally Telnet in to do that but only on my friends WRT54G ver.6, but that should work fine.
I have never had to change the MAC address of my WRT350N must be something the other firmware did.
Oh yeah remember that MAC address are in Hexadecimal.
0,1,2,3,4,5,6,7,8,9,a,b,c,d,e,f.
So if you MAC address is like this xx.xx.xx.xx.xx.1F
Plus one would be 20, Yay Learning ^_^
And if you restore to factory defaults it takes the MAC address so you have to do it again.
If only the writer can add an option of port used for IP checking, next to the Force Update Interval, then we don't need to write the DDNS update script ourselves!
I followed your guys' instructions and nothing.
I am using v24.
All I get is:
Code:
Sat May 24 08:41:30 2008: INADYN: Started 'INADYN Advanced version 1.96-ADV' - dynamic DNS updater.
Sat May 24 08:41:30 2008: I:INADYN: IP address for alias 'dyndns.org' needs update to 'XXXXXXX'
Sat May 24 08:41:30 2008: W:INADYN: Error validating DYNDNS svr answer. Check usr,pass,hostname!
Sat May 24 08:47:35 2008: W:INADYN: Error validating DYNDNS svr answer. Check usr,pass,hostname!
Sat May 24 08:53:40 2008: W:INADYN: Error validating DYNDNS svr answer. Check usr,pass,hostname!
I currently have:
Code:
DDNS Service = CUSTOM
Server = members.dyndns.org
Username = my username
Password = my password*
Hostname = dyndns.org (since I have username.dyndns.org)
URL = /nic/update?
Additional = --dyndns_system dyndns@dyndns.org --ip_server_name checkip.dyndns.org:8245 /
*whenever I type in my password and hit save OR apply changes the password which is 7 characters long is transformed to 16 (hidden) characters. is this unrelated?
Surprisingly when I first installed v24 dyndns WORKED (w/o need for the custom part). Then for some reason the errors started popping up. Now I can't get either to work.
Hostname must be your domain as registered with dyndns, eg mydomain.dyndns.org or whatever your domain name is. The error message you're getting implies that either the hostname (which looks wrong to me), your username or your password is incorrect. Check all of them, other than that your settings looks fine.
Hostname must be your domain as registered with dyndns, eg mydomain.dyndns.org or whatever your domain name is. The error message you're getting implies that either the hostname (which looks wrong to me), your username or your password is incorrect. Check all of them, other than that your settings looks fine.
Perfect! You were right. Thanks so much. I don't know why I was doing it that way.
Adding my two pennies worth: the password (or in fact any of the fields) should not have spaces. I spent some 10 minutes trying to figure out what's wrong here