ADSL2MUE

All about firmwares for routers. Support for RouterTech firmwares is here too.
Post Reply
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

ADSL2MUE

Post by Chronos » Fri Oct 09, 2009 1:24 pm

Hi all! First post here, so please go easy on me :shock:

The current situation is this: Linksys ADSL2MUE (AR7D PSPBoot FW 4.12UK) in half-bridge mode, NAT disabled (set up using the CLI and some little tricks using the busybox shell) serving a /29 with three hosts (other than the router itself on network address+1) hanging off of a switch. Here's the thing: half bridge mode on these is rather insecure, but I need this configuration for a number of reasons, not least being DHCP, NAT, filtering and access control from RFC1918 clients is done on one of the servers, not the router.

I have used iptables to secure the thing from outside interference using interface defines (the br0 and ppp0 interfaces have the same IP, which precludes IP based filtering - I need access to ssh from the local /29) and confirmed the desired effect from my shell account. This all works perfectly with no particular issues to report. The problem is that this doesn't get saved with the rest of the configuration meaning I have to faff about in the shell recreating the firewall and killing thttpd on every reboot, luckily not often as the thing hangs off a UPS. So here's my plea for help from you clued-up people: How would one, theoretically, go about modifying the firmware image to change certain files, for example /etc/init.d? What I would really like to do is add my iptables rules, echo 1 > /proc/net/firewall_start (which resets dropbear and kicks me out each and every time I use it :( ) and remove the thttpd (never used at all, I do all my configuration from the CLI and busybox) line from /etc./init.d/rcS. There are some other changes I'd like to make to certain things, but this is the main one. Any ideas using either the stock firmware or Routertech if that would be easier? I'm currently stuck on ADSL Max for the foreseeable, so the ADSL2+ problem with these things isn't yet an issue. I envisage checksum calculations and much messing with hex editors in my future... :D

Many thanks in advance.
Chronos
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: ADSL2MUE

Post by mstombs » Fri Oct 09, 2009 2:08 pm

Well I am amazed you have managed all that with Linksys 4.12, I couldn't maintain a DSL connection with the old V3 or V4 drivers it contains. RouterTech firmware on the ADSL2MUE allows a choice of V6.2, V7.3 and V7.5 drivers.

If you have a a small static range of internet IPs, with one given to the router then that "no-nat" mode is fully supported through the RouterTech web gui I believe, but small boot commands can be saved in the environment, or a startup script held on /CIFS or on a wriable flash partition on the device itself.

The half bridge code in RouterTech firmware, implemented as a script on top of the Linux OS and CLI, allows the use of a single dynamic WAN IP on an upstream router. My preferred option is to run without any firewall with no nat and no IP on ppp0 on the modem. I would welcome comments about security - as the device is only routing I don't think there is an issue.

Note there is no easy way back to 4.12, that was never released as an official firmware, 4.22 is available as a single image, and is the recommended firmware to load RouterTech from - the upgrade from 4.12 to 4.22 requires a conversion of mtd config to single image format.

If you really don't want a GUI you should try OpenWRT with writable flash filesystem - the latest 2.6 Linux kernel nearly works well...
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Fri Oct 09, 2009 4:16 pm

Thanks for the reply, mstombs. However, the half-bridge mode you describe sounds like the IP the router would have obtained (137) is passed to a single host on the LAN side via DHCP, which sort of defeats the point of my setup. I could have the same effect using full bridge and the MPD ppp daemon in PPPoE mode, although I'd also end up with a maximum MTU of 1492 instead of 1500, which would complicate the gateway and client setup. The LAN side is very heterogeneous, with a mixture of Win and *NIX clients, and PMTUD isn't all it could be for some hosts.

As it stands, the ADSL2MUE gets the gateway IP (137) of my x.x.x.136/29 and routes the rest of that allocation to the other hosts (three of them) with sequential IPs in that range. This is essential on this network as the servers are for different purposes and have their own filtering rules and services running. For example, host 139 is a tinderbox which builds packages for the BSD clients on the LAN. Host 138 is the main gateway from the RFC1918 LAN. The main gateway server blocks Google IP ranges (privacy reasons - clients get scroogle-ssl for searches) and a few other nasties, returning an ICMP admin-prohib to RFC1918 hosts trying to connect outbound and blackholing incoming connections from the WAN. 139, on the other hand, needs to be able to download from googlecode as many distfiles are now there and nowhere else, so it has a different firewall ruleset. 138, by the way, also has the IPv6 gif tunnel and acts as a RTADV server for the local net on its other interface.

This setup is, however, the cause of the initial insecurity. Since the ppp and br interfaces on the router have the same IP and no filtering on source, without the iptables rules, all services on the router itself are exposed to the WAN, confirmed from my shell account. With the iptables rules in place, it is as secure as it would be if it were simply routing, assuming no holes in this kernel's version of iptables, but a reboot, which could happen at any time without me realising, opens it all up again to abuse from the big, bad Internet.

As you say, with the IP passed to an upstream router there are no issues. Only when the router itself has a publicly routable IP do security issues come to light and the need for packet filtering rules on the router itself become required.

OpenWRT certainly looks interesting, especially since it seems to support IPv6 natively. Thanks again for the ideas. I have quite a bit to go on now.

Oh, and funny you should mention unstable DSL connections on 4.12. A friend of mine has one with 4.12 which refuses to stay connected for more than a couple of hours. We changed his PSU to a 5V 2A model, but still the problem persists. It is also on an APC UPS, so mains noise and spikes can be ruled out. I was on the verge of replacing the 3V3 VREG. I have a copy of the 4.22 firmware here, so we'll probably end up upgrading it to that or Routertech. Mine? It has an uptime of several months. You can imagine the gloating that took place :D
Chronos
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: ADSL2MUE

Post by mstombs » Fri Oct 09, 2009 5:33 pm

If you can set fixed Internet IPs on your LAN machines I believe there is a variant of the RouterTech half-bridge script that just routes without the modem itself having an internet IP. If your ISP gateway IP is fixed then the modem can become almost transparent, using "proxy arp" to respond to packets addressed to the Gateway IP on the LAN interface.

My initial problems with ADSL2MUE were mainly due to external wiring issues, after eventually breaking completely and repair my line is now much more tolerant of modem and DSL drivers and PSUs but I have to run with high SNR margin and interleaved. I do not believe it is the so-called AR7 bug (allegedly fixed in dsp 7.3 + drivers), I also have a Broadcom based Speedtouch which did not fair much better. So later drivers may help your friends problem, but may just hide the underlying issues.

As your line is so stable with current modem - definitely worth having a second modem to experiment with!
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Fri Oct 09, 2009 7:04 pm

mstombs wrote:If you can set fixed Internet IPs on your LAN machines I believe there is a variant of the RouterTech half-bridge script that just routes without the modem itself having an internet IP. If your ISP gateway IP is fixed then the modem can become almost transparent, using "proxy arp" to respond to packets addressed to the Gateway IP on the LAN interface.
I took a chance. Haha! So much better! I've just set up Routertech 2.91.1 on this thing, set it up in that same way as I did on the Linksys firmware (I did update to 4.22 first, don't worry, I knew there was an FS layout change) and set up access control. Guess what? It does exactly what I wanted to do manually. All set up and working fine (barring the LEDs, EDIT: I'm an idiot. Just give it time and the power LED goes green. Me of little faith, apologies all around, etc.). Thanks, you guys!
mstombs wrote:My initial problems with ADSL2MUE were mainly due to external wiring issues, after eventually breaking completely and repair my line is now much more tolerant of modem and DSL drivers and PSUs but I have to run with high SNR margin and interleaved. I do not believe it is the so-called AR7 bug (allegedly fixed in dsp 7.3 + drivers), I also have a Broadcom based Speedtouch which did not fair much better. So later drivers may help your friends problem, but may just hide the underlying issues.

As your line is so stable with current modem - definitely worth having a second modem to experiment with!
And guess what else? A speed increase in downstream bandwidth from 3552 to 4320kbps. Can you tell I'm pleased?

Code: Select all

[DSL Modem Stats]               
        US Connection Rate:     448     DS Connection Rate:     4320
        DS Line Attenuation:    49      DS Margin:              2   
        US Line Attenuation:    26      US Margin:              23  
        US Payload :            358512  DS Payload:             2508432
        US Superframe Cnt :     130932  DS Superframe Cnt:      130932 
        US Transmit Power :     12      DS Transmit Power:      19     
        LOS errors:             0       SEF errors:             0      
        Errored Seconds:        0       Severely Err Secs:      0      
        Frame mode:             3       Max Frame mode:         0      
        Trained Path:           1       US Peak Cell Rate:      1056   
        Trained Mode:           3       Selected Mode:          1      
        ATUC Vendor Code:       54535443        ATUC Revision:  2      
        Hybrid Selected:        1       Trellis:                1      
        Showtime Count:         1       DS Max Attainable Bit Rate: 4320 kbps
        BitSwap:                1       US Max Attainable Bit Rate:     n/a  
        Annex:                  AnxA    psd_mask_qualifier: 0x0000           
        ATUC ghsVid:  b5 00 54 53 54 43 00 00                                
        T1413Vid: 00 00         T1413Rev: 00            VendorRev: 00        
        ATUR ghsVid:  b5 00 54 53 54 43 00 00                                
        T1413Vid: 00 00 T1413Rev: 00    VendorRev: 00
Thanks very much for your help, mstombs. That's put my mind at ease. Tests from my lonestar.org shell account show me that nothing is leaking and the iptables entries are looking a little more secure than mine, too. If I may be permitted a somewhat childish utterance, W00T! :D
Chronos
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: ADSL2MUE

Post by mstombs » Fri Oct 09, 2009 7:41 pm

Hope you didn't Woot too early - that downstream margin looks a bit low, presumably it was +6 when first connected, and is now down to 2...

I guess you haven't swapped DSL drivers? The default current is V6, the later ones may connect slightly slower but more robustly. I assume most fixes in the later drivers are for ADSL2+, not the ADSL1 I'm sure you are in at the moment.

I assume you are just using no-nat configured via the web interface?
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Fri Oct 09, 2009 8:10 pm

Yes, DSL driver is 6.x. If it settles somewhere in the region of 4000-ish kbps I'll be happy. That'll give me a 3.5Mbps bRAS profile on the DSLAM once it updates, which is .5M more than I had before. Anything between 4000 and 4554kbps will give me the same throughput because of bRAS profiling anyway. I am, as I said, stuck on ADSL1 (max) as I'm on a rural exchange (WNMOS). They're not even looking at this one for 21CN until 2011.

Code: Select all

Product Information
Model Number 	  	RouterTech AR7RD (1 Port)
HW Revision 	  	Unknown
Serial Number 	  	none
USB PID 	  	0x000f
USB VID 	  	0x13b1
Ethernet MAC 	  	00:12:17:xx:xx:xx
DSL MAC 	  	
USB MAC 	  	00:E0:A6:xx:xx:xx
USB Host MAC 	  	00:E0:A6:xx:xx:xx
Software Versions
Gateway 	  	3.6.0D
ATM Driver 	  	6.01.03.00
DSL HAL 	  	6.01.02.00
DSL Datapump 	  	6.02.01.00 Annex A
SAR HAL 	  	01.07.2c
PDSP Firmware 	  	0.54
Boot Loader 	  	1.2.0.4
NAT disabled, firewall enabled, same IP on both LAN and WAN as before and no leakage whatsoever. I'll have a pass at it with nmap when I'm next on a "foreign" connection (I'm only an ARPA user on freeshell, so I don't get access to nmap there), but I very much doubt there will be anything to report. Everything this side of it is running as before, if not a little faster. System Uptime: 1 hours 23 minutes. A little early to be jumping to conclusions, of course, but I'm pleased with it so far.

EDIT: OK, jumped to conclusions. With the FW on and access control enabled, nothing from the WAN side reaches the three servers. Turn the FW off (from the PPP connection config, not echo 0 > /proc/net/firewall_start, this still shows iptables as active) and the ACL does nothing. Never mind, plan B.

WARNING to others reading this: This worked for me, YMMV, this may produce a rather funny looking doorstop, read the docs and be sure you understand the implications of this change.

First of all, I used the 2M flash image when I should have used the 4M (I wondered where dropbear had gone - still, no harm done. The other way around could have been fun, though), since my router has 4M of flash. Error corrected after opening the thing up and making sure the chip was what the specs said it was. I know it sounds foolish, but just compare the filesizes of the original 4.22 firmware image and that of the 2MB routertech image. So, since I have this surfeit of space, and since there is a nice little script that automatically resizes the partitions to make room for an mtd5 and mounts it on /nvram, I made a 128k minix partition and used the startup.sh method to populate my iptables. I could have added my rules to RT_init_<n> for the same result without the risk of breaking my flash as an alternative, but the RW minix slice appealed to me. Simple, desired result acquired, proof that there's more than one way to confound a s'kiddie.

mstombs, you were right about the 7.x DSP code. Much more stable and doesn't return DS margins of eight figures when it gets confused. We're still synced at ~4300kbps with a DS margin of 6-8dB depending on when you check, so it looks like I get the 3.5Mbit prize. I'm currently running 7.3, which I'll leave alone until my bRAS profile gets updated, then I'll test 7.5.

Code: Select all

AR7 DSL Modem Statistics:
--------------------------------
[DSL Modem Stats]               
        US Connection Rate:     448     DS Connection Rate:     4320
        DS Line Attenuation:    49      DS Margin:              7   
        US Line Attenuation:    26      US Margin:              24  
        US Payload :            20255952        DS Payload:             117194064
        US Superframe Cnt :     2318991 DS Superframe Cnt:      2318991          
        US Transmit Power :     12      DS Transmit Power:      18               
        LOS errors:             0       SEF errors:             0                
        Errored Seconds:        0       Severely Err Secs:      0                
        Frame mode:             3       Max Frame mode:         0                
        Trained Path:           1       US Peak Cell Rate:      1056             
        Trained Mode:           3       Selected Mode:          1                
        ATUC Vendor Code:       54535443        ATUC Revision:  2                
        Hybrid Selected:        1       Trellis:                1                
        Showtime Count:         1       DS Max Attainable Bit Rate: 4320 kbps    
        BitSwap:                1       US Max Attainable Bit Rate:     n/a      
        Annex:                  AnxA    psd_mask_qualifier: 0x0000               
        ATUC ghsVid:  b5 00 54 53 54 43 00 00                                    
        T1413Vid: 00 00         T1413Rev: 00            VendorRev: 00            
        ATUR ghsVid:  b5 00 54 53 54 43 00 00                                    
        T1413Vid: 00 00 T1413Rev: 00    VendorRev: 00
Still very, very impressed with this firmware. It seems to have turned a rather mediocre Linksys product into something very useful.
Chronos
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Re: ADSL2MUE

Post by thechief » Sat Oct 10, 2009 10:54 am

Good on you. :)
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
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Sat Oct 10, 2009 11:23 am

Actually, good on you and the rest of the Routertech team. Without this firmware, I'd still be open to ssh brute-force attacks. From a security perspective, RT firmware is a no-brainer given the features and low-level control it opens up. I only wish I had tried it sooner.

On that note, there was talk in security circles of embedded Linux devices getting rooted and used for nefarious purposes. The 'net needs people like you to open things up and allow finer control over what have traditionally been seen as closed black-boxes. It doesn't seem to have happened yet (although the DNS query for . DDoS that was doing the rounds a couple of months back had suspiciously Linux-looking TTLs) but this is not only making devices more useful, but also helping people to learn how these things work and allowing third-party patches if and when security issues arise. The more knowledge you're armed with, the better you can protect yourself and your network from others with malicious intent.

So thank you to you and the rest of the Routertech team.
Chronos
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: ADSL2MUE

Post by mstombs » Sat Oct 10, 2009 11:58 am

The ADSL2MUE has an untypical amount of flash/ram for a single port device - but there are some reports from Oz that some devices do only have 2MB flash/ 8MB ram.

The core logic in the 4MB version has a few more/different features, more similar to the wireless firmwares - would be interested to know if anything re access control is fixed.

Re minix partition, make sure you "umount" or reboot via the web gui to make sure stuff gets saved!

With your own scripts you may also have to watch out for the iptables rules getting flushed on a DSL connect - it is possible to hook into the ppp ip-up scripts if you need to do so - as you will see they are linked to writable file on the ram disk.

Finally watch out for the BT RAMBO - multiple reboots and you may find yourself severely rate limited!
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Sat Oct 10, 2009 12:55 pm

mstombs wrote:The ADSL2MUE has an untypical amount of flash/ram for a single port device - but there are some reports from Oz that some devices do only have 2MB flash/ 8MB ram.
That's why I took it to bits to be sure. Had I not been able to confirm this, it would have stayed as was.
mstombs wrote:The core logic in the 4MB version has a few more/different features, more similar to the wireless firmwares - would be interested to know if anything re access control is fixed.
I haven't tried, but the rules in iptables looked the same. Once the DSL settles down I will check what actually happens with the access control on the 4MB firmware.
mstombs wrote:Re minix partition, make sure you "umount" or reboot via the web gui to make sure stuff gets saved!
Oh yes. I'm quite used to this: I run FreeBSD as my primary OS. You can also # sync && sync && sync, which looks like overkill but isn't. Something else you can quite easily do to protect your minix slice is only mount rw when you need to make a change. Just alter the environment variable to add -o ro to the mount command like so:

Code: Select all

# setenv RT_init_99 mount -t minix -o ro /dev/mtdblock/5 /nvram
then, if you need to make any changes, simply mount -o remount,rw /nvram, make your edit, sync && sync && sync and mount -o remount,ro /nvram.
mstombs wrote:With your own scripts you may also have to watch out for the iptables rules getting flushed on a DSL connect - it is possible to hook into the ppp ip-up scripts if you need to do so - as you will see they are linked to writable file on the ram disk.
From startup.sh:

Code: Select all

echo "# Reinitialise firewall on every connect" >> /var/tmp/onconnectWAN
echo "/nvram/fw_reinit.sh" >> /var/tmp/onconnectWAN
and there's a copy of the ruleset in the shell script referenced preceded by a flush. That should do the trick.
mstombs wrote:Finally watch out for the BT RAMBO - multiple reboots and you may find yourself severely rate limited!
That's why I said I'm going to let the bRAS profile catch up. I've been stuck at 2000kbps before, and believe me, convincing some people that RAMBo does get stuck, especially when the helldesk person thinks they're smarter than you, isn't an experience I relish going through again. There again, I do cut them a little slack, knowing how clueless the average punter is and then remembering that half of them are dafter than that :lol:

Thanks again for all the help.
Chronos
User avatar
Chronos
Newbie
Newbie
Posts: 7
Joined: Fri Oct 09, 2009 12:30 pm
Location: North Wales
Contact:

Re: ADSL2MUE

Post by Chronos » Wed Oct 28, 2009 7:09 pm

OK, sorry about the long delay in reporting back, but I don't really like bringing the network down until it's quiet.

The 7.x DSP code seems rock solid. As mstombs said, it is settling for a slightly slower D/S, with a higher SNR. I'm not seeing much difference between 7.3A and 7.5A, but as I am on G.dmt (ADSL max) I doubt there is any difference for my line anyway. I'd expect fixes to be concentrating on ADSL2+.

The access control still doesn't work for my half-bridge setup but, saying that, my half-bridge setup is as far from standard as you can get. The startup.sh and additions to onconnectWAN have worked flawlessly for the fortnight I've been watching the thing like a hawk and achieves everything I set out to do.

If anyone is interested in a write-up on this setup, let me know and I'll oblige.

Once again, thanks to mstombs for all the help and pointers and to the Routertech team for some excellent firmware.
Chronos
silicium
Newbie
Newbie
Posts: 4
Joined: Mon Oct 22, 2007 7:54 pm

Re: ADSL2MUE

Post by silicium » Sun Apr 25, 2010 10:24 pm

Hi,
do I have an AR7 with DSP bug ? My adsl2mue has always been disconnecting after a few minutes, despite trying several firmwares, power supplies and different lines (only ADSL G.dmt, no ADSL2). I bought it in early 2006, then got a Netgear DG832 with working AR7. Linksys support was slow but eventually replaced it for free... with another one that has the same problem :damnall:. After leaving it in the attic for three years, flashing 3.6.0D_20100105_2.92_AR7RD-1Port_psbl_firmware.upgrade.img did not help. Serial number is MGY05EB05631, manufactured 11/2005.
I am about to toss this blinking brick with a web GUI :curse:, or is there a software fix ?
mstombs
RouterTech Team
RouterTech Team
Posts: 3753
Joined: Wed Jan 10, 2007 11:54 pm

Re: ADSL2MUE

Post by mstombs » Mon Apr 26, 2010 12:06 am

If the DSL doesn't stay connected, then as you say no Linux software or features is going to be much use! What DSP driver are you using, dsp 7.5 works best here on my 2MUEs, but I still have occasional (too many) disconnects in ADSL2+.

Before chucking out do have a look at the 'tweaks' available with the

Router Stats Logger

Maybe something in the descriptions may apply to your line?
Post Reply