1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

PADI packets error

Discussion in 'Tomato Firmware' started by QSxx, Feb 1, 2014.

  1. QSxx

    QSxx LI Guru Member

    Hello folks,

    here I go again asking for help. Recently i've acquired Gigaset SX 763 router/modem for my internet connectivity needs. I've put SX in bridge mode and RT-N16 (with Toastman's latest VLAN build) is handling PPPoE. It all works very well (since SX appears to have a VERY good modem) except for a little flaw. RT-N appears to be causing SX to act strange. Here's the log from SX

    Code:
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:7b:c0:86:80 on interface nas1 not permitted
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:83:a1:81:80 on interface nas1 not permitted
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:7a:43:87:42 on interface nas1 not permitted
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:7c:42:84:00 on interface nas1 not permitted
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:83:a0:82:c0 on interface nas1 not permitted
    Feb  1 01:03:12 Err  pppoe-relay[499]: PADI packet from 02:01:85:c0:83:4d on interface nas1 not permitted
    Feb  1 01:03:13 Err  pppoe-relay[499]: PADI packet from 02:01:89:80:86:80 on interface nas1 not permitted
    Feb  1 01:03:13 Err  pppoe-relay[499]: PADI packet from 02:01:7e:43:8b:00 on interface nas1 not permitted
    Feb  1 01:03:13 Err  pppoe-relay[499]: PADI packet from 02:01:7b:00:81:41 on interface nas1 not permitted
    Feb  1 01:03:13 Err  pppoe-relay[499]: PADI packet from 02:01:7b:60:83:c0 on interface nas1 not permitted
    Feb  1 01:03:14 Err  pppoe-relay[499]: PADI packet from 02:01:c2:02:05:40 on interface nas1 not permitted
    Feb  1 01:03:14 Err  pppoe-relay[499]: PADI packet from 02:01:7d:61:05:c2 on interface nas1 not permitted
    Feb  1 01:03:14 Err  pppoe-relay[499]: PADI packet from 02:01:85:23:04:01 on interface nas1 not permitted
    Feb  1 01:03:14 Err  pppoe-relay[499]: PADI packet from 02:01:7e:c3:8c:01 on interface nas1 not permitted
    Feb  1 01:03:14 Err  pppoe-relay[499]: PADI packet from 02:01:7c:23:00:40 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:7b:c0:86:80 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:78:06:04:81 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:7a:21:86:02 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:7e:c1:81:02 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:89:60:80:00 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:c2:02:05:40 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:7a:43:87:42 on interface nas1 not permitted
    Feb  1 01:03:15 Err  pppoe-relay[499]: PADI packet from 02:01:7c:42:84:00 on interface nas1 not permitted
    Now all of theese MACs are virtual and probably generated for the need of pppoe-relay. Trouble is, it only happens when SX is paired with RT-N. What also puzzles me is frequency of PADI packets... multiple times per second...

    So... anyone with deeper knowledge of pppoe around? Any way to rectify this situation? Is it a bug in Tomato or just poorly written pppoe relay?

    (P.S. If i leave logging on, SX log will get saturated and router will slow do to crawl - reboot saves the day but it's not the point...)
     
  2. koitsu

    koitsu Network Guru Member

    As always (has come up many times over the years), I recommend people use devices that can do the PPPoE encap/decap natively and not have the router do it. Many ADSL bridges (which use PPPoE) can do this; basically they store the PPPoE authentication bits + do the encap/decap, but pass DHCP along directly and give an actual Internet IP to the attached device. Meaning: the bridge does nothing other than handle the PPP layer, and your (Tomato) router gets an actual Internet IP on its WAN interface. I used this method for years with both SBC (now AT&T) and Covad.

    The reason I recommend this methodology is that any device your ISP gives you is what you're supposed to use. Other brands, models, revisions, etc. are not guaranteed to work with the equipment on the ISPs side. So punting the PPPoE layer off to the router is something I do not generally agree with; there's no promise things will work correctly, case in point.

    I could be wrong (someone will need to double check), but the pppd code (which I believe is pppoe-relay?) is here:

    http://repo.or.cz/w/tomato.git/tree/Toastman-RT-N:/release/src/router/pppd

    You would need to bring this up with the author/maintainers of that software, as it's third-party.

    I cannot help past this point.
     
    QSxx likes this.
  3. QSxx

    QSxx LI Guru Member

    As always, thank you koitsu...

    If I had a way to do this on RT-N, I would since it would solve alot of problems for me. I even toyed with the idea of using modem as, well, modem and letting Tomato do pure router thing but I don't have necessary knowledge or experience to acomplish that task.

    I can't get rid of the modem either (or replace it with something else) as my ISP does triple-play as they like to call it... TV, VoIP and net over one copper pair. VLAN stuff as you probably guessed (they managed to push remote management and one more unindentified link - probably conduit for firmware upgrade). I have no choice but to use what I'm provided with.

    So basically, only thing I can do for now is use Tomato as glorified access point (SX provides that function too, but RT-N antennae are much stronger)...

    About bringing it up with maintainers... well, that's the point of this thread... hopefully something will happen.
     
  4. koitsu

    koitsu Network Guru Member

    Sorry I wasn't clear: the maintainers of pppd do not lurk on this forum. The contacts are available per pppd's own documentation, see near bottom:

    http://repo.or.cz/w/tomato.git/blob/Toastman-RT-N:/release/src/router/pppd/README

    Or otherwise here: http://ppp.samba.org/

    TomatoUSB is using pppd 2.4.5, which is the latest "stable" version. However, their own website is confusing:

    - The official release repository shows 2.4.5 is the latest version: ftp://ftp.samba.org/pub/ppp/
    - ...but the link on their home page goes to a completely different README that says 2.4.6 is the latest (and it isn't available in the release repo): http://ppp.samba.org/ftp/unpacked/ppp/README
    - After doing some obvious URL hacking, the 2.4.6 release is here, dated January 2014: http://ppp.samba.org/ftp/unpacked/ppp/
    - ...but there is no ChangeLog that documents what got changed. The README for 2.4.6 just says "Several bug fixes" and a couple enhancements; "several bug fixes" is vague as hell.

    You would need to discuss the PADI problem with the authors of that software, not the authors of TomatoUSB. You're welcome to point them to this thread,, but you'll probably be asked to file a bug report:

    http://ppp.samba.org/cgi-bin/ppp-bugs

    Good luck and let us know how it goes.
     
    Last edited: Feb 1, 2014
    QSxx likes this.

Share This Page