Re: ADSL PPPoA using a bridged ADSL router?

On Mon, 10 Oct 2005, Ian Rawlings announced authoritatively:
> On 2005-10-10, Nix <nix-razor-pit@xxxxxxxxxxxxx> wrote:
>
>> I wrote a script that autoreboots it via the web interface whenever the
>> upstream gateway goes gaga for too long. (It exponentially backs off
>> reconnect attempts, because sometimes something really *is* wrong with
>> BT.)
>
> If it needs a reboot to restart it, then being as it's a linux box
> it's simple for it to restart itself, one of the advantages of not
> using a router!

Well, that's a firmware bug in that specific bit of Conexant hardware.
The corresponding bug on an ADSL card would probably require a physical
poweroff to fix :(

> If they fall off the network it's plug-pulling time,
> and one of my routers doesn't even like that, after a power outage (I
> live out in the countryside) the router doesn't come back up until I
> go downstairs and unplug it again.... Total rubbish, I can't believe
> they can sell this trash.

I can. The underlying firmware (running on VxWorks, typically) is
written by mostly Taiwanese companies two or three bulk purchases away
from the mere consumer. They don't care if the resulting code doesn't
work unless it fails to work so badly that the complaints trickle
all the way up to them.

(But the same is true of ADSL PCI cards.)

> I can do better myself, I'm sure of that,
> hence the linux box with ADSL route that I'm trying.

Errr, I'm using a `Linux box with ADSL' route, it's just that the Linux
box sees the ADSL as Ethernet, a nice long-term-standardized protocol
whose interface cards have open-sourced drivers.

>>>> (Of course, it spends its entire time in that mode.)
>>>
>>> Aren't computers fun.
>>
>> No, not in the refusing-to-reconnect mode; in the half-bridging mode :)
>
> Ah right, perhaps too much cynicism from me there ;-)

*That* is impossible.

>> The thing is that ADSL routers are *external hardware*; crap or not their
>> behaviour *will not change* no matter what happens to the Linux
>> kernel.
>
> Yes, I'm not intending to change the linux kernel on the ADSL card box
> much, it's going to be doing ADSL, firewalling, port forwarding,
> portscanning and maybe-just-maybe running a nessus daemon (but
> probably not).

And what do you do when there's a security hole in that kernel that
requires an upgrade, but your ADSL router company is no longer
maintaining the binary-only driver?

What do you do if you want a feature in some newer kernel and the
binary-only driver doesn't work with that kernel?

With an Ethernet card I have none of those problems. :)

>> And the rate the kernel is advancing at the moment there's no way I'd
>> do *anything* with binary-only modules on it (and yes, I do need 2.6;
>> I'm using libcrypto encrypted filesystems, SELinux, user-mode-linux,
>> ebtables bridging firewalls, digsig, and the security module
>> stacker).
>
> I intend to do at least SELinux on other machines, I am setting up a
> dual firewall design, the simple ADSL firewall connected to a DMZ on
> which some hosts will be running SELinux at least, and a second
> firewall also on the DMZ leading into my home network. In theory this
> allows a compromised DMZ host to snoop and intercept traffic from my
> internal LAN but the risk is relatively low given the type of traffic
> to/from the internal LAN, but I am considering plugging the internal
> firewall directly into the external firewall. It might sound
> excessive but I want the external firewall to be as simple as
> possible.

I dunno, my configuration has a bridged firewall with no userspace
running in a user-mode-linux instance, followed by another UML instance
with the network services in it, and then *another* firewall between
that and the host / internal network. So I'm pretty much doing what
you suggested, but on a single machine.

(The UML in the middle is running on the encrypted filesystem,
using digsig, SELinux, the stacking module, and ProPolice to boot.
One of these days I'll recompile it to use FORTIFY_SOURCE as well,
probably after GCC 4.1 is out.)

>> In fact, there's no way I'd do anything with binary-only modules no
>> matter what. Some things come with too high a cost, and the inability to
>> have effectively debuggable kernels is one such cost.
>
> I'm not keen on it either, but the ability to do some quite serious
> debugging and monitoring of the network on the first host that gets
> the packets wins it for me. Routers generally don't give you much
> help unless you get a decent one, but then I'm talking about a router
> that is routing, not running in half-bridge mode.

Well, yes, they're very annoying if you want lots of info. That's why
I don't use routers in all-singing-all-dancing mode: they should get
out of the way and let me do the packet-shuffling.

Using half-bridging gives you everything other than detailed
ADSL/PPPoA-layer packet info, and to be honest if you need *that* you're
a telco engineer and are probably using your own breadboard rather than
an ADSL router anyway :)

>> That last is a good idea. My point is that even a horrible thing like
>> the Dabs Value ADSL router is not actually that crap: in half-bridging
>> mode it has only one bug (I can ignore the fact that port forwarding
>> doesn't work and NAT is wobbly because that code never gets run), and
>> that bug is trivial to work around, for values of `trivial' that
>> include a 330-line Perl script.
>
> It'll be on the list of devices to get if the ADSL card doesn't work
> out. What is the bug in half-bridge mode, just NAT and forwarding
> (which I won't use either)?

The half-bridging bug is that when the line drops it never reconnects,
but keeps trying and getting poorly-described `errors'; only rebooting
the router makes it happy again. My ISP (Zetnet) drops the line every 24
hours as a simple way to reduce the number of places they need to check
to see if you haven't been paying your bills; when I got my ADSL router
that interval was 12 hours, so the link died every half-day until I
wrote that script. Writing it was correspondingly important to me :)

I've posted the Perl script here in the past but am happy to provide it
again. It *will* need adjustment, for upstream router addresses and
router passwords and local static IP address and probably also because
I use ip(8) to configure the network, so you might need to change
it to use the odious ifconfig/route pair instead.

--
`Next: FEMA neglects to take into account the possibility of
fire in Old Balsawood Town (currently in its fifth year of drought
and home of the General Grant Home for Compulsive Arsonists).'
--- James Nicoll
.

Relevant Pages

  • Re: Security for linux box
    ... > modem that is configurable to be a router. ... You will need some kind of firewall in place certainly. ... up the "iptables" on the server itself and connect directly to the ADSL, ... your server on the other. ...
    (comp.os.linux.security)
  • Re: ADSL PPPoA using a bridged ADSL router?
    ... live out in the countryside) the router doesn't come back up until I ... I'm not intending to change the linux kernel on the ADSL card box ... dual firewall design, the simple ADSL firewall connected to a DMZ on ...
    (uk.comp.os.linux)
  • Re: Ethernet config for net access query
    ... schedule made a call on the router, and the internal speaker was loud ... As Graham said its worth looking at a router, or may ponder if ADSL ... have to then enable the firewall rules to let you in to manage them to. ... Basically put one of those on an ADSL connection, ...
    (uk.comp.sys.mac)
  • Re: IE Routing Problem
    ... > We have ADSL. ... > MTU value in the registry, ... that this is the setting in our firewall as well ... The router will accomodate the modem. ...
    (microsoft.public.win2000.dns)
  • Re: IE Routing Problem
    ... > We have ADSL. ... > MTU value in the registry, ... that this is the setting in our firewall as well ... The router will accomodate the modem. ...
    (microsoft.public.win2000.networking)