8:11 a.m.
Dear all,
a few days ago I had my home ADSL connection working, and it was working
incredibly fast!
Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
for some weeks here at work with very positive results.
After the upgrade at home, the connection became so slow that it is
almost unusable. I swear I didn't touch the network configuration, which
is indeed very simple: I only did the upgrade, leaving everything as it
was before.
Please note that I still had no chance to install the updates for FC2,
and since one of the first was the kernel itself, I guess I should try
to install them before posting this message.
But, right because of the very slow connection, I must download them at
work, burn a CD and bring it home, and I still had no time to do that.
At present I don't have the network config files with me, but I guess
they wouldn't be enough, so feel free to ask what file you need to
investigate.
Many thanks in advance.
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
8:29 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 24 June 2004 14:11, Andrea Giuliano wrote:
Dear all,
a few days ago I had my home ADSL connection working, and it was working
incredibly fast!
Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
for some weeks here at work with very positive results.
After the upgrade at home, the connection became so slow that it is
almost unusable. I swear I didn't touch the network configuration, which
is indeed very simple: I only did the upgrade, leaving everything as it
was before.
What kind of hardware interface does the ADSL modem have? If it is Ethernet,
use tcpdump to look at the traffic, eg, /sbin/tcpdump host 192.168.0.1 if
that is your ADSL router IP. If it is USB or something else, you need to use
tcpdump -i <interface name> instead.
You should consider turning off ECN as a test too since some routers choke on
it.
echo 0 > /proc/sys/net/ipv4/tcp_ecn
Also, what is your network setup like generally?
- -Andy
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2tcojKeDCxMJCTIRAs7LAKCLYIg+vp+mIF+7iGUHKu7tBw36hgCfT4JC
SSr5jOPW8eCUlxQrmKJyYWM=
=0v93
-----END PGP SIGNATURE-----
10:21 a.m.
On Thu, 2004-06-24 at 15:29, Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
What kind of hardware interface does the ADSL modem have? If it is Ethernet,
use tcpdump to look at the traffic, eg, /sbin/tcpdump host 192.168.0.1 if
that is your ADSL router IP. If it is USB or something else, you need to use
tcpdump -i <interface name> instead.
It's an Ethernet ADSL modem, namely the Siemens Gigaset. I'll try
tcpdump as soon as possible.
You should consider turning off ECN as a test too since some routers
choke on
it.
echo 0 > /proc/sys/net/ipv4/tcp_ecn
What's that?
Also, what is your network setup like generally?
Well, I started configuring eth0
and ppp0, but in an Italian document I
found a different suggestion: remove eth0 (using the "Network" menù
item), then add an xDSL connection with just a name ("Alice"), username
and password. All other fields must be left as they are. In particular,
the device used is eth0 by default, and IP and DNS info are obtained at
dialup.
Here is the /etc/sysconfig/network/devices/ifcfg-Alice script:
------
IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=yes
TYPE=xDSL
DEVICE=ppp0
BOOTPROTO=dialup
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=no
SYNCHRONOUS=no
DEFROUTE=yes
USER=aliceadsl
ETH=eth0
PROVIDER=Alice
DEMAND=no
-----
Can it be of help?
Thanks a lot anyway.
- -Andy
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2tcojKeDCxMJCTIRAs7LAKCLYIg+vp+mIF+7iGUHKu7tBw36hgCfT4JC
SSr5jOPW8eCUlxQrmKJyYWM=
=0v93
-----END PGP SIGNATURE-----
--
10:33 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 24 June 2004 16:21, Andrea Giuliano wrote:
It's an Ethernet ADSL modem, namely the Siemens Gigaset. I'll
try
tcpdump as soon as possible.
Many times looking at tcpdump in one terminal window and trying things in
another has given me the big clue :-) I would be looking at the DNS
resolution behaviour (UDP port 53 traffic) especially hard first.
> You should consider turning off ECN as a test too since some
routers
> choke on it.
> echo 0 > /proc/sys/net/ipv4/tcp_ecn
What's that?
Explicit Congestion Notification. It is a bit in the TCP header, I think.
Some router devices cannot handle seeing it and have a mental attack. FC2
can issue it by default.
> Also, what is your network setup like generally?
Well, I started configuring eth0 and ppp0, but in an Italian document I
found a different suggestion: remove eth0 (using the "Network" menù
item), then add an xDSL connection with just a name ("Alice"), username
Heh, I just got wifi working here using a similar trick :-)
system-config-network is really cool once you can get it started with such an
ifcfg-* file.
I have no experience with ADSL unfortunately, but I would imagine you can do
tcpdump -i Alice and just see traffic headed down there.
- -Andy
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2vRTjKeDCxMJCTIRAmN0AJ4j23YH41KPGxTYByTBNy9U6doizgCdEjee
pu0JepUPwX11DYk+0OmyN6c=
=lcbE
-----END PGP SIGNATURE-----
3:23 a.m.
On Thu, 2004-06-24 at 17:33, Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 24 June 2004 16:21, Andrea Giuliano wrote:
> It's an Ethernet ADSL modem, namely the Siemens Gigaset. I'll try
> tcpdump as soon as possible.
Many times looking at tcpdump in one terminal window and trying things in
another has given me the big clue :-) I would be looking at the DNS
resolution behaviour (UDP port 53 traffic) especially hard first.
I tried yesterday night, but the output is quite complicated. I only
noticed, while Epiphany was trying to access Google, many lines with
"www.google.it" and, I think, the actual IP address for Google. This
should mean that DNS is not the problem here. Also, "traceroute
www.google.it" immediately outputs several lines with IP addresses and
times in milliseconds, but it starts printing "*" after some lines,
which should mean that Google could not be reached but, at the same
time, that the name was resolved immediately. The same conclusion comes
from a "ping www.google.it";, which answers immediately everytime is
issued.
> > You should consider turning off ECN as a test too since
some routers
> > choke on it.
> > echo 0 > /proc/sys/net/ipv4/tcp_ecn
>
> What's that?
Explicit Congestion Notification. It is a bit in the TCP header, I think.
Some router devices cannot handle seeing it and have a mental attack. FC2
can issue it by default.
It's 0 already.
> > Also, what is your network setup like generally?
>
> Well, I started configuring eth0 and ppp0, but in an Italian document I
> found a different suggestion: remove eth0 (using the "Network" menù
> item), then add an xDSL connection with just a name ("Alice"), username
Heh, I just got wifi working here using a similar trick :-)
system-config-network is really cool once you can get it started with such an
ifcfg-* file.
I have no experience with ADSL unfortunately, but I would imagine you can do
tcpdump -i Alice and just see traffic headed down there.
- -Andy
Thanks, I think we are making some progress!
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA2vRTjKeDCxMJCTIRAmN0AJ4j23YH41KPGxTYByTBNy9U6doizgCdEjee
pu0JepUPwX11DYk+0OmyN6c=
=lcbE
-----END PGP SIGNATURE-----
-- 
3:57 a.m.
>
> On Thursday 24 June 2004 16:21, Andrea Giuliano wrote:
>
> > It's an Ethernet ADSL modem, namely the Siemens Gigaset. I'll try
> > tcpdump as soon as possible.
>
> Many times looking at tcpdump in one terminal window and trying things
in
> another has given me the big clue :-) I would be looking at the
DNS
> resolution behaviour (UDP port 53 traffic) especially hard first.
I tried yesterday night, but the output is quite complicated. I only
noticed, while Epiphany was trying to access Google, many lines with
"www.google.it" and, I think, the actual IP address for Google. This
should mean that DNS is not the problem here. Also, "traceroute
www.google.it" immediately outputs several lines with IP addresses and
times in milliseconds, but it starts printing "*" after some lines,
which should mean that Google could not be reached but, at the same
time, that the name was resolved immediately. The same conclusion comes
from a "ping www.google.it";, which answers immediately everytime is
issued.
> > > You should consider turning off ECN as a test too since some routers
> > > choke on it.
> > > echo 0 > /proc/sys/net/ipv4/tcp_ecn
> >
> > What's that?
>
> Explicit Congestion Notification. It is a bit in the TCP header, I
think.
> Some router devices cannot handle seeing it and have a mental
attack.
FC2
> can issue it by default.
>
It's 0 already.
> > > Also, what is your network setup like generally?
> >
> > Well, I started configuring eth0 and ppp0, but in an Italian document
I
> > found a different suggestion: remove eth0 (using the
"Network" menù
> > item), then add an xDSL connection with just a name ("Alice"),
username
>
> Heh, I just got wifi working here using a similar trick :-)
> system-config-network is really cool once you can get it started with
such an
> ifcfg-* file.
>
> I have no experience with ADSL unfortunately, but I would imagine you
can do
> tcpdump -i Alice and just see traffic headed down there.
>
> - -Andy
Thanks, I think we are making some progress!
perhaps (most probably) you should change your mtu settings of your eth0
card
common is 1490 or 1492
6:40 a.m.
On Fri, 2004-06-25 at 10:57, Fons van der Beek wrote:
perhaps (most probably) you should change your mtu settings of your
eth0
card
common is 1490 or 1492
I guess it is already. I'm almost sure I saw that value in the output of
tcpdump. The MTU for ppp is 1500, instead, and I think that's right:
1492+8, the eth0 MTU plus the 8 byte overhead of ppp.
But I need to check again. On Monday I'll be back with some logs and
outputs...
Best regards.
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
7:30 a.m.
Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 13:40:
On Fri, 2004-06-25 at 10:57, Fons van der Beek wrote:
>perhaps (most probably) you should change your mtu settings of your eth0
>card
>common is 1490 or 1492
>
>
I guess it is already. I'm almost sure I saw that value in the output of
tcpdump. The MTU for ppp is 1500, instead, and I think that's right:
1492+8, the eth0 MTU plus the 8 byte overhead of ppp.
But I need to check again. On Monday I'll be back with some logs and
outputs...
Best regards.
This is the output of
/sbin/ifconfig.... My MTU is 1500 on both ethernet cards and 1492 on
ppp.I have no problem with net surfing.Please check!!!
eth0 Link encap:Ethernet HWaddr 52:54:05:E5:82:46
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::5054:5ff:fee5:8246/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6532 errors:0 dropped:0 overruns:0 frame:0
TX packets:11639 errors:0 dropped:0 overruns:0 carrier:0
collisions:5 txqueuelen:1000
RX bytes:606287 (592.0 Kb) TX bytes:14855134 (14.1 Mb)
Interrupt:10 Base address:0xe400
eth1 Link encap:Ethernet HWaddr 00:00:B4:9D:0E:78
inet addr:192.168.254.2 Bcast:192.168.254.255 Mask:255.255.255.0
inet6 addr: fe80::200:b4ff:fe9d:e78/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:149273 errors:0 dropped:0 overruns:0 frame:1
TX packets:141513 errors:0 dropped:0 overruns:0 carrier:0
collisions:12 txqueuelen:1000
RX bytes:156985292 (149.7 Mb) TX bytes:13641641 (13.0 Mb)
Interrupt:5 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:60040 errors:0 dropped:0 overruns:0 frame:0
TX packets:60040 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:35245542 (33.6 Mb) TX bytes:35245542 (33.6 Mb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:80.117.47.154 P-t-P:192.168.100.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:147511 errors:0 dropped:0 overruns:0 frame:0
TX packets:139611 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:153628941 (146.5 Mb) TX bytes:10436433 (9.9 Mb)
--
Antonio
=========================================================
Working with Mozilla 1.7 on Redhat Linux Fedora Core 2
=========================================================
=========================================================
Uso Mozilla 1.7 su Redhat Linux Fedora Core 2
=========================================================
6:31 p.m.
On Fri, Jun 25, 2004 at 02:30:04PM +0200, antonio montagnani wrote:
Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 13:40:
>On Fri, 2004-06-25 at 10:57, Fons van der Beek wrote:
>
>
>>perhaps (most probably) you should change your mtu settings of your eth0
>>card common is 1490 or 1492
>>
>I guess it is already. I'm almost sure I saw that value in the output of
>tcpdump. The MTU for ppp is 1500, instead, and I think that's right:
>1492+8, the eth0 MTU plus the 8 byte overhead of ppp.
Changing/forcing the MTU is an optimization for most of us.
If a packet is routed and the best MTU at one hop is smaller than the
incoming packet then the packet must be fragmented. Since
fragmentation happens only once no matter how many hops the fragments
will be the smallest MTU that the standard permits. MTU discovery in
most TCP/IP software stacks takes care of this. If you snoop you
might see a handful of "do not fragment ICMP packets" pass as part of
this MTU discovery process. You might also see incoming fragments as
a hint but you cannot clearly know the reason for fragmenting the
packet.
With ppp there is encapsulation overhead that effectively reduces the
maximum MTU to a number smaller than the ethernet MTU. If your
environment blocks MTU discovery it is often nice to just set the
local MTU so packets simply 'fit'.
It turns out that a dropped fragment is hard to recover so if your
packet of data are being fragmented to a minimum value (I think the
number is 576) then you want to specify an MTU that passes end to end
to optimize the link. This is mostly important when links drop packets.
If you have local links that use 'large MTU packets' (FDDI,
Gigabit+jumbo) by default and MTU discovery fails then pay attention.
I happen to set my ethernet MTU to match what I know my NAT/firewall
box must pass via PPP. It lightens the load on my inexpensive NAT box.
For most of us today this is a don't care topic because MTU discovery
just works (YMMV).
--
T o m M i t c h e l l
/dev/null the ultimate in secure storage.
3:32 a.m.
Dear Antonio,
how did you choose the parameters for you eth0 interface? I suppose I
cannot choose the same, right? What should I use instead?
Also, with respect to another post of yours, how did you choose and set
the parameters I see in the output of "route -N"?
Many thanks again.
On Fri, 2004-06-25 at 14:30, antonio montagnani wrote:
Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 13:40:
>On Fri, 2004-06-25 at 10:57, Fons van der Beek wrote:
>
>
>
>>perhaps (most probably) you should change your mtu settings of your eth0
>>card
>>common is 1490 or 1492
>>
>>
>
>I guess it is already. I'm almost sure I saw that value in the output of
>tcpdump. The MTU for ppp is 1500, instead, and I think that's right:
>1492+8, the eth0 MTU plus the 8 byte overhead of ppp.
>
>But I need to check again. On Monday I'll be back with some logs and
>outputs...
>
>Best regards.
>
>
This is the output of
/sbin/ifconfig.... My MTU is 1500 on both ethernet cards and 1492 on
ppp.I have no problem with net surfing.Please check!!!
eth0 Link encap:Ethernet HWaddr 52:54:05:E5:82:46
inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::5054:5ff:fee5:8246/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:6532 errors:0 dropped:0 overruns:0 frame:0
TX packets:11639 errors:0 dropped:0 overruns:0 carrier:0
collisions:5 txqueuelen:1000
RX bytes:606287 (592.0 Kb) TX bytes:14855134 (14.1 Mb)
Interrupt:10 Base address:0xe400
eth1 Link encap:Ethernet HWaddr 00:00:B4:9D:0E:78
inet addr:192.168.254.2 Bcast:192.168.254.255 Mask:255.255.255.0
inet6 addr: fe80::200:b4ff:fe9d:e78/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:149273 errors:0 dropped:0 overruns:0 frame:1
TX packets:141513 errors:0 dropped:0 overruns:0 carrier:0
collisions:12 txqueuelen:1000
RX bytes:156985292 (149.7 Mb) TX bytes:13641641 (13.0 Mb)
Interrupt:5 Base address:0xe800
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:60040 errors:0 dropped:0 overruns:0 frame:0
TX packets:60040 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:35245542 (33.6 Mb) TX bytes:35245542 (33.6 Mb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:80.117.47.154 P-t-P:192.168.100.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:147511 errors:0 dropped:0 overruns:0 frame:0
TX packets:139611 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:153628941 (146.5 Mb) TX bytes:10436433 (9.9 Mb)
--
Antonio
=========================================================
Working with Mozilla 1.7 on Redhat Linux Fedora Core 2
=========================================================
=========================================================
Uso Mozilla 1.7 su Redhat Linux Fedora Core 2
=========================================================
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
3:58 a.m.
Andrea Giuliano wrote/ha scritto, On/il 01/07/2004 10:32:
Dear Antonio,
how did you choose the parameters for you eth0 interface? I suppose I
cannot choose the same, right? What should I use instead?
Also, with respect to another post of yours, how did you choose and set
the parameters I see in the output of "route -N"?
Many thanks again.
On Fri, 2004-06-25 at 14:30, antonio montagnani wrote:
>Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 13:40:
>
>
>
>>On Fri, 2004-06-25 at 10:57, Fons van der Beek wrote:
>>
>>
>>
>>
>>
>>>perhaps (most probably) you should change your mtu settings of your eth0
>>>card
>>>common is 1490 or 1492
>>>
>>>
>>>
>>>
>>I guess it is already. I'm almost sure I saw that value in the output of
>>tcpdump. The MTU for ppp is 1500, instead, and I think that's right:
>>1492+8, the eth0 MTU plus the 8 byte overhead of ppp.
>>
>>But I need to check again. On Monday I'll be back with some logs and
>>outputs...
>>
>>Best regards.
>>
>>
>>
>>
>This is the output of
>/sbin/ifconfig.... My MTU is 1500 on both ethernet cards and 1492 on
>ppp.I have no problem with net surfing.Please check!!!
>
>eth0 Link encap:Ethernet HWaddr 52:54:05:E5:82:46
> inet addr:192.168.0.1 Bcast:192.168.0.255 Mask:255.255.255.0
> inet6 addr: fe80::5054:5ff:fee5:8246/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:6532 errors:0 dropped:0 overruns:0 frame:0
> TX packets:11639 errors:0 dropped:0 overruns:0 carrier:0
> collisions:5 txqueuelen:1000
> RX bytes:606287 (592.0 Kb) TX bytes:14855134 (14.1 Mb)
> Interrupt:10 Base address:0xe400
>
>eth1 Link encap:Ethernet HWaddr 00:00:B4:9D:0E:78
> inet addr:192.168.254.2 Bcast:192.168.254.255 Mask:255.255.255.0
> inet6 addr: fe80::200:b4ff:fe9d:e78/64 Scope:Link
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:149273 errors:0 dropped:0 overruns:0 frame:1
> TX packets:141513 errors:0 dropped:0 overruns:0 carrier:0
> collisions:12 txqueuelen:1000
> RX bytes:156985292 (149.7 Mb) TX bytes:13641641 (13.0 Mb)
> Interrupt:5 Base address:0xe800
>
>lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> inet6 addr: ::1/128 Scope:Host
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:60040 errors:0 dropped:0 overruns:0 frame:0
> TX packets:60040 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:35245542 (33.6 Mb) TX bytes:35245542 (33.6 Mb)
>
>ppp0 Link encap:Point-to-Point Protocol
> inet addr:80.117.47.154 P-t-P:192.168.100.1 Mask:255.255.255.255
> UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
> RX packets:147511 errors:0 dropped:0 overruns:0 frame:0
> TX packets:139611 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:3
> RX bytes:153628941 (146.5 Mb) TX bytes:10436433 (9.9 Mb)
>
>
>--
>
> Antonio
>
> =========================================================
> Working with Mozilla 1.7 on Redhat Linux Fedora Core 2
> =========================================================
> =========================================================
> Uso Mozilla 1.7 su Redhat Linux Fedora Core 2
> =========================================================
>
>
What is your modem?? please note that my eth0 is the interface to the
LAN and eth1 is to Internet.
I didn't change nothing, I fixed only IP numbers for my comfort
(especially to the internal interface, as it is a router/proxy/gateway).
I get the DNS numbers from modem.....and I didn't touch any MTU setting
(Linux is not Windows..in a network!!!): it works just out of the box!!
Any way please post again the output of command route -n and revert to
the original MTU values....
--
Antonio
================================================
Working with Mozilla 1.7 on Linux Fedora Core 2
================================================
Utilizzo Mozilla 1.7 su Linux Fedora Core 2
================================================
5:11 a.m.
My modem is the Siemens Gigaset. I didn't find any version or release
number on the case nor in the documentation.
The documentation says that the address of the modem is 192.168.1.1.
Actually, if I give "ifconfig eth0 192.168.1.2", I can even look at
modem status and statistics accessing the modem internal web server with
Mozilla.
Just like you, I didn't change anything by hands, I only used
"system-config-network". I admit I made some test playing with DNS,
route, and such, but unfortunately I cannot backtrack them any longer.
My situation is different from yours, in that I have just the interface
to the Internet (eth0). But that's puzzling me, just the relation
between eth0 and ppp0: how they are related? Can I change eth0 address
without affecting ppp0, or must I set it just in one way? And what is
that way?
I'll be back tomorrow with the output you asked for.
Many thanks.
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
9:20 a.m.
Am Fr, den 25.06.2004 schrieb Fons van der Beek um 10:57:
perhaps (most probably) you should change your mtu settings of your
eth0
card common is 1490 or 1492
No, leave the MTU of ethernet devices as eth0 untouched at 1500! The MTU
of the ppp device is typically 1492.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) on Athlon CPU kernel 2.6.6-1.435
Serendipity 16:19:24 up 2 days, 14:57, load average: 0.70, 0.49, 0.21
12:31 p.m.
Am Do, den 24.06.2004 schrieb Andrea Giuliano um 15:11:
Dear all,
a few days ago I had my home ADSL connection working, and it was working
incredibly fast!
Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
for some weeks here at work with very positive results.
After the upgrade at home, the connection became so slow that it is
almost unusable.
What exactly is slow: The transfer rate (e.g. when you download a big
file from a fast server) or name resolution (getting the IP for a
hostname)?
I think you _may_ be hitting the problem with mozilla and IPV6, which is
turned on by default in FC2. There has been some discussion about this
last week on the list.
Christoph
3:32 a.m.
On Thu, 2004-06-24 at 19:31, Christoph Wickert wrote:
Am Do, den 24.06.2004 schrieb Andrea Giuliano um 15:11:
> Dear all,
>
> a few days ago I had my home ADSL connection working, and it was working
> incredibly fast!
>
> Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
> for some weeks here at work with very positive results.
>
> After the upgrade at home, the connection became so slow that it is
> almost unusable.
What exactly is slow: The transfer rate (e.g. when you download a big
file from a fast server) or name resolution (getting the IP for a
hostname)?
When I activate the ppp interface, it takes much more time than with
FC1. When I had FC1 running, the log almost immediately showed the lines
with the local and remote IP addresses and DNS' addresses. Now, after
the line "ppp <- /dev/pts... " or whatever, it takes ten or more seconds
to see those addresses.
After that moment, the connection itself is very slow. As I say in the
answer to Andy Green, some traceroute and ping command show that DNS is
not the issue here: name are resolved immediately. Traceroute starts
printing "*" after several lines which appears quite rapidly, and keeps
on this way for many many seconds, I never had that much patience to
wait for it to stop.
I think you _may_ be hitting the problem with mozilla and IPV6, which
is
turned on by default in FC2. There has been some discussion about this
last week on the list.
This sounds interesting. But how can I disable IPv6 to see if it's the
cause? Must I recompile the kernel, or have I just to echo something
somewhere in /proc?
Many thanks.
Christoph
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
4:11 a.m.
Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 10:32:
On Thu, 2004-06-24 at 19:31, Christoph Wickert wrote:
>Am Do, den 24.06.2004 schrieb Andrea Giuliano um 15:11:
>
>
>>Dear all,
>>
>>a few days ago I had my home ADSL connection working, and it was working
>>incredibly fast!
>>
>>Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
>>for some weeks here at work with very positive results.
>>
>>After the upgrade at home, the connection became so slow that it is
>>almost unusable.
>>
>>
>What exactly is slow: The transfer rate (e.g. when you download a big
>file from a fast server) or name resolution (getting the IP for a
>hostname)?
>
>
When I activate the ppp interface, it takes much more time than with
FC1. When I had FC1 running, the log almost immediately showed the lines
with the local and remote IP addresses and DNS' addresses. Now, after
the line "ppp <- /dev/pts... " or whatever, it takes ten or more seconds
to see those addresses.
After that moment, the connection itself is very slow. As I say in the
answer to Andy Green, some traceroute and ping command show that DNS is
not the issue here: name are resolved immediately. Traceroute starts
printing "*" after several lines which appears quite rapidly, and keeps
on this way for many many seconds, I never had that much patience to
wait for it to stop.
>I think you _may_ be hitting the problem with mozilla and IPV6, which is
>turned on by default in FC2. There has been some discussion about this
>last week on the list.
>
>
This sounds interesting. But how can I disable IPv6 to see if it's the
cause? Must I recompile the kernel, or have I just to echo something
somewhere in /proc?
Many thanks.
>Christoph
>
>
>
Can you post the result of the output of the command:
/sbin/route -N
This is mine, please take inaccount that my machine is a router with two
ethernet cards (one to ADSL modem, one to internal network)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 ppp0
Regards
--
Antonio
=========================================================
Working with Mozilla 1.7 on Redhat Linux Fedora Core 2
=========================================================
=========================================================
Uso Mozilla 1.7 su Redhat Linux Fedora Core 2
=========================================================
8:34 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 25 June 2004 10:11, antonio montagnani wrote:
>>I think you _may_ be hitting the problem with mozilla and
IPV6, which is
>>turned on by default in FC2. There has been some discussion about this
>>last week on the list.
>
>This sounds interesting. But how can I disable IPv6 to see if it's the
>cause? Must I recompile the kernel, or have I just to echo something
>somewhere in /proc?
There's some great advice flying on this thread, I'm sure a solution is coming
with a few more iterations :-)
The IPv6 thing that I have seen is that DNS lookups can favour IPv6 even when
there is no ability to route IPv6 "out the door". You can kill IPv6 (which
is completely useless assuming you do not use it on your intranet and cannot
send it out on the Internet), by adding
install ipv6 /bin/true
to /etc/modprobe.conf.
These kind of problems, and another stupid problem I once had of setting my
private DNS cache IP in /etc/resolv.conf and then taking the machine back to
my friend to use on the Internet, show up really clearly if you shine tcpdump
on the traffic :-)
I think trying to discover exactly where the slowness starts to come from will
be a good clue. What I understand so far is that ICMP traffic is fine
(ping/traceroute) but www.google.it (tcp) comes up slowly. You might find it
easier to use for example wget -O- www.google.it since this will not try to
bring in the graphic. Why not try that with tcpdump in another window and
paste the result.
- -Andy
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3CnxjKeDCxMJCTIRAlUSAJ0cnZFZiAvvRTtpXeifquM6EIhPUACdFp/b
Nzjj2eqHYK3Ye4EDPU3Xyhw=
=RFxs
-----END PGP SIGNATURE-----
9:04 p.m.
On Fri, 2004-06-25 at 06:34, Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 25 June 2004 10:11, antonio montagnani wrote:
> >>I think you _may_ be hitting the problem with mozilla and IPV6, which is
> >>turned on by default in FC2. There has been some discussion about this
> >>last week on the list.
The IPv6 thing that I have seen is that DNS lookups can favour IPv6 even when
there is no ability to route IPv6 "out the door". You can kill IPv6 (which
is completely useless assuming you do not use it on your intranet and cannot
send it out on the Internet), by adding
install ipv6 /bin/true
to /etc/modprobe.conf.
These kind of problems, and another stupid problem I once had of setting my
private DNS cache IP in /etc/resolv.conf and then taking the machine back to
my friend to use on the Internet, show up really clearly if you shine tcpdump
on the traffic :-)
You are right.. Just look at these tcpdump rates. (crtl-C after 5 secs)
with Hostname resolving, a 5 sec capture will only capture 3 packets.
1 packets captured
1922 packets received by filter
1798 packets dropped by kernel
W/o Hostname resolving, this turns out to be like 100+ packets.
245 packets captured
249 packets received by filter
0 packets dropped by kernel
Just Look at the Dropped Packets!!
I've not tried rebooting with that line yet.. But I expect good news
5:21 a.m.
I sure will try to remove ipv6 support! But why my box here at work,
which is running with IPV6 support, is working perfectly?
The difference is that here I'm connected via ethernet, not xDSL... This
is going to be more and more puzzling...
Best regards.
On Fri, 2004-06-25 at 15:34, Andy Green wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 25 June 2004 10:11, antonio montagnani wrote:
> >>I think you _may_ be hitting the problem with mozilla and IPV6, which is
> >>turned on by default in FC2. There has been some discussion about this
> >>last week on the list.
> >
> >This sounds interesting. But how can I disable IPv6 to see if it's the
> >cause? Must I recompile the kernel, or have I just to echo something
> >somewhere in /proc?
There's some great advice flying on this thread, I'm sure a solution is coming
with a few more iterations :-)
The IPv6 thing that I have seen is that DNS lookups can favour IPv6 even when
there is no ability to route IPv6 "out the door". You can kill IPv6 (which
is completely useless assuming you do not use it on your intranet and cannot
send it out on the Internet), by adding
install ipv6 /bin/true
to /etc/modprobe.conf.
These kind of problems, and another stupid problem I once had of setting my
private DNS cache IP in /etc/resolv.conf and then taking the machine back to
my friend to use on the Internet, show up really clearly if you shine tcpdump
on the traffic :-)
I think trying to discover exactly where the slowness starts to come from will
be a good clue. What I understand so far is that ICMP traffic is fine
(ping/traceroute) but www.google.it (tcp) comes up slowly. You might find it
easier to use for example wget -O- www.google.it since this will not try to
bring in the graphic. Why not try that with tcpdump in another window and
paste the result.
- -Andy
- --
Automatic actions for USB cameras, cardreaders, memory sticks, MP3 players
http://warmcat.com/usbautocam
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3CnxjKeDCxMJCTIRAlUSAJ0cnZFZiAvvRTtpXeifquM6EIhPUACdFp/b
Nzjj2eqHYK3Ye4EDPU3Xyhw=
=RFxs
-----END PGP SIGNATURE-----
--
3:47 a.m.
Dear Antonio,
as you may have seen in my last post (the one with several outputs and
log files), my MTU are the same as yours.
One output I didn't provide yet is that of "route -N". Nevertheless I
tried that command, as you suggested, but the result is just made up of
two lines, and I'm almost sure they are identical to the first and last
one of the output you provided. Previously, I saw several other lines, I
really don't know what happened to them...
Someone else suggested the problem was due to IPv6. I turned IPv6
support off, but nothing happened: everything works exactly as before
(or should I say, it doesn't work at all).
At last, I've got a sneaky suspicion that our good old friend Telecom
Italia has something to deal with this issue. Check the many lines in
the tcpdump output with "host x.x.x.x unreachable - admin prohibited
filter", and the others with "microsoft-ds". What do they mean? As
Telecom changed something so that I simply cannot access Alice this way?
I really don't know what else to try...
Best regards.
On Fri, 2004-06-25 at 11:11, antonio montagnani wrote:
Andrea Giuliano wrote/ha scritto, On/il 25/06/2004 10:32:
>On Thu, 2004-06-24 at 19:31, Christoph Wickert wrote:
>
>
>>Am Do, den 24.06.2004 schrieb Andrea Giuliano um 15:11:
>>
>>
>>>Dear all,
>>>
>>>a few days ago I had my home ADSL connection working, and it was working
>>>incredibly fast!
>>>
>>>Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
>>>for some weeks here at work with very positive results.
>>>
>>>After the upgrade at home, the connection became so slow that it is
>>>almost unusable.
>>>
>>>
>>What exactly is slow: The transfer rate (e.g. when you download a big
>>file from a fast server) or name resolution (getting the IP for a
>>hostname)?
>>
>>
>When I activate the ppp interface, it takes much more time than with
>FC1. When I had FC1 running, the log almost immediately showed the lines
>with the local and remote IP addresses and DNS' addresses. Now, after
>the line "ppp <- /dev/pts... " or whatever, it takes ten or more
seconds
>to see those addresses.
>
>After that moment, the connection itself is very slow. As I say in the
>answer to Andy Green, some traceroute and ping command show that DNS is
>not the issue here: name are resolved immediately. Traceroute starts
>printing "*" after several lines which appears quite rapidly, and keeps
>on this way for many many seconds, I never had that much patience to
>wait for it to stop.
>
>
>
>>I think you _may_ be hitting the problem with mozilla and IPV6, which is
>>turned on by default in FC2. There has been some discussion about this
>>last week on the list.
>>
>>
>
>This sounds interesting. But how can I disable IPv6 to see if it's the
>cause? Must I recompile the kernel, or have I just to echo something
>somewhere in /proc?
>
>Many thanks.
>
>
>
>>Christoph
>>
>>
>>
Can you post the result of the output of the command:
/sbin/route -N
This is mine, please take inaccount that my machine is a router with two
ethernet cards (one to ADSL modem, one to internal network)
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.100.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.254.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth1
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
0.0.0.0 192.168.100.1 0.0.0.0 UG 0 0 0 ppp0
Regards
--
Antonio
=========================================================
Working with Mozilla 1.7 on Redhat Linux Fedora Core 2
=========================================================
=========================================================
Uso Mozilla 1.7 su Redhat Linux Fedora Core 2
=========================================================
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
3:58 a.m.
Andrea Giuliano wrote/ha scritto, On/il 30/06/2004 10:47:
Dear Antonio,
as you may have seen in my last post (the one with several outputs and
log files), my MTU are the same as yours.
One output I didn't provide yet is that of "route -N". Nevertheless I
tried that command, as you suggested, but the result is just made up of
two lines, and I'm almost sure they are identical to the first and last
one of the output you provided. Previously, I saw several other lines, I
really don't know what happened to them...
Someone else suggested the problem was due to IPv6. I turned IPv6
support off, but nothing happened: everything works exactly as before
(or should I say, it doesn't work at all).
At last, I've got a sneaky suspicion that our good old friend Telecom
Italia has something to deal with this issue. Check the many lines in
the tcpdump output with "host x.x.x.x unreachable - admin prohibited
filter", and the others with "microsoft-ds". What do they mean? As
Telecom changed something so that I simply cannot access Alice this way?
I really don't know what else to try...
Best regards.
I suggest that you post the output of command route -n
I am connected both at home and office with Tin.it that is not very different from Alice
and I have good connection. My Ipv6 is ON on both systems and I do not suffer from any lag
during websurfing.
I am surprised that you have only two lines ....I suggest to re-start from scratch to
solve the problem (but not re-install of course).Some guru will help, I am sure!!!!
--
Antonio
================================================
Working with Mozilla 1.7 on Linux Fedora Core 2
================================================
Utilizzo Mozilla 1.7 su Linux Fedora Core 2
================================================
5:10 a.m.
I even tried to install FC1 on another partition, and creating the Alice
xDSL connection from scratch, but the result is always the same.
Are you really using an ADSL connection? What kind of modem do you have,
USB or Ethernet?
I'm afraid I need a whole team of gurus to solve this problem...
Thanks anyway for your kind help!
PS
Bestiale parlarsi in inglese fra italiani, neh?
On Wed, 2004-06-30 at 10:58, antonio montagnani wrote:
Andrea Giuliano wrote/ha scritto, On/il 30/06/2004 10:47:
>Dear Antonio,
>
>as you may have seen in my last post (the one with several outputs and
>log files), my MTU are the same as yours.
>
>One output I didn't provide yet is that of "route -N". Nevertheless I
>tried that command, as you suggested, but the result is just made up of
>two lines, and I'm almost sure they are identical to the first and last
>one of the output you provided. Previously, I saw several other lines, I
>really don't know what happened to them...
>
>Someone else suggested the problem was due to IPv6. I turned IPv6
>support off, but nothing happened: everything works exactly as before
>(or should I say, it doesn't work at all).
>
>At last, I've got a sneaky suspicion that our good old friend Telecom
>Italia has something to deal with this issue. Check the many lines in
>the tcpdump output with "host x.x.x.x unreachable - admin prohibited
>filter", and the others with "microsoft-ds". What do they mean? As
>Telecom changed something so that I simply cannot access Alice this way?
>
>I really don't know what else to try...
>
>Best regards.
>
>
>
I suggest that you post the output of command route -n
I am connected both at home and office with Tin.it that is not very different from Alice
and I have good connection. My Ipv6 is ON on both systems and I do not suffer from any lag
during websurfing.
I am surprised that you have only two lines ....I suggest to re-start from scratch to
solve the problem (but not re-install of course).Some guru will help, I am sure!!!!
--
Antonio
================================================
Working with Mozilla 1.7 on Linux Fedora Core 2
================================================
Utilizzo Mozilla 1.7 su Linux Fedora Core 2
================================================
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
5:37 a.m.
Andrea Giuliano wrote/ha scritto, On/il 30/06/2004 12:10:
I even tried to install FC1 on another partition, and creating the
Alice
xDSL connection from scratch, but the result is always the same.
Are you really using an ADSL connection? What kind of modem do you have,
USB or Ethernet?
I'm afraid I need a whole team of gurus to solve this problem...
Thanks anyway for your kind help!
PS
Bestiale parlarsi in inglese fra italiani, neh?
On Wed, 2004-06-30 at 10:58, antonio montagnani wrote:
>Andrea Giuliano wrote/ha scritto, On/il 30/06/2004 10:47:
>
>
>
Ethernet Ericcsson DP220 supplied by Tin.it...both home and office, and
both PC are gateway/routers....
--
Antonio
================================================
Working with Mozilla 1.7 on Linux Fedora Core 2
================================================
Utilizzo Mozilla 1.7 su Linux Fedora Core 2
================================================
5:43 a.m.
I have an idea.
Do not up ppp0 on boot.
Watch logfile ( tail -f /var/log/messages)
Start ppp0
Em Sex, 2004-06-25 às 05:32, Andrea Giuliano escreveu:
On Thu, 2004-06-24 at 19:31, Christoph Wickert wrote:
> Am Do, den 24.06.2004 schrieb Andrea Giuliano um 15:11:
> > Dear all,
> >
> > a few days ago I had my home ADSL connection working, and it was working
> > incredibly fast!
> >
> > Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
> > for some weeks here at work with very positive results.
> >
> > After the upgrade at home, the connection became so slow that it is
> > almost unusable.
>
> What exactly is slow: The transfer rate (e.g. when you download a big
> file from a fast server) or name resolution (getting the IP for a
> hostname)?
When I activate the ppp interface, it takes much more time than with
FC1. When I had FC1 running, the log almost immediately showed the lines
with the local and remote IP addresses and DNS' addresses. Now, after
the line "ppp <- /dev/pts... " or whatever, it takes ten or more seconds
to see those addresses.
After that moment, the connection itself is very slow. As I say in the
answer to Andy Green, some traceroute and ping command show that DNS is
not the issue here: name are resolved immediately. Traceroute starts
printing "*" after several lines which appears quite rapidly, and keeps
on this way for many many seconds, I never had that much patience to
wait for it to stop.
> I think you _may_ be hitting the problem with mozilla and IPV6, which is
> turned on by default in FC2. There has been some discussion about this
> last week on the list.
This sounds interesting. But how can I disable IPv6 to see if it's the
cause? Must I recompile the kernel, or have I just to echo something
somewhere in /proc?
Many thanks.
> Christoph
>
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
10:38 p.m.
Hi Andrea,
try installing ntop and running "ntop -i eth0"; then open
http://localhost:3000 on your preferred browser and watch all kinds of
network statistics you can imagine. Maybe this can give you an idea.
HTH
Andre
On Thu, 24 Jun 2004 15:11:14 +0200
Andrea Giuliano <a.giuliano(a)iccu.sbn.it> wrote:
Dear all,
a few days ago I had my home ADSL connection working, and it was
working incredibly fast!
Then I decided to upgrade from FC1 to FC2. Note that I've been using
FC2 for some weeks here at work with very positive results.
After the upgrade at home, the connection became so slow that it is
almost unusable. I swear I didn't touch the network configuration,
which is indeed very simple: I only did the upgrade, leaving
everything as it was before.
Please note that I still had no chance to install the updates for FC2,
and since one of the first was the kernel itself, I guess I should try
to install them before posting this message.
But, right because of the very slow connection, I must download them
at work, burn a CD and bring it home, and I still had no time to do
that.
At present I don't have the network config files with me, but I guess
they wouldn't be enough, so feel free to ask what file you need to
investigate.
Many thanks in advance.
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
--
fedora-list mailing list
fedora-list(a)redhat.com
To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
--
Andre Oliveira da Costa
3:54 a.m.
Dear posters,
first of all I wish to thank all of you for the answers.
Here are the missing outputs most of you asked for. I'll try to compare
them to the similar ones I found this morning on the list, but I'll be
back on Wednesday, because tomorros we are in holidays here in Rome.
1) /var/log/messages excerpt, just the lines written during the the ppp
connection:
Jun 27 23:49:28 localhost kernel: device eth0 left promiscuous mode
Jun 27 23:50:02 localhost pppd[4363]: pppd 2.4.2 started by root, uid 0
Jun 27 23:50:02 localhost pppd[4363]: Using interface ppp0
Jun 27 23:50:02 localhost pppd[4363]: Connect: ppp0 <--> /dev/pts/15
Jun 27 23:50:02 localhost pppoe[4364]: PPP session is 10956
Jun 27 23:50:14 localhost kernel: eth0: Promiscuous mode enabled.
Jun 27 23:50:14 localhost kernel: device eth0 entered promiscuous mode
Jun 27 23:50:20 localhost kernel: device eth0 left promiscuous mode
Jun 27 23:50:22 localhost pppd[4363]: PAP authentication succeeded
Jun 27 23:50:22 localhost pppd[4363]: local IP address 82.53.151.158
Jun 27 23:50:22 localhost pppd[4363]: remote IP address 192.168.100.1
Jun 27 23:50:22 localhost pppd[4363]: primary DNS address 80.21.7.56
Jun 27 23:50:22 localhost pppd[4363]: secondary DNS address 80.21.6.58
Jun 27 23:50:25 localhost kernel: device ppp0 entered promiscuous mode
Jun 27 23:53:34 localhost adsl-stop: Killing pppd
Jun 27 23:53:34 localhost adsl-stop: Killing adsl-connect
Jun 27 23:53:34 localhost pppd[4363]: Terminating on signal 15.
Jun 27 23:53:34 localhost last message repeated 11504 times
Jun 27 23:53:34 localhost pppoe[4364]: read (asyncReadFromPPP): Session 10956:
Input/output error
Jun 27 23:53:34 localhost pppoe[4364]: Sent PADT
2) output from ifconfig after ppp0 has come up:
eth0 Link encap:Ethernet HWaddr 00:20:ED:84:D4:86
inet6 addr: fe80::220:edff:fe84:d486/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:595 errors:0 dropped:0 overruns:0 frame:0
TX packets:542 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:46874 (45.7 Kb) TX bytes:40028 (39.0 Kb)
Interrupt:11 Base address:0xe000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:406 errors:0 dropped:0 overruns:0 frame:0
TX packets:406 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:30928 (30.2 Kb) TX bytes:30928 (30.2 Kb)
ppp0 Link encap:Point-to-Point Protocol
inet addr:82.51.169.145 P-t-P:192.168.100.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:3
RX bytes:102 (102.0 b) TX bytes:94 (94.0 b)
3) output from tcpdump -i ppp0, after ppp0 has come up and before it has
gone down again (sorry, it's 234 lines long):
23:50:26.836259 IP 217.144.248.190.42986 > 82.53.151.158.4662: S
1416838046:1416838046(0) win 5840 <mss 1412,sackOK,timestamp 113682885 0,nop,wscale
0>
23:50:27.073260 IP 82.53.151.158.4662 > 217.144.248.190.42986: R 0:0(0) ack 1416838047
win 0
23:50:26.836853 IP 82.53.151.158.32807 > 80.21.7.56.domain: 37702+ PTR?
158.151.53.82.in-addr.arpa. (44)
23:50:26.876061 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 217.144.248.190
unreachable - admin prohibited filter
23:50:26.885141 IP 80.21.7.56.domain > 82.53.151.158.32807: 37702 1/0/0 (94)
23:50:26.885330 IP 82.53.151.158.32807 > 80.21.7.56.domain: 37703+ PTR?
190.248.144.217.in-addr.arpa. (46)
23:50:27.073155 IP 80.21.7.56.domain > 82.53.151.158.32807: 37703 NXDomain 0/1/0
(109)
23:50:27.073447 IP 82.53.151.158.32807 > 80.21.7.56.domain: 37704+ PTR?
56.7.21.80.in-addr.arpa. (41)
23:50:27.116992 IP 80.21.7.56.domain > 82.53.151.158.32807: 37704 NXDomain 0/1/0
(112)
23:50:27.117176 IP 82.53.151.158.32807 > 80.21.7.56.domain: 37705+ PTR?
1.100.168.192.in-addr.arpa. (44)
23:50:27.160136 IP 80.21.7.56.domain > 82.53.151.158.32807: 37705 NXDomain 0/1/0
(121)
23:50:27.980100 IP 82.53.151.77.4100 > 82.53.151.158.microsoft-ds: S
568382196:568382196(0) win 16384 <mss 1412,nop,nop,sackOK>
23:50:27.980138 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4100: R 0:0(0) ack
568382197 win 0
23:50:27.980363 IP 82.53.151.158.32807 > 80.21.7.56.domain: 37706+ PTR?
77.151.53.82.in-addr.arpa. (43)
23:50:28.019020 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:50:28.032053 IP 80.21.7.56.domain > 82.53.151.158.32807: 37706 1/0/0 (92)
23:50:30.894367 IP 82.53.151.77.4100 > 82.53.151.158.microsoft-ds: S
568382196:568382196(0) win 16384 <mss 1412,nop,nop,sackOK>
23:50:30.894393 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4100: R 0:0(0) ack 1 win
0
23:50:30.933229 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:50:32.835355 IP 217.144.248.190.42986 > 82.53.151.158.4662: S
1416838046:1416838046(0) win 5840 <mss 1412,sackOK,timestamp 113683485 0,nop,wscale
0>
23:50:32.835379 IP 82.53.151.158.4662 > 217.144.248.190.42986: R 0:0(0) ack 1 win 0
23:50:32.875202 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 217.144.248.190
unreachable - admin prohibited filter
23:50:36.964492 IP 82.53.151.77.4100 > 82.53.151.158.microsoft-ds: S
568382196:568382196(0) win 16384 <mss 1412,nop,nop,sackOK>
23:50:36.964518 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4100: R 0:0(0) ack 1 win
0
23:50:37.003362 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:50:41.650953 IP 82.53.151.158.32807 > 80.21.7.56.domain: 64974+ AAAA?
fedora.redhat.com. (35)
23:50:43.170624 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412,nop,wscale 0,nop,nop,timestamp 1898400125 0>
23:50:43.170667 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 3923091241 win
0
23:50:43.170902 IP 82.53.151.158.32808 > 80.21.7.56.domain: 37707+ PTR?
38.126.61.81.in-addr.arpa. (43)
23:50:43.209558 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:50:43.280508 IP 80.21.7.56.domain > 82.53.151.158.32808: 37707 1/0/0 (83)
23:50:44.840626 IP 217.144.248.190.42986 > 82.53.151.158.4662: S
1416838046:1416838046(0) win 5840 <mss 1412,sackOK,timestamp 113684685 0,nop,wscale
0>
23:50:44.840651 IP 82.53.151.158.4662 > 217.144.248.190.42986: R 0:0(0) ack 1 win 0
23:50:44.879530 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 217.144.248.190
unreachable - admin prohibited filter
23:50:46.309542 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412,nop,wscale 0,nop,nop,timestamp 1898400130 0>
23:50:46.309567 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:50:46.349048 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:50:46.650459 IP 82.53.151.158.32808 > 80.21.6.58.domain: 64974+ AAAA?
fedora.redhat.com. (35)
23:50:46.650651 IP 82.53.151.158.32809 > 80.21.7.56.domain: 37708+ PTR?
58.6.21.80.in-addr.arpa. (41)
23:50:46.708703 IP 80.21.7.56.domain > 82.53.151.158.32809: 37708 NXDomain 0/1/0
(112)
23:50:48.125639 IP 80.129.158.173.4057 > 82.53.151.158.4662: S 494021183:494021183(0)
win 5808 <mss 1412,nop,nop,sackOK,nop,wscale 0>
23:50:48.125677 IP 82.53.151.158.4662 > 80.129.158.173.4057: R 0:0(0) ack 494021184 win
0
23:50:48.125913 IP 82.53.151.158.32809 > 80.21.7.56.domain: 37709+ PTR?
173.158.129.80.in-addr.arpa. (45)
23:50:48.165541 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 80.129.158.173
unreachable - admin prohibited filter
23:50:48.217772 IP 80.21.7.56.domain > 82.53.151.158.32809: 37709 1/0/0 (84)
23:50:48.799758 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412,nop,wscale 0,nop,nop,timestamp 1898400136 0>
23:50:48.799783 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:50:48.838639 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:50:51.329857 IP 80.129.158.173.4057 > 82.53.151.158.4662: S 494021183:494021183(0)
win 5808 <mss 1412,nop,nop,sackOK,nop,wscale 0>
23:50:51.329883 IP 82.53.151.158.4662 > 80.129.158.173.4057: R 0:0(0) ack 1 win 0
23:50:51.369765 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 80.129.158.173
unreachable - admin prohibited filter
23:50:51.650659 IP 82.53.151.158.32807 > 80.21.7.56.domain: 64974+ AAAA?
fedora.redhat.com. (35)
23:50:52.830824 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412>
23:50:52.830848 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:50:52.869734 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:50:54.818921 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412>
23:50:54.818946 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:50:54.858794 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:50:56.650899 IP 82.53.151.158.32808 > 80.21.6.58.domain: 64974+ AAAA?
fedora.redhat.com. (35)
23:50:57.094002 IP 80.129.158.173.4057 > 82.53.151.158.4662: S 494021183:494021183(0)
win 5808 <mss 1412,nop,nop,sackOK,nop,wscale 0>
23:50:57.094027 IP 82.53.151.158.4662 > 80.129.158.173.4057: R 0:0(0) ack 1 win 0
23:50:57.132895 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 80.129.158.173
unreachable - admin prohibited filter
23:50:57.607931 IP 66.201.198.19.1533 > 82.53.151.158.microsoft-ds: R 0:3(3) ack 0 win
0
23:50:57.608166 IP 82.53.151.158.32809 > 80.21.7.56.domain: 37710+ PTR?
19.198.201.66.in-addr.arpa. (44)
23:50:57.653978 IP 80.21.7.56.domain > 82.53.151.158.32809: 37710 1/0/0 (95)
23:50:57.713878 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412>
23:50:57.713903 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:50:57.753759 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:51:01.651191 IP 82.53.151.158.32809 > 80.21.7.56.domain: 64975+ AAAA?
fedora.redhat.com. (35)
23:51:03.031087 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412>
23:51:03.031112 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:51:03.071085 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:51:06.651413 IP 82.53.151.158.32810 > 80.21.6.58.domain: 64975+ AAAA?
fedora.redhat.com. (35)
23:51:09.092151 IP 80.129.158.173.4057 > 82.53.151.158.4662: S 494021183:494021183(0)
win 5808 <mss 1412,nop,nop,sackOK,nop,wscale 0>
23:51:09.092177 IP 82.53.151.158.4662 > 80.129.158.173.4057: R 0:0(0) ack 1 win 0
23:51:09.131275 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 80.129.158.173
unreachable - admin prohibited filter
23:51:11.651621 IP 82.53.151.158.32809 > 80.21.7.56.domain: 64975+ AAAA?
fedora.redhat.com. (35)
23:51:12.331360 IP 83.35.148.238.23250 > 82.53.151.158.4662: S 954831870:954831870(0)
win 64240 <mss 1400,nop,nop,sackOK>
23:51:12.331401 IP 82.53.151.158.4662 > 83.35.148.238.23250: R 0:0(0) ack 954831871 win
0
23:51:12.331648 IP 82.53.151.158.32811 > 80.21.7.56.domain: 37711+ PTR?
238.148.35.83.in-addr.arpa. (44)
23:51:12.371238 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 83.35.148.238
unreachable - admin prohibited filter
23:51:12.465348 IP 80.21.7.56.domain > 82.53.151.158.32811: 37711 1/0/0 (94)
23:51:14.871324 IP 81.61.126.38.14411 > 82.53.151.158.4662: S 3923091240:3923091240(0)
win 32768 <mss 1412>
23:51:14.871350 IP 82.53.151.158.4662 > 81.61.126.38.14411: R 0:0(0) ack 1 win 0
23:51:14.911425 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 81.61.126.38
unreachable - admin prohibited filter
23:51:15.260336 IP 83.35.148.238.23250 > 82.53.151.158.4662: S 954831870:954831870(0)
win 64240 <mss 1400,nop,nop,sackOK>
23:51:15.260361 IP 82.53.151.158.4662 > 83.35.148.238.23250: R 0:0(0) ack 1 win 0
23:51:16.495465 IP 207.172.126.42.4007 > 82.53.151.158.microsoft-ds: S
1052150086:1052150086(0) win 64240 <mss 1412,nop,nop,sackOK>
23:51:16.495507 IP 82.53.151.158.microsoft-ds > 207.172.126.42.4007: R 0:0(0) ack
1052150087 win 0
23:51:16.495748 IP 82.53.151.158.32811 > 80.21.7.56.domain: 37712+ PTR?
42.126.172.207.in-addr.arpa. (45)
23:51:16.534403 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 207.172.126.42
unreachable - admin prohibited filter
23:51:16.542470 IP 80.21.7.56.domain > 82.53.151.158.32811: 37712 1/0/0 (112)
23:51:16.651856 IP 82.53.151.158.32810 > 80.21.6.58.domain: 64975+ AAAA?
fedora.redhat.com. (35)
23:51:19.508504 IP 207.172.126.42.4007 > 82.53.151.158.microsoft-ds: S
1052150086:1052150086(0) win 64240 <mss 1412,nop,nop,sackOK>
23:51:19.508530 IP 82.53.151.158.microsoft-ds > 207.172.126.42.4007: R 0:0(0) ack 1 win
0
23:51:19.548373 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 207.172.126.42
unreachable - admin prohibited filter
23:51:21.652384 IP 82.53.151.158.32811 > 80.21.7.56.domain: 64976+ A?
fedora.redhat.com. (35)
23:51:21.693685 IP 80.21.7.56.domain > 82.53.151.158.32811: 64976+ [1a] [0q] (45)
23:51:25.479639 IP 192.168.100.1 > 224.0.0.1: igmp query v2
23:51:25.479842 IP 82.53.151.158.32812 > 80.21.7.56.domain: 37713+ PTR?
1.0.0.224.in-addr.arpa. (40)
23:51:25.537722 IP 80.21.7.56.domain > 82.53.151.158.32812: 37713 1/0/0 PTR[|domain]
23:51:26.693352 IP 82.53.151.158.32812 > 80.21.6.58.domain: 64976+ A?
fedora.redhat.com. (35)
23:51:26.772629 IP 80.21.6.58.domain > 82.53.151.158.32812: 64976+ [1a] [0q] (45)
23:51:31.772563 IP 82.53.151.158.32811 > 80.21.7.56.domain: 64976+ A?
fedora.redhat.com. (35)
23:51:31.814882 IP 80.21.7.56.domain > 82.53.151.158.32811: 64976+ [1a] [0q] (45)
23:51:36.814791 IP 82.53.151.158.32812 > 80.21.6.58.domain: 64976+ A?
fedora.redhat.com. (35)
23:51:36.895085 IP 80.21.6.58.domain > 82.53.151.158.32812: 64976+ [1a] [0q] (45)
23:51:41.895077 IP 82.53.151.158.32813 > 80.21.7.56.domain: 64977+ A?
fedora.redhat.com. (35)
23:51:41.937024 IP 80.21.7.56.domain > 82.53.151.158.32813: 64977+ [1a] [0q] (45)
23:51:42.865126 IP 82.50.73.108.4956 > 82.53.151.158.135: S 2246548242:2246548242(0)
win 16384 <mss 1412,nop,nop,sackOK>
23:51:42.865165 IP 82.53.151.158.135 > 82.50.73.108.4956: R 0:0(0) ack 2246548243 win
0
23:51:42.865396 IP 82.53.151.158.32814 > 80.21.7.56.domain: 37714+ PTR?
108.73.50.82.in-addr.arpa. (43)
23:51:42.904056 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.50.73.108
unreachable - admin prohibited filter
23:51:42.926209 IP 80.21.7.56.domain > 82.53.151.158.32814: 37714 1/0/0 (92)
23:51:44.748262 IP localhost.localdomain.http > 82.53.151.158.1845: R 0:0(0) ack
1069088769 win 0
23:51:45.707176 IP 82.50.73.108.4956 > 82.53.151.158.135: S 2246548242:2246548242(0)
win 16384 <mss 1412,nop,nop,sackOK>
23:51:45.707201 IP 82.53.151.158.135 > 82.50.73.108.4956: R 0:0(0) ack 1 win 0
23:51:45.746070 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.50.73.108
unreachable - admin prohibited filter
23:51:46.937276 IP 82.53.151.158.32814 > 80.21.6.58.domain: 64977+ A?
fedora.redhat.com. (35)
23:51:47.017200 IP 80.21.6.58.domain > 82.53.151.158.32814: 64977+ [1a] [0q] (45)
23:51:52.017482 IP 82.53.151.158.32813 > 80.21.7.56.domain: 64977+ A?
fedora.redhat.com. (35)
23:51:52.059454 IP 80.21.7.56.domain > 82.53.151.158.32813: 64977+ [1a] [0q] (45)
23:51:54.262361 IP 208.28.230.28.40674 > 82.53.151.158.microsoft-ds: S
3830808558:3830808558(0) win 64512 <mss 1380,nop,nop,sackOK>
23:51:54.262403 IP 82.53.151.158.microsoft-ds > 208.28.230.28.40674: R 0:0(0) ack
3830808559 win 0
23:51:54.262641 IP 82.53.151.158.32815 > 80.21.7.56.domain: 37715+ PTR?
28.230.28.208.in-addr.arpa. (44)
23:51:54.301504 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 208.28.230.28
unreachable - admin prohibited filter
23:51:54.429425 IP 80.21.7.56.domain > 82.53.151.158.32815: 37715 NXDomain 0/1/0
(120)
23:51:57.059716 IP 82.53.151.158.32814 > 80.21.6.58.domain: 64977+ A?
fedora.redhat.com. (35)
23:51:57.136378 IP 80.21.6.58.domain > 82.53.151.158.32814: 64977+ [1a] [0q] (45)
23:51:57.295538 IP 208.28.230.28.40674 > 82.53.151.158.microsoft-ds: S
3830808558:3830808558(0) win 64512 <mss 1380,nop,nop,sackOK>
23:51:57.295564 IP 82.53.151.158.microsoft-ds > 208.28.230.28.40674: R 0:0(0) ack 1 win
0
23:51:57.335439 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 208.28.230.28
unreachable - admin prohibited filter
23:52:00.156566 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412,nop,wscale 0,nop,nop,timestamp 2192487124
0>
23:52:00.156608 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 3334071387
win 0
23:52:00.156838 IP 82.53.151.158.32815 > 80.21.7.56.domain: 37716+ PTR?
21.221.109.194.in-addr.arpa. (45)
23:52:00.195514 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:00.324576 IP 80.21.7.56.domain > 82.53.151.158.32815: 37716 1/0/0 (77)
23:52:00.665606 IP 82.53.151.77.1860 > 82.53.151.158.microsoft-ds: S
865356270:865356270(0) win 16384 <mss 1412,nop,nop,sackOK>
23:52:00.665631 IP 82.53.151.158.microsoft-ds > 82.53.151.77.1860: R 0:0(0) ack
865356271 win 0
23:52:00.704490 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:52:00.930691 IP 82.53.144.160.4029 > 82.53.151.158.135: S 780828066:780828066(0) win
16384 <mss 1412,nop,nop,sackOK>
23:52:00.930732 IP 82.53.151.158.135 > 82.53.144.160.4029: R 0:0(0) ack 780828067 win
0
23:52:00.930946 IP 82.53.151.158.32815 > 80.21.7.56.domain: 37717+ PTR?
160.144.53.82.in-addr.arpa. (44)
23:52:00.992531 IP 80.21.7.56.domain > 82.53.151.158.32815: 37717 1/0/0 (94)
23:52:02.136168 IP 82.53.151.158.32815 > 80.21.7.56.domain: 17117+ AAAA?
fedora.redhat.com. (35)
23:52:02.958661 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412,nop,wscale 0,nop,nop,timestamp 2192487129
0>
23:52:02.958686 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:02.997606 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:03.333668 IP 208.28.230.28.40674 > 82.53.151.158.microsoft-ds: S
3830808558:3830808558(0) win 64512 <mss 1380,nop,nop,sackOK>
23:52:03.333694 IP 82.53.151.158.microsoft-ds > 208.28.230.28.40674: R 0:0(0) ack 1 win
0
23:52:03.635760 IP 82.53.151.77.1860 > 82.53.151.158.microsoft-ds: S
865356270:865356270(0) win 16384 <mss 1412,nop,nop,sackOK>
23:52:03.635785 IP 82.53.151.158.microsoft-ds > 82.53.151.77.1860: R 0:0(0) ack 1 win
0
23:52:03.675637 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:52:03.929686 IP 82.53.144.160.4029 > 82.53.151.158.135: S 780828066:780828066(0) win
16384 <mss 1412,nop,nop,sackOK>
23:52:03.929711 IP 82.53.151.158.135 > 82.53.144.160.4029: R 0:0(0) ack 1 win 0
23:52:05.919752 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412,nop,wscale 0,nop,nop,timestamp 2192487135
0>
23:52:05.919778 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:05.957632 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:07.136206 IP 82.53.151.158.32816 > 80.21.6.58.domain: 17117+ AAAA?
fedora.redhat.com. (35)
23:52:08.907887 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412>
23:52:08.907913 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:08.947719 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:09.705890 IP 82.53.151.77.1860 > 82.53.151.158.microsoft-ds: S
865356270:865356270(0) win 16384 <mss 1412,nop,nop,sackOK>
23:52:09.705914 IP 82.53.151.158.microsoft-ds > 82.53.151.77.1860: R 0:0(0) ack 1 win
0
23:52:09.745773 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:52:11.192822 IP 82.53.48.170.1384 > 82.53.151.158.microsoft-ds: S
1211941074:1211941074(0) win 16384 <mss 1412,nop,nop,sackOK>
23:52:11.192863 IP 82.53.151.158.microsoft-ds > 82.53.48.170.1384: R 0:0(0) ack
1211941075 win 0
23:52:11.193100 IP 82.53.151.158.32817 > 80.21.7.56.domain: 37718+ PTR?
170.48.53.82.in-addr.arpa. (43)
23:52:11.232182 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.48.170
unreachable - admin prohibited filter
23:52:11.256832 IP 80.21.7.56.domain > 82.53.151.158.32817: 37718 1/0/0 (92)
23:52:11.934906 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412>
23:52:11.934931 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:11.973803 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:12.136422 IP 82.53.151.158.32815 > 80.21.7.56.domain: 17117+ AAAA?
fedora.redhat.com. (35)
23:52:14.136888 IP 82.53.48.170.1384 > 82.53.151.158.microsoft-ds: S
1211941074:1211941074(0) win 16384 <mss 1412,nop,nop,sackOK>
23:52:14.136914 IP 82.53.151.158.microsoft-ds > 82.53.48.170.1384: R 0:0(0) ack 1 win
0
23:52:14.176000 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.48.170
unreachable - admin prohibited filter
23:52:14.932953 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412>
23:52:14.932989 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:14.973063 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:17.136669 IP 82.53.151.158.32816 > 80.21.6.58.domain: 17117+ AAAA?
fedora.redhat.com. (35)
23:52:20.921314 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412>
23:52:20.921339 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:20.960154 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:22.136956 IP 82.53.151.158.32817 > 80.21.7.56.domain: 17118+ AAAA?
fedora.redhat.com. (35)
23:52:25.521236 IP 192.168.100.1 > 224.0.0.1: igmp query v2
23:52:27.137165 IP 82.53.151.158.32818 > 80.21.6.58.domain: 17118+ AAAA?
fedora.redhat.com. (35)
23:52:32.137785 IP 82.53.151.158.32817 > 80.21.7.56.domain: 17118+ AAAA?
fedora.redhat.com. (35)
23:52:32.948588 IP 194.109.221.21.56326 > 82.53.151.158.4662: S
3334071386:3334071386(0) win 65535 <mss 1412>
23:52:32.948614 IP 82.53.151.158.4662 > 194.109.221.21.56326: R 0:0(0) ack 1 win 0
23:52:32.987494 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 194.109.221.21
unreachable - admin prohibited filter
23:52:37.137701 IP 82.53.151.158.32818 > 80.21.6.58.domain: 17118+ AAAA?
fedora.redhat.com. (35)
23:52:42.138521 IP 82.53.151.158.32818 > 80.21.7.56.domain: 17119+ A?
fedora.redhat.com. (35)
23:52:42.180701 IP 80.21.7.56.domain > 82.53.151.158.32818: 17119+ [1a] [0q] (45)
23:52:47.180730 IP 82.53.151.158.32819 > 80.21.6.58.domain: 17119+ A?
fedora.redhat.com. (35)
23:52:47.250810 IP 80.21.6.58.domain > 82.53.151.158.32819: 17119+ [1a] [0q] (45)
23:52:52.250326 IP 82.53.151.158.32818 > 80.21.7.56.domain: 17119+ A?
fedora.redhat.com. (35)
23:52:52.292060 IP 80.21.7.56.domain > 82.53.151.158.32818: 17119+ [1a] [0q] (45)
23:52:57.291587 IP 82.53.151.158.32819 > 80.21.6.58.domain: 17119+ A?
fedora.redhat.com. (35)
23:52:57.372233 IP 80.21.6.58.domain > 82.53.151.158.32819: 17119+ [1a] [0q] (45)
23:53:02.371825 IP 82.53.151.158.32819 > 80.21.7.56.domain: 17120+ A?
fedora.redhat.com. (35)
23:53:02.414208 IP 80.21.7.56.domain > 82.53.151.158.32819: 17120+ [1a] [0q] (45)
23:53:02.594265 IP 82.53.149.48.4779 > 82.53.151.158.135: S 1511895157:1511895157(0)
win 16384 <mss 1412,nop,nop,sackOK>
23:53:02.594307 IP 82.53.151.158.135 > 82.53.149.48.4779: R 0:0(0) ack 1511895158 win
0
23:53:02.594546 IP 82.53.151.158.32820 > 80.21.7.56.domain: 37719+ PTR?
48.149.53.82.in-addr.arpa. (43)
23:53:02.634609 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.149.48
unreachable - admin prohibited filter
23:53:02.641380 IP 80.21.7.56.domain > 82.53.151.158.32820: 37719 1/0/0 (92)
23:53:03.957313 IP 82.53.151.77.3539 > 82.53.151.158.microsoft-ds: S
1067339000:1067339000(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:03.957339 IP 82.53.151.158.microsoft-ds > 82.53.151.77.3539: R 0:0(0) ack
1067339001 win 0
23:53:03.996217 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:53:05.566447 IP 82.53.149.48.4779 > 82.53.151.158.135: S 1511895157:1511895157(0)
win 16384 <mss 1412,nop,nop,sackOK>
23:53:05.566472 IP 82.53.151.158.135 > 82.53.149.48.4779: R 0:0(0) ack 1 win 0
23:53:05.606326 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.149.48
unreachable - admin prohibited filter
23:53:06.907524 IP 82.53.151.77.3539 > 82.53.151.158.microsoft-ds: S
1067339000:1067339000(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:06.907551 IP 82.53.151.158.microsoft-ds > 82.53.151.77.3539: R 0:0(0) ack 1 win
0
23:53:06.947356 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:53:07.414042 IP 82.53.151.158.32820 > 80.21.6.58.domain: 17120+ A?
fedora.redhat.com. (35)
23:53:07.494403 IP 80.21.6.58.domain > 82.53.151.158.32820: 17120+ [1a] [0q] (45)
23:53:10.384474 IP 82.53.151.77.4469 > 82.53.151.158.microsoft-ds: S
1088524029:1088524029(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:10.384500 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4469: R 0:0(0) ack
1088524030 win 0
23:53:10.423381 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:53:12.494290 IP 82.53.151.158.32819 > 80.21.7.56.domain: 17120+ A?
fedora.redhat.com. (35)
23:53:12.536633 IP 80.21.7.56.domain > 82.53.151.158.32819: 17120+ [1a] [0q] (45)
23:53:12.942675 IP 82.53.151.77.3539 > 82.53.151.158.microsoft-ds: S
1067339000:1067339000(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:12.942701 IP 82.53.151.158.microsoft-ds > 82.53.151.77.3539: R 0:0(0) ack 1 win
0
23:53:12.981555 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:53:13.345498 IP 82.53.151.77.4469 > 82.53.151.158.microsoft-ds: S
1088524029:1088524029(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:13.345523 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4469: R 0:0(0) ack 1 win
0
23:53:17.539240 IP 82.53.151.158.32820 > 80.21.6.58.domain: 17120+ A?
fedora.redhat.com. (35)
23:53:17.597600 IP 80.21.6.58.domain > 82.53.151.158.32820: 17120+ [1a] [0q] (45)
23:53:19.411710 IP 82.53.151.77.4469 > 82.53.151.158.microsoft-ds: S
1088524029:1088524029(0) win 16384 <mss 1412,nop,nop,sackOK>
23:53:19.411735 IP 82.53.151.158.microsoft-ds > 82.53.151.77.4469: R 0:0(0) ack 1 win
0
23:53:19.451588 IP 192.168.100.1 > 82.53.151.158: icmp 36: host 82.53.151.77
unreachable - admin prohibited filter
23:53:25.546918 IP 192.168.100.1 > 224.0.0.1: igmp query v2
4) content of the file ifcfg-alice ("Alice" is the name of the provider):
# Please read /usr/share/doc/initscripts-*/sysconfig.txt
# for the documentation of these parameters.
IPV6INIT=no
ONBOOT=no
USERCTL=yes
PEERDNS=yes
TYPE=xDSL
DEVICE=ppp0
BOOTPROTO=dialup
PIDFILE=/var/run/pppoe-adsl.pid
FIREWALL=NONE
PING=.
PPPOE_TIMEOUT=80
LCP_FAILURE=3
LCP_INTERVAL=20
CLAMPMSS=1412
CONNECT_POLL=6
CONNECT_TIMEOUT=60
PERSIST=no
SYNCHRONOUS=no
DEFROUTE=yes
USER=aliceadsl
ETH=eth0
PROVIDER=alice
DEMAND=no
5) content of /etc/resolv.conf
# MADE-BY-RP-PPPOE
nameserver 80.21.7.56
nameserver 80.21.6.58
Well, that's all for now. Thanks a lot again for your help!
Best regards.
On Thu, 2004-06-24 at 15:11, Andrea Giuliano wrote:
Dear all,
a few days ago I had my home ADSL connection working, and it was working
incredibly fast!
Then I decided to upgrade from FC1 to FC2. Note that I've been using FC2
for some weeks here at work with very positive results.
After the upgrade at home, the connection became so slow that it is
almost unusable. I swear I didn't touch the network configuration, which
is indeed very simple: I only did the upgrade, leaving everything as it
was before.
Please note that I still had no chance to install the updates for FC2,
and since one of the first was the kernel itself, I guess I should try
to install them before posting this message.
But, right because of the very slow connection, I must download them at
work, burn a CD and bring it home, and I still had no time to do that.
At present I don't have the network config files with me, but I guess
they wouldn't be enough, so feel free to ask what file you need to
investigate.
Many thanks in advance.
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
--
Andrea Giuliano, Ph. D.
ICCU - Istituto Centrale per il Catalogo Unico
Viale Castro Pretorio 105, Rome - ITALY
Tel. +39064989509, Fax +39064059302
7262
days inactive
7269
days old
25 comments
10 participants
participants (10)
-
Alexander Dalloz -
Andre Costa -
Andrea Giuliano -
Andy Green -
Antonio Montagnani -
Christoph Wickert -
Cosme Faria Corrêa -
Fons van der Beek -
Ow Mun Heng -
Tom Mitchell