Hello, I have Suse 9.2 running on 2 PCs in a Windows domain. The main domain server is Windows 2003. All of the thin clients and Windows machines are connecting to the internet fine. The Suse machines connect to the internet as well, but there are quite a few pages that are unreachable. Windows will load these pages, even running in VMWare on the Suse machines. Apparently I have a DNS problem, but I can't seem to figure it out. For my DNS I had two local addresses (for the Windows Server 2003 boxes). I added one of the ISPs DNS to the list, but it did not resolve the problem. I removed the Windows Server 2003 DNS entirely, and replaces with the ISPs DNS addresses, but still have the same problem. I must be missing something, but what? I am happy to post my DNS if necessary, is there a command line program that I can use to list this, so it is easier to send via e-mail? I would rather that than transcribing from Yast. Thanks. James Wright
On Thursday 14 July 2005 4:54 pm, James Wright wrote:
Hello, I have Suse 9.2 running on 2 PCs in a Windows domain. The main domain server is Windows 2003. All of the thin clients and Windows machines are connecting to the internet fine. The Suse machines connect to the internet as well, but there are quite a few pages that are unreachable. Windows will load these pages, even running in VMWare on the Suse machines. Apparently I have a DNS problem, but I can't seem to figure it out. For my DNS I had two local addresses (for the Windows Server 2003 boxes). I added one of the ISPs DNS to the list, but it did not resolve the problem. I removed the Windows Server 2003 DNS entirely, and replaces with the ISPs DNS addresses, but still have the same problem. I must be missing something, but what? I am happy to post my DNS if necessary, is there a command line program that I can use to list this, so it is easier to send via e-mail? I would rather that than transcribing from Yast. Thanks. The DNS servers are listed in /etc/resolv.conf. If you are using dynamic IP addresses, DHCP should populate your resolv.conf file. You can easily edit it and list it using the cat(1) comand. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Thursday 14 July 2005 12:54 pm, James Wright wrote:
Apparently I have a DNS problem, but I can't seem to figure it out. For my DNS I had two local addresses (for the Windows Server 2003 boxes). I added one of the ISPs DNS to the list, but it did not resolve the problem.
You may be confused as to how the dns servers work. The second and third etc. dns servers are only used if the first one fails, (goes off line). You need to open up a shell and ping the sites where these "unreachable pages" are. Ping by name, (not IP) and see if an ip is returned. If an ip Is returned, its not a dns problem. You have not mentioned anything about how you connect to the internet, the layout of your network, or your default route. All of these are needed to diagnose your problem. -- _____________________________________ John Andersen
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote:
Hello, I have Suse 9.2 running on 2 PCs in a Windows domain. The main domain server is Windows 2003. All of the thin clients and Windows machines are connecting to the internet fine. The Suse machines connect to the internet as well, but there are quite a few pages that are unreachable. Windows will load these pages, even running in VMWare on the Suse machines. Apparently I have a DNS problem, but I can't seem to figure it out. For my DNS I had two local addresses (for the Windows Server 2003 boxes). I added one of the ISPs DNS to the list, but it did not resolve the problem. I removed the Windows Server 2003 DNS entirely, and replaces with the ISPs DNS addresses, but still have the same problem. I must be missing something, but what? I am happy to post my DNS if necessary, is there a command line program that I can use to list this, so it is easier to send via e-mail? I would rather that than transcribing from Yast. Thanks.
James Wright
So all of the internet traffic on your network funnels through two machines that are running Windows Server operating systems, you connect through those servers from your Linux machines, and you can get to some external web sites and not others. Is that what you're saying? Greg Wallace
Quoting Greg Wallace <jgregw@acsalaska.net>:
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote: So all of the internet traffic on your network funnels through two machines that are running Windows Server operating systems, you connect through those servers from your Linux machines, and you can get to some external web sites and not others. Is that what you're saying?
Greg Wallace
Yes, the two Windows servers run the DNS. Beyond that is a SonicWall Firewall (not the problem, I checked), and then a high speed DSL. All PCs and thin clients are attached to D-link switches. Again, all Windows machines can browse all, Suse machines can browse only some. I cannot ping, say, www.sonicwall.com or browse to it from Suse 9.2. Windows machines load www.sonicwall.com without a problem. In VMWare running Win2k on a Suse machine all pages load. I have to use VMWare just to check my e-mail. I am more than happy to post any information required for help. I really think it is a local DNS problem, as I can't even get to the webpage for the ISP we are using, with Suse. Thank you. James W
On Fri, 15 Jul 2005 11:52:40 -0400 jwright@vermontel.net wrote:
Quoting Greg Wallace <jgregw@acsalaska.net>:
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote: So all of the internet traffic on your network funnels through two machines that are running Windows Server operating systems, you connect through those servers from your Linux machines, and you can get to some external web sites and not others. Is that what you're saying?
Greg Wallace
Yes, the two Windows servers run the DNS. Beyond that is a SonicWall Firewall (not the problem, I checked), and then a high speed DSL. All PCs and thin clients are attached to D-link switches. Again, all Windows machines can browse all, Suse machines can browse only some. I cannot ping, say, www.sonicwall.com or browse to it from Suse 9.2. Windows machines load www.sonicwall.com without a problem. In VMWare running Win2k on a Suse machine all pages load. I have to use VMWare just to check my e-mail. I am more than happy to post any information required for help. I really think it is a local DNS problem, as I can't even get to the webpage for the ISP we are using, with Suse. Thank you.
James W
On the suse boxes you have set the nameserver in etc/resolv.conf to point to your internal dns?Internal DNS does do forwarding? Have A and PTR records of suse boxes? _____________________________________________________________________ For super low premiums, click here http://www.dialdirect.co.za/quote
On Friday, July 15, 2005 @ 7:53 AM, James Wright wrote:
Quoting Greg Wallace <jgregw@acsalaska.net>:
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote: So all of the internet traffic on your network funnels through two machines that are running Windows Server operating systems, you connect through those servers from your Linux machines, and you can get to some external web sites and not others. Is that what you're saying?
Greg Wallace
Yes, the two Windows servers run the DNS. Beyond that is a SonicWall Firewall (not the problem, I checked), and then a high speed DSL. All PCs and thin clients are attached to D-link switches. Again, all Windows machines can browse all, Suse machines can browse only some. I cannot ping, say, www.sonicwall.com or browse to it from Suse 9.2. Windows machines load www.sonicwall.com without a problem. In VMWare running Win2k on a Suse machine all pages load. I have to use VMWare just to check my e-mail. I am more than happy to post any information required for help. I really think it is a local DNS problem, as I can't even get to the webpage for the ISP we are using, with Suse. Thank you.
James W
You could try doing a complete end-around of your domain servers and let SuSE pick up the servers dynamically. I'm running an older version of SuSE, but you should be able to do something comparable to *) Connect a linux machine directly to your WAN *) Under "Host name and name server configuration" (or whatever it may be called now), select "Update name server list via DHCP. This should let SuSE scan your network and pick up any and all of the name servers that are out there (maybe you're missing one?). See if you can then get to those unreachable sites you mention. At least that way you can go back and look at the "Host name and name server configuration" and see what servers were picked up. Greg Wallace P. S.: I'm no expert in this area, but the above should (?) give you the full list of name servers that are reachable on your provider's network.
I just started to read this thread. I am not sure if you have done it or not. Have you checked your search domain name is correctly setup in the /etc/resolv.conf. It seems to me that your setup has created your own domain name and the SUSE machine is not talking to it properly. Another thing you did not mention if you are using a dhcp server to resolv your ip address on the machine. If you have it imporperly setup, it may not resolve the DNS address properly. This can be seen in the /etc/resolv.conf. Also does your windows machine use DNS services to resolve the address. I am thinking about the ones that are not the DNS Servers. It might be resolving the address another way. Make sure that your windows server s a true master-slave setup. Greg Wallace wrote:
On Friday, July 15, 2005 @ 7:53 AM, James Wright wrote:
Quoting Greg Wallace <jgregw@acsalaska.net>:
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote: So all of the internet traffic on your network funnels through two
machines
that are running Windows Server operating systems, you connect through
those
servers from your Linux machines, and you can get to some external web
sites
and not others. Is that what you're saying?
Greg Wallace
Yes, the two Windows servers run the DNS. Beyond that is a SonicWall Firewall (not the problem, I checked), and then a high speed DSL. All PCs and thin clients are attached to D-link switches. Again, all Windows machines can browse all, Suse machines can browse only some. I cannot ping, say, www.sonicwall.com or browse to it from Suse 9.2. Windows machines load www.sonicwall.com without a problem. In VMWare running Win2k on a Suse machine all pages load. I have to use VMWare just to check my e-mail. I am more than happy to post any information required for help. I really think it is a local DNS problem, as I can't even get to the webpage for the ISP we are using, with Suse. Thank you.
James W
You could try doing a complete end-around of your domain servers and let SuSE pick up the servers dynamically. I'm running an older version of SuSE, but you should be able to do something comparable to
*) Connect a linux machine directly to your WAN *) Under "Host name and name server configuration" (or whatever it may be called now), select "Update name server list via DHCP.
This should let SuSE scan your network and pick up any and all of the name servers that are out there (maybe you're missing one?). See if you can then get to those unreachable sites you mention. At least that way you can go back and look at the "Host name and name server configuration" and see what servers were picked up.
Greg Wallace
P. S.: I'm no expert in this area, but the above should (?) give you the full list of name servers that are reachable on your provider's network.
-- Joseph Loo jloo@acm.org
You could try doing a complete end-around of your domain servers and let SuSE pick up the servers dynamically. I'm running an older version of SuSE, but you should be able to do something comparable to
*) Connect a linux machine directly to your WAN *) Under "Host name and name server configuration" (or whatever it may be called now), select "Update name server list via DHCP.
I do have that option enabled, and tried disabling and manually entering the IPs, but it did not work for me. James W
On Friday, July 15, 2005 @ 7:53 AM, James Wright wrote:
Quoting Greg Wallace <jgregw@acsalaska.net>:
On Thursday, July 14, 2005 @ 12:54 PM, James Wright wrote: So all of the internet traffic on your network funnels through two machines that are running Windows Server operating systems, you connect through those servers from your Linux machines, and you can get to some external web sites and not others. Is that what you're saying?
Greg Wallace
Yes, the two Windows servers run the DNS. Beyond that is a SonicWall Firewall (not the problem, I checked), and then a high speed DSL. All PCs and thin clients are attached to D-link switches. Again, all Windows machines can browse all, Suse machines can browse only some. I cannot ping, say, www.sonicwall.com or browse to it from Suse 9.2. Windows machines load www.sonicwall.com without a problem. In VMWare running Win2k on a Suse machine all pages load. I have to use VMWare just to check my e-mail. I am more than happy to post any information required for help. I really think it is a local DNS problem, as I can't even get to the webpage for the ISP we are using, with Suse. Thank you.
James W
I'm completely ignorant of VMWARE (along with, say, a few other things), but are you saying above that if, after having failed to reach a site on your SuSE box, you turn right around and launch VMWARE on that same machine, launch Win2K under VMWARE, and log into your Windows domain, that you can then reach these same sites that you can't reach under native SuSE? Greg Wallace
I'm completely ignorant of VMWARE (along with, say, a few other things), but are you saying above that if, after having failed to reach a site on your SuSE box, you turn right around and launch VMWARE on that same machine, launch Win2K under VMWARE, and log into your Windows domain, that you can then reach these same sites that you can't reach under native SuSE?
Greg Wallace
Yes, that is correct. Also, here is my ping and traceroute of www.sonicwall.com from a Suse PC (sorry it took so long, way too busy lately): black-kdavzbpz3:/home/james # ping www.sonicwall.com <http://www.sonicwall.com> PING www.global.sonicwall.com <http://www.global.sonicwall.com> (64.41.140.167 <http://64.41.140.167>) 56(84) bytes of data. --- www.global.sonicwall.com <http://www.global.sonicwall.com> ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms black-kdavzbpz3:/home/james # traceroute 64.41.140.167 <http://64.41.140.167> traceroute to 64.41.140.167 <http://64.41.140.167> (64.41.140.167 <http://64.41.140.167>), 30 hops max, 40 byte packets 1 172.16.200.17 <http://172.16.200.17> 7.877 ms 7.005 ms 6.817 ms 2 vtelinet-216-66-108-205.vermontel.net <http://vtelinet-216-66-108-205.vermontel.net> (216.66.108.205 <http://216.66.108.205>) 6.788 ms 6.857 ms 7.494 ms 3 g11-2.core01.bos01.atlas.cogentco.com <http://g11-2.core01.bos01.atlas.cogentco.com> (38.112.23.169 <http://38.112.23.169>) 18.955 ms 17.997 ms 17.938 ms 4 p5-0.core01.jfk02.atlas.cogentco.com <http://p5-0.core01.jfk02.atlas.cogentco.com> (66.28.4.118 <http://66.28.4.118>) 22.829 ms 22.693 ms22.559 ms 5 p4-0.core02.dca01.atlas.cogentco.com <http://p4-0.core02.dca01.atlas.cogentco.com> (66.28.4.81 <http://66.28.4.81>) 29.631 ms 29.606 ms 29.411 ms 6 p14-0.core01.iad01.atlas.cogentco.com <http://p14-0.core01.iad01.atlas.cogentco.com> (154.54.2.198 <http://154.54.2.198>) 95.433 ms 62.297 ms 29.063 ms 7 cpr1-ge-8-1.VirginiaEquinix.savvis.net <http://cpr1-ge-8-1.VirginiaEquinix.savvis.net> (208.173.10.181 <http://208.173.10.181>) 29.759 ms 30.020ms 30.395 ms 8 dcr1-so-6-1-0.Washington.savvis.net <http://dcr1-so-6-1-0.Washington.savvis.net> (208.173.52.114 <http://208.173.52.114>) 30.189 ms 29.924 ms 57.266 ms 9 bcs2-so-5-2-0-500.Washington.savvis.net <http://bcs2-so-5-2-0-500.Washington.savvis.net> ( 204.70.192.162 <http://204.70.192.162>) 30.418 ms 30.548 ms bcs1-so-5-0-0-500.Washington.savvis.net <http://bcs1-so-5-0-0-500.Washington.savvis.net> (204.70.192.170 <http://204.70.192.170>) 30.952 ms 10 dcr1-so-5-0-0.SanFranciscosfo.savvis.net <http://dcr1-so-5-0-0.SanFranciscosfo.savvis.net> (204.70.192.149 <http://204.70.192.149>) 96.613 ms 96.045 ms 96.089 ms 11 bhr1-pos-13-0.SantaClarasc5.savvis.net <http://bhr1-pos-13-0.SantaClarasc5.savvis.net> (208.172.147.110 <http://208.172.147.110>) 96.581 ms 96.517 ms 96.834 ms 12 csr1-ve242.sc4.savvis.net <http://csr1-ve242.sc4.savvis.net> (216.34.2.243 <http://216.34.2.243>) 97.105 ms 96.622 ms 96.664 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * black-kdavzbpz3:/home/james # I don't really know what this tells me. It seems as though it works up to the 12th entry and dies? I am a little confused that I can resolve the IP, but the page will not load. Thanks for all the help so far, you guys are great. James W
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies? I am a little confused that I can resolve the IP, but the page will not load. Thanks for all the help so far, you guys are great.
It says that packets (traceroute) are getting out from the SuSE box up to a point. At this point, either the routers are dropping the traceroute packets (possible and likely probable) or the route has problems (can't hop to the next router). But it does show that packets are indeed routing out from you to the internet, so not a routing problem from your network, maybe after. Now do the other SuSE boxes and the Windows PCs follow the same/similar route? If so, do those have problems getting to the site? If they do, then the routes may have problems. You could try using ethereal to capture the raw packets that come to and leave the SuSE box and see if something is wrong. When I try the ping I get the ip 64.56.191.114, but when captured with ethereal I get the ip you get with ping (64.41.140.167). BTW, have you tried typing in the ip in your browser on SuSE to see if this works? I know that dns works for you, but it does eliminate the need to resolve, and based on what you've provided it should fail as well. You resolve the name to the ip, but can't get there. I'm gonna venture a guess that the problem has to do with routers outside of your network. Based on dns working and the fact that you can route out of your network up to a certain point. Ethereal should reveal more about what's happeining. John
I'm gonna venture a guess that the problem has to do with routers outside of your network. Based on dns working and the fact that you can route out of your network up to a certain point. Ethereal should reveal more about what's happeining.
John
What exactly would I look for in ethereal? I have it and can run it, but the results are relatively meaningless to me. James W.
On 7/20/05, James Wright <jwright@blackriverproduce.com> wrote:
I'm gonna venture a guess that the problem has to do with routers outside of your network. Based on dns working and the fact that you can route out of your network up to a certain point. Ethereal should reveal more about what's happeining.
John
What exactly would I look for in ethereal? I have it and can run it, but the results are relatively meaningless to me.
James W.
You should capture packets from the Windows box that works and compare to packets from the SuSE box that doesn't. Ping and traceroute are good tools to get started with, but they don't provide alot of information. Dns works as has been determined by pinging by name. You can route out of your network, as has been determined by traceroute. But you're not going to get much farther than that with those tools. As for what you should look for. You should see the the dns query for www.sonicwall.com and then the traffic to and from the web server including any errors. For all we know the server could be allowing your Windows box to connect, but for some unknown reason, not responding to your SuSE box (not responding to the handshake or the http request, etc.). I don't buy the reason I just stated because my SuSE boxes can hit sonicwall.com just fine. It's just an example. Or (another example), the SuSE box does its dns query, gets a reply from the local dns server, but then can't get the http packets out of the network. The firewall logs should show if the http packets are getting out. Ethereal can show you all this. as well as the difference between the packet sizes of the Windows box and the SuSE box. Maybe a router isn't happy with your packet size and is dropping them, but your packets (traceroute packets anyway) are leaving your network based on traceroute. After that, who knows. It's either it's router has route table issues or it doesn't like the packets from your SuSE box. If it's a route table issue, then more than just yor SuSE box should have problems if they all follow the same route, and more people than you would be having problems also. If it isn't a route issue, then it's back to your SuSE box and how it's networking is setup or something on your local network (i.e. firewall, traffic shapper, etc.) that is affecting the traffic from the SuSE box. John
John Scott wrote:
Ethereal can show you all this. as well as the difference between the packet sizes of the Windows box and the SuSE box. Maybe a router isn't happy with your packet size and is dropping them, but your packets (traceroute packets anyway) are leaving your network based on traceroute. After that, who knows. It's either it's router has route table issues or it doesn't like the packets from your SuSE box. If it's a route table issue, then more than just yor SuSE box should have problems if they all follow the same route, and more people than you would be having problems also. If it isn't a route issue, then it's back to your SuSE box and how it's networking is setup or something on your local network (i.e. firewall, traffic shapper, etc.) that is affecting the traffic from the SuSE box.
John
Ok, from ethereal it looks as if my packets go out (like previously determined) and are not making it back in right. On Windows in VMWare ethereal shows the GET requests and then the incoming information. On Linux it shows "Continuation or Non-HTTP Traffic" with the source being the web page www.sonicwall.com and the destination being my LAN IP. So I guess that there is some sort of an error reading incoming packets, or they are being malformed somewhere on the way in. Does this seem like a good conclusion from the information provided? If so, how do I determine what and where things are going wrong? James W
On Tuesday 19 July 2005 05:20, James Wright wrote:
I'm completely ignorant of VMWARE (along with, say, a few other things), but are you saying above that if, after having failed to reach a site on your SuSE box, you turn right around and launch VMWARE on that same machine, launch Win2K under VMWARE, and log into your Windows domain, that you can then reach these same sites that you can't reach under native SuSE?
Greg Wallace
Yes, that is correct.
How do you have vmware configured? Bridging or NAT?
Also, here is my ping and traceroute of www.sonicwall.com from a Suse PC (sorry it took so long, way too busy lately):
black-kdavzbpz3:/home/james # ping www.sonicwall.com <http://www.sonicwall.com> PING www.global.sonicwall.com <http://www.global.sonicwall.com> (64.41.140.167 <http://64.41.140.167>) 56(84) bytes of data.
--- www.global.sonicwall.com <http://www.global.sonicwall.com> ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms
Suspicious, but not necessarily conclusive, since not all sites respond to ICMP packets.
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies?
Yeah, but it doesn't have to mean anything, since as I mentioned, not all sites respond to ICMP packets, and traceroute uses ICMP to do its thing
I am a little confused that I can resolve the IP, but the page will not load.
Well, the IP is resolved by your name server, which is separate from the remote web server. the name/ip mapping is maintained by a distributed database, usually not by the actual machine that is mapped You could try lowering your MTU a bit, say ifconfig eth0 1492 and see if that helps
On Wed, 2005-07-20 at 04:47 +0200, Anders Johansson wrote:
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies?
Yeah, but it doesn't have to mean anything, since as I mentioned, not all sites respond to ICMP packets, and traceroute uses ICMP to do its thing
Actually, "traceroute" (at least on Unix/Linux machines) uses UDP packets to find out hops in between utilizing TTL. Not ICMP packets. http://www.private.org.il/mini-tcpip.faq.html#1.%20Of%20ping%20&% 20traceroute. Therefore, in my understanding, if there is a FW inbetween that doesn't allow any high port UDP packets (over port 33434 by default) to go though, or at least it wouldn't reply to the timed-out UDP packet to let the source to know its IP address, so you get.... 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * even in case the destination responses for pinging. Almost all of commercial web servers are protected by FWs. "traceroute" from a SuSe machine to any www.xxxxx.com may not work in many cases. Toshi
On Wednesday 20 July 2005 09:55, Toshi Esumi wrote:
On Wed, 2005-07-20 at 04:47 +0200, Anders Johansson wrote:
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies?
Yeah, but it doesn't have to mean anything, since as I mentioned, not all sites respond to ICMP packets, and traceroute uses ICMP to do its thing
Actually, "traceroute" (at least on Unix/Linux machines) uses UDP packets to find out hops in between utilizing TTL. Not ICMP packets.
It uses both. When a packet's time to live has been exceeded, the remote host is supposed to send ICMP TTL EXCEEDED, and that is what traceroute uses to discover the path the packets take There cam be a number of reasons why you get the * * * in the traceroute output, but firewall blocking should not be one of them, except perhaps in the last hop. Since it's not the final destination, a router on the internet that blocks packets would disrupt a great amount of internet traffic on its path. Some routers simply block all ICMP traffic, which would include the ICMP TTL EXCEEDED packets. And apparently some older, broken routers use the same TTL in the response ICMP packet as the original packet that caused the timeout, which of course means it's not going anywhere, since it's already timed out. In both cases, you get the * * *
http://www.private.org.il/mini-tcpip.faq.html#1.%20Of%20ping%20&% 20traceroute.
Therefore, in my understanding, if there is a FW inbetween that doesn't allow any high port UDP packets (over port 33434 by default) to go though,
As I said, since they're not the final destination, any router that does this has no business being a public router in the first place. And it wouldn't be for very long, it would disrupt too much traffic along its path
Ok, I go my MTU reset and am back on the network. I checked to see that I was on the right domain and I am. ifconfig shows: black-kdavzbpz3:/home/james # ifconfig eth0 Link encap:Ethernet HWaddr 00:01:6C:3B:85:07 inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::201:6cff:fe3b:8507/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:206501 errors:0 dropped:0 overruns:0 frame:0 TX packets:147063 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:36522235 (34.8 Mb) TX bytes:112697672 (107.4 Mb) Interrupt:11 Base address:0xc000 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:22859 errors:0 dropped:0 overruns:0 frame:0 TX packets:22859 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:101776601 (97.0 Mb) TX bytes:101776601 (97.0 Mb)
On Wednesday 20 July 2005 19:30, James Wright wrote:
Ok, I go my MTU reset and am back on the network. I checked to see that I was on the right domain and I am. ifconfig shows:
black-kdavzbpz3:/home/james # ifconfig eth0 Link encap:Ethernet HWaddr 00:01:6C:3B:85:07 inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::201:6cff:fe3b:8507/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:206501 errors:0 dropped:0 overruns:0 frame:0 TX packets:147063 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:36522235 (34.8 Mb) TX bytes:112697672 (107.4 Mb) Interrupt:11 Base address:0xc000
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:22859 errors:0 dropped:0 overruns:0 frame:0 TX packets:22859 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:101776601 (97.0 Mb) TX bytes:101776601 (97.0 Mb)
If you're using bridging, why aren't you seeing the vmware interfaces? Please show the output of ifconfig when vmware is running.
If you're using bridging, why aren't you seeing the vmware interfaces? Please show the output of ifconfig when vmware is running.
I don't know why it didn't show. I rebooted and it now shows: black-kdavzbpz3:/home/james # ifconfig eth0 Link encap:Ethernet HWaddr 00:01:6C:3B:85:07 inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::201:6cff:fe3b:8507/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 TX packets:873 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:253155 (247.2 Kb) TX bytes:122704 (119.8 Kb) Interrupt:11 Base address:0xc000 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:592 errors:0 dropped:0 overruns:0 frame:0 TX packets:592 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:61040 (59.6 Kb) TX bytes:61040 (59.6 Kb) vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet addr:172.16.102.1 Bcast:172.16.102.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:49 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) I don't know if this helps too, but in Windows 2000 running on VMWare ipconfig /all shows: C:\>ipconfig /all Windows 2000 IP Configuration Host Name . . . . . . . . . . . . : jw-pa9irtwlmhi0 Primary DNS Suffix . . . . . . . : blackriverproduce.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : blackriverproduce.com Ethernet adapter Local Area Connection: Connection-specific DNS Suffix . : blackriverproduce.com Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapte r Physical Address. . . . . . . . . : 00-0C-29-61-36-43 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.139 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.7 DNS Servers . . . . . . . . . . . : 192.168.1.7 192.168.1.4 Lease Obtained. . . . . . . . . . : Wednesday, July 20, 2005 3:07:35 PM Lease Expires . . . . . . . . . . : Thursday, July 28, 2005 3:07:35 PM James W
On Wed, 2005-07-20 at 15:24 -0400, James Wright wrote:
black-kdavzbpz3:/home/james # ifconfig eth0 Link encap:Ethernet HWaddr 00:01:6C:3B:85:07 inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::201:6cff:fe3b:8507/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1523 errors:0 dropped:0 overruns:0 frame:0 TX packets:873 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:253155 (247.2 Kb) TX bytes:122704 (119.8 Kb) Interrupt:11 Base address:0xc000
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:592 errors:0 dropped:0 overruns:0 frame:0 TX packets:592 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:61040 (59.6 Kb) TX bytes:61040 (59.6 Kb)
vmnet8 Link encap:Ethernet HWaddr 00:50:56:C0:00:08 inet addr:172.16.102.1 Bcast:172.16.102.255 Mask:255.255.255.0 inet6 addr: fe80::250:56ff:fec0:8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:49 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
I don't know if this helps too, but in Windows 2000 running on VMWare ipconfig /all shows:
C:\>ipconfig /all
Windows 2000 IP Configuration
Host Name . . . . . . . . . . . . : jw-pa9irtwlmhi0 Primary DNS Suffix . . . . . . . : blackriverproduce.com Node Type . . . . . . . . . . . . : Hybrid IP Routing Enabled. . . . . . . . : No WINS Proxy Enabled. . . . . . . . : No DNS Suffix Search List. . . . . . : blackriverproduce.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : blackriverproduce.com Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapte r Physical Address. . . . . . . . . : 00-0C-29-61-36-43 DHCP Enabled. . . . . . . . . . . : Yes Autoconfiguration Enabled . . . . : Yes IP Address. . . . . . . . . . . . : 192.168.1.139 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 192.168.1.1 DHCP Server . . . . . . . . . . . : 192.168.1.7 DNS Servers . . . . . . . . . . . : 192.168.1.7 192.168.1.4 Lease Obtained. . . . . . . . . . : Wednesday, July 20, 2005 3:07:35 PM Lease Expires . . . . . . . . . . : Thursday, July 28, 2005 3:07:35 PM
James W
In your last traceroute, the first hop was "172.16.200.17". But it's not in the vmnet8 subnet:172.16.102.0/24. Is 172.16.200.17 one of IP addresses the SonicWall FW has? Do you have the same problem when you don't run VMWare? (Maybe you already commented this but I don't remember.) What kind of output of "tracert 64.41.140.167" do you get when you run this on a Windows client? Is it exactly the same as the one you posted? Toshi
Toshi Esumi wrote:
In your last traceroute, the first hop was "172.16.200.17". But it's not in the vmnet8 subnet:172.16.102.0/24. Is 172.16.200.17 one of IP addresses the SonicWall FW has? Do you have the same problem when you don't run VMWare? (Maybe you already commented this but I don't remember.) What kind of output of "tracert 64.41.140.167" do you get when you run this on a Windows client? Is it exactly the same as the one you posted?
Toshi
172.16.200.17 is not listed in my SonicWall. tracert in VMWare/Windows2k shows: C:\>tracert 64.41.140.167 Tracing route to www.global.sonicwall.com [64.41.140.167] over a maximum of 30 hops: 1 15 ms <10 ms 16 ms 172.16.200.17 2 <10 ms 15 ms <10 ms vtelinet-216-66-108-205.vermontel.net [216.66.10 8.205] 3 16 ms 15 ms 16 ms g11-2.core01.bos01.atlas.cogentco.com [38.112.23 .169] 4 16 ms 31 ms 16 ms p5-0.core01.jfk02.atlas.cogentco.com [66.28.4.11 8] 5 16 ms 31 ms 31 ms p4-0.core02.dca01.atlas.cogentco.com [66.28.4.81 ] 6 31 ms 32 ms 31 ms p14-0.core01.iad01.atlas.cogentco.com [154.54.2. 198] 7 94 ms 31 ms 16 ms cpr1-ge-8-1.VirginiaEquinix.savvis.net [208.173. 10.181] 8 31 ms 32 ms 31 ms dcr1-so-6-1-0.Washington.savvis.net [208.173.52. 114] 9 32 ms 31 ms 47 ms bcs2-so-5-0-0-500.Washington.savvis.net [204.70. 192.174] 10 93 ms 94 ms 94 ms dcr1-so-5-0-0.SanFranciscosfo.savvis.net [204.70 .192.149] 11 94 ms 94 ms 94 ms bhr1-pos-13-0.SantaClarasc5.savvis.net [208.172. 147.110] 12 93 ms 94 ms 94 ms csr1-ve242.sc4.savvis.net [216.34.2.243] 13 * * * Request timed out. 14 * * * Request timed out. 15 * * * Request timed out. 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out. Trace complete. James W
Toshi Esumi wrote:
Do you have the same problem when you don't run VMWare? (Maybe you already commented this but I don't remember.)
Toshi
Yes I still have the problem. This computer worked fine on our old Windows 2000 Server using a different provider. We moved locations, servers, and ISP. Now, all the Windows boxes still have full internet access, and the Suse boxes ( I have two of them) only have partial internet access. I can't get to big sites like weather.com or one of my webmail accounts at netzero.net. It's a bit frustrating. Thanks for your help so far. James W
OK, my problem is solved. I want to thank John Scott for all of his troubleshooting help. It had been suggested that I needed a lower MTU, which was exactly the case. The settings that I tried were not correct. The MTU had to be set to 1490, no more, no less. My SonicWall firewall has an MTU setting of 1500, which confused me. I can only guess that the DSL modem has an MTU of 1490. I don't understand though, why something like 1400 didn't work. I had tried going as low as 500. But, for some reason it had to be at exactly 1490. If anyone wishes to explain, please do. If not, I'll just call it a mystery. Thanks to everyone that helped! James W
On Wed, 2005-07-20 at 19:33 +0200, Anders Johansson wrote:
On Wednesday 20 July 2005 19:30, James Wright wrote:
Ok, I go my MTU reset and am back on the network. I checked to see that I was on the right domain and I am. ifconfig shows:
black-kdavzbpz3:/home/james # ifconfig eth0 Link encap:Ethernet HWaddr 00:01:6C:3B:85:07 inet addr:192.168.1.123 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::201:6cff:fe3b:8507/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:206501 errors:0 dropped:0 overruns:0 frame:0 TX packets:147063 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:36522235 (34.8 Mb) TX bytes:112697672 (107.4 Mb) Interrupt:11 Base address:0xc000
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:22859 errors:0 dropped:0 overruns:0 frame:0 TX packets:22859 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:101776601 (97.0 Mb) TX bytes:101776601 (97.0 Mb)
If you're using bridging, why aren't you seeing the vmware interfaces? Please show the output of ifconfig when vmware is running.
I have always used bridged networking with vmware and never see any vmware interface when typing ifconfig. Perhaps it is the way you have your vmware setup. As I recall I used to have one but changed the network setup as I saw no reason for an interface to be configured under ifconfig. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
How do you have vmware configured? Bridging or NAT?
I have it bridged with it's own IP address.
You could try lowering your MTU a bit, say
ifconfig eth0 1492
and see if that helps
Not only did this not help, but I can no longer reach my local network, or any webpage, or my AS400 connection. What should I reset that to, so that I can get back on my network? James W
On Monday, July 18, 2005 @ 7:21 PM, James Wright wrote:
I'm completely ignorant of VMWARE (along with, say, a few other things),
but
are you saying above that if, after having failed to reach a site on your SuSE box, you turn right around and launch VMWARE on that same machine, launch Win2K under VMWARE, and log into your Windows domain, that you can then reach these same sites that you can't reach under native SuSE?
Greg Wallace
Yes, that is correct. Also, here is my ping and traceroute of www.sonicwall.com from a Suse PC (sorry it took so long, way too busy lately):
black-kdavzbpz3:/home/james # ping www.sonicwall.com <http://www.sonicwall.com> PING www.global.sonicwall.com <http://www.global.sonicwall.com> (64.41.140.167 <http://64.41.140.167>) 56(84) bytes of data.
--- www.global.sonicwall.com <http://www.global.sonicwall.com> ping statistics --- 2 packets transmitted, 0 received, 100% packet loss, time 999ms
black-kdavzbpz3:/home/james # traceroute 64.41.140.167 <http://64.41.140.167> traceroute to 64.41.140.167 <http://64.41.140.167> (64.41.140.167 <http://64.41.140.167>), 30 hops max, 40 byte packets 1 172.16.200.17 <http://172.16.200.17> 7.877 ms 7.005 ms 6.817 ms 2 vtelinet-216-66-108-205.vermontel.net <http://vtelinet-216-66-108-205.vermontel.net> (216.66.108.205 <http://216.66.108.205>) 6.788 ms 6.857 ms 7.494 ms 3 g11-2.core01.bos01.atlas.cogentco.com <http://g11-2.core01.bos01.atlas.cogentco.com> (38.112.23.169 <http://38.112.23.169>) 18.955 ms 17.997 ms 17.938 ms 4 p5-0.core01.jfk02.atlas.cogentco.com <http://p5-0.core01.jfk02.atlas.cogentco.com> (66.28.4.118 <http://66.28.4.118>) 22.829 ms 22.693 ms22.559 ms 5 p4-0.core02.dca01.atlas.cogentco.com <http://p4-0.core02.dca01.atlas.cogentco.com> (66.28.4.81 <http://66.28.4.81>) 29.631 ms 29.606 ms 29.411 ms 6 p14-0.core01.iad01.atlas.cogentco.com <http://p14-0.core01.iad01.atlas.cogentco.com> (154.54.2.198 <http://154.54.2.198>) 95.433 ms 62.297 ms 29.063 ms 7 cpr1-ge-8-1.VirginiaEquinix.savvis.net <http://cpr1-ge-8-1.VirginiaEquinix.savvis.net> (208.173.10.181 <http://208.173.10.181>) 29.759 ms 30.020ms 30.395 ms 8 dcr1-so-6-1-0.Washington.savvis.net <http://dcr1-so-6-1-0.Washington.savvis.net> (208.173.52.114 <http://208.173.52.114>) 30.189 ms 29.924 ms 57.266 ms 9 bcs2-so-5-2-0-500.Washington.savvis.net <http://bcs2-so-5-2-0-500.Washington.savvis.net> ( 204.70.192.162 <http://204.70.192.162>) 30.418 ms 30.548 ms bcs1-so-5-0-0-500.Washington.savvis.net <http://bcs1-so-5-0-0-500.Washington.savvis.net> (204.70.192.170 <http://204.70.192.170>) 30.952 ms 10 dcr1-so-5-0-0.SanFranciscosfo.savvis.net <http://dcr1-so-5-0-0.SanFranciscosfo.savvis.net> (204.70.192.149 <http://204.70.192.149>) 96.613 ms 96.045 ms 96.089 ms 11 bhr1-pos-13-0.SantaClarasc5.savvis.net <http://bhr1-pos-13-0.SantaClarasc5.savvis.net> (208.172.147.110 <http://208.172.147.110>) 96.581 ms 96.517 ms 96.834 ms 12 csr1-ve242.sc4.savvis.net <http://csr1-ve242.sc4.savvis.net> (216.34.2.243 <http://216.34.2.243>) 97.105 ms 96.622 ms 96.664 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * black-kdavzbpz3:/home/james #
I don't really know what this tells me. It seems as though it works up to the 12th entry and dies? I am a little confused that I can resolve the IP, but the page will not load. Thanks for all the help so far, you guys are great.
James W
This is getting a little over my head here, but I keep thinking it might be a security issue. I believe you indicated (or maybe I'm reading between the lines) that you aren't using Samba to connect to your LAN when you're running SuSE, but you are logged into your network when you launch VMWARE/Win2K. Maybe VMWARE/Win2K is routing through your LAN and picking up some security privilege that that isn't available trying to hit your WAN directly (bypassing the network). If all else fails, you might want to look at setting up Samba and joining your Linux box to the domain. Greg Wallace
This is getting a little over my head here, but I keep thinking it might be a security issue. I believe you indicated (or maybe I'm reading between the lines) that you aren't using Samba to connect to your LAN when you're running SuSE, but you are logged into your network when you launch VMWARE/Win2K. Maybe VMWARE/Win2K is routing through your LAN and picking up some security privilege that that isn't available trying to hit your WAN directly (bypassing the network). If all else fails, you might want to look at setting up Samba and joining your Linux box to the domain.
Greg Wallace
I am using samba for SUSE, and I rarely use VMWare except when absolutely necessary, like right now. I do log into the network with VMWare as well, but VMWare gets it's own IP address when I do. I should check to make sure that I am on the right domain though, as it changed when we changed servers. I cannot get back on the network until I get the default MTU value though. James W
participants (12)
-
Anders Johansson -
Greg Wallace -
it clown -
James Wright -
James Wright -
Jerry Feldman -
John Andersen -
John Scott -
Joseph Loo -
jwright＠vermontel.net
-
Ken Schneider -
Toshi Esumi