On Sat, 31 Jan 2004 14:06:11 +0000, Menno Duursma wrote:

> Yes. You want to make as sure as possible the packets "mozilla" and "lynx"
> gegerate look the same. (To rule out diffrences, being scheduled oddball).
>
> Try looking at the output of "tcpdump" and/or "etherreal" for that.


hmmmm. I took a closer look at the output of Mozilla Firebird as compared
to that of Links using Ethereal and the results are completely different.
This is interesting to note, as this setup worked fine before the upgrade
to 2.6.1. In any case, here is a breakdown of what I have found (I've
shortened it up a bit to make it easier to read).


The test site I used was postnuke.com. Reason being is that since the
upgrade, it is one of the sites that takes the longest to load (20s using
firebird, 5s using links). Here is the edited output of Ethereal:

Mozilla Firebird:

ARP who has 192.168.0.32? Tell 192.168.0.1
ARP 192.168.0.32 is at 00:60:97:78:9a:3a
DNS Standard query response
DNS Standard query AAAA postnuke.com.lv.cox.net
DNS Standard query response, No such name
DNS Standard query AAAA www.postnuke.info.lv.cox.net
DNS Standard query response, No such name
DNS Standard query A www.postnuke.info

....this goes on for some time before it actually connects and downloads data
from the site. Like I said, this kind of activity continues for about 20
seconds. Completely unacceptable for a 3MB Internet connection.



Links:
ARP who has 192.168.0.32? Tell 192.168.0.1
ARP 192.168.0.32 is at 00:60:97:78:9a:3a

DNS Standard query A www.postnuke.info
DNS Standard response A 66.227.122.74
DNS Standard query A www.postnuke.com
DNS Standard response A 66.227.122.74

It is at this point that the browser gets the resources it needs from the
site.... working well by the looks of it.


There is my problem in a nutshell. Thanks for pointing me to sniffing my
traffic from this box, Menno. Good idea that I failed to think of.