Two hardware-related problems with Knoppix 5.0.1

Ok then everyone, here goes...

I think going from Harry's last sentence that there's a DNS problem. When I follow as suggested and try to access that check IP website while running ethereal, things work quite smoothly in Konqueror.

But when I put the URL into Firefox, the destination IP is weird: 1.0.0.0. However when I enter the IP address directly into Firefox, it connects fine, no problems at all. This extends to the URL - so if I've entered the IP first and it connects, FF always connects when the URL is subsequently entered.

So does is sound as though there is some sort of DNS error? OR should I provide more information from the ethereal output? If it is a DNS issue, is there anything I can do? I read somewhere that this is often an ISP problem. Should I talk to them then? Or would it be more a FF problem?

Hope I've provided the necessary information. Thanks heaps for all your help!

PS: Here are the troublesome parts of the FF loading. Unfortunately since I tried entering the IP address first, it now always connects :P so I tried a different website (The Sydney Morning Herald that demonstrates the problem:

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.2 192.168.1.1 DNS Standard query AAAA www.smh.com.au

Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
User Datagram Protocol, Src Port: 32877 (32877), Dst Port: domain (53)
Domain Name System (query)

No. Time Source Destination Protocol Info
2 0.022463 192.168.1.1 192.168.1.2 DNS Standard query response CNAME www.smh.com.au.edgesuite.net CNAME a1758.g.akamai.net

Frame 2 (206 bytes on wire, 206 bytes captured)
Ethernet II, Src: XaviTech_48:f3:61 (00:01:38:48:f3:61), Dst: AsustekC_b5:37:7e (00:11:d8:b5:37:7e)
Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: domain (53), Dst Port: 32877 (32877)
Domain Name System (response)

No. Time Source Destination Protocol Info
3 0.024915 192.168.1.2 192.168.1.1 DNS Standard query A www.smh.com.au

Frame 3 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 192.168.1.1 (192.168.1.1)
User Datagram Protocol, Src Port: 32877 (32877), Dst Port: domain (53)
Domain Name System (query)

No. Time Source Destination Protocol Info
4 0.026686 192.168.1.1 192.168.1.2 DNS Standard query response A 1.0.0.0

Frame 4 (90 bytes on wire, 90 bytes captured)
Ethernet II, Src: XaviTech_48:f3:61 (00:01:38:48:f3:61), Dst: AsustekC_b5:37:7e (00:11:d8:b5:37:7e)
Internet Protocol, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.2 (192.168.1.2)
User Datagram Protocol, Src Port: domain (53), Dst Port: 32877 (32877)
Domain Name System (response)

No. Time Source Destination Protocol Info
5 0.027516 192.168.1.2 1.0.0.0 TCP 57820 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=316663 TSER=0 WS=7

Frame 5 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 57820 (57820), Dst Port: www (80), Seq: 0, Len: 0

No. Time Source Destination Protocol Info
6 3.028375 192.168.1.2 1.0.0.0 TCP 57820 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=317413 TSER=0 WS=7

Frame 6 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 57820 (57820), Dst Port: www (80), Seq: 0, Len: 0

[2 more ARP packets]

No. Time Source Destination Protocol Info
9 9.028460 192.168.1.2 1.0.0.0 TCP 57820 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=318913 TSER=0 WS=7

Frame 9 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 57820 (57820), Dst Port: www (80), Seq: 0, Len: 0

[Repeats]

Yea, this sounds DNS related, but it's still not making sense. It's the same DNS services fior Konquror and Firefox. And you say that now that you have does a sucessful access by IP address that the url now works??? That would imply that Firefox has made the URL to IP connection, which is the DNS lookup. So something else seems to be going wrong.

You say that you can't do the checkip.dyndns.org test any more since now Firefox is working fine on that url. But we are talking about Knoppix from the Live CD here right???? If you reboot does the problem not come back? If this fix survives a reboot of the CD then something very very very strange is going on in the router And, of course, if this isn't a Live dCD or DVD boot then you are just wasting my time, networking after Knoppix has been "installed" is known to be buggy.

I'll wait for your response, then I want to go off and contemplate this for a while. I seems like it could be something like a proxy setting in Firefox. But even a proxy setting should affect both access by URL and access by IP, so I just need to take some time to let these new facts sink in.

Goto a console and type cat /etc/resolv.conf and post the results.

You mention that Konqeror "seems to work fine" is Konq 100% and this just effects other browsers? Or can you reproduce it in Konq? With the EXACT same results.

G'day everyone,

rec9140, the output is below:

knoppix@2[knoppix]$ cat /etc/resolv.conf
nameserver 192.168.1.1

Here's my checklist of what I do and what happens [have rebooted Knoppix from the Live-CD]:

1. Go to http://checkip.dyndns.org/ in Konq: Opens fine, no problems at all.
2. Go to http://checkip.dyndns.org/ in FF: After opening FF and trying (without success) for a compatibility update, it works.
3. Go to http://www.smh.com.au in FF: Hangs, with the following ethereal output:

No. Time Source Destination Protocol Info
1 0.000000 192.168.1.2 1.0.0.0 TCP 54784 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=168381 TSER=0 WS=7

Frame 1 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 54784 (54784), Dst Port: www (80), Seq: 0, Len: 0

No. Time Source Destination Protocol Info
2 2.999158 192.168.1.2 1.0.0.0 TCP 54784 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=169131 TSER=0 WS=7

Frame 2 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 54784 (54784), Dst Port: www (80), Seq: 0, Len: 0

No. Time Source Destination Protocol Info
3 4.999160 AsustekC_b5:37:7e XaviTech_48:f3:61 ARP Who has 192.168.1.1? Tell 192.168.1.2

Frame 3 (42 bytes on wire, 42 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Address Resolution Protocol (request)

No. Time Source Destination Protocol Info
4 4.999475 XaviTech_48:f3:61 AsustekC_b5:37:7e ARP 192.168.1.1 is at 00:01:38:48:f3:61

Frame 4 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: XaviTech_48:f3:61 (00:01:38:48:f3:61), Dst: AsustekC_b5:37:7e (00:11:d8:b5:37:7e)
Address Resolution Protocol (reply)

No. Time Source Destination Protocol Info
5 8.999245 192.168.1.2 1.0.0.0 TCP 54784 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=170631 TSER=0 WS=7

Frame 5 (74 bytes on wire, 74 bytes captured)
Ethernet II, Src: AsustekC_b5:37:7e (00:11:d8:b5:37:7e), Dst: XaviTech_48:f3:61 (00:01:38:48:f3:61)
Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 1.0.0.0 (1.0.0.0)
Transmission Control Protocol, Src Port: 54784 (54784), Dst Port: www (80), Seq: 0, Len: 0

No. Time Source Destination Protocol Info
6 20.999416 192.168.1.2 1.0.0.0 TCP 54784 > www [SYN] Seq=0 Len=0 MSS=1460 TSV=173631 TSER=0 WS=7

[Repeats this TCP packet twice more]

[Repeats ARP packets as before]

I even tried using Elinks and entering the Check IP address there, no luck either... just hangs "making connection." And have only used the Live-CD (wouldn't even know how to install Knoppix to my hard drive :P)

So it appears that every other browser is playing up... except for Konqueror!

Hope this helps guys and it hasn't made life even more confusing for you!

Quote:

---

Originally Posted by DaXiuyi

rec9140, the output is below:

knoppix@2[knoppix]$ cat /etc/resolv.conf
nameserver 192.168.1.1

---

goto a console, swith to super user mode via su

something along

rec9140@rickscne:~$ su
Password:
root@rickscne:/home/rec9140# joe /etc/resolv.conf

You can use Kate or KWrite too which ever your most familar with, kwrite|kate /etc/resolv.conf would do the same thing. joe is just a simple text based editor and much easier than vi or emacs (awful programs!)

Edit resolv.conf to be:
nameserver 208.67.222.222

Save the file.

See if the problems persists.

Your router may not like acting as DNS proxy, some SOHO types just don't do it well or at all. Which is perplexing as Konq works but others have an issue with address resolution...hmmmm..... live cd......hmmm even more strange....

I take it that you zero issues with visting sites as the router is configured if used under winvirus, at least thats the way I read things, correct?

No, using Win XP I get no problems at all.

Well, I edited the file as you said, rec9140, and now everything works beautifully :) All other programs (FF, Gaim etc) connect and work fine :D

Thanks heaps for all your help guys. I'm still scratching my head as to why it suddenly works, but thank you so much all the same...

Now that I know I can connect to the Net in Linux now, and that with a proper dist'n I can load the drivers for my printer, I think I'll be switching to some sort of *nix distribution before long ^^

Thanks again

Hi,

I have been following this in the background, and I also know of some previous posters on this forum who have encountered a similar problem where Konqueror works but Firefox and other browsers do not. From what has been described and how it was solved, I now think that what we are seeing is something called the IPv6 problem which has been discussed on other forums. IPv6 is the new form of internet addressing which is slowly being introduced but which is not supported everywhere yet. This problem occurs when a DNS does not properly support IPv6. The DNS then times out or returns an error when a browser sends out a IPv6 request because it does not know what to do with it.

I found some details of the problem here: http://www.cisco.com/web/about/ac123...e_servers.html
and some discussion here: http://www.linuxforums.org/forum/lin...eror-does.html

The solution given for Firefox in the above link is to disable IPv6, or as, for DaXiuYi did, simply change to a different DNS.

The evidence for my hunch is when I did an ethereal capture of Konqueror and Firefox -- they behave differently when making DNS requests. Konqueror sends out a Type A (IPv4) request first followed by a Type AAAA request (IPv6). Firefox and Elink sends out a Type AAAA request first, and then a Type A request. So in the case of Firefox and Elink, it could be possible that when the DNS receives a Type AAAA request, it does not know what to do, and so times out and never gets round to handling the Type A request. On the other hand, Konqueror sends out a Type A request to the DNS and gets a good response, so it doesn't matter whether the Type AAAA request gets a response or not.

I can't completely test this hunch until I get the IP of a DNS which we know for sure is faulty and does not support IPv6 (for example, DaXiuYi, you might know which DNS your ISP has provided and tell it to me). I will then set my system to these faulty DNS and see if I get a problem.

Anyway I am glad this episode happened because in the past I have read of other posters having this problem and we all puzzled over it and could not understand what was wrong. Now at least we are solving the puzzle.

Jacky has a very interesting theory there. DaXiuyi, one good test of this theory would be to change the DNS setting in your router to the one that works, and then see if Knoppix works fine from a cold boot of the CD with no editing. Unfortunately, I've read through the router manual and as far as I can see you don't get an option to change this setting in the router when using PPPoE or PPPoA, only when using static settings. However, you may want to look, I may have overlooked something, or you may have newer firmware than the manual documants that allows this. You could even check if you are running the current firmware and flash your router if you are not.

Many routers do allow the DNS server to be changed when running PPPoE/PPPoA, although the one that I'm currently running doesn't allow it either. I never liked that about my router, now that we see a potential serious problem that it can lead to I like it even less. If you do figure out how to change the DNS server used in your router settings please let us know the results.

I think my router does allow DNS settings to be changed. What I need now are DNS addresses which have been known to cause people trouble.

DaXiuYi, if you can tell me what DNS settings are on your router (the DNS settings which your router was using when you had the Firefox problems), I will set my router to use your DNS settings. If this causes my Firefox to fail, then we shall know.

Quote:

---

Originally Posted by Jacky

I have been following this in the background, and I also know of some previous posters on this forum who have encountered a similar problem where Konqueror works but Firefox and other browsers do not. From what has been described and how it was solved, I now think that what we are seeing is something called the IPv6 problem which has been discussed on other forums. IPv6 is the new form of internet addressing which is slowly being introduced but which is not supported everywhere yet. This problem occurs when a DNS does not properly support IPv6. The DNS then times out or returns an error when a browser sends out a IPv6 request because it does not know what to do with it.

I found some details of the problem here: http://www.cisco.com/web/about/ac123...e_servers.html
and some discussion here: http://www.linuxforums.org/forum/lin...eror-does.html

The solution given for Firefox in the above link is to disable IPv6, or as, for DaXiuYi did, simply change to a different DNS.

The evidence for my hunch is when I did an ethereal capture of Konqueror and Firefox -- they behave differently when making DNS requests. Konqueror sends out a Type A (IPv4) request first followed by a Type AAAA request (IPv6). Firefox and Elink sends out a Type AAAA request first, and then a Type A request. So in the case of Firefox and Elink, it could be possible that when the DNS receives a Type AAAA request, it does not know what to do, and so times out and never gets round to handling the Type A request. On the other hand, Konqueror sends out a Type A request to the DNS and gets a good response, so it doesn't matter whether the Type AAAA request gets a response or not.

---

This is interesting....hmmmm... OK.. I was always wondering what kind of issues are going to come up in the IPV4 to IPV6 mess.