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

Fragmented UDP trafic blocked by Tomato firewall, how to unblock?

Discussion in 'Tomato Firmware' started by Suspenders, Apr 27, 2012.

  1. Suspenders

    Suspenders Serious Server Member

    Hi there :)

    I'm currently running Tomato Firmware (v1.28.0497 MIPSR2-Toastman-VLAN-RT-N K26 USB VPN) on an E3000 router.

    Everything works well except that the Tomato firewall blocks fragmented UDP traffic, and I need that traffic unblocked. I've searched on google for adjusting tomato firewall settings but I haven't found anything helpful related to unblocking fragmented UDP traffic.

    I've run the Netalyzr test ( http://netalyzr.icsi.berkeley.edu/index.html ) with DMZ enabled and disabled, which is how I've pinpointed the issue to the Tomato firewall. With DMZ enabled I get:

    "The applet was able to receive fragmented UDP traffic."

    While with it disabled I get this message instead:

    "Fragmented UDP traffic is blocked. The applet was unable to send fragmented UDP traffic. The most likely cause is an error in your network's firewall configuration or NAT."

    Any help on how to adjust this setting in the firewall would be appreciated.
     
  2. fopagi

    fopagi Serious Server Member

    Hi,

    I have exactly the same problem with the same hardware. Did you find any explanation to this problem or may it be related to the ISP ?
     
  3. koitsu

    koitsu Network Guru Member

    net.core.rmem_max and net.core.wmem_max control the maximum permitted buffer allocation size for a socket at the application level; this does not have anything (directly) to do with fragmented UDP packets or packet reassembly at the network level. It's a separate issue, and one that really isn't an issue at all -- whoever decided on those "recommended defaults" (in transmission) made the assumption the program would never be run on an embedded device with not a lot of memory.
     
  4. koitsu

    koitsu Network Guru Member

    Cannot reproduce reported issue using firmware tomato-K26USB-1.28.0501.3MIPSR2Toastman-RT-N-Ext.trx on an RT-N16:

    Code:
    UDP connectivity ([URL='http://n2.netalyzr.icsi.berkeley.edu/info_udp_connectivity.html']?[/URL]): OK [URL='http://n2.netalyzr.icsi.berkeley.edu/summary/id=43ca208a-29263-db3c4b9f-3452-43d6-87e4#']–[/URL]
    Basic UDP access is available.
    The client was able to send fragmented UDP traffic.
    The client was able to receive fragmented UDP traffic.
    
    You need to provide full details about your network configuration and all settings you change in the router (GUI and/or CLI).
     
  5. fopagi

    fopagi Serious Server Member

    Thank you koitsu, your test result is very useful for me. Based on that, I have ran a set of tests using different Tomato flavours. To minimize the potential problems, I have only changed few parameters in Basic -> Network.

    WAN / Internet
    Type: PPPoE
    Username: username
    Password: password
    Service Name: Name
    MTU: Manual 1462

    Wireless (2.4 GHz / eth1)
    Enable Wireless: unchecked

    Wireless (5 GHz / eth2)
    Enable Wireless: unchecked

    For those tests, I was connected wired to the router with a static IP and the router IP as default gateway and DNS. I have tried the following Tomato flavours: tomato-E3000USB-1.28.9054MIPSR2-beta-Ext.bin, tomato-E3000-NVRAM60K-1.28.7501.3MIPSR2Toastman-RT-Std.bin, tomato-E3000USB-NVRAM60K-1.28.RT-MIPSR2-107-Big-VPN.bin and tomato-E3000-NVRAM60K-1.28.2025MIPSR2-FG-VLAN-VPN.bin (compiled from Teaman sources).
    However, the result is always the same.
    Code:
    UDP connectivity (?): Note
     
    Basic UDP access is available.
    The client was able to send a packet of 1471 bytes of payload (1499 bytes total) only on
    the second try, suggesting your host is running Linux (or other path MTU discovery) on
    UDP traffic.
    The client was unable to receive fragmented UDP traffic. The most likely cause is an
    error in your network's firewall configuration or NAT.
    The maximum packet successfully received was 1464 bytes of payload.
    But I have another message that might be related to this problem.
    Code:
    Path MTU (?): Warning
    The path between your network and our system supports an MTU of at least 1500 bytes,
    and the path between our system and your network has an MTU of 1492 bytes. The
    path MTU bottleneck that fails to properly report the ICMP "too big" is between
    193.x.xxx.x and 83.xxx.xxx.xxx. The path between our system and your network does
    not appear to report properly when the sender needs to fragment traffic
    For information, 83.xxx.xxx.xxx is my IP address. Is it possible that Tomato blocks those ICMP "too big" packets ? Btw, why is it reported that "the path between our system and your network has an MTU of 1492 bytes." ?
     
  6. koitsu

    koitsu Network Guru Member

    Where did you come up with the value of 1462 for your MTU size? It's almost glaringly obvious you have this wrong, but you should not go fiddling about with values. I'd like to know where you got this number from.

    You've continued to leave out important parts of your network topology. You're focusing on the Tomato-based router and your PC and firmware, not on the other bits.

    You should really use whatever PPPoE device your ISP gave you when you signed up, and have it operate in "bridged mode" or equivalent so that -- except the PPPoE negotiation part -- it passes all traffic through blindly to whatever device is on the other end of the Ethernet connection (this also includes DHCP traffic).

    Path MTU negotiation is failing for you because of the same problem.

    Tomato itself is not "causing these issues" per se.
     
  7. fopagi

    fopagi Serious Server Member

    The MTU has been given (and confirmed for 99,9%) by my ISP. How can you pretend that Tomato itself is not causing these issues ? When I use the Zyxel I have received in router mode everything is working fine. When I change for the modem/bridge mode and use my Tomato router, it sucks.
    And what do you mean by "You've continued to leave out important parts of your network topology. You're focusing on the Tomato-based router and your PC and firmware, not on the other bits." ? My configuration is clear and works as expected when using Zyxel as the router, not when using Tomato.
     
  8. koitsu

    koitsu Network Guru Member

    Most MTUs when PPPoE is used are 1492 -- not 1462. Do you understand what the MTU is? Normally MTU is 1500 bytes, but PPPoE's encapsulation overhead takes up (normally) 8 extra bytes (2 for the PPP headers, and 6 for the PPPoE headers). If you're using PPPoA, an MTU of 1462 would make more sense.

    Your very first post states clearly that the "issue is with the Tomato firewall". There is no issue with the Tomato firewall; there may, however, be issues with the PPPoE implementation in Tomato. But there are no issues with the firewall.

    I believe it -- because the Zyxel is doing the PPPoE encapsulation.

    Again -- no details. Just "it sucks". This is the mode you should be using, as all the PPPoE authentication and encapsulation happens within the unit that your ISP has given you (which as you just said in the previous quote, "everything is working fine". It's guaranteed to work correctly. When you move the PPPoE portions to the Tomato router, that's when problems can happen. "It sucks" doesn't provide any details.

    You haven't stated if you're using DSL, and if so, what type of DSL. You haven't stated what ISP (you would be surprised how many different users of different ISPs linger here; by knowing the ISP, folks can help!). You haven't stated the exact model name/model string of the Zyxel either. For all I know there could be a massive firmware bug on those things (for example the DSLReports/Broadbandreports forums are filled with people finding bugs in Zyxel firmwares all the time) that impacts bridged mode badly.
     
  9. Toastman

    Toastman Super Moderator Staff Member Member

    Just something for you to reflect on. One of the biggest ISP's here issued a free Zyxel 4 port wifi router/modem to PPPoE ADSL customers some years ago. If memory serves me correctly it was a P660 series. They had a bad reputation. I did try using a few once as bridged modems. They would not work properly with MTU of 1492 even when bridged, and gave problems with fragmentation, I don't remember the details as it was about 3 years ago. I remember that I kept reducing MTU until I got down to about 1460. The modem was doing *something* internally, but I can't imagine what. The ISP concerned had no staff who understood the problem or even what I was talking about, and they were advising people use settings as low as 1400-1440, I believe - at that setting they would work. All other modems I have ever used are fine at 1492.

    I believe your problems will go away if you change to a different manufacturer.

    I threw many of those modems in the bin. All brand new. If you walk around the junk shops here you can see thousands of Zyxel devices. Even for a dollar, nobody wants them.
     
  10. leandroong

    leandroong Addicted to LI Member

    My modem is Zyxel P-600 series and my MTU setting 1500 (Manual), setup as bridge mode. Any test I can help?
     
  11. fopagi

    fopagi Serious Server Member

    Thank you for your feedback Toastman. If I use a Zyxel device (P-870H-53A to be precise), it is because it was advised by my ISP. Ironically I was using one of those P-660 series in bridge mode for years without any troubles on my ADSL(2) lines. However, as soon as I have migrated to VDSL2 and I have started using P-870H in bridge mode, problems have began. And yes, as you have stated above, the modem is doing *something* internally, but I can't imagine what.
    Tomato is definitely not the problem, it is the Zyxel in modem/bridge mode, because it happends with the stock firmware on my E3000, too.
    I know that not so many people here are using xDSL line, but has anyone a good advice on what kind of VDSL2 modem/bridge I can buy ?
     
  12. mstombs

    mstombs Network Guru Member

    I'd never heard of "Fragmented udp" till seen in this thread, always thought udp was simple individual packets in a protocol that can loose some packets! Should use TCP where the receiver can reassemble packets in order and get repeats for failures! In theory a router can do fragmentation, but unless it really understands the protocol just likely to mess things up, and the best it can do i inform the source that fragmentation needed. Note the router doesn't do reassembly, its the higher level processes at the end points that must. But it seems the issue is really full size packets and MTU/MRU discovery. Tomato is definitely not the state of the art here, it just defaults to Ethernet 1500, or you have to define your own, I have seen router firmwares that auto-tune, possibly even Tomato's predecessot HyperWRT?. There used to be a simple bash script that you can run to discover your maximum MTU on a specific path. ([edit] here it as example

    http://www.routertech.org/viewtopic.php?t=1720

    I used to have trouble with a pppoa adsl isp, The isp recommended 1400 but 1500 would usually work, but sometimes 1432 was the max, due to special routing in force I understood. Routers (home and ISP) can definitely break end-to-end MTU discovery, and there are iptables commands to clamp mtu which may help IIRC, used to be common for users to report inability to upload to certain websites when the MTU was wrong.
     
  13. Pentangle

    Pentangle Serious Server Member

    Hi Fopagi.

    I'm using Tomato on an RT-N16 (soon to be 66U) connected to a Huawei HG612. If you have VDSL in the UK, chances are you're giong to get one of these as BT deploy them in bridge mode in front of their "Home Hub". The BT Home Hub is a POS, but the Huawei HG612 (also found on Google under "BT Openreach modem") is solid as a rock and definitely recommended for VDSL2 connections.

    You should be able to pick one up from Ebay quite cheap?

    Cheers,
    Mike.
     
  14. fopagi

    fopagi Serious Server Member

    Thanks Mike, I'll take a look.

    However, before changing anything, I'm still trying to figure out where might be the real problem. I have tried to connect on the Zyxel bridge, which is running Linux with iptables, but I haven't found anything relevant. So I have decided to run tcpdump on the router to catch the ICMP and UDP packets that are sent and received by the router and my PC.
    As you can see in the result, there's no problem with the outgoing path MTU. The UDP trafic is fragmented and sent correctly. However, the path MTU for incoming packets is wrong and when I receive fragmented traffic, it seems that fragments are too big and it is never reassembled and of course I get nothing back on br0 interface.

    Outgoing trafic:

    br0 interface
    Code:
    1    0.000000    192.168.19.199    192.168.19.1    DNS    89    Standard query A n3.netalyzr.icsi.berkeley.edu
    2    0.202397    192.168.19.1    192.168.19.199    DNS    150    Standard query response A 174.129.176.88
    55    11.395169    192.168.19.199    174.129.176.88    UDP    1513    Source port: 50601  Destination port: eye2eye
    56    11.395361    192.168.19.1    192.168.19.199    ICMP    590    Destination unreachable (Fragmentation needed)
    57    11.396343    192.168.19.199    174.129.176.88    IPv4    1474    Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3fd8) [Reassembled in #58]
    58    11.396402    192.168.19.199    174.129.176.88    UDP    73    Source port: 38396  Destination port: eye2eye
    59    11.514112    174.129.176.88    192.168.19.199    UDP    67    Source port: eye2eye  Destination port: 38396
    60    11.519844    192.168.19.199    174.129.176.88    IPv4    1474    Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3fd9) [Reassembled in #61]
    61    11.519890    192.168.19.199    174.129.176.88    UDP    602    Source port: 58445  Destination port: eye2eye
    62    11.638392    174.129.176.88    192.168.19.199    UDP    67    Source port: eye2eye  Destination port: 58445
    
    ppp0 interface
    Code:
    24    11.395782    83.xxx.xxx.xxx    174.129.176.88    IPv4    1476    Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3fd8) [Reassembled in #25]
    25    11.395837    83.xxx.xxx.xxx    174.129.176.88    UDP    75    Source port: 38396  Destination port: eye2eye
    26    11.513212    174.129.176.88    83.xxx.xxx.xxx    UDP    69    Source port: eye2eye  Destination port: 38396
    27    11.519274    83.xxx.xxx.xxx    174.129.176.88    IPv4    1476    Fragmented IP protocol (proto=UDP 0x11, off=0, ID=3fd9) [Reassembled in #28]
    28    11.519334    83.xxx.xxx.xxx    174.129.176.88    UDP    604    Source port: 58445  Destination port: eye2eye
    29    11.637495    174.129.176.88    83.xxx.xxx.xxx    UDP    69    Source port: eye2eye  Destination port: 58445
    

    Incoming trafic:

    br0 interface
    Code:
    79    21.772706    192.168.19.199    174.129.176.88    UDP    60    Source port: 43363  Destination port: eye2eye
    80    22.774074    192.168.19.199    174.129.176.88    UDP    60    Source port: 43363  Destination port: eye2eye
    81    23.775433    192.168.19.199    174.129.176.88    UDP    60    Source port: 43363  Destination port: eye2eye
    82    24.776801    192.168.19.199    174.129.176.88    UDP    60    Source port: 43363  Destination port: eye2eye
    83    25.778179    192.168.19.199    174.129.176.88    UDP    60    Source port: 43363  Destination port: eye2eye
    
    ppp0 interface
    Code:
    45    21.772066    83.xxx.xxx.xxx    174.129.176.88    UDP    58    Source port: 43363  Destination port: eye2eye
    46    21.888563    174.129.176.88    83.xxx.xxx.xxx    IPv4    564    Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7750)
    47    22.773387    83.xxx.xxx.xxx    174.129.176.88    UDP    58    Source port: 43363  Destination port: eye2eye
    48    22.890037    174.129.176.88    83.xxx.xxx.xxx    IPv4    564    Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7751)
    49    23.774743    83.xxx.xxx.xxx    174.129.176.88    UDP    58    Source port: 43363  Destination port: eye2eye
    50    23.891073    174.129.176.88    83.xxx.xxx.xxx    IPv4    564    Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7752)
    51    24.776109    83.xxx.xxx.xxx    174.129.176.88    UDP    58    Source port: 43363  Destination port: eye2eye
    52    24.893039    174.129.176.88    83.xxx.xxx.xxx    IPv4    564    Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7753)
    53    25.777491    83.xxx.xxx.xxx    174.129.176.88    UDP    58    Source port: 43363  Destination port: eye2eye
    54    25.894342    174.129.176.88    83.xxx.xxx.xxx    IPv4    564    Fragmented IP protocol (proto=UDP 0x11, off=1480, ID=7754)
    
    I'm confused about those fragmented UDP packets and the MTU problem. And I don't understand the "magic" with the Zyxel router which does not suffer this path MTU discovery problem.

    Should I try each value between 1400 and 1492 for MTU until I find the good one or may it be a problem with my ISP that block some ICMP packets ? How can I test that ?

    Thank you
     
  15. fopagi

    fopagi Serious Server Member

    Ok, I have found the problem. I have tried to connect to my ISP using ppp debug and here's what I've found:

    Code:
    pppd[473]: using channel 1
    pppd[473]: Using interface ppp0
    pppd[473]: Connect: ppp0 <--> vlan2
    pppd[473]: Couldn't increase MTU to 1500
    pppd[473]: Couldn't increase MRU to 1500
    pppd[473]: sent [LCP ConfReq id=0x1 <mru 1462> <magic 0xnnnnnnnn>]
    pppd[473]: rcvd [LCP ConfReq id=0x1 <mru 1492> <auth chap MD5> <magic 0xxnnnnnnnn>]
    pppd[473]: sent [LCP ConfAck id=0x1 <mru 1492> <auth chap MD5> <magic 0xxnnnnnnnn>]
    pppd[473]: rcvd [LCP ConfAck id=0x1 <mru 1462> <magic 0xxnnnnnnnn>]
    pppd[473]: sent [LCP EchoReq id=0x0 magic=0xxnnnnnnnn]
    pppd[473]: rcvd [CHAP Challenge id=0xf7 <.....>, name = "ipc-xxxxx-x-xx-xx"]
    pppd[473]: sent [CHAP Response id=0xf7 <.....>, name = "user@isp"]
    pppd[473]: rcvd [LCP EchoRep id=0x0 magic=0xxnnnnnnnn]
    pppd[473]: rcvd [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xxnnnnnnnn>]
    pppd[473]: Couldn't increase MTU to 1500
    pppd[473]: Couldn't increase MRU to 1500
    pppd[473]: sent [LCP ConfReq id=0x2 <mru 1462> <magic 0xxnnnnnnnn>]
    pppd[473]: sent [LCP ConfAck id=0x1 <auth chap MD5> <magic 0xxnnnnnnnn>]
    pppd[473]: rcvd [LCP ConfNak id=0x2 <mru 1500>]
    
    It seems that the server force the MRU at 1500 in the last line. Therefore my 1462 value is not used. My ISP drops too big packets but does not send ICMP packets to inform the sender.

    There should probably be a patch in the Zyxel ppp code that doesn't accept the 1500 MRU value. However, I have really no idea how to fix this issue in my tomato router.
     
  16. koitsu

    koitsu Network Guru Member

    What you should be doing is reporting this to your ISP; their DSLAM or equivalent device which does PPPoE is configured to force an MTU of 1500, despite what you've been told in the past. Their equipment may be misconfigured -- report the problem to them, work with their engineers. If you're using PPPoA, then an MTU of 1500 is actually normal.

    The evidence you've presented refutes your own previous claims of what your ISP has claimed.

    There is no way a unit (Zyxel or any other brand) could "not accept the MRU value" -- in reality what's happening is that there's probably some other LCP parameters the Zyxel unit is sending along which causes their DSLAM/PPPoE device to behave differently than if you were to do PPPoE yourself. Are you starting to see why I said what I did earlier about using the equipment your ISP gives you for PPPoE encapsulation + authentication? My comment is well-founded.

    You need to work with your ISP on this matter. You're going to need to push your ISP continually until you get into conversations with actual network engineers, and not "tier 1" support (they won't know anything about this, it's too low-level).

    Alternately, you could try removing the TCPMSS clamping iptables rule in TomatoUSB and see if that has some effect. Look at iptables -L -n -v --line-numbers, specifically the FORWARD chain, for the TCPMSS clamping rule; you can try deleting it using iptables -D FORWARD {line number}. This won't affect the PPPoE layer, but it would affect the NAT/translation layer. You can read about the details here: http://www.linuxtopia.org/Linux_Firewall_iptables/x4700.html

    The default rule in TomatoUSB is iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; you can see this for yourself by looking at /etc/iptables (which the router maintains/creates itself, so don't mess with the file).

    Another alternate solution would be to insert a new rule after the existing one, but for the UDP protocol (which obviously has no SYN equivalent since UDP is stateless). The effects of this to me are unknown; YMMV.

    Good luck, and be sure to document what transpires with your ISP.
     
  17. Mangix

    Mangix Networkin' Nut Member

    Remove the magic numbers as well as the CHAP hashes posted above. Those can be bruteforced to reveal your username and password.
     
    koitsu likes this.
  18. fopagi

    fopagi Serious Server Member

    Yes, I agree and this is what makes me so confused. They insist on the MTU size 1462, they have even asked me if my MTU was bi-directional, they silently drop the bigger packets without sending back ICMP packets, but at the end they force my MRU to a size 1500 (which is finally set to the max for PPPoE 1492) !

    Absolutely. All my apologies, I was even not thinking this was possible. I though I had a missing parameter in my ppp or pppoe config, but I have tried many of them without any success. What I find really strange is that the MRU parameter is negociated twice, and the first one seems to be good. Why it is trying to renegociate it in id=0x2 is a mistery for me.

    Of course, I have already contacted them to ask for more details about the LCP process. Of course, they are not pressed to give me an answer. Unfortunately, I have to send the message to a useless level 1 support guy that transmits it to the engineer. I don't have a direct contact.

    I have already tried. However, I have noticed that the size of the first UDP packet sent (with the Df bit set) is based on the MRU setting.

    For sure, I'll let you know. Anyway, thank you very much for your useful advices.
     
  19. fopagi

    fopagi Serious Server Member

    Done. Thank you.
     
  20. koitsu

    koitsu Network Guru Member

    Hmm, thanks for bringing that to my attention -- I overlooked that part of the log. I agree, indeed that's a little strange/interesting. I wonder if the PPPoE (specifically pppd) that's on TomatoUSB is old/has bugs relating to this.

    Are you absolutely 100% certain the log you're showing is accurate, i.e. the log from pppd after the router is rebooted? I imagine that some LCP parameters can be negotiated after the link is up -- you didn't include timestamps in your log, which doesn't help matters at all. Can you not provide the relevant data from /var/log/messages instead?

    Alternately, possibly pppd's logging is incorrect or is not logging enough details to truly make out what's going on. The version of pppd used is 2.4.5 from the folks at samba.org, which is the latest and last updated 2009 (yes, 4 years ago). Possibly there is a different pppd package available somewhere that is newer/better/more compatible.

    Another possibility is that there's some LCP setting/option that needs to be used to "make your ISP happy" and not induce the above behaviour, e.g. which the Zyxel unit sends but the PPPoE layer/daemon on TomatoUSB does not. Unless the Zyxel unit has some way to get at the raw data going out across the DSL interface, this isn't going to be possible to debug. Again, reliance on your ISP's engineers would be required, sadly.

    It would be really useful to try and get a packet capture of the actual raw data that's going across the wire (on TomatoUSB anyway), and then feed that into Wireshark (which can decode PPPoE sanely) + show it to your ISP and say "here's proof. Explain what's going on here".
     
  21. fopagi

    fopagi Serious Server Member

    Here it is. I have dumped a complete sequence, however I have done this from my computer using ppp 2.4.5 and rp-pppoe 3.11 because the behaviour is the same (yes, yes, I know....).

    Code:
    Mar 19 14:28:55 hp-desktop pppd[25442]: Plugin rp-pppoe.so loaded.
    Mar 19 14:28:55 hp-desktop pppd[25442]: pppd options in effect:
    Mar 19 14:28:55 hp-desktop pppd[25442]: debug #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: updetach #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: dump #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: plugin rp-pppoe.so #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: noauth #011#011# (from /etc/ppp/options)
    Mar 19 14:28:55 hp-desktop pppd[25442]: user user@isp #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: eth0 #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: rp_pppoe_service XXXXXXXX #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: default-asyncmap #011#011# (from /etc/ppp/options)
    Mar 19 14:28:55 hp-desktop pppd[25442]: mru 1462 #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: mtu 1462 #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: lcp-echo-failure 4 #011#011# (from /etc/ppp/options)
    Mar 19 14:28:55 hp-desktop pppd[25442]: lcp-echo-interval 30 #011#011# (from /etc/ppp/options)
    Mar 19 14:28:55 hp-desktop pppd[25442]: hide-password #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: noipdefault #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: defaultroute #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: usepeerdns #011#011# (from /etc/ppp/peers/dsl-provider)
    Mar 19 14:28:55 hp-desktop pppd[25442]: noipx #011#011# (from /etc/ppp/options)
    Mar 19 14:28:55 hp-desktop pppd[25442]: pppd 2.4.5 started by fopagi, uid 0
    Mar 19 14:28:55 hp-desktop pppd[25442]: Send PPPOE Discovery V1T1 PADI session 0x0 length 20
    Mar 19 14:28:55 hp-desktop pppd[25442]:  dst ff:ff:ff:ff:ff:ff  src 3c:d9:2b:79:11:be
    Mar 19 14:28:55 hp-desktop pppd[25442]:  [service-name XXXXXXXX] [host-uniq  62 63 00 00]
    Mar 19 14:28:56 hp-desktop pppd[25442]: Recv PPPOE Discovery V1T1 PADO session 0x0 length 66
    Mar 19 14:28:56 hp-desktop pppd[25442]:  dst 3c:d9:2b:79:11:be  src 0:90:1a:a3:40:cc
    Mar 19 14:28:56 hp-desktop pppd[25442]:  [AC-name ipc-bem640-r-br-01] [host-uniq  62 63 00 00] [service-name XXXXXXXX] [AC-cookie  22 a5 b3 8e 4a 50 17 83 d0 6b aa fa 64 07 9f 06] [end-of-list]
    Mar 19 14:28:56 hp-desktop pppd[25442]: Send PPPOE Discovery V1T1 PADR session 0x0 length 40
    Mar 19 14:28:56 hp-desktop pppd[25442]:  dst 0:90:1a:a3:40:cc  src 3c:d9:2b:79:11:be
    Mar 19 14:28:56 hp-desktop pppd[25442]:  [service-name XXXXXXXX] [host-uniq  62 63 00 00] [AC-cookie  22 a5 b3 8e 4a 50 17 83 d0 6b aa fa 64 07 9f 06]
    Mar 19 14:28:56 hp-desktop pppd[25442]: Recv PPPOE Discovery V1T1 PADS session 0x1d80 length 24
    Mar 19 14:28:56 hp-desktop pppd[25442]:  dst 3c:d9:2b:79:11:be  src 0:90:1a:a3:40:cc
    Mar 19 14:28:56 hp-desktop pppd[25442]:  [service-name XXXXXXXX] [host-uniq  62 63 00 00] [end-of-list]
    Mar 19 14:28:56 hp-desktop pppd[25442]: PADS: Service-Name: 'XXXXXXXX'
    Mar 19 14:28:56 hp-desktop pppd[25442]: PPP session is 7552
    Mar 19 14:28:56 hp-desktop pppd[25442]: Connected to 00:90:1a:a3:40:cc via interface eth0
    Mar 19 14:28:56 hp-desktop pppd[25442]: using channel 27
    Mar 19 14:28:56 hp-desktop pppd[25442]: Using interface ppp0
    Mar 19 14:28:56 hp-desktop pppd[25442]: Connect: ppp0 <--> eth0
    Mar 19 14:28:56 hp-desktop pppd[25442]: sent [LCP ConfReq id=0x1 <mru 1462> <magic 0xnnnnnnnn>]
    Mar 19 14:28:56 hp-desktop pppd[25442]: rcvd [LCP ConfReq id=0xc8 <mru 1492> <auth chap MD5> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:56 hp-desktop pppd[25442]: sent [LCP ConfAck id=0xc8 <mru 1492> <auth chap MD5> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:56 hp-desktop pppd[25442]: rcvd [LCP ConfAck id=0x1 <mru 1462> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:56 hp-desktop pppd[25442]: sent [LCP EchoReq id=0x0 magic=0xxnnnnnnnn]
    Mar 19 14:28:56 hp-desktop pppd[25442]: rcvd [CHAP Challenge id=0xb4 <.....>, name = "ipc-bem640-r-br-01"]
    Mar 19 14:28:56 hp-desktop pppd[25442]: sent [CHAP Response id=0xb4 <.....>, name = "user@isp"]
    Mar 19 14:28:56 hp-desktop pppd[25442]: rcvd [LCP EchoRep id=0x0 magic=0xxnnnnnnnn]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [LCP ConfReq id=0x1 <auth chap MD5> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [LCP ConfReq id=0x2 <mru 1462> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [LCP ConfAck id=0x1 <auth chap MD5> <magic 0xxnnnnnnnn>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [LCP ConfNak id=0x2 <mru 1500>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [LCP ConfReq id=0x3 <magic 0xxnnnnnnnn>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [LCP ConfAck id=0x3 <magic 0xxnnnnnnnn>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [LCP EchoReq id=0x0 magic=0xxnnnnnnnn]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [CHAP Challenge id=0xb5 <.....>, name = "DanyDoor3"]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [CHAP Response id=0xb5 <.....>, name = "user@isp"]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [LCP EchoRep id=0x0 magic=0xxnnnnnnnn]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [CHAP Success id=0xb5 ""]
    Mar 19 14:28:57 hp-desktop pppd[25442]: CHAP authentication succeeded
    Mar 19 14:28:57 hp-desktop pppd[25442]: CHAP authentication succeeded
    Mar 19 14:28:57 hp-desktop pppd[25442]: peer from calling number 00:90:1A:A3:40:CC authorized
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [IPCP ConfReq id=0x1 <addr 212.yy.yyy.yyy>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [IPCP ConfAck id=0x1 <addr 212.yy.yyy.yyy>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [IPCP ConfNak id=0x1 <addr 83.yyy.yyy.yyy> <ms-dns1 212.yy.yyy.y> <ms-dns2 212.yy.yyy.y>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: sent [IPCP ConfReq id=0x2 <addr 83.yyy.yyy.yyy> <ms-dns1 212.yy.yyy.y> <ms-dns2 212.yy.yyy.y>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: rcvd [IPCP ConfAck id=0x2 <addr 83.yyy.yyy.yyy> <ms-dns1 212.yy.yyy.y> <ms-dns2 212.yy.yyy.y>]
    Mar 19 14:28:57 hp-desktop pppd[25442]: local  IP address 83.yyy.yyy.yyy
    Mar 19 14:28:57 hp-desktop pppd[25442]: remote IP address 212.yy.yyy.yyy
    Mar 19 14:28:57 hp-desktop pppd[25442]: primary  DNS address 212.yy.yyy.y
    Mar 19 14:28:57 hp-desktop pppd[25442]: secondary DNS address 212.yy.yyy.y
    Mar 19 14:28:57 hp-desktop pppd[25446]: Script /etc/ppp/ip-up started (pid 25447)
    Mar 19 14:28:57 hp-desktop pppd[25446]: Script /etc/ppp/ip-up finished (pid 25447), status = 0x0
    
    If I have understood evrything correctly, at that point LCP should be closed and MUST not accept any requests.

    I have tried to find one, but I had no luck. It seems that only Zyxel is using a different version of ppp for router using PTM Layer2 Interface with VDSL2.

    Yes, it is really hard to debug without any assistance of the ISP's engineers. Btw, I have requested the source code for my Zyxel unit, which should be released on 4/12 based on the Zyxel support reply and it could possibly help to find what's different. However, it may be the opposite and my Zyxel unit may just skip one LCP step because it is not needed to negociate any asyncmap option. Based on what I have found, here is the list of PPP options and format:

    Code:
    Type  Length  Option's data
     
    0x01  4        Maximum receive Unit
    0x02  6        Async Control Character Map
    0x03  >= 4     Authentication Protocol
    0x04  >= 4     Quality Protocol
    0x05  6        Magic Number
    0x07  2        Protocol Field Compression
    0x08  2        Address and Control Field Compression
    0x09           FCS Alternative
    
    But there's a default-asyncmap parameter in pppoe that disable async map negotiation and then initiate a wrong MRU. Maybe ppp should not send any LCP request or my ISP server should answer differently.

    Yes, but based on what I'm suggesting above, I must be sure that my LCP negociation sequence is good and therefore rely on my ISP as you mentioned clearly.
     
  22. mstombs

    mstombs Network Guru Member

    Does your desktop have same fragmented packet problem? Interesting because that would make it a Linux problem - or possibly the modem bridge mode?

    I thought that Tomato had its own plugin for pppoe, pppoecd ? But the folks implementing MLPPP for bonded lines had to upgrade to a fuller version?
     
  23. fopagi

    fopagi Serious Server Member

    Yes it does. As you can read in my previous post, the problem is clearly during the LCP negotiation. However, I don't know if it is a pppoe, pppd or ISP problem.

     
  24. koitsu

    koitsu Network Guru Member

    It looks to me like the actual PPPoE portion is working fine, at least in the log you just provided from your desktop. That's abundantly clear. The PPPoE stuff ends and the standard PPP stuff begins starting here:

    Mar 19 14:28:56 hp-desktop pppd[25442]: PPP session is 7552

    Other than broken LCP negotiation, I can't really explain what's going on here on multiple levels. For example I cannot explain what LCP type 0xc8 (200) is -- I can't find any documentation on it. Likewise, LCP type 0x01 is supposed to be used for MTU/MRU negotiation, yet what's showing up in the log is that it's involved in type 2 negotiation (asyncmap), which makes no sense.

    All I can guess at this point is that there's either a logging-oriented mistake/bug in pppd that's making the log hard to follow/inaccurate thus troubleshooting here is basically impossible without a raw packet capture obtained via tcpdump that can be looked at in Wireshark for full/proper analysis (and yes, it would contain your username/password), AND, that there is a compatibility issue between pppd and your ISP.

    Like I said, this is why with PPPoE and PPPoA, you really must use the equipment your ISP gives you. I can tell you factually (because I own such devices) that some products (like Speedstream units) offer a "bridge mode" where the PPPoE and PPP authentication/encapsulation happens on the DSL modem, while all other packets after that get handed off to whatever device is attached to the LAN port. I used this configuration for years (as did many AT&T/SBC subscribers!), where the DSL bridge I had would do the PPPoE/PPP authentication and encapsulation, while letting me use a router (LAN port on DSL bridge plugged into WAN port on router, router was configured to get an IP via DHCP (talking to the DSL bridge itself)). The reason I, and tons of other customers, used this model was solely because of incompatibilities with the PPPoE/PPP model/method on consumer routers vs. the ISP's DSLAM equipment.
     

Share This Page