kernel PPPoE woes - BSD

This is a discussion on kernel PPPoE woes - BSD ; I'm this close to installing a fresh 3.8 box as a new edge box, but ran into a snag with the kernel space pppoe stuff. Userland pppoe works fine (I tested that just to be sure this box was sane). ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: kernel PPPoE woes

  1. kernel PPPoE woes

    I'm this close to installing a fresh 3.8 box as a new edge box, but ran
    into a snag with the kernel space pppoe stuff. Userland pppoe works
    fine (I tested that just to be sure this box was sane).

    I've followed the instructions from pppoe(4) and created a default
    hostname.pppoe0 device. I have a static IP address, and my ISP always
    gives me the same "gateway" (ppp refers to this as HISADDR) though I
    usually just accept what they give me. It's not entirely clear (to me)
    from the manual if the kernel pppoe supports a hard-coded IP for one
    side and a wildcard for the other.

    However, even if I use the wildcard 0.0.0.0 and 0.0.0.1 addresses
    [apropos of sppp(4), I assume] I cannot get a route. spppcontrol -v
    pppoe0 is claiming it is in phase establish. Of course, the routing
    tables have the wildcard values in them, though I assume that the pppoe0
    devices knows what to do with those.

    However, the "/sbin/ifconfig \$if inet 0.0.0.0 0.0.0.1 netmask
    0xffffffff" command is failing with an error or warning (sorry, had to
    down the box to put the original box online) about not being about to do
    something with "0.0.0.0/0".

    Speaking of which, I'm completely confused by a route table that has

    default 0.0.0.1
    0.0.0.1 0.0.0.0

    in it. I'm not talking about the wildcards so much, but why we have a
    route that appears to recursively run back in itself. Evidently, I am
    not getting the logic behind that ifconfig line.

    It's no surprise to me that things like traceroute simply hit the
    external device and go nowhere.

    A review of the mail list archives and some Google hits of interest have
    not yielded anyone having the exact same problem. I did read one
    interesting tid-bit about ISPs not providing the right stuff for the
    kernel pppoe under some circumstances (i.e., when one has an IP address
    associated with a myauthname), and a mention of ifstated in -current
    being a potential solution. I have no idea if or why this applies to my
    current problem.

    I just have no idea what to look at next. Even if I tweak the route
    tables by hand (with values I see I'm getting from debugging the pppoe0
    device during PPPoE negotiation) I still get no joy. It occurs to me
    just now I should have put tcpdump on the external device (I assume
    pppoe0) to see what, if anything, was going on there.

    I'd like to use the kernel pppoe if possible, since userland requires so
    much cruft when starting the net to make sure it's up.

  2. Re: kernel PPPoE woes

    void * clvrmnky() wrote:
    > I'm this close to installing a fresh 3.8 box as a new edge box, but ran
    > into a snag with the kernel space pppoe stuff. Userland pppoe works
    > fine (I tested that just to be sure this box was sane).
    >
    > I've followed the instructions from pppoe(4) and created a default
    > hostname.pppoe0 device. I have a static IP address, and my ISP always
    > gives me the same "gateway" (ppp refers to this as HISADDR) though I
    > usually just accept what they give me. It's not entirely clear (to me)
    > from the manual if the kernel pppoe supports a hard-coded IP for one
    > side and a wildcard for the other.
    >

    I did find
    which
    indicates that something like this is acceptable:

    pppoedev vr0
    !/usr/sbin/spppcontrol \$if myauthproto=chap \
    myauthname=YOURNAME \
    myauthkey=YOURPASSWORD
    !/sbin/ifconfig \$if inet XXX.XXX.XXX.XXX 0.0.0.1 \
    netmask 0xffffffff
    !/sbin/route add default 0.0.0.1
    up

    That is, the static IP XXX.XXX.XXX.XXX works just fine with magic remote
    IP of 0.0.0.1.

    In fact, this is nearly identical to my hostname.if file for pppoe0
    (including the vr device I associate with the pppoe0 device).

    So, I just have to figure out why I can't get anywhere with this default
    route.

  3. Re: kernel PPPoE woes

    > However, even if I use the wildcard 0.0.0.0 and 0.0.0.1 addresses
    > [apropos of sppp(4), I assume] I cannot get a route. spppcontrol -v
    > pppoe0 is claiming it is in phase establish. Of course, the routing
    > tables have the wildcard values in them, though I assume that the pppoe0
    > devices knows what to do with those.
    >

    Hrmph. What I'm getting from the Fine Manual is that I probably want to
    be in phase "network", and that the -v option to spppcontrol should be
    showing this.

    Poking around in if_sppp.h seems to indicate that this device is not
    completely ready until pp_phase >= PHASE_AUTHENTICATE.

    Back to the drawing board.

  4. Re: kernel PPPoE woes

    "void * clvrmnky()" wrote in message
    news:HSjUf.15451$43.9844@nnrp.ca.mci.com!nnrp1.uun et.ca...
    > Hrmph. What I'm getting from the Fine Manual is that I probably want to
    > be in phase "network", and that the -v option to spppcontrol should be
    > showing this.
    >
    > Poking around in if_sppp.h seems to indicate that this device is not
    > completely ready until pp_phase >= PHASE_AUTHENTICATE.
    >
    > Back to the drawing board.


    Heh .

    I remember having similar (ish) weirdness (but over dial-up) trying to get
    Demon (in the UK) to play nice a few years ago. ISTR I gave up and changed
    ISP .

    Good luck!

    Steve
    http://www.fivetrees.com



  5. Re: kernel PPPoE woes

    void * clvrmnky() wrote:
    >> However, even if I use the wildcard 0.0.0.0 and 0.0.0.1 addresses
    >> [apropos of sppp(4), I assume] I cannot get a route. spppcontrol -v
    >> pppoe0 is claiming it is in phase establish. Of course, the routing
    >> tables have the wildcard values in them, though I assume that the
    >> pppoe0 devices knows what to do with those.
    >>

    > Hrmph. What I'm getting from the Fine Manual is that I probably want to
    > be in phase "network", and that the -v option to spppcontrol should be
    > showing this.
    >
    > Poking around in if_sppp.h seems to indicate that this device is not
    > completely ready until pp_phase >= PHASE_AUTHENTICATE.
    >
    > Back to the drawing board.


    In the spirit of completeness, here is the entire story.

    The kernel space pppoe stuff seems to work. It took me a bit, but I
    narrowed down the various problems to:

    1. Shell meta characters have to be escaped three times to survive being
    picked up by netstart and passed to eval. As soon as I realized what
    netstart actually did with the contents of the hostname.if files (and
    though about what "\$if" in the hostname.if file means to the script) I
    figure that out. The old "three backslashes" trick worked a treat.

    Yes, I know it's stupid to have these sorts of things in myauthkey. I
    just picked a bunch of ASCII characters, and never considered how the
    various processes on a Unix box might process them.

    2. I have to use the "link1" option to ifconfig for the sppp device.
    I'm not entirely sure why this is so, as I don't fully understand what
    the "lower layer" in this case is. I'm not sure if this is a bug or a
    feature, but if I disconnect the DSL modem from the RJ-11 and force it
    to retrain I don't see any notice of this in the OBSD logs.

    3. Similar to this problem report
    I
    cannot specify my static IP address. It appears that my ISP knows it
    wants to give me an IP associated with myauthname, and will fail even if
    I ask for the same one.

    I suppose I can live with using the wildcards, as my ISP always gives me
    the same values (it's what I pay them for) but I will consider using
    ifstated to check the device when it comes up to make sure it matches my
    expected IP address. I'm not sure what I can do with this information,
    but at least I can send a notification to the syslog or email an admin.

    Perhaps ifstated can be tweaked to see if any of the devices go into a
    non-up state as a result of modem failure, which will alleviate any
    problems I discover with (2) above. SPPP(4) has a fair amount of
    information about diagnostics, as well.

    I wonder if it might be worthwhile forwarding this synopsis (with
    connect logs) to misc@?

+ Reply to Thread