RouterTech AR7WRD beta - TNETW1350A wifi chipset (20070905)

Beta Software / Firmware releases made by our in-house development team. Please read all relevant disclaimers before using any beta firmwares - You have been warned! This is the only area where support for beta firmwares will be provided.
User avatar
Neo
RouterTech Team
RouterTech Team
Posts: 3583
Joined: Thu Jan 26, 2006 1:09 pm
Contact:

RouterTech AR7WRD beta - TNETW1350A wifi chipset (20070905)

Post by Neo » Sun Sep 02, 2007 3:27 pm

NOTE: The beta releases on this page have been superceded, and should now be considered obsolete. Please to go straight the release download page: viewtopic.php?t=1496

-----------------------------------------------------------------

Introduction

The following release is a only at the beta stage and as such cannot be considered stable. Also, and this is very important, it is easier to brick your router with this firmware so you must be prepared to do a repair and take the necessary precautions (like backing up anything important from the router). If you are at all uncertain about how to fix your router then we strongly advise to not touch this beta firmware at all.

After downloading the attached ZIP file, please read the readme file that is included and follow all instructions in that file to the letter. If you do not read the instructions then there is a good chance you will 'brick' your router. You will find further documentation in the v23.docs folder that is also included. The documentation in that folder is for the standard RouterTech v2.3 firmware, and most (but not all) of it is applicable to this beta release.

Please read EVERYTHING below - do not skip any of it!

-----------------

RouterTech Firmware TNETW1350A beta

Version: 3.7.1B_20070721_2.4.007 TNETW1350A beta (20070721)
Author: RouterTech Development Team (thechief, biro)

This firmware is only for the AR7WRD PSPBOOT-based range of routers that use the newer TNETW1350A wireless chipset. Do NOT attempt to install it on any router using the old TNETW1130 wireless chipset. Doing so WILL brick any incompatible router.

See THIS for more details on router types.

This beta release has been tested on the new "R" series Solwise SAR600EW (not the original series, which are incompatible), and on the newer range of SWART2-54125 ( (not the original series, which are also incompatible).

Disclaimer & Warning

This firmware is beta software. This means that it possibly has bugs, and flashing it onto your router may well "brick" your router quite badly (e.g., it may trash the bootloader environment, which you will then need to restore).

You must not flash this firmware onto your router unless you are very familiar with the PC-Tool and are competent in using it to un-brick a router.

Please take this warning very seriously. If you are not adept at recovering bricked routers, and if you are not familiar with the PC-Tool, then do not install this firmware!

And do NOT even consider installing this firmware unless you have first backed up your router's bootloader environment to your hard disk. If you fail to observe this, then you are entirely on your own - and if your environment gets corrupted, your router (or at least it's wireless functionality) will be irrecoverable.


Upgrading
The safest way to upgrade to this firmware is by using the PC Tool.

You must first reset the router to factory defaults before installing this beta firmware.

If you choose to upgrade via the router's web interface, then you MUST observe the following
[1] First reset the router to factory defaults before trying to install this beta firmware.
[2] When upgrading via the web interface, you must wait for at least 5 minutes for the new firmware to establish itself. Do not do anything to the router for at least 5 minutes from the moment the upgrade process starts, and do not interrupt the upgrade process.

NOTE:
BEFORE installing this firmware, you must, among other things (see the docs in the zip file for those other things) back up a copy of your router's current "/etc /led.conf" file. We only have a few LED configuration files, and the chances are that we do not have one suitable for your own router. If you do not keep a copy of the original contents of that file, then we have no way of knowing how your LEDs should be configured, and the LEDs will always be wrong. This will not affect the router's normal operation - but you the LEDs will not be reporting the correct operations.
The RUC can backup your LED config - if you use the RUC then you can double-check the output by looking in the check*.txt file for data after the "/etc /led.conf" line.


PC-Tool and repairing / unbricking

See viewtopic.php?t=961

Downloading
The links to our firmware require you to be registered and logged into the site to see and use them. This is to make sure we can provide you with support easily (in this forum) if you need it. When logged in they appear below this post.

Files
The previously files listed here are now obsolete. See RC1 here: viewtopic.php?t=1448

Please Note
To save this post becoming too wordy or long-winded a lot of introductory text has been omitted - you will find more back-information here: viewtopic.php?t=1250
You should read that first (if you haven't already) to gain a better understanding.
Last edited by Neo on Thu Oct 04, 2007 6:02 pm, edited 3 times in total.
RouterTech Team
Image
No support via PM, please ask your questions on the forum!
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Sun Sep 02, 2007 4:22 pm

One thing to note with this beta firmware. The router's LEDs may not be correct. If this happens, then it means that the default led.conf file is not the correct one for your router. You will need to go to the "led" folder in the zip file, and try the led batch files in it (in Windows, you should just run the batch file, and wait for the router to reboot itself, etc). If the LEDs are still not correct, then you will need to try another one. If you don't find one that works correctly, then you need to send us a copy of your router's original led.conf file, so that we can add it to the next beta.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Sun Sep 02, 2007 4:58 pm

Ok, let's start to collate some success (or otherwise) stories:

This firmware has been tested on the new "R" series Solwise SAR600EW (note: NOT the original SAR600EW series - those have the "wrong" wifi chip and are not compatible), and seems to work just fine. You have to use the "sar600" LED file to get the correct LEDs.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Post by mstombs » Sun Sep 02, 2007 11:10 pm

Well, you know what modem I have - it has PSPBoot and 4Mb flash at least (and serial console plus working JTAG so no worries about bricking!):-

The upgrade from a RT2.3 Web screen went fine.

USB worked, so I had a look around the web screens, reset to defaults etc.

All was working so I entered my ISP data, plugged in my phone line and

Code: Select all

Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing
 DSL in Sync
DSL out of sync
DSL in Sync
DSL out of sync
DSL in Sync
DSL out of sync
So I rebooted and reloaded the correct version of RT2.3 via the working USB connection (first time I've ever tried that... and it worked), just got a couple of new env variables to clear up and it'll be fine...
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Mon Sep 03, 2007 7:12 am

Your router is the wrong one, if I remember correctly, so I am surprised that anything worked at all.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
User avatar
Neo
RouterTech Team
RouterTech Team
Posts: 3583
Joined: Thu Jan 26, 2006 1:09 pm
Contact:

Post by Neo » Thu Sep 06, 2007 2:54 pm

Update: A beta version supporting Annex B is now available from the first post of this topic.

We would appreciate it if people who are suitably equipped (i.e. they have the right type of router and use Annex B), brave & prepared (i.e. have read ALL of the above warnings etc) could test the Annex B functionality :)
RouterTech Team
Image
No support via PM, please ask your questions on the forum!
chez
Novice
Novice
Posts: 28
Joined: Tue Jul 25, 2006 6:35 pm
Location: UK

Post by chez » Thu Sep 06, 2007 6:46 pm

Finally re-flashed the SWART2-54125 today- after dowloading the file on Sunday!
Now to set it up for my connection and try it.
Perhaps I should have checked that it worked "as received" before playing with it.
Also, I need to learn how to set up a wireless LAN under linux.
Now son, this is the safe way to... ohh?
chez
Novice
Novice
Posts: 28
Joined: Tue Jul 25, 2006 6:35 pm
Location: UK

Post by chez » Fri Sep 07, 2007 8:19 am

The unit can be very slow at navigating between screens, I get frustrated and stop it to then try going somewhere else.
Other times it is ok.

HeHe, next time I will overwrite the brackets aswell as the wild cards for my username when setting up the account details!

Anyway, it is working now.
Just need to add the port forwarding from the old unit.

Is there any useful data that I could post?
Now son, this is the safe way to... ohh?
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Fri Sep 07, 2007 9:15 am

Delays in navigating screens are usually due to timeouts - i.e., the firmware is trying to query something that doesn't quite exist (e.g., a piece of hardware component), and it waits until a timeout. Normally, the system log would reveal what is causing the timeout. So it would be nice to see a copy of the system log (after removing all sensitive data of course).

Did you install the firmware using the PCTool, or via the web interface?
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
chez
Novice
Novice
Posts: 28
Joined: Tue Jul 25, 2006 6:35 pm
Location: UK

Post by chez » Fri Sep 07, 2007 6:37 pm

The firmware was installed by 'pctool version 2.3'

Hmm: I have changed the admin's password on the web interface, which is working ok.
However, I cannot login on telnet....
To check for typing errors, I typed the username & password in notebook, and then copied-pasted into both web-interface & then telnet.

Should I be able to telnet with the unit connected to the ISP? (and being used.)
Now son, this is the safe way to... ohh?
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Fri Sep 07, 2007 7:07 pm

The telnet login name is "root". Hint - check the docs ;).
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
chez
Novice
Novice
Posts: 28
Joined: Tue Jul 25, 2006 6:35 pm
Location: UK

Post by chez » Sat Sep 08, 2007 3:34 pm

Thanks,

As requested, this the contents of the 'system-log':

Code: Select all

Jul 21 01:04:13 cfgmgr(sar):  Could not get oam_ping_interval from boot loader env 
Jul 21 01:04:13 cfgmgr(sar):  Trying to retreive the value from Configuration 
Jul 21 01:04:13 cfgmgr(sar): oamPingInterval(20)(20)
Jul 21 01:04:13 cfgmgr(ap): AP Acquiring Lock
Jul 21 01:04:13 cfgmgr(pppoa-109): Valid Configuration Tree
Jul 21 01:04:13 cfgmgr(resolver): stat successfull for /etc/resolv.conf.
Jul 21 01:04:13 cfgmgr(resolver): Resolver Polling Timer Started succesfully.
Jul 21 01:04:13 cfgmgr(sntp): NTP Polling Timer for DHCP Started succesfully.
Jul 21 01:04:13 cfgmgr(sar): DSL Polling Timer Started succesfully.
Jul 21 01:04:13 cfgmgr(fdb): Firewall NAT service started
Jul 21 01:04:13 cfgmgr(ap): AP REPORT LOCK ACQUIRED
Jul 21 01:04:13 cfgmgr(ap): wlan_handle_load_event - Acquired Lock
Jul 21 01:04:13 cfgmgr(ap): MAC address is : xx:xx:xx:xx:xx:xx
Jul 21 01:04:13 crond[155]: crond 2.3.2 dillon, started, log level 8 
Jul 21 01:04:14 cfgmgr(lanbridge0): Bridge Created: br0
Jul 21 01:04:16 cfgmgr(lanbridge1): Bridge Created: br1
Jul 21 01:04:18 cfgmgr(lanbridge2): Bridge Created: br2
Jul 21 01:04:19 cfgmgr(ap): WPA Authenticator Started
Jul 21 01:04:19 cfgmgr(lanbridge3): Bridge Created: br3
Jul 21 01:04:21 cfgmgr(lanbridge0): Bridge Interface Added: eth0
Jul 21 01:04:23 root: USB enabled
Jul 21 01:04:23 cfgmgr(sar): DSL Carrier is down
Jul 21 01:04:23 cfgmgr(pppoa-109): del_iptable_rules : ppp_name not intact 
Jul 21 01:04:24 cfgmgr(ap): EEPROM len 473
Jul 21 01:04:25 cfgmgr(ap): Set PIL mode (1)
Jul 21 01:04:25 cfgmgr(ap): AP Driver configuration successful
Jul 21 01:04:30 cfgmgr(ap): AP IS UP
Jul 21 01:04:30 cfgmgr(ap): AP Releasing Lock
Jul 21 01:04:31 cfgmgr(lanbridge0): Bridge Interface Added: wbif0
Jul 21 01:04:33 cfgmgr(sar): DSL Carrier is up
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.35)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.32)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.40)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.36)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.38)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_default oamPing(0.96)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(0.35)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(8.35)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(0.43)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(0.51)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(0.59)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(8.43)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(8.51)result(2)
Jul 21 01:04:33 cfgmgr(sar): auto_vcc_search oamPing(8.59)result(2)
Jul 21 01:04:34 cfgmgr(pppoa-109): ---}}} Start of connection delayed for 7 sec
Jul 21 01:04:34 cfgmgr(pppoa-109): PPPoA launch delay.
Jul 21 01:04:41 cfgmgr(pppoa-109): PPPoA Launch after conn delay timeout ...
Jul 21 01:04:41 pppd[350]: pppd 2.4.1 started by root, uid 0
Jul 21 01:04:41 pppd[350]: Connect: ppp0 {--} 
Jul 21 01:04:41 pppd[350]: MRU: 1500
Jul 21 01:04:41 pppd[350]: Couldn't increase MTU to 32725
Jul 21 01:04:41 pppd[350]: MRU: 1500
Jul 21 01:04:44 pppd[350]: Connection terminated.
Jul 21 01:04:46 pppd[365]: pppd 2.4.1 started by root, uid 0
Jul 21 01:04:46 pppd[365]: Connect: ppp0 {--} 
Jul 21 01:04:46 pppd[365]: MRU: 1500
Jul 21 01:04:49 pppd[365]: MRU: 1500
Jul 21 01:04:49 pppd[365]: Couldn't increase MTU to 32725
Jul 21 01:04:49 pppd[365]: local  IP address xx.xxx.xxx.xxx
Jul 21 01:04:49 cfgmgr(pppoa-109): PPPoA Connect with IP Address xx.xxx.xxx.xxx 
Jul 21 01:04:49 cfgmgr(pppoa-109): PPPoA Connection Successfully Established 
Jul 21 01:04:49 cfgmgr(pppoa-109): PPPoA Connect with Gateway IP Address: xxx.xxx.xxx.xxx 
Jul 21 01:04:49 pppd[365]: remote IP address xxx.xxx.xxx.xxx
Jul 21 01:04:50 pppd[365]: primary   DNS address xxx.xxx.xxx.xxx
Jul 21 01:04:50 pppd[365]: secondary DNS address xxx.xxx.xxx.xxx
Jul 21 01:04:50 syslog: dproxy force reload config.
Jul 21 01:04:50 cfgmgr(pppoa-109): PPPD Successfully Started 
Sep  7 07:49:01 crond[155]: time disparity of 69524 minutes detected 
Sep  7 17:37:16 login[416]: invalid password for `UNKNOWN' on `pts/11' 
Sep  7 17:38:15 login[418]: invalid password for `UNKNOWN' on `pts/11' 
How are the other folk getting on with this release?
Now son, this is the safe way to... ohh?
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12066
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Sat Sep 08, 2007 4:25 pm

Thanks. The log doesn't show any timeouts. Can you please go through all the screens that are slow, one by one. This will log the timeouts. and then please post the log. Thanks.

Only one other report has been received so far, and that was for the second beta, for a PTI-8505. at his first attempt, the environment was trashed, but he recovered it and succeeded in installing the firmware. His Realtek switch is not supported, but everything else works well.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
chez
Novice
Novice
Posts: 28
Joined: Tue Jul 25, 2006 6:35 pm
Location: UK

Post by chez » Mon Sep 10, 2007 8:17 pm

Ooops.
I think the hang-ups were attributable to win 98.
The unit works well with the other machines in the house running varieties of Linux & win xp.
Now son, this is the safe way to... ohh?
User avatar
studioeng
Experienced
Experienced
Posts: 454
Joined: Mon Oct 23, 2006 11:59 pm
Location: Dorset, England
Contact:

Post by studioeng » Tue Sep 11, 2007 4:08 pm

Hi guys, maybe a stupid question but is there any beta tests being performed on the Netgear DG834Gv3 router?
Locked