ppp0e bridge setup with external linux pppd

[burchbri]

I am probably being stupid and have missed something simple, but I can't get this working.

I have two solwise routers, both running routertech version 2.97, so I have been able to make a/b comparisons without having to change their configurations every time.

I have been using pppoa for years to support my static internet subnet on the router LAN. I have about 35 iptables rules on the router, which are established with RT_cmd_nn environment variables. Changes are unwieldy, and so I would like to use a linux pc to act as the primary router/firewall instead of the solwise.

Firstly, I had to find out whether my ISP supports pppoe, so I configured my spare router to use pppoe instead of pppoa, but making no other changes. This was successful, so I converted my production router to use pppoe and it is working as I type this message.

To be paranoid, I deleted the working pppoe connection definition and created a new one for a pppoe bridge. I configured my linux pppd to use the same parameters (and some others) as used by my production router's pppd-pppoe. Because the linux pppd never gets a reply to its PADI broadcast messages, most of the parameters are not even relevant at this time.

When I read the routertech help panel about Bridge Filters, I wondered whether the 3 default rules might not be not enough. I added 2 new rules to ALLOW ANY/ANY for PPPOE Discovery and PPPOE Session frames, but that did not seem to make a difference. (And yes, I was doing these tests while the router's DSL LED was solid green, so the route from the DSL port to my ISP's pppoe server should have been OK.)

Wireshark shows perfectly reasonable PADI frames being sent with the source MAC of the correct ethernet interface on my linux machine. Each PADI times out and is retried.

I hoped the connection definition for pppoe bridging (not shared) would be enough to route all ethernet packets between the linux system and the router, but it doesn't look as if that is happening. I then hoped the two Bridge Filter rules would solve the problem (even though I couldn't find that approach mentioned in other posts).

When the router is running normally, ifconfig shows me its nas0 interface has a sensible MAC. (I even tried spoofing a 00:30 MAC on the linux eth0, similar to those of my routers nas0 interfaces, but that didn't help).

I defined a LAN configuration on the router for a 172.16.101.0 subnet, which allows me to check its configuration to some extent. I collected /proc/avalanche/avsar_modem_stats before and after 12 PADI timeouts (each 34 bytes on the wire). When I diffed the files, there seems to be no change to the upstream packet counter. (The downstream count increased, but I assume those packets were unsolicited).

Have I missed something obvious?

Brian

[mstombs]

I think you know more about this than any of us!

Isn't there also a 'sharing' tick box which I recall mixed results.

I wonder if you require a working local IP address to set up the bridge, I have seen many posts about maintaining modem gui when in bridge mode - need to route normal comms outside the bridge

[burchbri]

I think you know more about this than any of us!

Oh... thanks very much for just being there! It is really VERY HELPFUL (no irony) to know you don't think I've overlooked something obvious. Once (not if) I sort it out we will all be wiser and I'll document the details as I go.

Isn't there also a 'sharing' tick box which I recall mixed results.

Yes, there is. I wondered what it meant, and also what might happen if I selected "shared" during configuration. The funny thing is that once you apply the config, the selection box is greyed out and preselected to be "disable", and then it cannot be changed.

I wonder if you require a working local IP address to set up the bridge, I have seen many posts about maintaining modem gui when in bridge mode - need to route normal comms outside the bridge

Hmmm. I sort of follow you, but not completely. I'm not that familiar with ethernet bridges (forgotten a lot since they mattered 15 years ago), and less so with linux bridging (messed about with it 5+ years ago before tun support became stable). I see the router actually has four ethernet interfaces and four bridges. Do you mean I should reserve eth0/br0 and use it ONLY for pppoe, then use eth1/br1 ONLY for a routable IP subnet? I've seen a couple of posts that mentioned needing two ethernet cables, but I didn't think they were correct, even if relevant to this issue.

There seem to be several people who have successfully configured adsl pppoe bridging between an adsl router and a wireless ethernet-only router, so I presumed I wasn't doing anything different or difficult. Step 1: config adsl the same way as everyone else; Step 2: substitute my linux server for the wireless router. That is why I thought I had missed something obvious, either with routertech setup, or linux configuration. (That is still what I think!)

Any thoughts, even if wrong, would be appreciated. I'm still stuck.

[mstombs]

I've only ever had pppoa, and therefore my interest in half-bridging (which still works for me!), I thought pppoe full bridge was supposed to be an easy option, but I have noticed that it either 'just works' or is a complete pain! It is possible something is broken in RT firmware for you with pppoe, we did upgrade the pppd daemon (to newer version used by Acorp I recall) and had to rely on external testers because that mode wasn't used by developers. In bridge mode most of the features of RT firmware are bypassed, as responsibility for those functions is passed up the chain - which is actually your interest!

In your first config I assume you were running in 'no-nat' configuration on the modem - for which you give the modem a real Internet IP and it then acts as 'gateway' for your network?

In full-bridge mode I just recommend you give the modem a local IP (default 192.168.1.1) on its lan, so that its value has no interference when you set up the bridge - your Linux PC will then hold the true WAN IP on its ppp0 or equivalent interface. Could you try starting with modem fully reset to defaults and just try minimal config - even the ISP username and password is not required?

The normal issue with Ethernet routers is that access to the modem gui is lost in full bridge mode, to get it back it is necessary to add a local IP to the Router and route/nat comms to the modem over that.

http://www.dd-wrt.com/wiki/index.php/Ac ... figuration

I guess having a completely separate link with another Ethernet card could also work (but overkill!).

This does suggest the normal pppoe bridge works at a level lower than IP, hence your interest in MACs I guess.

[burchbri]

I've only ever had pppoa, and therefore my interest in half-bridging (which still works for me!), I thought pppoe full bridge was supposed to be an easy option, but I have noticed that it either 'just works' or is a complete pain! It is possible something is broken in RT firmware for you with pppoe, we did upgrade the pppd daemon (to newer version used by Acorp I recall) and had to rely on external testers because that mode wasn't used by developers. In bridge mode most of the features of RT firmware are bypassed, as responsibility for those functions is passed up the chain - which is actually your interest!

I agree - most of the firmware and config should not be in use with pppoe bridging. I will follow up on the pppd change you mentioned, as well as looking for the router's other options when running its own pppd (nothing in /etc/ppp/options, but /etc/ppp/pptpd-options might be helpful).

In your first config I assume you were running in 'no-nat' configuration on the modem - for which you give the modem a real Internet IP and it then acts as 'gateway' for your network?

Yes, that is correct. No NAT with the router bridge statically assigned one of my internet subnet addresses. The router pppd is dynamically assigned an address by my ISP, but all my hosts use the static router LAN address as their default route.

In full-bridge mode I just recommend you give the modem a local IP (default 192.168.1.1) on its lan, so that its value has no interference when you set up the bridge - your Linux PC will then hold the true WAN IP on its ppp0 or equivalent interface. Could you try starting with modem fully reset to defaults and just try minimal config - even the ISP username and password is not required?

I did a factory reset as you suggested - no harm in being paranoid!

There is a strange quirk... pppoa and bridge both have a radio button choice for LLC or VC, but this does not exist with pppoe connections. My pppoe works with VPI=0 and VCI=38, but I can't tell whether it is using LLC or VC!!

I deleted the quickstart connection and created a new one. First I tried LLC, with just the usual PADI timeouts. The syslog didn't have anything interesting. Then I deleted that connection and created a new one using VC, but with identical PADI timeouts. In both cases I used VPI=0 and VCI=38. This time syslog showed DSL carrier up, then a series of auto_vcc_default oamPing(n,mm) result(2) messages, where n,mm was 0,32 0,40 0,36 0,38 0,96 0,35 8,35 0,43 0,51 0,59 8,43 8,51 8,59, then DSL carrier down. 0,38 looks a lot like VPI=0 VCI=38, so I am surprised the "result" was still 2. I'm not sure what is going on here, but it looks like something triggered by the pppoe bridge option, even though I explicitly chose VPI/VCI. I wonder whether this behaviour is related to you having to change the pppd version.

The normal issue with Ethernet routers is that access to the modem gui is lost in full bridge mode, to get it back it is necessary to add a local IP to the Router and route/nat comms to the modem over that.

http://www.dd-wrt.com/wiki/index.php/Ac ... figuration

I guess having a completely separate link with another Ethernet card could also work (but overkill!).

At the moment, I don't seem to have problems with telnet and gui access to the router on the same eth0 interface as I'm trying to use for pppoe bridging, but, of course, the pppoe big isn't working!

This does suggest the normal pppoe bridge works at a level lower than IP, hence your interest in MACs I guess.

Yes, the ethernet frames have different type fields in their headers: tcp/ip, pppoe discovery and pppoe session. All three types of frame will carry the same source and destination MAC's, but the "bridge logic" will have to handle these types differently. I still think I need to do some work on bridge filters, but no-one else has said they are relevant. I am still nervous of being too clever in case I've missed something simple. (I have a usb-console adapter, so if necessary I could dispense with tcp/ip completely and monitor via the console session).

I wish I knew what the "enable bridge filter management" check box is supposed to do.

[burchbri]

Yes, the ethernet frames have different type fields in their headers: tcp/ip, pppoe discovery and pppoe session. All three types of frame will carry the same source and destination MAC's, but the "bridge logic" will have to handle these types differently. I still think I need to do some work on bridge filters, but no-one else has said they are relevant. I am still nervous of being too clever in case I've missed something simple. (I have a usb-console adapter, so if necessary I could dispense with tcp/ip completely and monitor via the console session).

I have just blown the dust off an old book and discovered that I was not quite correct. The ethernet 802.3 frame header does not carry the type field... it is in the payload within the 802.2 LLC header. I wonder whether that is telling me the pppoe bridge connection should use LLC? (I've found posts that said it should use VC)

[burchbri]

I've done some more tests and comparisons. I think I've found some differences, but don't know enough to understand whether they are significant. I could post a load of output from both routers running /usr/local/bin/diagnostics.sh - it would have the advantage of missing nothing, but would require someone to spend ages comparing them. I'll start on the brief-but-hopefully-trustworthy path!

The working pppd-ppppoe system has both a ppp0 and nas0 interface. Right at the very end of dmesg, I see...

Code: Select all

DSL in Sync
Default Asymmetric MTU for nas0 1500
atm_connect (TX: cl 1,bw 0-0,sdu 1524; RX: cl 1,bw 0-0,sdu 1524,AAL 5)

I assume the hardware driver tiatm listed in /proc/modules creates this interface once it has established the DSL link.

I also see the nas0 interface used in the pppd command line. As expected, nas0 never gets associated with an IP address - pppd creates a new interface ppp0 once it has established the pppoe connection to my ISP. The point-to-point address supplied by my ISP's DHCP server is allocated to the ppp0 interface, and appropriate routes are established for my static subnet.

Things ought to be somewhat different for the router running the pppoe bridge, but not too much. The end of dmesg looks like this:

Code: Select all

DSL in Sync
Bridge Multicasting for br0 is now Enabled

A nas0 interface is never created, but then perhaps it isn't needed in bridge mode? I expected to see nas0 created and added to br0, but brctl showmacs br0 only lists eth0/1/2/3.

Also, the two solwise routers are running the same version of the firmware, but different images because they have different hadware platforms. I am suspicious because diagnostics.sh indicates they are running different versions of tiatm. Here is an extract for the production router:

Code: Select all

Linux version 2.4.17_mvl21-malta-mips_fp_le (developers at RouterTech dot Org) #1 Mon Jan 30 22:27:28 GMT 2012

BUILD=RouterTech_3.6.0D_20120130_2.97
VERSION=3.6.0D-RouterTech-4P-PSBL
BOARD=AR7RD
TARGET=psbl
FSSTAMP=20120130223011
ROHS=0

Linux OS DSL-PSPOhioL version 4.5.0.5 Best and Final on BasePSP Version 5.7.6.12  Jan 30 2012 22:28:29 
Avalanche SOC Version: 0x11002b operating in cached, write back, write allocate mode
Cpu Frequency:211 MHZ
System Bus frequency: 105 MHZ

Core Logic version: 3.6.0D
Texas Instruments CPMAC driver version: 1.5
Texas Instruments CPMAC HAL version: CPMAC 01.07.08 Jan 30 2012 22:27:39
ATM Driver version:[7.05.01.00]
DSL HAL version: [7.05.01.00]
DSP Datapump version: [7.05.01.00] Annex A
SAR HAL version: [01.07.2c]
PDSP Firmware version:[0.54]
Chipset ID: [Ohio250(7200/7100A2)]

The development router configured in bridge mode looks like this:

Code: Select all

Linux version 2.4.17_mvl21-malta-mips_fp_le (developers at RouterTech dot Org) #370 Mon Jan 30 23:17:55 GMT 2012
BUILD=RouterTech_3.7.1B_1350A_20120130_2.97_AR7WRD_psbl
VERSION=1350A_20120130
BOARD=AR7WRD
TARGET=psbl
FSSTAMP=20120130232217
ROHS=1

Linux OS DSL-PSP 5.2.1.1 on DEV_BasePSP7.4.4.24_Patch compiled at Jan 30 2012 23:18:57
Avalanche SOC Version: 0x11002b
Operating in cached, write back, write allocate mode
CPU Frequency: 211968000 Hz
System Bus frequency: 105984000 Hz
VBUS frequency: 52992000 Hz

Core Logic version: 3.7.1B
Texas Instruments : CPMAC Linux DDA version 1.9
Texas Instruments : CPMAC DDC version 0.3
ATM Driver version:[7.01.00.10]
DSL HAL version: [7.01.00.08]
DSP Datapump version: [7.01.01.00] Annex A
SAR HAL version: [01.07.2c]
PDSP Firmware version:[0.54]
Chipset ID: [Ohio250(7200/7100A2)]

Just to repeat, the non-wireless SAR-600ER router is my production system, currently running an internal pppd-pppoe. The second, wireless (AP disabled) SAR-605EW is configured to run in bridge mode. I am very reluctant to try the production router in bridge mode until I can prove the development router works as desired. In any case, it looks to me as if the later version of Core Logic is running on the dev router, and the latest ATM driver is on the prod router!

Does it look as if I have the latest and correct 2.97 images on both routers, or have I done something wrong? If the images are as you would expect, why are they shipped with different versions of Core Logic? Why don't they have the same version of the ATM driver when they have the same DSL hardware?

[mstombs]

The 1350A router has a different 'core logic version' and different kernel/drivers than the older non-wireless router. We were not able to get the 7.05 drivers to work in a 1350 firmware because Acorp never released the appropriate GPL sourcecode. What you see is correct.

[burchbri]

The 1350A router has a different 'core logic version' and different kernel/drivers than the older non-wireless router. We were not able to get the 7.05 drivers to work in a 1350 firmware because Acorp never released the appropriate GPL sourcecode. What you see is correct.

Thanks very much for confirming the situation. It is good news for everyone, but you can't blame me for hoping it was the reason!

What do you feel about the "missing" nas0 interface in bridge mode? I realise the ATM device is managed by a TI closed-source driver, but I am having trouble imagining how linux software could achieve LAN-WAN bridging without instantiating a visible interface - it is possible, but very perverse.

I will schedule some downtime for my production router, make some paranoid backups, then reconfigure it in bridge mode to see whether anything changes under the different core logic and driver.

[thechief]

What do you feel about the "missing" nas0 interface in bridge mode? I realise the ATM device is managed by a TI closed-source driver, but I am having trouble imagining how linux software could achieve LAN-WAN bridging without instantiating a visible interface - it is possible, but very perverse.

I am no networking guru, but why would the nas0 exist in bridge mode? It should only exist in the router that is actually doing the WAN connection.

[burchbri]

What do you feel about the "missing" nas0 interface in bridge mode? I realise the ATM device is managed by a TI closed-source driver, but I am having trouble imagining how linux software could achieve LAN-WAN bridging without instantiating a visible interface - it is possible, but very perverse.

I am no networking guru, but why would the nas0 exist in bridge mode? It should only exist in the router that is actually doing the WAN connection.

I set up the test (painful). I configured my non-wireless SAR-600ER as a bridge. As soon as it rebooted, I was VERY surprised and pleased to see the following:

Code: Select all

~ # ifconfig
br0       Link encap:Ethernet  HWaddr 00:30:0A:7C:7C:8A  
          inet addr:217.154.193.220  Bcast:217.154.193.223  Mask:255.255.255.240
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2012 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1857 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:96025 (93.7 KiB)  TX bytes:241045 (235.3 KiB)

br1       Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

br2       Link encap:Ethernet  HWaddr 00:00:00:00:00:00  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:30:0A:7C:7C:8A  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:125579 (122.6 KiB)  TX bytes:242809 (237.1 KiB)

eth1      Link encap:Ethernet  HWaddr 82:30:0A:7C:7C:8A  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:125579 (122.6 KiB)  TX bytes:242809 (237.1 KiB)

eth2      Link encap:Ethernet  HWaddr 92:30:0A:7C:7C:8A  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:125579 (122.6 KiB)  TX bytes:242809 (237.1 KiB)

eth3      Link encap:Ethernet  HWaddr A2:30:0A:7C:7C:8A  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2021 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:125579 (122.6 KiB)  TX bytes:242809 (237.1 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:12 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:1425 (1.3 KiB)  TX bytes:1425 (1.3 KiB)

nas0      Link encap:Ethernet  HWaddr 00:30:0A:7C:7C:8B  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:29 dropped:0 overruns:0 frame:0
          TX packets:122 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:0 (0.0 B)  TX bytes:8378 (8.1 KiB)

i.e. the nas0 interface had been created.

I also saw this:

Code: Select all

~ # brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00300a7c7c8a       no              eth0
                                                        eth1
                                                        eth2
                                                        eth3
                                                        nas0
br1             8000.000000000000       no              
br2             8000.000000000000       no              
~ # brctl showmacs br0
port no mac addr                is local?       ageing timer
  1     00:30:0a:7c:7c:8a       yes                0.00
  5     00:30:0a:7c:7c:8b       yes                0.00
  2     82:30:0a:7c:7c:8a       yes                0.00
  3     92:30:0a:7c:7c:8a       yes                0.00
  4     a2:30:0a:7c:7c:8a       yes                0.00
  1     b8:ac:6f:6a:b4:ad       no                 0.03
~ # 

i.e. the nas0 interface had been added to the br0 bridge (I don't currently know what br0:5 is, but it's MAC is 0x01 bigger than nas0).

This makes a lot of sense to me: once the nas0 interface exists and has been added to the bridge, all IEEE 802.3 frames, including the PAD0 broadcast, will pass transparently through the router in both directions, between the eth0 and nas0 interfaces.

I then tried to run pppd-pppoe from my linux system. Although it didn't connect perfectly, it went a very long way into the dialog. Most notably, a response to the PADI broadcast came back from the pppoe server:

Code: Select all

May 20 13:21:36 bacchus pppd[21383]: Plugin rp-pppoe.so loaded.
May 20 13:21:36 bacchus pppd[21385]: pppd 2.4.5 started by root, uid 0
May 20 13:21:36 bacchus pppd[21385]: Interface eth0 has MTU of 1440 -- should be at least 1500.
May 20 13:21:36 bacchus pppd[21385]: This may cause serious connection problems.
May 20 13:21:36 bacchus pppd[21385]: Send PPPOE Discovery V1T1 PADI session 0x0 length 12
May 20 13:21:36 bacchus pppd[21385]:  dst ff:ff:ff:ff:ff:ff  src b8:ac:6f:6a:b4:ad
May 20 13:21:36 bacchus pppd[21385]:  [service-name] [host-uniq  89 53 00 00]
May 20 13:21:36 bacchus pppd[21385]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 43
May 20 13:21:36 bacchus pppd[21385]:  dst b8:ac:6f:6a:b4:ad  src 0:30:88:0:0:4
May 20 13:21:36 bacchus pppd[21385]:  [host-uniq  89 53 00 00] [AC-name bras-red2.bs-B20C4110500109] [service-name]
May 20 13:21:36 bacchus pppd[21385]: Send PPPOE Discovery V1T1 PADR session 0x0 length 12
May 20 13:21:36 bacchus pppd[21385]:  dst 0:30:88:0:0:4  src b8:ac:6f:6a:b4:ad
May 20 13:21:36 bacchus pppd[21385]:  [service-name] [host-uniq  89 53 00 00]
May 20 13:21:36 bacchus pppd[21385]: Recv PPPOE Discovery V1T1 PADS session 0x314 length 43
May 20 13:21:36 bacchus pppd[21385]:  dst b8:ac:6f:6a:b4:ad  src 0:30:88:0:0:4
May 20 13:21:36 bacchus pppd[21385]:  [service-name] [host-uniq  89 53 00 00] [AC-name bras-red2.bs-B20C4110500109]
May 20 13:21:36 bacchus pppd[21385]: PADS: Service-Name: ''
May 20 13:21:36 bacchus pppd[21385]: PPP session is 788
May 20 13:21:36 bacchus kernel: [15638.535132] NET: Registered protocol family 24
May 20 13:21:36 bacchus pppd[21385]: Connected to 00:30:88:00:00:04 via interface eth0
May 20 13:21:36 bacchus pppd[21385]: using channel 1
May 20 13:21:36 bacchus pppd[21385]: Using interface ppp0
May 20 13:21:36 bacchus pppd[21385]: Connect: ppp0 <--> eth0
May 20 13:21:36 bacchus pppd[21385]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x6237841c>]
..etc..

Note: the MAC addresses of the frames correspond to my linux firewall's eth0 interface, and my ISP's pppoe interface. The bridge router's eth0 and nas0 MACs do not appear in the traffic because they are components of a transparent bridge.

It looks pretty conclusive to me: the 2.97 AR7WRD combination of Core Logic 3.7.1B and TI ATM Driver 7.01.nn does not work in bridge mode, but the AR7RD combination 3.6.0D and 7.05.nn works fine.

I fully understand the developers will have plenty of interesting and important things to work on, so I doubt whether this problem will be considered worth fixing in a hurry. I will spend the next couple of days flipping my SAR-605EW (wireless) into "production" pppoe mode, then reconfigure the SAR-600ER as a bridge. That will allow me to get on with my external firewall development.

[thechief]

Well, you've lost me (I did say that I was no networking guru). I have always thought that ppp0+br0 = pppoa, and that ppp0+nas0 = pppoe. I don't think that I've ever seen br0+nas0, so I have no idea what that means.

You are right that finding a fix to this problem would not be high on our list of priorities, especially as there is absolutely nothing that we can do about the core logic and tiatm. If those are the problem, then it will never be fixed. If the problem is how pppd interacts with one or more of them, then it might be fixed one day, if one understood what the problematic interaction actually is, and how to fix it without breaking anything else.

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.

[burchbri]

Well, you've lost me (I did say that I was no networking guru). I have always thought that ppp0+br0 = pppoa, and that ppp0+nas0 = pppoe. I don't think that I've ever seen br0+nas0, so I have no idea what that means.

You are basically correct as far as running pppd inside the same router. The big difference is that I am using a third scenario: when the router connection is configured in bridge mode, the pppd is outside the router. In fact, it would be more accurate to say the router is not being used as a router (i.e. level 3) at all - only as a (level 2) bridge. We need pppoe (a strange invention of a protocol) to make this possible, because a bridge normally acts as an interface between two lans and doesn't change the frame contents. The sneaky bit is the use of pppoe, which simulates an ethernet lan over the DSL-and-ATM WAN. Our bridge can then legitimately and transparently transport ethernet frames (source and dest MACs, as well as the entire payload) between one lan segment (eth0) and another (nas0). Wierd but true.

When the router is running its own internal pppd-pppoe (your second scenario), there is no need for lan bridging because the on-board pppd can directly access the nas0 interface as a local device. This confirms my original suspicion that bridge mode was failing because there wasn't an interface to represent the DSL link.

You are right that finding a fix to this problem would not be high on our list of priorities, especially as there is absolutely nothing that we can do about the core logic and tiatm. If those are the problem, then it will never be fixed. If the problem is how pppd interacts with one or more of them, then it might be fixed one day, if one understood what the problematic interaction actually is, and how to fix it without breaking anything else.

pppd is not running on the router in bridge mode, so in my simple view the "problem" lies entirely within those two closed-source components. I read your warnings about the potential pain of trying to home-build the firmware. However, would there be any mileage in me learning to do a build, and then substituting the newer binary tiatm (with or without the corresponding core logic)? Would such an endeavor be doomed from the outset?

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...

[thechief]

However, would there be any mileage in me learning to do a build, and then substituting the newer binary tiatm (with or without the corresponding core logic)? Would such an endeavor be doomed from the outset?

If you can build linux, then you can build the firmware. However, substituting the binary tiatm would be doomed to failure. You would need to have the correct binary tiatm and core logic and the corresponding kernel sources (and there are zillions of different kernel sources for AR7 firmwares out there). Get one wrong (usually kernel sources not matching tiatm), and the core logic would always segfault when trying to load tiatm. Believe me, we have tried for several years to get around this problem as far as 1350A wireless firmwares are concerned. Life is too short, and we gave up long ago.

[burchbri]

However, would there be any mileage in me learning to do a build, and then substituting the newer binary tiatm (with or without the corresponding core logic)? Would such an endeavor be doomed from the outset?

If you can build linux, then you can build the firmware. However, substituting the binary tiatm would be doomed to failure. You would need to have the correct binary tiatm and core logic and the corresponding kernel sources (and there are zillions of different kernel sources for AR7 firmwares out there). Get one wrong (usually kernel sources not matching tiatm), and the core logic would always segfault when trying to load tiatm. Believe me, we have tried for several years to get around this problem as far as 1350A wireless firmwares are concerned. Life is too short, and we gave up long ago.

Yeah, I'm getting quite good at building custom linux kernels, but I haven't done any cross-compiled ones. I've also experienced the long work followed by an unbootable system too many times, hence my question! I gratefully accept your advice. I'll work on "plan B" aka wireless router with no wireless support... but I won't be asking the router upgrade checker what it thinks about the idea!!!