I have just reinstalled SusE v8.1 on my linux box (last resort to fix a number of problems that have occurred over the past few months). The platform is on a small LAN. Before reinstalling I could connect to the LAN. Now when I attempt to envoke samba I get the following: abnormal:~ # mount -t smbfs abnormal:~ # mount -t smbfs //igor/N /mnt Error connecting to 10.0.0.1 (No route to host) 2082: Connection to igor failed SMB connection failed or abnormal:~ # smbmount //igor/N /mnt Error connecting to 10.0.0.1 (No route to host) 2083: Connection to igor failed SMB connection failed What is the solution to this problem? Thanks in advance.a
Stephen P. Molnar, Ph.D. wrote, On 07/28/2003 01:50 AM:
Now when I attempt to envoke samba I get the following: abnormal:~ # mount -t smbfs abnormal:~ # mount -t smbfs //igor/N /mnt Error connecting to 10.0.0.1 (No route to host) 2082: Connection to igor failed SMB connection failed
Check your firewall, make sure udp 137 and 138, tcp 139 is open. Also make sure your hosts are in /etc/samba/lmhosts. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
At 08:38 PM 7/27/2003, you wrote:
Stephen P. Molnar, Ph.D. wrote, On 07/28/2003 01:50 AM:
Now when I attempt to envoke samba I get the following: abnormal:~ # mount -t smbfs abnormal:~ # mount -t smbfs //igor/N /mnt Error connecting to 10.0.0.1 (No route to host) 2082: Connection to igor failed SMB connection failed
Check your firewall, make sure udp 137 and 138, tcp 139 is open. Also make sure your hosts are in /etc/samba/lmhosts.
No firewalls are set up. Adding hosts to /etc/samba/lmhosts made no difference ifconfig results in: eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000 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:2936 errors:0 dropped:0 overruns:0 frame:0 TX packets:2936 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:427292 (417.2 Kb) TX bytes:427292 (417.2 Kb)
-- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Web Address: http://www.mydestiny.net/~joe_morris Registered Linux user 231871 God said, I AM that I AM. I say, by the grace of God, I am what I am.
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Monday 28 July 2003 07:08, Stephen P. Molnar, Ph.D. wrote:
ifconfig results in:
eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000 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:2936 errors:0 dropped:0 overruns:0 frame:0 TX packets:2936 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:427292 (417.2 Kb) TX bytes:427292 (417.2 Kb)
<snip> First change your subnet mask to the proper configuration. The 10.0.0.0 subnet is designated as a class A network. The subnet mask for class A networks are 255.0.0.0 You probably are able to communicate with distant computers without a problem. However for the local network(s), the subnet mask is used to determine if a particular device is accessible. if not, the datagrams must be forwarded to the gateway ---- as your computer is doing -------- if i am right. This is surely why you are able to access the internet. But not talk to the LAN. ;) -- Thomas Jones Linux-Howtos Network Administrator OpenGPG Key: 0x6A3DF6E9
On Mon, 28 Jul 2003, Thomas Jones wrote:
On Monday 28 July 2003 07:08, Stephen P. Molnar, Ph.D. wrote:
ifconfig results in:
eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000 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:2936 errors:0 dropped:0 overruns:0 frame:0 TX packets:2936 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:427292 (417.2 Kb) TX bytes:427292 (417.2 Kb)
<snip>
First change your subnet mask to the proper configuration. The 10.0.0.0 subnet is designated as a class A network. The subnet mask for class A networks are 255.0.0.0
In my network I am able to ping other hosts using a class C netmask (and ip addresses 10.0.0.).... And being 10.0.0.0/8 a reserved range what would make it not possible to subnet it into 10.0.0.1/24(for example) to use it in your private network ?? As long as you are consistent with your netmasks (you are subnetting in a correct matter) and you are using IPs within a reservered class you should be fine... What does tcpdump show anyways..?
You probably are able to communicate with distant computers without a problem. However for the local network(s), the subnet mask is used to determine if a particular device is accessible. if not, the datagrams must be forwarded to the gateway ---- as your computer is doing -------- if i am right.
This is surely why you are able to access the internet. But not talk to the LAN.
;) -- Thomas Jones Linux-Howtos Network Administrator OpenGPG Key: 0x6A3DF6E9
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
On Monday 28 July 2003 12:34 pm, Raúl Gutiérrez Segalés wrote:
On Mon, 28 Jul 2003, Thomas Jones wrote:
On Monday 28 July 2003 07:08, Stephen P. Molnar, Ph.D. wrote: <...cut...> In my network I am able to ping other hosts using a class C netmask (and ip addresses 10.0.0.)....
And being 10.0.0.0/8 a reserved range what would make it not possible to subnet it into 10.0.0.1/24(for example) to use it in your private network ??
As long as you are consistent with your netmasks (you are subnetting in a correct matter) and you are using IPs within a reservered class you should be fine...
What does tcpdump show anyways..?
listening on eth0 then nothing
You probably are able to communicate with distant computers without a problem. However for the local network(s), the subnet mask is used to determine if a particular device is accessible. if not, the datagrams must be forwarded to the gateway ---- as your computer is doing -------- if i am right.
This is surely why you are able to access the internet. But not talk to the LAN.
;) -- Thomas Jones Linux-Howtos Network Administrator OpenGPG Key: 0x6A3DF6E9
-- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-- Stephen P. Molnar, Ph.D. Life is a fuzzy set Foundation for Chemistry Stochastic and multivariant http://web.jadeinc.com/FoundationChem
Monday, Jul 28 at 11:26am, Thomas Jones wrote:
On Monday 28 July 2003 07:08, Stephen P. Molnar, Ph.D. wrote: <snip>
First change your subnet mask to the proper configuration. The 10.0.0.0 subnet is designated as a class A network. The subnet mask for class A networks are 255.0.0.0
You probably are able to communicate with distant computers without a problem. However for the local network(s), the subnet mask is used to determine if a particular device is accessible. if not, the datagrams must be forwarded to the gateway ---- as your computer is doing -------- if i am right.
This is surely why you are able to access the internet. But not talk to the LAN.
WRONG!! The netmask shown is surely not the reason why he cannot talk to the LAN. I don't know what the solution to Dr. Molnar's problem is, but changing to a class A netmask is barking up the wrong tree. There is absolutely no requirement that a 10.x.x.x network use a class A netmask--we use Class C netmasks on such a network with no problems whatsoever. Ever since the adoption of CIDR (Classless Inter-Domain Routing - see RFC 1519), the concept of Class A, B and C netmasks has been obsolete. Jim
On Monday 28 July 2003 12:03, Jim Cunning wrote: <snip>
WRONG!! The netmask shown is surely not the reason why he cannot talk to the LAN. I don't know what the solution to Dr. Molnar's problem is, but changing to a class A netmask is barking up the wrong tree.
There is absolutely no requirement that a 10.x.x.x network use a class A netmask--we use Class C netmasks on such a network with no problems whatsoever. Ever since the adoption of CIDR (Classless Inter-Domain Routing - see RFC 1519), the concept of Class A, B and C netmasks has been obsolete.
Jim
Jim, I understand CIDR....i have a certificate in TCP/IP administration. And in fact, i did calculate his broadcast address by supernetting his subnet and using ANDing. However, what you fail to realize is that for the CIDR implementation to work there have to be various things to possibly work: 1. No routing device between the hosts in question. 2. If a routing device does exist in the network, it must be CIDR compatible. 3. If that device is compatible it must be configured to correctly process the proper routing protocol ---- as in BGP or RIPv2. So as you can see, your explanation that CIDR WILL work is incorrectly stated. Specifically for private/residential networks, the use of BGP is next to nil. Nevertheless, this is fairly easy to determine. All he has to do is ping the IP addy of the other node. Then attempt to ping an outside entity ----maybe www.google.com - 216.239.37.99 . Do so from both nodes. If he cannot ping the local node, and the node is in fact accessing the WAN; than it is the routing at fault. That's all there is to it. -- Thomas Jones Linux-Howtos Network Administrator OpenGPG Key: 0x6A3DF6E9
Monday July 28 at 4:03pm, Thomas Jones wrote:
On Monday 28 July 2003 12:03, Jim Cunning wrote: <snip>
WRONG!! The netmask shown is surely not the reason why he cannot talk to the LAN. I don't know what the solution to Dr. Molnar's problem is, but changing to a class A netmask is barking up the wrong tree.
There is absolutely no requirement that a 10.x.x.x network use a class A netmask--we use Class C netmasks on such a network with no problems whatsoever. Ever since the adoption of CIDR (Classless Inter-Domain Routing - see RFC 1519), the concept of Class A, B and C netmasks has been obsolete.
Jim
Jim,
I understand CIDR....i have a certificate in TCP/IP administration. And in fact, i did calculate his broadcast address by supernetting his subnet and using ANDing.
If you did, then you must have concluded that the broadcast address he had for the network address and mask was correct. Address: 10.0.0.2, broadcast: 10.0.0.255, and netmask 255.255.255.0 is just fine.
However, what you fail to realize is that for the CIDR implementation to work there have to be various things to possibly work:
1. No routing device between the hosts in question.
Dr. Molnar did say it was a small LAN, so that is a safe assumption. He was having trouble with 10.0.0.2 not reaching 10.0.0.1. With ANY netmask we've discussed (class A or C), those two hosts have to be on the same subnet, so routers are irrelevant.
2. If a routing device does exist in the network, it must be CIDR compatible.
OK, but that isn't an issue because of #1.
3. If that device is compatible it must be configured to correctly process the proper routing protocol ---- as in BGP or RIPv2.
This doesn't follow at all. There is no need for any routing protocols here for a CIDR compatible router to work. We have a lab with hundreds of IP hosts and many different sorts of routers. None of them has BGP or RIP configured, yet we have many networks: 10.x.x.x/12 and /24, 172.16.x.x/20, 192.168.x.x/24, /28, and /30. All work just fine without routing protocols, just a lot of static routes.
So as you can see, your explanation that CIDR WILL work is incorrectly stated. Specifically for private/residential networks, the use of BGP is next to nil.
No I don't see, though from my response above I agree that BGP use is low in those networks.
Nevertheless, this is fairly easy to determine.
All he has to do is ping the IP addy of the other node. Then attempt to ping an outside entity ----maybe www.google.com - 216.239.37.99 .
Do so from both nodes.
If he cannot ping the local node, and the node is in fact accessing the WAN; than it is the routing at fault. That's all there is to it.
I wouldn't be so categorical. First, Dr. Molnar never said he was accessing the WAN from either of the hosts he identified. Second, routing is far from the only possible reason for failure to reach a local host. Earlier in this thread, Dr. Molnar said that ifconfig only showed two interfaces: eth0 and lo. If you look at his output from eth0
eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000
you'll see that 133 packets have been transmitted, but NONE has been received. He also said that tcpdump reported no traffic. From this I would suspect: ethernet cable, NIC (in either host on the LAN), or ethernet hub/switch. BTW, when mount fails to reach a host (using smbfs, at least), perhaps for one of the faults I listed above, it reports test:~ # mount -t smbfs //testhost12/N /mnt Error connecting to 10.1.1.12 (No route to host) 24534: Connection to testhost failed SMB connection failed The "No route to host" is a bit of a red herring, because there was no routing problem in my test, just a non-responsive host (because it wasn't there). Jim
On Monday 28 July 2003 17:57, Jim Cunning wrote:
If you did, then you must have concluded that the broadcast address he had for the network address and mask was correct. Address: 10.0.0.2, broadcast: 10.0.0.255, and netmask 255.255.255.0 is just fine.
And you have determined that both devices are utilizing the same masking scheme from what statement?
However, what you fail to realize is that for the CIDR implementation to work there have to be various things to possibly work:
1. No routing device between the hosts in question.
Dr. Molnar did say it was a small LAN, so that is a safe assumption. He was having trouble with 10.0.0.2 not reaching 10.0.0.1. With ANY netmask we've discussed (class A or C), those two hosts have to be on the same subnet, so routers are irrelevant.
This doesn't follow at all. There is no need for any routing protocols here for a CIDR compatible router to work. We have a lab with hundreds of IP hosts and many different sorts of routers. None of them has BGP or RIP configured, yet we have many networks: 10.x.x.x/12 and /24, 172.16.x.x/20, 192.168.x.x/24, /28, and /30. All work just fine without routing protocols, just a lot of static routes.
You may be using OSPF. Actually, i am not sure whether that is a classless compatible protocol or not.
So as you can see, your explanation that CIDR WILL work is incorrectly stated. Specifically for private/residential networks, the use of BGP is next to nil.
I wouldn't be so categorical. First, Dr. Molnar never said he was accessing the WAN from either of the hosts he identified. Second, routing is far from the only possible reason for failure to reach a local host.
Earlier in this thread, Dr. Molnar said that ifconfig only showed two interfaces: eth0 and lo. If you look at his output from eth0
eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000
you'll see that 133 packets have been transmitted, but NONE has been received. He also said that tcpdump reported no traffic. From this I would suspect: ethernet cable, NIC (in either host on the LAN), or ethernet hub/switch.
tcpdump should intercept every outbound packet on the eth0 interface whether or not he is receiving any responses at all. You can capture traffic in the following scenarios to test my point. 1. Remove the network medium from your machine. start up tcpdump or ethereal for eth?. now issue a ping command to any host ---- say 192.168.1.1. You will see outbound traffic with reference to 'icmp_echo_request'. or 2. Start up tcpdump for promisc() mode on loopback ---- lo. Now issue a ping 127.0.0.1 command. You will see traffic as well. This leads me to believe that the traffic is in fact not being generated at all. If the good doctor had captured all outbound traffic but no response; i would be inclined to agree with your NIC and/or medium proposal. However, as you can see; this is not the case. The only reason that i can think that his system would be neglecting to generate any traffic at all would be three things: 1. The stack is corrupt. 2. A filtering function is in place. 3. The stack cannot determine a valid route for the appropriate ethernet headers. Your thoughts?
BTW, when mount fails to reach a host (using smbfs, at least), perhaps for one of the faults I listed above, it reports
test:~ # mount -t smbfs //testhost12/N /mnt Error connecting to 10.1.1.12 (No route to host) 24534: Connection to testhost failed SMB connection failed
The "No route to host" is a bit of a red herring, because there was no routing problem in my test, just a non-responsive host (because it wasn't there).
Well, you may have noticed from my previous post that it is a definite answer as to whether or not it will be a routing issue or not. That is precisely why i made a note of possible mask issues. Meaning, this is a very easy way to test the ARP and/or route configuration of any stack. I realize that it is an odd request. After all, if a person could not access local hosts how can they access remote ones. Seems logical from afar. BUt, in the underlying layers of the stack there is much more to it. I don't know how much TCP/IP experience you may have, but the symptoms that local versus remote connectivity problems are typical for mask mis-configurations. Hence, my hasty reply. You win some ---- you lose some. I just am throwing out ideas. ;) -- Thomas Jones Linux-Howtos Network Administrator OpenGPG Key: 0x6A3DF6E9
I trust that this is a friendly exchange. I would hate to think that my LAN problem is causing dissention. A few more observations about the problem. Someone suggested that the problem was due to the hub or the cables. I don't think that this is the case as my linux machine will access my laptop running Win2000pro via the LAN without any problems. However, LinNeighborhood tells me that: GetSMBShare:smbclient -L INGA -I 10.0.0.3 -U% -W FFC -d3 Initialising global parameters params.c:pm_process() - Processing configuration file "//etc/samba/smb.conf" Processing section "[global]" added interface ip=10.0.0.2 bcast=10.0.0.255 nmask=255.255.255.0 Client started (version 2.2.5). Connecting to 10.0.0.3 at port 139 Domain=[FFC] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager] Sharename Type Comment --------- ---- ------- Error returning browse list: NT_STATUS_ACCESS_DENIED Server Comment --------- ------- INGA Workgroup Master --------- ------- FFC INGA However, I can mount INGA via SAMBA by executing smbmount in a console. Having answered the hardware question. I find that I can ping both ways between the linux platform and the laptop. If, however I ping the W2000p box (not the laptop) I get: abnormal:~ # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) from 10.0.0.2 : 56(84) bytes of data. From 10.0.0.2: icmp_seq=1 Destination Host Unreachable From 10.0.0.2 icmp_seq=1 Destination Host Unreachable From 10.0.0.2 icmp_seq=2 Destination Host Unreachable From 10.0.0.2 icmp_seq=3 Destination Host Unreachable --- 10.0.0.1 ping statistics --- 6 packets transmitted, 0 received, +4 errors, 100% loss, time 5028ms , pipe 3 Now if I switch to the W2000p platform pinging either other machine doesn't work. I am forced to conclude that the problem wies with W2000p on that machine. Therefore, I am really at sea. On Monday 28 July 2003 06:57 pm, Jim Cunning wrote:
Monday July 28 at 4:03pm, Thomas Jones wrote:
On Monday 28 July 2003 12:03, Jim Cunning wrote: <snip>
WRONG!! The netmask shown is surely not the reason why he cannot talk to the LAN. I don't know what the solution to Dr. Molnar's problem is, but changing to a class A netmask is barking up the wrong tree.
There is absolutely no requirement that a 10.x.x.x network use a class A netmask--we use Class C netmasks on such a network with no problems whatsoever. Ever since the adoption of CIDR (Classless Inter-Domain Routing - see RFC 1519), the concept of Class A, B and C netmasks has been obsolete.
Jim
Jim,
I understand CIDR....i have a certificate in TCP/IP administration. And in fact, i did calculate his broadcast address by supernetting his subnet and using ANDing.
If you did, then you must have concluded that the broadcast address he had for the network address and mask was correct. Address: 10.0.0.2, broadcast: 10.0.0.255, and netmask 255.255.255.0 is just fine.
However, what you fail to realize is that for the CIDR implementation to work there have to be various things to possibly work:
1. No routing device between the hosts in question.
Dr. Molnar did say it was a small LAN, so that is a safe assumption. He was having trouble with 10.0.0.2 not reaching 10.0.0.1. With ANY netmask we've discussed (class A or C), those two hosts have to be on the same subnet, so routers are irrelevant.
2. If a routing device does exist in the network, it must be CIDR compatible.
OK, but that isn't an issue because of #1.
3. If that device is compatible it must be configured to correctly process the proper routing protocol ---- as in BGP or RIPv2.
This doesn't follow at all. There is no need for any routing protocols here for a CIDR compatible router to work. We have a lab with hundreds of IP hosts and many different sorts of routers. None of them has BGP or RIP configured, yet we have many networks: 10.x.x.x/12 and /24, 172.16.x.x/20, 192.168.x.x/24, /28, and /30. All work just fine without routing protocols, just a lot of static routes.
So as you can see, your explanation that CIDR WILL work is incorrectly stated. Specifically for private/residential networks, the use of BGP is next to nil.
No I don't see, though from my response above I agree that BGP use is low in those networks.
Nevertheless, this is fairly easy to determine.
All he has to do is ping the IP addy of the other node. Then attempt to ping an outside entity ----maybe www.google.com - 216.239.37.99 .
Do so from both nodes.
If he cannot ping the local node, and the node is in fact accessing the WAN; than it is the routing at fault. That's all there is to it.
I wouldn't be so categorical. First, Dr. Molnar never said he was accessing the WAN from either of the hosts he identified. Second, routing is far from the only possible reason for failure to reach a local host.
Earlier in this thread, Dr. Molnar said that ifconfig only showed two interfaces: eth0 and lo. If you look at his output from eth0
eth0 Link encap:Ethernet HWaddr 00:A0:CC:78:C9:1F inet addr:10.0.0.2 Bcast:10.0.0.255 Mask:255.255.255.0 inet6 addr: fe80::2a0:ccff:fe78:c91f/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:133 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:6790 (6.6 Kb) Interrupt:11 Base address:0x7000
you'll see that 133 packets have been transmitted, but NONE has been received. He also said that tcpdump reported no traffic. From this I would suspect: ethernet cable, NIC (in either host on the LAN), or ethernet hub/switch.
BTW, when mount fails to reach a host (using smbfs, at least), perhaps for one of the faults I listed above, it reports
test:~ # mount -t smbfs //testhost12/N /mnt Error connecting to 10.1.1.12 (No route to host) 24534: Connection to testhost failed SMB connection failed
The "No route to host" is a bit of a red herring, because there was no routing problem in my test, just a non-responsive host (because it wasn't there).
Jim
-- Stephen P. Molnar, Ph.D. Life is a fuzzy set Foundation for Chemistry Stochastic and multivariant http://web.jadeinc.com/FoundationChem
Tuesday July 29 at 8:28am, Stephen P. Molnar, Ph.D. wrote:
Someone suggested that the problem was due to the hub or the cables. I don't think that this is the case as my linux machine will access my laptop running Win2000pro via the LAN without any problems. However, LinNeighborhood tells me that:
GetSMBShare:smbclient -L INGA -I 10.0.0.3 -U% -W FFC -d3 Initialising global parameters params.c:pm_process() - Processing configuration file "//etc/samba/smb.conf" Processing section "[global]" added interface ip=10.0.0.2 bcast=10.0.0.255 nmask=255.255.255.0 Client started (version 2.2.5). Connecting to 10.0.0.3 at port 139 Domain=[FFC] OS=[Windows 5.0] Server=[Windows 2000 LAN Manager]
Sharename Type Comment --------- ---- ------- Error returning browse list: NT_STATUS_ACCESS_DENIED
That is probably a password problem. LinNeighborhood won't show me any shares on my NT box unless I right-click to select "scan as user" and enter a username and password. [snip]
Having answered the hardware question. I find that I can ping both ways between the linux platform and the laptop.
If, however I ping the W2000p box (not the laptop) I get:
abnormal:~ # ping 10.0.0.1 PING 10.0.0.1 (10.0.0.1) from 10.0.0.2 : 56(84) bytes of data.
From 10.0.0.2: icmp_seq=1 Destination Host Unreachable
How does your W2000p box get it IP address? Is it statically configured, or does it need a DHCP server? Could you have forgotten to setup dhcpd on your Linux box after you reinstalled? I have done that before. :^) (BTW, given the recent discussions about routing and netmasks, you may already know that "Destination Host Unreachable" from ping above doesn't mean there is a route problem. That's what ping now reports when it gets no response from a host.) Jim
participants (5)
-
Jim Cunning -
Joe Morris (NTM) -
Raúl Gutiérrez Segalés -
Stephen P. Molnar, Ph.D. -
Thomas Jones