ppp0e bridge setup with external linux pppd

[mstombs]

The problem with atm/dsp 7/05 and 1350A was a combination issue. We had the atm/dsp working but not in combination with the GPL kernel and Acorp core-logic, clearly something was changed in the kernel module interface which was used by the core logic.

There may be an Acorp firmware with the atm/dsp 7.05 that would work, but I don't know which model, nor where they are any more. My Linksys ADSL2MUE could run Acorp LAN122 firmwares for example.

[burchbri]

The problem with atm/dsp 7/05 and 1350A was a combination issue. We had the atm/dsp working but not in combination with the GPL kernel and Acorp core-logic, clearly something was changed in the kernel module interface which was used by the core logic.

There may be an Acorp firmware with the atm/dsp 7.05 that would work, but I don't know which model, nor where they are any more. My Linksys ADSL2MUE could run Acorp LAN122 firmwares for example.

So now it is my turn to use thecheif's phrase "Well, you've lost me"!!

I don't have a lot of spare time, but I would have liked to help if a high-probablility solution was within my various fields of expertise. Your description sounds too near to the metal and too far from where I feel comfortable.

The good news is:

• The problem is defined and documented.
  Flashing the non-wireless firmware on a wireless-capable router (which otherwise would not work in bridge mode) is a good circumvention.

Please let me know if the general "binary compatibility issue" becomes important during development of the next version of the firmware. I'll be happy to help with testing and debugging if needed.

[thechief]

Your description sounds too near to the metal and too far from where I feel comfortable.

This was just another way of saying that "the GPL kernel sources that match the core logic and tiatm binaries have not been released to the public".

Please let me know if the general "binary compatibility issue" becomes important during development of the next version of the firmware. I'll be happy to help with testing and debugging if needed.

As far as 1350A is concerned, the issue will remain until the relevant kernel sources are released under the GPL.

As far as documenting your specific problem is concerned, perhaps full documentation of how you got to unearth the problem would be helpful for posterity (i.e., a step-by-step account of your attempts at setting up the bridge, etc).

[burchbri]

PS: if you are not too fussed about losing the wireless functionality on your 1350A wireless router, then you could always install the non-wireless firmware on it (you would most definitely need to reset to factory defaults first). This would give you the core logic and tiatm versions that you know to work for what you want.

What a brilliantly helpful suggestion! Thanks for mentioning it. I didn't know enough about the hardware platform dependencies to even think of taking that approach. I will try it straight away.... well, soon, at least...

Just to complete this part of the story, I tried to flash the wireless router with the non-wireless firmware. I hit a LOT of problems, most of which I have been through in the past, and a couple that are documented but were new to me. In the end I flashed the new firmware image successfully (what value I've had from the usb console adapter!). The new firmware worked well and the only issue was that it did not have a copy of led.sar605ew.conf, so the leds didn't work properly.

After several days successful operation, I reconfigured my production SAR-600ER for pppoe bridging and took the temporary router offline again.

[burchbri]

As far as documenting your specific problem is concerned, perhaps full documentation of how you got to unearth the problem would be helpful for posterity (i.e., a step-by-step account of your attempts at setting up the bridge, etc).

Once again, thanks to everyone for your valuable advice. Which forum category should I post my description to?

[thechief]

I think it would be best to post it in this thread. Thanks.

[burchbri]

I think it would be best to post it in this thread. Thanks.

If you are reading this post, either you have encountered the problem discussed earlier, or you are just wondering why anyone would need or want to use a pppoe-bridge connection. This is a summary of my reasoning and the steps I took to set up a working system.

RouterTech version 2.97 has many features that make it suitable as the primary ADSL router in many types of internet configuration. There are three common types of service that your ISP could provide - each type requires a somewhat different WAN and LAN configuration:

• Dynamic Internet Address :- Your router could have a PPPoA or PPPoE connection. Some ISP's only support one of these low-level protocols. However, if your ISP supports both, then PPPoA is preferred because ATM broadband packets will be used more efficiently and IP datagrams exchanged with internet hosts will never require fragmentation and re-assembly (i.e. MTU will be 1500). Your router will run the PPP daemon to authenticate with your ISP, and it will be dynamically assigned a single internet IP address. This means only the router itself can access the internet, so you need to activate the NAT feature to allow all your other systems to share that single internet address. You should also turn on the firewall feature in the connection configuration (which will also protect the router). You can simply use the default LAN configuration, where the router runs a DHCP service which allocates IP addresses to each of your systems. If you have a wireless router, then the simplest configuration is to let the DHCP server assign wireless client addresses from the same pool.
  
  Single Static Internet Address:- This is very similar to case 1, except your ISP has reserved a single internet IP address for your dedicated use (so that other hosts on the internet can always find and access your servers). Your router will run a PPP daemon which is dynamically assigned a fixed IP address for itself (actually its ppp0 logical interface owns this address). You will need the NAT feature active to allow all your other systems to share the single internet address. You probably ordered a static address so you could provide internet-accessible services on your own server(s), and so you need to use the port-forwarding feature to make the router deliver incoming packets to those services. The router firewall feature should be turned on, although you should be aware that port forwarding effectively "punches holes" through to your internal servers.
  
  Static Subnet:- I have several servers that need their own fixed internet-addressable IP addresses, so my ISP provides me with a small subnet. For a long time I found it acceptable to run my router with a normal PPPoA configuration. The ppp daemon executed on my router and was assigned a dynamic IP address. I configured the LAN interface to map my entire internet subnet, and turned off the NAT and firewall features so that all incoming internet datagrams were delivered to my internet servers. Obviously, each server had its own fairly constant firewall configuration, because the services hardly ever changed.

As time went by, my internet servers became the subject of more and more port scans and attacks. Usually, each of my servers would log the same attack patterns. I started to manually build iptables in the RouterTech environment to catch a lot of these attacks as early as possible (e.g. block SIP probes to systems that are not proxies, block DNS to systems not running bind). This approach served me well for nearly 5 years, but recent attacks indicated I would have to hand-craft an ever-increasing set of iptables rules, and then regularly update the RT-cmd_xx environment variables that I used to get them loaded in the right order whenever the router rebooted.

I was fairly proficient at building and testing these iptables, but had already changed the way I maintened my linux server firewalls. I now use the Shorewall (http://shorewall.net/) open source product and it suits me well as a way to elegantly express my firewall rules. Shorewall compiles my symbolic requirements into iptables rules and also takes care of deployment. Unfortunately, the version of the linux kernel used by RouterTech is quite old, so many of the iptables features that Shorewall expects are not available on the router.

In order to maintain my ever-more-sophisticated "first entry" firewall rules into the future, I realised I would have to separate my existing ADSL router functions. Obviously, RouterTech would still have to run the ADSL (ATM) connection, but I would have to move the PPP daemon onto a modern linux system. This topology is called Bridge (PPPoE-Bridge to be precise) on the RouterTech setup connection type selector. First, I confirmed my ISP could support ordinary PPPoE by reconfiguring the router PPPoA connection, keeping most of the parameters the same (note: the maximum MTU is automatically reduced to 1492 bytes for PPPoE).

The Bridge connection type has very few parameters because most of the setup is associated with the PPP daemon, which has moved to the "funnel" linux system. LLC Encapsulation should be selected (in the UK, at least). The only other parameters not greyed-out are VPI and VCI (set to 0 and 38 in the UK).

At this point the router is configured as an ethernet bridge, so it will try to send ALL outbound ethernet packets to your ISP over the ADSL link. You need to also assign an IP address to the router if you want to manage it via the web interface, or telnet. It does not need to be internet addressable as long as you can provide the services it needs on your own systems (e.g. DNS and SNTP). My own network is fairly messy because many devices like to use 192.168.x.0 "black hole" subnets in their default modes, so I decided to configure the LAN between the router and my "funnel" linux system to use a 172.16.101.x "black hole" subnet. I proved this worked by running telnet and browser sessions to the router from my "funnel" linux system.

Because the router is running as a bridge, any outbound ethernet frames which are not addressed to its own IP address would be leaked onto the ADSL link. Therefore, I configured two ANY/ANY Bridge filters to PERMIT only the PPPoE Discovery and PPPoE Session frame types, and so all other frame types will be discarded.

Now I could connect the ADSL cable and confirm the router connected to the local BT exchange (using the LED or the web admin interface). Of course, I couldn't access the internet yet because there was no PPP connection to my ISP. However, I could see from the brctl command that the ADSL driver had created a nas0 device and connected it to the br0 bridge. PPP traffic would flow once I could generate it.

My "funnel" machine is a low-power mini-ITX system with two ethernet interfaces. It is powerful enough to run a modern ubuntu (debian) linux distribution. It has the shorewall and shorewall-init packages installed to manage my iptables rule set. I made some small changes to the sample two-interface configuration: an extra zone for the router's administration linked to the eth0 interface, and a ppp0 interface associated with the standard "net" zone". Along with some rules to ALLOW specific incoming connections to my services, that was enough to get started.

I installed the pppoeconf package and ran it. The program starts by probing both ethernet interfaces with PADI Discovery broadcast frames. Once I had the underlying network properly configured, one of these frames arrived at the router's ethernet bridge, and was sent out over the ADSL connection. A reponse was received (carring the MAC address of a peer system prepared to negotiate a connection) and the pppoeconf program prompted me for the correct username and password assigned by my ISP. It then logged on and established a point-to-point session and my ISP's DHCP server assigned a routable IP address to my "funnel" linux system's ppp0 logical interface. The pppoeconf program updated the /etc/ppp/chap-secrets and /etc/ppp/peers/dsl-provider files and configured the init scripts to bring up the link each time the system is booted. Shorewall detects the ppp0 interface and activates its rules automatically. I modified the peer definiton slightly to improve the way it dealt with LCP timeouts and recovery.

At this point I could access the internet from my "funnel" linux system. I then went to each of my servers to make sure they still worked properly. Their existing network and firewall configurations worked without change. This was because the IP address of their default route now belonged to the the "funnel" system's eth0 interface, rather than the ADSL router. These systems could also transparently access the ADSL router administrative services because it was reachable via their default route. There were a couple of wrinkles associated with the Shorewall rules on my main NAT firewall before my internal client systems could administer the router properly, but that story belongs to the Shorewall mailing list (search for martians!).

[thechief]

Thanks

[burchbri]

Postscript:

After thinking I had successfully converted my ADSL connection to PPPoE, I began to notice strange intermittent problems. Sometimes a complex web page would appear to have loaded, even though the browser indicated it was still expecting data. I captured the ppp traffic with wireshark, but couldn't see anything wrong. It looked a bit like an mtu problem, but the same page would often reload perfectly. There were often a lot of ADSL CRC and FEC errors, but I couldn't tell whether they were related.

After a particularly bad spell, I found this article http://aa.net.uk/kb-broadband-mtu.html. My local BT exchange has finished implementing fibre to the cabinet, but the cabinet associated with my line is still a rusty old one that leaves me with 2km of copper to the exchange. A couple of years ago BT switched me to a "more modern" DSLAM and the results were terrible. Eventually I persuaded my ISP to persuade BT to put my line back how it was when it worked. I haven't had the nerve to ask for any further changes.

I decided my intermittent problems were most likely to be due to a buggy pppoe implementation between my router and my ISP. I reconfigured my router back to pppoa and used my recent experience to keep my static subnet on the linux firewall. My broadband service has been stable, fast and with very low error rates ever since. If you are tempted to venture down the pppoe path in the UK, BEWARE!

[mstombs]

RT firmware has a half-bridge script pppHB.sh that may be of use with pppoa connection. Theoretically this allows an MTU of 1500 to be maintained, no 8 bytes pppoe overhead, but my old isp TalkTalk used to set their modems to an MTU of 1400, presumbaly to allow encapsulation further on?

[burchbri]

RT firmware has a half-bridge script pppHB.sh that may be of use with pppoa connection.

I took a quick look at the script, which credits you as the author 5 years ago. It is too big and full of symbolics for me to understand easily. I found a discussion that suggested half-bridge is applicable to a single static IP address, while full bridge was the choice for a static subnet. I sort-of understood, but nowhere well enough to follow the details.

Theoretically this allows an MTU of 1500 to be maintained, no 8 bytes pppoe overhead, but my old isp TalkTalk used to set their modems to an MTU of 1400, presumbaly to allow encapsulation further on?

Well, yes, that is because using pppoa does not require the "simulated ethernet" 8 byte pppoe header. The difficulty comes when you need routing (or bridging) to/from all the individual addresses your subnet - it is a different situation if your ISP only gives you a single address via DHCP. There have been developments with pppoe to allow jumbo frames, which can be used to transport (typically) 1508 byte pppoe packets, thus permitting an MTU of 1500 to be preserved. As far as I can tell, that is where all the buggy implementations come from - there are too many edge cases when the implementations are not identical at each end of the ppp.

I shouldn't speculate further because I don't understand well enough and don't want to confuse anyone. Fortunately my routed pppoa solution works fine with my own BT local exchange and my current ISP. Judging from the lack of action on this thread recently, I don't think anyone else is in the same situation as me. I'm happy to give more details if someone asks for help in future.

[mstombs]

IIRC most of that script is to handle dynamic IPs and passing them to host via dhcp, and hooking into wan up/down scripts when wan IP changes. It should be easier with a static WAN IP, but if you can have a range of static IPs no-nat config should be configurable from the web gui - give the modem an IP and tell your internal network to use it as gateway.

Hope your solution works for long enough till something better comes along - ADSL next to obsoleted now dial-up gone!