Strange routing / NAT issue - Networking

This is a discussion on Strange routing / NAT issue - Networking ; Something has changed with pogo.com again. I have a linux router. It has ethernet (192.168.1.*) and wireless (192.168.2.*). Everything works fine as far as connecting across interfaces and to the internet through a dialup connection (ppp0). Every once in while ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: Strange routing / NAT issue

  1. Strange routing / NAT issue

    Something has changed with pogo.com again. I have a linux router. It has
    ethernet (192.168.1.*) and wireless (192.168.2.*). Everything works fine
    as far as connecting across interfaces and to the internet through a dialup
    connection (ppp0). Every once in while pogo.com screws up something and
    my mom is unable to play her pogo games. Anyway on to the issue.

    Accessing the internet works fine. But when pogo launches a java applet
    (pop-up) game it sort of stalls out like it can't resolve DNS. Only DNS
    for the most part works fine. As does general web browsing. It only
    seems to affect these games. On the previous time I was able to get it
    working by changing the MTU on the network. And as a last resort it
    generally works in windows. Only this time around even that is screwed
    up. MTU changes don't work. OS changes don't work. But I can run X and
    launch the games on the router itself. It worked two weeks ago and AFAIK,
    nothing has changed on our end. I generally run the network at an MTU of
    576. If I don't connect with my ISP at that MTU, it generally dials out
    again about every two minutes. Any idea why it works on the router and
    not any computers connecting through it? Is it my ISP, or pogo? Or did
    something change in the NAT specs to mess this up? Everything else seems
    to work fine.

    The modem that is used to dial out is a lucent/agere so I'm using the
    martian-modem stuff. Which is a bit dated (2006). So much so that it
    wont compile against a 2.6.24 kernel. And the router is currently running
    a 2.6.21 kernel. I guess I'm starting to ramble now, so does anyone know
    of any iptables tricks to bypass NAT if only temporarily until pogo.com
    gets their s### together? My mom gets very frustrated at issues like
    these and generally goes out and buys a new computer thinking that will
    fix the issue. Which it doesn't since windows generally needs 200MB of
    updates the day after you take it home, which means even once you get on
    the internet, you can't use the internet for two weeks until it's done
    updating.

    I just don't know what's going on this time. There's generally something
    I can do to work around or fix it. I'm on the latest java, and up to date
    with Debian Etch/stable. And everything was working two weeks ago. And
    was working with much older java versions on windows last week.

    Is there any tricks for capturing via strace, tcpdump, or other way to see
    all of the DNS requests (in plain text) to see if that is the issue. Via
    putting them in the /etc/hosts file to bypass DNS lookup.

  2. Re: Strange routing / NAT issue

    Shadow_7 wrote:

    > Is there any tricks for capturing via strace, tcpdump, or other way to see
    > all of the DNS requests (in plain text) to see if that is the issue. Via
    > putting them in the /etc/hosts file to bypass DNS lookup.


    Most of the time, some flaky client will try to some server that's
    either overloaded or even offline.

    You could try switching from MASQUERADE to SNAT in iptables. or the
    other way around. (hoping it would be some iptables bug or something).

    As far as monitoring traffic goes, try using iptraf.

    -R-

  3. Re: Strange routing / NAT issue

    > Most of the time, some flaky client will try to some server that's
    > either overloaded or even offline.


    I guess I tracked it down to the packet size again. Except this time I
    needed to add -mru to /etc/ppp/options to get it working. Which sets the
    MRU to 1500. In addition to changing the MTU size to 1500 in
    /etc/ppp/options. I'm not quite sure why I have to keep changing my
    configuration to maintain a connection with this one website. On the
    local machines the MTU is still 576. Having larger packet sizes really
    screws with the queuing of packets. And otherwise makes it feel and behave
    slower than it really is on this already slow shared dial-up connection.

  4. Re: Strange routing / NAT issue

    On Fri, 04 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Shadow_7 wrote:

    >I guess I tracked it down to the packet size again. Except this time I
    >needed to add -mru to /etc/ppp/options to get it working. Which sets the
    >MRU to 1500.


    In your original post you stated this is Debian Etch and this is a dialup
    connection. I'm not using Etch, but the latest version of pppd is 2.4.4
    available at ftp://ftp.samba.org/pub/ppp

    -rw-r--r-- 1 ftp ftp 688763 Jun 28 2006 ppp-2.4.4.tar.gz

    Looking at the man page or the source file for ~/pppd/options.c there is
    no '-mru' option. The Changes-2.3 file stated for 2.3.0

    * Pppd options beginning with - or + have been renamed, e.g. -ip
    became noip, +chap became require-chap, etc. The old options are
    still accepted for compatibility but may be removed in future.

    though there never was a "nomru" option. There is a

    default-mru
    Disable MRU [Maximum Receive Unit] negotiation. With this
    option, pppd will use the default MRU value of 1500 bytes
    for both the transmit and receive direction.

    which might be suitable. However, without the 'mru' option, pppd
    should default to 1500, so I'm not sure why things are changing for you.
    You might try temporarily adding the 'dump' option

    dump With the dump option, pppd will print out all the option
    values which have been set. This option is like the dryrun
    option except that pppd proceeds as normal rather than
    exiting.

    to see if something is "helping" you by screwing with the MRU.

    >I'm not quite sure why I have to keep changing my configuration to
    >maintain a connection with this one website. On the local machines the
    >MTU is still 576. Having larger packet sizes really screws with the
    >queuing of packets. And otherwise makes it feel and behave slower than
    >it really is on this already slow shared dial-up connection.


    Firewall issue?

    1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990.
    (Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
    STANDARD)

    2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
    (Format: TXT=30976 bytes) (Status: INFORMATIONAL)

    Those two RFCs (you can find them using any search engine) might explain
    the problem. PMTU tries to discover the largest packet that can be sent
    from "a" to "b". It does this by trying large packets with the "Don't
    Fragment" flag set in the IP header. A host enroute that has a smaller
    link MTU will send back an ICMP Type 3 Code 4 message ("Fragmentation
    needed, but don't fragment bit set"), but some router may be dropping
    ICMP packets (because they think it improves security or something).
    The result is effectively a black hole. You can detect this using
    a packet sniffer - you'll see the 3-way handshake establishing the
    connection, maybe one or two additional packets, and then nothing.

    Another possible problem (nearly unheard-of now) is ECN packet drops.
    When the 2.4.0 kernel was released in 2000, it included ECN by default,
    and some routers on the Internet were dropping packets with the (then
    comparatively unknown) ECN flag bit set in the IP header. There was a
    kernel work-around, of sticking a zero into /proc/sys/net/ipv4/tcp_ecn
    but that was over six years ago, and I can't believe someone could be
    still running ancient versions of router software.

    I'm not sure why you are having queuing problems. Setting MTU to a
    smaller figure _was_ done to improve interaction in FTP when there were
    slow links (1980s), and _is_ done where you are running PPPoE links
    (the PPPoE protocol adds 8 bits to a packet, and the maximum packet
    size on standard Ethernet is 1500 octets - so PPPoE links have an
    MTU set at 1492 to avoid fragmentation).

    Old guy

  5. Re: Strange routing / NAT issue

    Moe Trin wrote:
    > On Fri, 04 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    > article , Shadow_7 wrote:


    >>I guess I tracked it down to the packet size again. Except this time I
    >>needed to add -mru to /etc/ppp/options to get it working. Which sets the
    >>MRU to 1500.


    > In your original post you stated this is Debian Etch and this is a dialup
    > connection. I'm not using Etch, but the latest version of pppd is 2.4.4
    > available at ftp://ftp.samba.org/pub/ppp


    > -rw-r--r-- 1 ftp ftp 688763 Jun 28 2006 ppp-2.4.4.tar.gz


    > Looking at the man page or the source file for ~/pppd/options.c there is
    > no '-mru' option. The Changes-2.3 file stated for 2.3.0


    Hi Moe!

    Man pages don't always include dated options while the source may but
    not always where one would expect.

    ~/shop/pppd/ppp-2.4.4/pppd$ grep -Irs '\-mru' .
    ../lcp.c: { "default-mru", o_bool, &lcp_wantoptions[0].neg_mru,
    ../lcp.c: { "-mru", o_bool, &lcp_wantoptions[0].neg_mru,
    ../pppd.8:.B default\-mru
    ~/shop/pppd/ppp-2.4.4/pppd$

    Unfortunately I have nothing else to offer the OP in the way of help.
    But I would be suspicious of the Java applet. Or the new Java versions
    of M$:

    "I'm on the latest java, and up to date with Debian Etch/stable.
    And everything was working two weeks ago. And was working with much
    older java versions on windows last week."

    Cheers-
    --
    Clifford Kite
    /* "PPPoE has many advantages for DSL service providers, and
    practically none for DSL consumers."
    - David F. Skoll */

  6. Re: Strange routing / NAT issue

    On Sat, 5 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in article
    , Clifford Kite wrote:

    >Moe Trin wrote:


    >> Looking at the man page or the source file for ~/pppd/options.c there
    >> is no '-mru' option. The Changes-2.3 file stated for 2.3.0

    >
    >Hi Moe!


    Hi Clifford!

    >Man pages don't always include dated options while the source may but
    >not always where one would expect.


    You caught me there - I knew the option was still included, as pppd
    would be barfing otherwise. I thought that option was in ppps/options.c
    with the rest of the mess. ;-)

    >~/shop/pppd/ppp-2.4.4/pppd$ grep -Irs '\-mru' .
    >./lcp.c: { "default-mru", o_bool, &lcp_wantoptions[0].neg_mru,
    >./lcp.c: { "-mru", o_bool, &lcp_wantoptions[0].neg_mru,


    Ah well - learn something new.

    >./pppd.8:.B default\-mru


    Now that's the man page... OK - it's the title of an option. The
    section reads:

    .B default\-mru
    Disable MRU [Maximum Receive Unit] negotiation. With this option,
    pppd will use the default MRU value of 1500 bytes for both the
    transmit and receive direction.
    .TP

    which turns out to read:

    default-mru
    Disable MRU [Maximum Receive Unit] negotiation. With this
    option, pppd will use the default MRU value of 1500 bytes
    for both the transmit and receive direction.

    when displayed with the man command.

    >Unfortunately I have nothing else to offer the OP in the way of help.
    >But I would be suspicious of the Java applet. Or the new Java versions
    >of M$:


    I thought of that, except he indicated he got it working by setting the
    MRU up to 1500.

    I guess I tracked it down to the packet size again. Except this time
    I needed to add -mru to /etc/ppp/options to get it working. Which
    sets the MRU to 1500.

    Now what he _could_ be seeing is different versions on a pool of servers
    with the same name. Wouldn't be the first time that has occurred. I also
    didn't understand (or comment upon) this item in his original post:

    I generally run the network at an MTU of 576. If I don't connect
    with my ISP at that MTU, it generally dials out again about every two
    minutes. Any idea why it works on the router and not any computers
    connecting through it?

    To the O/P - if this is still a problem, I suggest running a packet
    sniffer, or at least putting a command in /etc/ppp/ip.up that reads

    /bin/netstat -anptu > /tmp/ppp.traffic

    which will run that command when the link comes up. You MAY need to
    precede it with a five or ten second 'sleep' command. If you have
    tcpdump installed, you could use

    /usr/sbin/tcpdump -ni ppp0 -c 20 -w /tmp/ppp.tcpdump

    which will put the first twenty packets over the ppp0 interface into
    a packet dump file named '/tmp/ppp.tcpdump'

    Old guy

  7. Re: Strange routing / NAT issue

    I guess I should clarify. The current router is running debian sarge.
    About six months to a year and a half out of date. I used it a lot in
    2006, but have gotten better machines since then. I set it up to replace
    the old router in case of an unresolvable issue. Which is what it's
    currently doing.

    This replaced an older box with mobo battery issues and various other
    upgrade issues. It originated from debian woody. As well as a video card
    that likes to zap monitors out of commission. But it made a good router.
    I've since replaced the battery and installed Debian Etch on it. But I've
    yet to get the modem working on it. Every thing else on it is up to
    baring a 2.6.24.x kernel that has the SA_INTERRUPT stuff replaced with
    IRQF_Shared (+/- off the top of my head). Although not an issue in this
    case as it's currently offline and not used.

    Beyond that my laptop the one trying to play the game is on Debian Etch
    and up to date for the most part. A new video driver out now, and
    kernel 2.6.24.2 is no longer the most recent. The other game playing
    desktop is running Knoppix 2007.0. With the most recent java from sun.
    And various other boxes, but we'll leave them out of it for now.

    I like dialing out to my ISP at an MTU of 576. This gives me the most
    throughput and the best queueing of packets. At 576 I can download about
    15MB per hour and things are more responsive. At 1500 I can download
    about 12MB per hour. And pages with a lot of little pictures, ads, and
    other things take upward of five minutes just to do the initial render
    (mail.yahoo.com). I prefer to run at 576 given a choice.

    In the past I worked around this same issue by changing my internal
    network from 576 to 1500. Ethernet and wireless. And changed it back a
    month later when it no longer seemed to be an issue with pogo. Now here's
    the catch, since the current router is my old desktop, it has X and java
    and all that jazz. Pogo works fine on it at 576. So there's probably some
    greater issue with pppd versioning and NAT with iptables. Kernel 2.6.21 on
    that box.

    For this time around I not only had to adjust the internal network to
    1500, but I had to connect to my ISP at that same packet size. AND I had
    to up the mru, or at least explicitly state a value for it, where
    previously it was just a commented line of configuration. I imagine that
    I could set everything back to how it used to be in six weeks and all will
    be fine again. With that one site and java applets.

    I've also had packet size issues with other sites (tracfone.com). Where
    that website wouldn't load at all until I changed my packet sizes. But I
    think it too worked at one point six months later with the older
    configuration. Now it may not be a packet size issue at all. All I know
    is that making a change in the packet sizes seems to get things working
    again. Normally I just touch the MTU (which is rough enough for windows).
    But this time some effort on the MRU was needed. Now it may have been
    something else, I did change a few things. But it seemed to start working
    immediately after touching the MRU. I hope this clarifies it a bit.

  8. Re: Strange routing / NAT issue

    On Sat, 05 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <4Iednat_YaX4rWXanZ2dnUVZ_rzinZ2d@earthlink.com>, Shadow_7 wrote:

    >I guess I should clarify. The current router is running debian sarge.
    >About six months to a year and a half out of date.


    Sarge - released 06 Jun 2005 - went through several updates.

    >I've since replaced the battery and installed Debian Etch on it. But I've
    >yet to get the modem working on it.


    Etch - released in Apr 2007. Your 'sarge' box was probably running
    ppp-2.4.3 (released November 2004), while 'etch' is almost certain to be
    running ppp-2.4.4. The README file in 2.4.4 (which details changes made
    since the previous versions) mentions adding /etc/ppp/ip-pre-up, fixing
    bugs in the area of demand-dialed and persistent connections, and a
    change in the rp-pppoe plugin. I don't _know_ of any significant changes
    other than that - perhaps Clifford Kite has more to add.

    >I like dialing out to my ISP at an MTU of 576. This gives me the most
    >throughput and the best queueing of packets. At 576 I can download about
    >15MB per hour and things are more responsive. At 1500 I can download
    >about 12MB per hour. And pages with a lot of little pictures, ads, and
    >other things take upward of five minutes just to do the initial render
    >(mail.yahoo.com). I prefer to run at 576 given a choice.


    MTU only speaks of traffic you are generating. Unless you are setting
    the MRU, this shouldn't have a problem about packet size you are
    receiving. I guess you are downloading tiny things (files less than
    1450 bytes total), as normally the larger packets should be slightly
    (about 6 percent) faster.

    >In the past I worked around this same issue by changing my internal
    >network from 576 to 1500. Ethernet and wireless. And changed it back a
    >month later when it no longer seemed to be an issue with pogo. Now here's
    >the catch, since the current router is my old desktop, it has X and java
    >and all that jazz. Pogo works fine on it at 576. So there's probably some
    >greater issue with pppd versioning and NAT with iptables.


    The only thing that jumps out at me would be PMTU problems, and that could
    be caused by firewall rules, where the last box on a 1500 byte MSS has to
    fragment the packet for a subsequent 576 byte link. If that box is unable
    to generate a ICMP Type 3 Code 4 error message OR routers between it and
    the source are dropping ICMP, then the remote server will never hear
    anything from "here", and time out the connection. Both problems are
    common enough.

    >For this time around I not only had to adjust the internal network to
    >1500, but I had to connect to my ISP at that same packet size. AND I had
    >to up the mru, or at least explicitly state a value for it, where
    >previously it was just a commented line of configuration.


    That's a bit of confusion. If your ppp link is not explicitly told to use
    a smaller MTU/MRU, it should default to 1500 bytes. If it's coming up with
    something less unless you include the '-mru' or 'default-mru' options,
    then it's being told to request that lesser figure. You would see this in
    the debug output from pppd

    Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfReq id=0x1 0x8bab12d4> ]
    Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x2
    ]
    Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfAck id=0x1 0x8bab12d4> ]
    Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfAck id=0x2
    ]

    Here, this box asked only for 'magic', 'pcomp' and 'accomp' options,
    while the peer (an ISP) asked for an MRU of 1524, PAP authentication,
    'pcomp' and 'accomp' but no 'magic'. This means the link from the
    ISP to here would have a MRU of 1500 (the default), while the link in
    the opposite direction would have an MRU of 1524 (although this end
    was not configured with the 'mtu 1524' option, so the packets sent
    from this side would be a maximum of 1500 bytes - which is after all,
    less than the requested maximum of 1524). When 'mru' is not
    negotiated, the default value of 1500 applies. The pppd 'dump' option
    should allow you to see if an 'mru' is being set at the command line or
    one of the options files.

    >I've also had packet size issues with other sites (tracfone.com). Where
    >that website wouldn't load at all until I changed my packet sizes. But I
    >think it too worked at one point six months later with the older
    >configuration. Now it may not be a packet size issue at all. All I know
    >is that making a change in the packet sizes seems to get things working
    >again.


    I'd be looking at the possibility of PMTU discovery problems - firewall
    rules typically. Without being able to put a packet sniffer at both ends
    of the link, all you would see here is the 3-way handshake went OK, and
    perhaps one or a few small packets, then nothing.

    >Normally I just touch the MTU (which is rough enough for windows).


    If you mean setting the MTU in pppd, that only affects the size of the
    packets you are sending, not the packets you will receive. If you are
    setting the MTU on your local LAN (Ethernet or wireless), I can't see
    why this would have any effect on packets over the ppp link (other than
    sent packets being smaller). Even end-to-end packets on the dialin would
    leave plenty of space between packets on the original 3Base5 Ethernet,
    never mind the ancient (1984) 10 megabit Ethernet.

    Old guy

  9. Re: Strange routing / NAT issue

    >>I like dialing out to my ISP at an MTU of 576. This gives me the most
    >>throughput and the best queueing of packets. At 576 I can download about
    >>15MB per hour and things are more responsive. At 1500 I can download
    >>about 12MB per hour. And pages with a lot of little pictures, ads, and
    >>other things take upward of five minutes just to do the initial render
    >>(mail.yahoo.com). I prefer to run at 576 given a choice.

    >
    > MTU only speaks of traffic you are generating. Unless you are setting
    > the MRU, this shouldn't have a problem about packet size you are
    > receiving. I guess you are downloading tiny things (files less than
    > 1450 bytes total), as normally the larger packets should be slightly
    > (about 6 percent) faster.


    On dialup at least for earthlink not really the case. Granted that some
    of the increased throughput is packet headers. But not to the tune of 3MB
    per hour. 15% or more units of data per unit of time (guestimate).
    Previous mru was unused. Negotiation with earthlink is CHAP. When I
    initially set it up on the old router I found that I had to use passive in
    /etc/ppp/options or NAT didn't work. To make it more complex, google.com
    at http 1.1 loaded, at least the initial page via NAT across the network.
    And sometimes search results. Where yahoo.com http 1.0 didn't. This was
    quite a while ago. And just changing passive in pppd's options fixed it.
    Traffic on the originating machine worked fine in that case too. As far as
    pogo and tracfone issues of old, not having 1500 MTU's didn't mean that
    they didn't load. But that loading them could take upwards of fifteen
    minutes to load. With virtually nothing loaded in the first five minutes.
    Under normal conditions they'd load entirely in under two minutes.


    >>I've also had packet size issues with other sites (tracfone.com). Where
    >>that website wouldn't load at all until I changed my packet sizes. But
    >>I think it too worked at one point six months later with the older
    >>configuration. Now it may not be a packet size issue at all. All I
    >>know is that making a change in the packet sizes seems to get things
    >>working again.

    >
    > I'd be looking at the possibility of PMTU discovery problems - firewall
    > rules typically. Without being able to put a packet sniffer at both ends
    > of the link, all you would see here is the 3-way handshake went OK, and
    > perhaps one or a few small packets, then nothing.


    Which describes the typical packet behavior when there's an issue.
    Although nothing usually turned into something if you waited upwards of
    fifteen minutes. Even this last spurt pogo games would load about one out
    of twenty times, if you're waiting thirty minutes to three hours for it to
    start after launching the game. Typically an initial burst of 17 to 33
    packets then a long delay.

    >>Normally I just touch the MTU (which is rough enough for windows).

    >
    > If you mean setting the MTU in pppd, that only affects the size of the
    > packets you are sending, not the packets you will receive.


    Yes, in the case of previous issues I only changed the MTU for packets on
    the internal interfaces (eth0, wlan0) and left ppp0 untouched. Now when
    the neice brings over her XBox 360 and wants to game online, I have to
    change all MTU's to 1500. Otherwise it fails to even negotiate the
    wireless connection to the router. Without 1500 on ppp0 it fails to
    negotiate anything with the internet. Not that gaming with team speak
    worked all that great once working. But it did work somewhat.

  10. Re: Strange routing / NAT issue

    Shadow_7 wrote:

    > Yes, in the case of previous issues I only changed the MTU for packets on
    > the internal interfaces (eth0, wlan0) and left ppp0 untouched. Now when
    > the neice brings over her XBox 360 and wants to game online, I have to
    > change all MTU's to 1500. Otherwise it fails to even negotiate the
    > wireless connection to the router. Without 1500 on ppp0 it fails to
    > negotiate anything with the internet. Not that gaming with team speak
    > worked all that great once working. But it did work somewhat.


    Asking for a MRU < 1500 or setting MTU < 1500 on lan facing ifs is
    asking for PMTUD problems. If you want 576 either mss clamp with
    iptables & set 576 on ppp or set MTU to 576 on the client PCs (this will
    affect packets both ways).

    Other thoughts - IIRC ppp gets a 3 packet txqueuelength. This doesn't
    usually hurt as devices tend to have fair sized buffers beyond ppp, but
    maybe yours doesn't so it may be worth putting

    ifconfig ppp0 txqueuelen 20

    in /etc/ppp/ip-up.

    If you get link layer packet loss on the wireless then that will hurt
    throughput. If I had to use dialup today I would consider running
    something like squid as a transparent proxy on the router.

    Andy.

  11. Re: Strange routing / NAT issue

    On Sun, 06 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article <44GdnZSEBprJzGTanZ2dnUVZ_vninZ2d@earthlink.com>, Shadow_7 wrote:

    [I wrote]

    >> MTU only speaks of traffic you are generating. Unless you are
    >> setting the MRU, this shouldn't have a problem about packet size
    >> you are receiving. I guess you are downloading tiny things (files
    >> less than 1450 bytes total), as normally the larger packets should
    >> be slightly (about 6 percent) faster.

    >
    >On dialup at least for earthlink not really the case. Granted that
    >some of the increased throughput is packet headers. But not to the
    >tune of 3MB per hour. 15% or more units of data per unit of time
    >(guestimate).


    The advantage of smaller packets is that this lessens the wait to be
    able to stick in "competing" traffic. I've only seen that on simplex
    links with highly interactive traffic. If you were downloading a huge
    file (such as a kernel tarball), large packets would be the only way
    to go. But if you are also trying to read Usenet at the same time, the
    smaller packets allow traffic to co-exist better.

    >Previous mru was unused. Negotiation with earthlink is CHAP


    Authentication is not a factor here.

    >When I initially set it up on the old router I found that I had to use
    >passive in /etc/ppp/options or NAT didn't work.


    That doesn't sound right at-all. The ppp 'passive' option relates to
    how your peer attempts to start a ppp _link_ with the peer at the other
    end. Once the peer answers the initial '[LCP ConfReq' packet, the
    option has no further effect. ON THE OTHER HAND, the 'passiv' option
    may be desired with the 'ftp' file transfer protocol. That option to
    ftp tells the remote ftp server to use the existing control connection
    for data transfer rather than opening a separate data connection. That
    simplifies the firewall setup significantly.

    >To make it more complex, google.com at http 1.1 loaded, at least the
    >initial page via NAT across the network. And sometimes search results.
    >Where yahoo.com http 1.0 didn't.


    Both providers use a bewildering number of secondary page sources. I
    can see where that would be a problem.

    >This was quite a while ago. And just changing passive in pppd's
    >options fixed it.


    But I can't see that at all. Looking at the man page for pppd, that
    option only effects the initial Link Control Protocol stage of setting
    up a link (see also RFC1661 section 3.1). Once the link setup
    progresses to the IP address negotiation stage (where the peers agree
    on what IP addresses each will use), the next time you will use LCP
    is when you are tearing down the link, and hanging up the phone.

    >Traffic on the originating machine worked fine in that case too. As
    >far as pogo and tracfone issues of old, not having 1500 MTU's didn't
    >mean that they didn't load. But that loading them could take upwards
    >of fiftee minutes to load. With virtually nothing loaded in the first
    >five minutes. Under normal conditions they'd load entirely in under
    >two minutes.


    That still sounds like PMTU discovery problems.

    >Yes, in the case of previous issues I only changed the MTU for packets
    >on the internal interfaces (eth0, wlan0) and left ppp0 untouched.


    When you do that, packets that you create are all "small", and they
    stay that way. On the other hand, the rest of the world (more or less)
    is generating packets on the assumption that everyone uses 1492 to
    1500 octet MTUs, and if these can't be fragmented, your link is
    isolated. On the box with the modem (which I expect is running your
    iptables setup), I'd suggest looking at the rules you have
    (/sbin/iptables -L) to see if there is anything related to the ICMP
    protocol.

    Old guy

  12. Re: Strange routing / NAT issue

    Shadow_7 wrote:
    ....

    > Yes, in the case of previous issues I only changed the MTU for packets on
    > the internal interfaces (eth0, wlan0) and left ppp0 untouched. Now when
    > the neice brings over her XBox 360 and wants to game online, I have to
    > change all MTU's to 1500. Otherwise it fails to even negotiate the
    > wireless connection to the router. Without 1500 on ppp0 it fails to
    > negotiate anything with the internet.


    If an XBox can't "negotiate the wireless connection to the router"
    when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
    Discovery enabled.

    --
    Clifford Kite

  13. Re: Strange routing / NAT issue

    > If an XBox can't "negotiate the wireless connection to the router"
    > when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
    > Discovery enabled.


    I think it was more that the XBox had an MTU of 1500 and no customization
    of that value. Although I wasn't the one on the other end of the
    controller making the changes. I don't run DHCP on the home network, so
    everything is for the most part hard coded. Which is only an issue when
    relatives come to visit with their tech gear. I'm probably more tech
    savvy than them, just not tech current.

  14. Re: Strange routing / NAT issue

    On Tue, 08 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
    article , Shadow_7 wrote:

    >> If an XBox can't "negotiate the wireless connection to the router"
    >> when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
    >> Discovery enabled.

    >
    >I think it was more that the XBox had an MTU of 1500 and no customization
    >of that value.


    Next time your niece brings the XBox over, set the MTU on your LAN to
    576, and then run /usr/sbin/tcpdump -n on that LAN side NIC. What you
    are looking for is

    12:34:56.780000 192.168.10.20.4283 > 192.168.33.55.53: S
    1759784758:1759784758(0) win 60352 (DF)

    which shows time, source_IP.port > destination_IP.port SYN_flag
    sequence_number:sequence_number(0) window_size (DF)

    and the key is the last item - the Don't_Fragment flag. If you see
    that flag (Ethereal/wireshark would also show the flag, but in a more
    user-friendly format), the system is set for PMTU discovery. In this
    particular case, the LAN MTU was large enough to carry the packet
    without fragmenting, and there would be subsequent packets from the
    destination making the handshake. A bit later, this host is going to
    send a packet that is to big (the number in parentheses following the
    sequence number will be something greater than ~540), and what SHOULD
    happen is that the "router" should send an ICMP Type 3 Code 4 error
    indicating that the packet is to large. That one you may see (if you
    don't, then you've discovered your problem is the router or relay
    between the router and your local host), but if the remote host this
    box is conversing with sends a packet that is to large, _IT_ should
    receive a similar ICMP Type 3 Code 4 error (which you won't see as
    it's directed at the remote). That remote host should send the reply
    in a smaller packet (perhaps without the DF flag set).

    Seeing as how many DSL setups are using PPPoE (which requires an
    MTU of 1492 rather than the 1500 normally used), I'd really expect
    the XBox to be ready to reset the packet size, or not use the DF
    flag, but only if it receives that ICMP error. But conversations
    are two-way, so both sides need to know about the lower than normal
    MTU so that they can adjust for it.

    Old guy

+ Reply to Thread