Prev: qt4 applications - font size
Next: qt4 applications - font size (solved)
From: Alex Samad on 25 Nov 2009 16:10
On Wed, Nov 25, 2009 at 09:34:30PM +0100, Guillaume CHARDIN wrote:
> 2009/11/25 Alex Samad <alex(a)samad.com.au>:
> > On Wed, Nov 25, 2009 at 08:03:52PM +0100, Guillaume CHARDIN wrote:
> >> Hi,
> > [snip]
> > so when you browse from the linux computer running pppoe you have
> > problems ? or only when you have a computer behind it.
>
> I don't have any graphical ui on the linux box but a `wget
> website.domain` is endless.
>
> To fix mtu problem, i edit the /etc/ppp/peer/dsl-provider and modify the line :
> mtu 1492
> to
> mtu 1450 (i tried many value between 1450-1400)
> the disconnect/reconnect.
> I tried to set it to another value with the ifconfig command too.
>
> And I found on an internal windows station a max mtu size of 1463
> (with ping -l 1463 -f)
>
> For information, the MTU discovery is set on iptable on the debian gateway :
> #iptables -t mangle -L
> [...]
> Chain FORWARD (policy ACCEPT)
> target prot opt source destination
> TCPMSS tcp -- anywhere anywhere tcp
> flags:SYN,RST/SYN tcpmss match 1400:1536 TCPMSS clamp to PMTU

Great thats about all the things I would have checked as well.

you can test from linux itself with ping -M do -s <packet size> -c 10
<dest ip>

I would try using the ping above to find the max mtu size to say
your isp dns or proxy.

then try it to the sites you can't always get to




>
> Thanks for your help

--
"But all in all, it's been a fabulous year for Laura and me."

- George W. Bush
12/20/2001
Washington, DC
summing up his first year in office, three months after the 9/11 attacks
From: Guillaume CHARDIN on 25 Nov 2009 16:50
> Great thats about all the things I would have checked as well.
>
> you can test from linux itself with ping -M do -s <packet size> -c 10
> <dest ip>
>
> I would try using the ping above to find the max mtu size to say
> your isp dns or proxy.
>
> then try it to the sites you can't always get to
>
>

I do the same test on the gateway and on windows clients below the results :

Linux debian 5
ping -M do -s 1465 -c 10 86.64.145.147
PING 86.64.145.147 (86.64.145.147) 1465(1493) bytes of data.
>From 86.77.213.79 icmp_seq=1 Frag needed and DF set (mtu = 1492)

ping -M do -s 1464 -c 10 86.64.145.147
PING 86.64.145.147 (86.64.145.147) 1464(1492) bytes of data.
1472 bytes from 86.64.145.147: icmp_seq=1 ttl=56 time=56.0 ms
--> So mtu is 1464 (+8 ?)

on windows :
ping -l 1464 -f 86.64.145.147
Envoi d'une requête 'ping' sur 86.64.145.147 avec 1464 octets de données :
Réponse de 86.64.145.147 : octets=1464 temps=54 ms TTL=55

ping -l 1465 -f 86.64.145.147
Envoi d'une requête 'ping' sur 86.64.145.147 avec 1465 octets de données :
Le paquet doit être fragmenté mais paramétré DF.
--> Same MTU 1464

Same thing on the websites i cannot access

Haha, this issue is starting to make me crazy !
--
Guillaume


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Alex Samad on 25 Nov 2009 17:10
On Wed, Nov 25, 2009 at 10:41:47PM +0100, Guillaume CHARDIN wrote:
> > Great thats about all the things I would have checked as well.
> >
> > you can test from linux itself with ping -M do -s <packet size> -c 10
> > <dest ip>
> >
> > I would try using the ping above to find the max mtu size to say
> > your isp dns or proxy.
> >
> > then try it to the sites you can't always get to
> >
> >
>
> I do the same test on the gateway and on windows clients below the results :
>
> Linux debian 5
> ping -M do -s 1465 -c 10 86.64.145.147
> PING 86.64.145.147 (86.64.145.147) 1465(1493) bytes of data.
> >From 86.77.213.79 icmp_seq=1 Frag needed and DF set (mtu = 1492)
>
> ping -M do -s 1464 -c 10 86.64.145.147
> PING 86.64.145.147 (86.64.145.147) 1464(1492) bytes of data.
> 1472 bytes from 86.64.145.147: icmp_seq=1 ttl=56 time=56.0 ms
> --> So mtu is 1464 (+8 ?)
>
> on windows :
> ping -l 1464 -f 86.64.145.147
> Envoi d'une requête 'ping' sur 86.64.145.147 avec 1464 octets de données :
> Réponse de 86.64.145.147 : octets=1464 temps=54 ms TTL=55
>
> ping -l 1465 -f 86.64.145.147
> Envoi d'une requête 'ping' sur 86.64.145.147 avec 1465 octets de données :
> Le paquet doit être fragmenté mais paramétré DF.
> --> Same MTU 1464
>
> Same thing on the websites i cannot access
>
> Haha, this issue is starting to make me crazy !

okay for something silly try setting the mtu to 1400 in pppoe.

check to make sure it is being set so in another window

tcpdump -pni ppp0 host <ip address of the site in question>

other window

wget <ip address of the site in question>

you can see the size being set in tcpdump.

if it still stalls after setting to 1400, try something smaller 900 -
just to make sure we are on the right track.

Alex


--
"You never know what your history is going to be like until long after you're gone."

- George W. Bush
05/05/2006
Washington, DC
From: Guillaume CHARDIN on 25 Nov 2009 18:10
> wget <ip address of the site in question>
>
> you can see the size being set in tcpdump.
>
> if it still stalls after setting to 1400, try something smaller 900 -
> just to make sure we are on the right track.
>
> Alex
>
>
I've done 4 tests
a) tcpdump in non promiscous mode and try to contact via wget
www.microsoft.com with a mtu set to 1400 : segment size is regulated
to 1360 so under the value
b) tcpdump in promiscous mode try to contact via wget
www.microsoft.com from win station same max mtu size : segment size is
regulated to 1360 so under the value
c) same as (a) but with a mtu of 1000 : packet size is maximized to 960...
d same as (b) but with mtu of 1000 : packet size is maximized to 960...


a)
# tcpdump -pni ppp0 host www.microsoft.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
22:16:31.535269 IP 86.69.85.63.49104 > 207.46.19.190.80: S
1429337682:1429337682(0) win 5440 <mss 1360,sackOK,timestamp 24647950
0,nop,wscale 1>
22:16:34.535269 IP 86.69.85.63.49104 > 207.46.19.190.80: S
1429337682:1429337682(0) win 5440 <mss 1360,sackOK,timestamp 24648700
0,nop,wscale 1>

b)
tcpdump -ni ppp0 host www.microsoft.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
22:21:24.527269 IP 86.69.85.63.3183 > 207.46.192.254.80: S
824552434:824552434(0) win 65535 <mss 1360,nop,nop,sackOK>

c)
tcpdump -pni ppp0 host www.microsoft.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
22:58:39.003269 IP 86.77.213.79.55709 > 207.46.19.190.80: S
2417518931:2417518931(0) win 3840 <mss 960,sackOK,timestamp 25279817
0,nop,wscale 1>

d)
tcpdump -ni ppp0 host www.microsoft.com
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
23:01:13.539269 IP 86.77.213.79.3433 > 65.55.21.250.80: S
1538952923:1538952923(0) win 65535 <mss 960,nop,nop,sackOK>

Ok so maybe its not mtu related ?! no ? what do you think about that Alex ?

--
Guillaume


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Alex Samad on 25 Nov 2009 18:50
On Thu, Nov 26, 2009 at 12:03:24AM +0100, Guillaume CHARDIN wrote:
> > wget <ip address of the site in question>
> >
> > you can see the size being set in tcpdump.
> >
> > if it still stalls after setting to 1400, try something smaller 900 -
> > just to make sure we are on the right track.
> >
> > Alex
> >
> >
> I've done 4 tests
> a) tcpdump in non promiscous mode and try to contact via wget
> www.microsoft.com with a mtu set to 1400 : segment size is regulated
> to 1360 so under the value
> b) tcpdump in promiscous mode try to contact via wget
> www.microsoft.com from win station same max mtu size : segment size is
> regulated to 1360 so under the value
> c) same as (a) but with a mtu of 1000 : packet size is maximized to 960...
> d same as (b) but with mtu of 1000 : packet size is maximized to 960...
>
>
> a)
> # tcpdump -pni ppp0 host www.microsoft.com
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
> 22:16:31.535269 IP 86.69.85.63.49104 > 207.46.19.190.80: S
> 1429337682:1429337682(0) win 5440 <mss 1360,sackOK,timestamp 24647950
> 0,nop,wscale 1>
> 22:16:34.535269 IP 86.69.85.63.49104 > 207.46.19.190.80: S
> 1429337682:1429337682(0) win 5440 <mss 1360,sackOK,timestamp 24648700
> 0,nop,wscale 1>
>
> b)
> tcpdump -ni ppp0 host www.microsoft.com
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
> 22:21:24.527269 IP 86.69.85.63.3183 > 207.46.192.254.80: S
> 824552434:824552434(0) win 65535 <mss 1360,nop,nop,sackOK>
>
> c)
> tcpdump -pni ppp0 host www.microsoft.com
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
> 22:58:39.003269 IP 86.77.213.79.55709 > 207.46.19.190.80: S
> 2417518931:2417518931(0) win 3840 <mss 960,sackOK,timestamp 25279817
> 0,nop,wscale 1>
>
> d)
> tcpdump -ni ppp0 host www.microsoft.com
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
> 23:01:13.539269 IP 86.77.213.79.3433 > 65.55.21.250.80: S
> 1538952923:1538952923(0) win 65535 <mss 960,nop,nop,sackOK>
>
> Ok so maybe its not mtu related ?! no ? what do you think about that Alex ?

Well by the looks of things, I would guess you are loosing packets
somewhere, I would presume than 960 mtu would work on all routers on the
internet by now


>

--
It's not reality that's important, but how you perceive things.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: qt4 applications - font size
Next: qt4 applications - font size (solved)