Prev: Routing to multiple gateways from a single NIC
Next: DHCP client and ifconfig
From: Shadow_7 on 4 Apr 2008 00:07
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.
From: Jurgen Haan on 4 Apr 2008 08:48
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-
From: Shadow_7 on 4 Apr 2008 17:23
> 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.
From: Moe Trin on 5 Apr 2008 14:51
On Fri, 04 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <otadnUIA1JbyAWvanZ2dnUVZ_qGknZ2d(a)earthlink.com>, 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
From: Clifford Kite on 5 Apr 2008 18:13
Moe Trin <ibuprofin(a)painkiller.example.tld> wrote:
> On Fri, 04 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
> article <otadnUIA1JbyAWvanZ2dnUVZ_qGknZ2d(a)earthlink.com>, 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 */
 |  Next  |  Last
Pages: 1 2 3
Prev: Routing to multiple gateways from a single NIC
Next: DHCP client and ifconfig