Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    PPPoE oversize packets

    Scheduled Pinned Locked Moved Routing and Multi WAN
    1 Posts 1 Posters 209 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • GrimetonG
      Grimeton
      last edited by

      Hello,

      for a few days now I run into an odd problem.

      I'm running pfSense behind a FritzBox that I use as DSL modem only. I dial in directly via mpd5 and get a connection. Everything is working fine and as expected.

      I'm also using the FritzBox' builtin VoIP stuff to drive my telephones and the fax machine. This worked as expected as well until a few days ago ....

      All of a sudden incoming calls are not answered anymore. I began looking into it and what I found is that I'm getting packets delivered that are outside the configured MTU boundaries.

      So what I do is, I call a number and wait for it to be connected. It takes a while and then the packets are send to me from the provider and it looks like this:

      21:29:56.748113 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      21:29:57.248856 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      21:29:58.249849 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      21:30:00.250825 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      21:30:04.251742 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      21:30:12.252660 IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1679 > 1464
      

      When I capture the whole packets including PPPoE, you get something like this:

      # tcpdump -pqni igb2.178 '(pppoes and udp and port 5060) or (udp and port 5060)'
      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
      listening on igb2.178, link-type EN10MB (Ethernet), capture size 262144 bytes
      21:41:17.176015 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      21:41:17.676301 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      21:41:18.677444 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      21:41:20.678230 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      21:41:24.679234 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      21:41:32.680256 PPPoE [ses 0x303c] IP 217.0.29.32.5060 > 84.151.83.18.55391: UDP, bad length 1678 > 1464
      

      Now the deal here is, that these packet sizes can go up to 1908 bytes while at the same time the MTU is set to 1492 and the MRU has been manually set to 3000 for testing on my end.

      I also changed the MTU on all interfaces involved to 9000 and enabled jumbo frames all around just to see if there is a chance I can just forward this packet to the VoIP equipment somehow.

      As you might have guessed: No success.

      One thing is strange: When I dump the packets via tcpdump and write them to a file, the packets seem to have the right size again. Copying the file over and opening it in Wireshark shows me that the packets have an "on the wire" size of 1514 bytes, which, when you calculate out all the headers, you end up with a payload that either matches or is below the requested MTU...

      8758873b-ee96-4582-80b2-6d5fc0e53666-image.png

      So right now I have multiple options here:

      • The German Telekom all of a sudden decided that it's ok to void all their configurations and send packets way above the accepted MTU/MRU sizes to their customers.
      • The FirtzBox all of a sudden decided to "blow up" VoIP packets for no reason.
      • pfSense is doing some weird things which leads to wrong packet sizes on the PPPoE end and gets them thrown away.

      One thing that I actually noticed is that this only happens when it comes to VoIP. So from my point of view it might actually be possible that the German Telekom is sending packets bigger than "hand shaked" over the line.

      Now when I use the FritzBox' builtin routing capabilities it all works... So the system either knows about this and accepts bigger packets or something else is going on here...

      BTW: It has nothing to do with the latest update on pfSense. I had this problem before (updated today).

      Any ideas or help would be highly appreciated.

      KR,

      G.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.