HALF-BRIDGE mode in Routertech 2.2/2.3 UPDATED using 2.9+

[mstombs]

[Updated script:- removed references to iptables commands that clearly aren't needed for the half bridge operation. Updated Gateway Philosophy, now pass ISP gateway to client, and route through modem using proxy arp, reduced verbosity of messages]

[Update 3, removed script, replaced by new version with instructions later]

With no apologies for starting a new thread for this, but you may not have noticed my post in here:- viewtopic.php?t=1139

I have finally found a way to make Routertech 2.2 firmware 'brain dead' and pretend to only be a pppoa modem, just dealing with the DSL connection and passing the WAN IP to a single connected computer (which will generally be a firewall router).

If you have static IP addresses, or just want to do it manually, all that is needed is the following standard linux configuration commands - no firmware/kernel etc changes are needed - and most of the problems other modem manufacturers introduce are avoided! First disable NAT/FIREWALL in web interface, commands assume a pppoa connection.

a.

Code: Select all

ifconfig ppp0

this displays the ISP supplied WANIP and GW (p-t-p) address and netmask MK which is usually 255.255.255.255 meaning you only are given the one address. You also need to know your DNS servers from the web interface or look in the /var/tmp/resolv.conf file.

b.

Code: Select all

ifconfig ppp0 0.0.0.0

this effectively removes the IP address from the ppp0 interface, so we can re-use it elsewhere, not important what IP address is used - but removing completely avoids any security issue I guess. The ppp tunnel still works (for me at least!) it just sends anything received at one end to the other.

c.

Code: Select all

route add -net $WANIP netmask 255.255.255.255 dev br0

(use your WANIP and netmask from step a)
This tells your modem where to find the WANIP, my modem only has one LAN port eth0 which is software bridged to br0

d.

Code: Select all

route add default ppp0

This sets the default route on the modem, this is normally set but is lost when command b) is entered

[edit] the current code uses a more explicit form of this default gateway, after the host route in f.

e. You can now manually set the WANIP on your PC/router as its IP address, and specify the modem IP address as the gateway 192.168.1.1 and it should all work. The next 2 steps allow you to also use the ISP supplied gateway, access to the modem still works as everything is routed through it.

f.

Code: Select all

route add -host $GW dev ppp0

This tells the modem where to find the ISP Gateway

[edit] and now can explicity set the gateway through the gateway IP address

Code: Select all

route add default gw $WANIP

g.

Code: Select all

echo "1" > /proc/sys/net/ipv4/conf/ppp0/proxy_arp
echo "1" > /proc/sys/net/ipv4/conf/br0/proxy_arp

This allows the modem to advertise the fact it knows how to route packets to the real gateway to requests received on the LAN side

h) Set the ISP supplied IP, netmask and gateway on your PC or router. NB windows XP does not allow you to manually enter 255.255.255.255 as the netmask, you can use 255.255.255.0, which is what some manufacturers half-bridge does, the only downside is that you will not be able to connect to similar IP addresses because you have told windows they are local, not out on the internet.

If, like me you have an ISP that changes the IP address every time their is a glitch on the DSL line then the above procedure is no practical use and an automatic script is needed. This should continuously monitor the ISP supplied IP address and pass it on to the client PC/router using dhcp. It should also tidy up and remove the old routes before setting the new.

See the pppHB.sh script in RouterTech firmwares for the latest version of the script
[2.95 still a non-gui script, see pppHB readme in firmware download for latest instructions]

[Shotokan101]

Nice work - just wish I understood half of it

[legume]

I am useless at reading scripts aswell especially at this hour. A few comments -

If the default policy on INPUT is accept then there is no point setting accept rules.

The --set-mss 1360 is naughty you shouldn't just set mss - that option needs to be used with the match (not in firmware) because you have to respect an endpoint asking for a lower value. Cfgmgr uses --clamp-to-pmtu .

Cfgmgr seems to notice a dsl retrain quickly and will kill pppd only when it comes back up - I am not sure if this will affect what your script monitoring - I dropped tonight and have remote logging I was back up with a new ppp in < 30 sec.

Andy.

[mstombs]

The various iptables commands in the original scripts are there because I have been trying in the past to copy what I observe D-Link zipb to do. ie

#
#
# Setup IPTABLES
#
# SIP phone use?
IPTABLES -I INPUT 1 -p udp --dport 5060 -j ACCEPT
IPTABLES -I INPUT 1 -p udp --dport 5061 -j ACCEPT
IPTABLES -A OUTPUT -o ! br0 -p icmp --icmp-type 3 -j DROP
IPTABLES -A OUTPUT -o ! br0 -p icmp -m state --state INVALID -j DROP
IPTABLES -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

I also removed the NAT command that D-Link issues

IPTABLES -t nat -A POSTROUTING -o ! br0 -j MASQUERADE

which I have had explained to me means NAT everything leaving interfaces except br0 - which in my case means only ppp0. Zipb manages to leave the WAN IP allocated to ppp0 so I guess this command is left in to prevent any packets being sent to the ISP not from the IP that they told the modem to use - at expense of breaking p2p apps etc.

I don't know what the ... j CFG commands do,

IPTABLES -I INPUT 1 -p tcp --dport 80 -s $defclientIPA -j CFG
IPTABLES -D INPUT -p tcp --dport 80 -s $pppHBIP -j CFG
IPTABLES -I INPUT 1 -p tcp --dport 80 -s $IP -j CFG

may be used to communicate the true WAN IP to the kernel for use by zipb kernel patch?

Cfgmgr seems to notice a dsl retrain quickly and will kill pppd only when it comes back up - I am not sure if this will affect what your script monitoring - I dropped tonight and have remote logging I was back up with a new ppp in < 30 sec.

I tested my script by pulling the DSL cable out, it notices - eventually, would be better to hook into pppd with ppp-up scripts, but I think this needs a code change because RT2.2 doesn't seem to have ppp scripts. It may just need links in /etc/ppp to editable scripts in /var/tmp added to the filesystem?

[moosh]

OK, I installed RT( after I saw your post, but where do you run the script? Surely not from the command line and I could not see a page for init scripts. If this works, it is exactly what I am looking for, so thanks! Rt is VERY impressive and makes 2.17AU look pretty dated, so it would be an ideal partner for Tomato on my WRT. I did try to run in bridge mode, but could not get it to work:

Feb 27 14:49:45 | System Call Error
Feb 27 14:49:45 | pppd 2.4.1 started by root, uid 0
Feb 27 14:49:45 | connect(0.38)_ : Device or resource busy
Feb 27 14:49:45 | System Call Error

was in the log. I was logging in from the desktop, don't know if that makes a difference. Anyway, the PPoA perFormance is superb. As a single port router with RT, this box is a bargain.

[Shotokan101]

OK, I installed RT( after I saw your post, but where do you run the script? Surely not from the command line and I could not see a page for init scripts. If this works, it is exactly what I am looking for, so thanks! Rt is VERY impressive and makes 2.17AU look pretty dated, so it would be an ideal partner for Tomato on my WRT. I did try to run in bridge mode, but could not get it to work:

Feb 27 14:49:45 | System Call Error
Feb 27 14:49:45 | pppd 2.4.1 started by root, uid 0
Feb 27 14:49:45 | connect(0.38)_ : Device or resource busy
Feb 27 14:49:45 | System Call Error

was in the log. I was logging in from the desktop, don't know if that makes a difference. Anyway, the PPoA perFormance is superb. As a single port router with RT, this box is a bargain.

Unless thhe development team build this script (or equivalent) into a future RT release then it's the command line for you my Lad wink:

...but all is not lost - see the link below for Neo's excellent Telnet Scripting utility - or alternatively see the RT documentation on using autoexec.sh to pull the file from an external web server
viewtopic.php?t=282 :

[mstombs]

OK, I installed RT( after I saw your post, but where do you run the script? Surely not from the command line and I could not see a page for init scripts. If this works, it is exactly what I am looking for, so thanks! Rt is VERY impressive and makes 2.17AU look pretty dated, so it would be an ideal partner for Tomato on my WRT. I did try to run in bridge mode, but could not get it to work:

Feb 27 14:49:45 | System Call Error
Feb 27 14:49:45 | pppd 2.4.1 started by root, uid 0
Feb 27 14:49:45 | connect(0.38)_ : Device or resource busy
Feb 27 14:49:45 | System Call Error

was in the log. I was logging in from the desktop, don't know if that makes a difference. Anyway, the PPoA perFormance is superb. As a single port router with RT, this box is a bargain.

Oo err, not sure it is ready for primetime, unless you really know what you are doing can read my obscure code and debug it for me!. You did reset to defaults after upgrading, strange things can happen - I don't recall that error message, but looks like you have 2 connections defined? I will update the script and documentation later based on feedback received - keep it coming!

The way I run the script is by getting it onto the router called say /var/pppHB.sh, make this file executable with chmod +x /var/pppHB.sh then make temporary changes from the web interface (so reboot defaults to sensible operation) then run from serial console using ./var/pppHB.sh &, and watch the hundreds of messages go past. Telnet sessions will break with changing IP addresses, and the connected machine may have to release/renew any IP address it has to change to the shorter ones needed by the script operation.

I'm typing this through my linux box checking that the half-bridge mode is still working since yesterday?

[legume]

The various iptables commands in this scripts are there because I have been trying in the past to copy what I observe D-Link zipb to do. I removed the NAT command that D-Link issues

Ahh, I guess there isn't a definition of zeroip so they do what they want

I don't know what the ... j CFG commands do, may be used to communicate the true WAN IP to the kernel for use by zipb kernel patch?

When I first saw it I thought it was another table, but it seems it's a TI added target - from the sources -

Module Name: Kernel extension in netfilter.New target CFG
Module Purpose: To Control the execution of udhcp client

I haven't got a clue what use it is in practise, the help says it "Records Packet's Source Interface".

I tested my script by pulling the DSL cable out, it notices - eventually, would be better to hook into pppd with ppp-up scripts, but I think this needs a code change because RT2.2 doesn't seem to have ppp scripts. It may just need links in /etc/ppp to editable scripts in /var/tmp added to the filesystem?

OK, I used to do "my own" ppp when I used a PCI modem - ppp stayed up throughout a retrain, and before max dsl it would always just carry on working when the line was back.
Post max it's not that easy - sometimes it will be OK but not always (I think it's because of BT Rambo heartbeat, or possibly different ISP kit - I changed ISP to get Max).
Whatever the reason you may find to be safe you have to poll often enough to notice a retrain. This assumes that you were to totally take over from cfgmgr.
From what I have seen it looks like cfgmgr just uses a long command line for all the pppd options.
If you ever take over you'll need to handle ppp dropping because of termreq sent by ISP/or a timeout getting new ppp - the version of pppd/the pppoa patch that I used didn't always handle this well, so using the persist option of pppd didn't always work, hence it would need scripting - as you do, I just say incase you try other things in future.

Andy.

[mstombs]

OK I have updated the script in the first post to my latest version. The iptables commands are clearly not essential for half bridge operation [its still working] - but to avoid sending packets to the ISP that do not come from the intended WIP I suggest adding one of the following from another thread

...
from the router -

iptables -I OUTPUT -o ppp0 -j DROP

from the lan - either drop anything from lan ip subnet or just allow real your ip through, your scrip would need to handle real ip for the latter.

iptables -I FORWARD -o ppp0 --src ! $REALIP -j DROP

or

iptables -I FORWARD -o ppp0 --src 192.168.1.0/24 -j DROP

Andy.

comments - my vote for No 2, but have to remember to delete/ reinsert on WAN IP change (as per other rules)

[legume]

New script looks good, not that I am much good at scripting. If pppd has the default route option it will make/delete it's own entry. IIRC it won't if there is already one, though. I don't know if that affects anything.

As for the iptables I would use

Code: Select all

iptables -I OUTPUT -o ppp0 -j DROP 
iptables -I FORWARD -o ppp0 --src ! $REALIP -j DROP

Since conntrack is still happening anyway (I looked at compiling ip, but it would also need a config change in kernel to do what I wanted - so I gave up) You could probably use iptables to get igmp to work for multicast - I'll have to try over the weekend and see if it'll work.

Andy.

[mstombs]

New script looks good, not that I am much good at scripting.

Thanks, but I only started a couple of months ago just to fix this problem and I am still learning...

If pppd has the default route option it will make/delete it's own entry. IIRC it won't if there is already one, though. I don't know if that affects anything.

I think you are correct, this will be linked to the "default gateway" tick box in the pppoa setup I guess.

As for the iptables I would use

Code: Select all

iptables -I OUTPUT -o ppp0 -j DROP 
iptables -I FORWARD -o ppp0 --src ! $REALIP -j DROP

I understand the second, does the first set a default rule to drop everything and the second only allow forwarded packets from the REAL IP, which gets around the first?

Since conntrack is still happening anyway (I looked at compiling ip, but it would also need a config change in kernel to do what I wanted - so I gave up) You could probably use iptables to get igmp to work for multicast - I'll have to try over the weekend and see if it'll work.

Andy.

You have lost me here, but I have been able to compile the Routertech distributed sources for the Acorp LAN120 which will run on my modem.

PS I am working on a next version which makes better use of the Routertech firmware functionality (before switching it off). I propose to use the standard web configuration to run when the router first boots, with the half bridge script started later by the autoexec.sh function (which checks internet is working first). This way the router can get the correct time, send me a welcome "router has booted" email etc before switching to half-bridge mode. This means the script won't need the hard coded addresses and times or step 2 above.

[legume]

As for the iptables I would use

Code:
iptables -I OUTPUT -o ppp0 -j DROP
iptables -I FORWARD -o ppp0 --src ! $REALIP -j DROP

I understand the second, does the first set a default rule to drop everything and the second only allow forwarded packets from the REAL IP, which gets around the first?

You need both, the FORWARD only sees forwarded traffic the OUTPUT only sees locally generated traffic - eg. the router will send icmp net unreachables if the next router or single PC is down. The default set up blocks these also - but allows other traffic, this just blocks everything to avoid sending packets to wan with private addresses. The FORWARD rule may not see any traffic - but then if you have to use a silly mask for windows it probably will.... (It may be worth using the smallest subnet and putting a big warning about not being firewalled anymore in the instructions) You can look at the counters with

iptables -L -vn

http://www.docum.org/docum.org/kptd/

Shows the path packets take.

Quote:

Since conntrack is still happening anyway (I looked at compiling ip, but it would also need a config change in kernel to do what I wanted - so I gave up) You could probably use iptables to get igmp to work for multicast - I'll have to try over the weekend and see if it'll work.

You have lost me here, but I have been able to compile the Routertech distributed sources for the Acorp LAN120 which will run on my modem.

I mungled two issues into one sentence

It's cool you can compile stuff - I'll have to find time to learn about all that.
The motivation for doing zero IP for me, was to try and avoid using iptables conntracking, which eats memory/cpu. If it's possible to do away with it, then you could have the benefit of the TI DSL fornt end for £20 and possibly serve 00s of users using a bigger (but still cheap) Linux gateway box for nat/Qos etc.

I thought I would just have to compile one userspace binary - IP, to do this, if I messed up it would just need a reboot. Looking at the configs in the sources I see I need to do a kernel as well = bricked router/kernel size issues. I haven't checked out the routing daemons yet. The Idea was to have no default route on the router, so no need to block its traffic. You can also do stateless nat with IP which gives a bit of hope for getting mullticast to work without iptables.

Your current setup won't work for multicast - but could probably be made to work with a couple of extra iptables rules - still thinking about the detail.

You could also still do statefull firewall if you wanted.

Andy.

[mstombs]

[Note: This post is now obsolete - the calling syntax was rewritten in RT 2.5 and the script does not stay resident in memory, it is only called when required by ppp ip-up and ip-down scripts, see readme in firmware distribution]


OK I have now incorporated the iptables commands above, but left the default route command in because the default route seems to get lost when changing the ppp IP address.

The script now attempts to do all the configuration required, using the local IP addresses, lease time and a web based enable (fudge) flag.

To use this script.

1. The modem/router must be set up and operate successfully in normal 'NAT routing mode' with time set via sntp, dyndns updated by ddns etc.

2. Important variables for half bridge mode are

a) The LAN dhcp lease_time. This defaults to 3600 seconds in the web GUI, for half bridge mode this should be set to about 60 seconds. The script will read the value set through the web screen when it starts - this allows the user to customize. A longer time means changes are not picked up quickly but processor/ bandwidth wasted in dhcp messages is reduced.

b) The string "pppHB" must be added to the hostname or domain (default AR7D) in the LAN Group setup. This is a 'fudge' it just turns out it is easy for the script to monitor this string, if it is not there the half bridge script will exit. If everything goes wrong resetting to defaults will also disable the half-bridge script. Adding a custom web screen flag is not easy - I won't be doing that!

c) The modem will continue to be accessible from the LAN using whatever the Local IP address is set to (default 192.168.1.1, but it generally recommended to change this). If something goes wrong with the dhcp IP address transfer - setting the client PC to a static IP address in the same range as the modem should restore access to the modem for diagnostics.

The attached script is intended to be run in the future using the Routertech Autoexec.sh function, after the modem has booted, set the time, updated ddns, sent welcome emails etc. In half bridge mode the modem itself doesn't have internet access so the script attempts to turn off NAT,SNTP,DNS,UPNP using CLI commands equivalent to those used by the web interface (see Routertech guide in firmware distribution for more info). If settings are "saved" while in half-bridge mode these changes will also be saved which may not be what you want.

Brief documentation on the script

Stage 1, Initialization

The script accepts one parameter, the main loop pause time which defaults to 30 seconds. The script will not start if the string b) above doesn't appear in the 'hosts file'.

Stage 2, setup operation managing the dhcp process, initially with the same configuration file as set by the user through the web interface.

Stage 3, main loop
Continuously monitor DSL and ppp state setting up routing and dhcp configuration as appropriate to enable the connected PC/router to obtain and operate with the ISP supplied IP address, netmask and Gateway.

The attached script was last edited on my modem, then compressed with

Code: Select all

/var/nvramdir # tar -cz -f pppHB.tgz pppHB.sh

Then zipped under windows as this message board doesn't allow tgz attachments.

If you would like to test it - it needs to be unzipped, untarred, got onto the modem and made executable before running.

If sufficient positive feedback I hope it will be distributable with next version of Routertech firmware which will make this a bit easier!

Note - it seems to work for me. Main issue to be addressed is configuration of firewall with IPtables commands. The outgoing firewall is configured as discussed above in this thread. The incoming firewall is not deliberately disabled but turning off NAT effectively disables it.[*] Some additional rules may be added to ensure access to the modem from the WAN is prevented - but in half -bridge mode everything should be passed on to the connected machine which needs the firewall for the LAN. Further configuration may also be needed for 'multicast' (as above).

In final testing on both Windows and Linux I have observed some warning error messages which I may be able to get rid off. When changing IP address it appears the rules using ppp0 sometimes disappear and do not need to be explicitly deleted removed. Other improvements will be bug fixes and more checks to make the script more robust for 'general use'.

Unfortunately this does not work with my WRT54GS because the WRT54GS firmware expects the gateway to be in the same network as the IP address. This can be fixed with 2 extra route commands on the WRT54GS, but an alternative method is to spoof the netmask given to the router. I have now added this as an option to the script, and will post update when passed my tests - but this is added with it running... I have also fixed the problem with the WRT54GS by adding a custom firewall script - details over at linksysinfo Hyperwrt forum. The same firewall script also appears to work with the same half-bridge Gateway problem using Tomato [update]and dd-wrt[/update] firmware:

http://www.linksysinfo.org/forums/showt ... hp?t=52937

New version attached, accepts a second parameter to spoof the netmask should the router need it

Code: Select all

# RouterTech AR7* Firmware Shell Script
# Function: Manage ppp Half-Bridge mode
# Author:    mstombs
# Date:    13 May 2007 Amended 16 May 2007 BETA 2
# Usage:   ./pppHB.sh [check_wait] [N8 N16 N24 N32]
# The second parameter instructs the modem to ignore the ISP
# netmask and force a specific netmask to be used
# -----------------------------------------------

Choices for netmask are

N8) NETMASK="255.0.0.0" ;;
N16) NETMASK="255.255.0.0" ;;
N24) NETMASK="255.255.255.0" ;;
N32) NETMASK="255.255.255.255" ;;

I've also found out how to send messages to the system log so a successful boot into half-bridge mode now looks like

Code: Select all

May 11 22:06:09 | Valid Configuration Tree
May 11 22:06:09 | NTP Polling Timer for DHCP Started succesfully.
May 11 22:06:09 | DSL Polling Timer Started succesfully.
May 11 22:06:09 | PSP Boot environment  Modem Modulation Change: 0x3
May 11 22:06:10 | Firewall NAT service started
May 11 22:06:10 | Bridge Created: br0
May 11 22:06:12 | Bridge Created: br1
May 11 22:06:13 | Bridge Created: br2
May 11 22:06:14 | Bridge Interface Added: eth0
May 11 22:06:16 | Add Bridge Iface Error: 1
May 11 22:06:16 | crond 2.3.2 dillon, started, log level 8 
May 11 22:06:19 | DSL Carrier is down
May 11 22:06:29 | DSL Carrier is up
May 11 22:06:30 | sar read trained mode (1)(ADSL_G.dmt)
May 11 22:06:30 | pppd 2.4.1 started by root, uid 0
May 11 22:06:30 | Connect: ppp0 {--} 
May 11 22:06:30 | Couldn't increase MTU to 1500
May 11 22:06:31 | PPPoA Connect with IP Address 89.243.45.142 
May 11 22:06:31 | PPPoA Connection Successfully Established 
May 11 22:06:31 | PPPoA Connect with Gateway IP Address: 89.243.32.1 
May 11 22:06:31 | local  IP address 89.243.45.142
May 11 23:06:32 | remote IP address 89.243.32.1
May 11 23:06:32 | primary   DNS address 62.24.252.135
May 11 23:06:32 | secondary DNS address 62.24.252.134
May 11 23:06:35 | PPPD Successfully Started 
May 11 23:06:42 | DDNS dyndns: Update Successful ip 89.243.45.142 from ppp0
May 16 23:48:35 | pppHB: Using main loop wait time of 20 seconds
May 16 23:48:36 | Firewall NAT service stopped
May 16 23:48:38 | pppHB: udhcpd started with conf /var/tmp/pppHBdefault.conf
May 16 23:48:39 | pppHB: DSL Conn status US Rate: 448 DS Rate: 7904
May 16 23:48:39 | pppHB: IP=89.243.45.142 ;GW=89.243.32.1 ;MK=255.255.255.255
May 16 23:48:39 | pppHB: udhcpd started for 89.243.45.142
May 16 23:48:48 | time disparity of 7242 minutes detected 

If half bridge mode stopped from web screen (clear "pppHB" from hostname) modem is now put back into NAT with FIREWALL and normal dhcp enabled.

I have tidied up the code as far as I can - now does pretty much all I want...

[update post: adding html instructions in form of FAQ]

[update: An updated version of the script now built into Routertech 2.3, this uses the new RT2.3 function cm_cli_ex to configure the modem, so the example script that was posted here has been removed]

[*] WARNING, the firewall is completely disabled by the script, can be restarted and checked by the Linux commands

Code: Select all

/var # echo 1 >/proc/net/firewall_start
/var # cat /proc/net/firewall_start
Current Firewall State is 1.

[update in response to query, not yet in html doc]The half bridge script can be made to auto run on router boot up without also leaving autoexec.sh running with a pair of environment variables

Code: Select all

setenv RT_CMD_1 "cd /var;echo \"pppHB.sh &\" >hb.sh;chmod +x hb.sh" 
setenv autoexec.sh /var/hb.sh

The first creates a small executable script file called by the second run by the autoexec.sh. This 2 step approach seems to be needed to be able to get the trailing "&" on the command in - this allows the calling script to continue and exit leaving just pppHB.sh running.

[legume]

An updated version of the script now built into Routertech 2.3

I decided to upgrade to have a look, but though it seemed to go OK I am still 2.2

Andy.

[thechief]

Better fire up the pctool then.