unable to connect in a LAN

[navneethr]

I have a desktop with 4 GB of RAM ...intel mother board, intel dual core...fairly recent one...about 6 months old.. I run fedora 14 on it..
It was working well...at least the networking part of it..I had connected it to a D-Link hub ...with another one also connected to the hub. Both were in a network...However all of a sudden I cannot connect to it from the other machine via an ethernet cable.
I can see the network icon (2 monitors next to the speaker icon) on the top right hand side showing up correctly. (No red cross against it).
However I am unable to connect to it.
The ping command only works against itself ...there is not packet loss.
Howerver when I ping the other machine I there is 100% packet loss.
I changed cables, I reconnected the hub...I changed the location of the cable in the hub.....But am just not able to connect.
Can someone let me know what is going on here...I did not change any network parameters neihter is this machine on the itnernet...
What could go wrong...Which log files should I see ..
Any help would be very much appreciated.

[glennzo]

Open a terminal and type

PHP Code:

ip addr 


Could you post the result of that command please?

[george_toolan]

If you're using a DHCP server then the IP addresses probably have changed.

[navneethr]

Thanks for your replies.
Here is the information you need...and the output of other commands which I think may throw some more light...
I have not connected the computers via DHCP..Its a local LAN and the values have been set by me..



output of ip addr command

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
link/ether e0:cb:4e:28:61:e8 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.16/24 brd 192.168.1.255 scope global eth0
inet6 fe80::e2cb:4eff:fe28:61e8/64 scope link
valid_lft forever preferred_lft forever


output of dmesg |tail command

[ 55.615330] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 56.407047] r8169 0000:03:00.0: eth0: link up
[ 56.571400] RPC: Registered udp transport module.
[ 56.571402] RPC: Registered tcp transport module.
[ 56.571404] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 56.578045] SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts
[ 66.634009] eth0: no IPv6 routers present
[ 135.894544] fuse init (API version 7.14)
[ 135.909457] SELinux: initialized (dev fusectl, type fusectl), uses genfs_contexts
[ 135.928829] SELinux: initialized (dev fuse, type fuse), uses genfs_contexts


output of ifconfig -a command

eth0 Link encap:Ethernet HWaddr E0B:4E:28:61:E8
inet addr:192.168.1.16 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::e2cb:4eff:fe28:61e8/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:24 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:4442 (4.3 KiB)
Interrupt:44 Base address:0x2000

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:47 errors:0 dropped:0 overruns:0 frame:0
TX packets:47 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:3785 (3.6 KiB) TX bytes:3785 (3.6 KiB)

output of iptables -L -n command

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

[george_toolan]

What exactly is the problem?

Is your WAN connection still working?

You'll need the IP address for the "other machine" in your LAN and your routing table.

route

[stevea]

ip route

What other machine are you trying to ping ? Post the ping command and output.

[navneethr]

Thanks for trying to solve this vexing and strange isse that I am facing...
Here are the outputs for your scrutiny....

Command output from the machine having the machine having an issue
name dkshm IP address 192.168.1.16

ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.16 metric 1
default via 192.168.1.2 dev eth0 proto static

route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 1 0 0 eth0
default 192.168.1.2 0.0.0.0 UG 0 0 0 eth0



ping hp
PING hp (192.168.1.4) 56(84) bytes of data.
From localhost.localdomain (192.168.1.16) icmp_seq=2 Destination Host Unreachable
From localhost.localdomain (192.168.1.16) icmp_seq=3 Destination Host Unreachable
From localhost.localdomain (192.168.1.16) icmp_seq=4 Destination Host Unreachable
From localhost.localdomain (192.168.1.16) icmp_seq=6 Destination Host Unreachable


Commands from the other machine 192.168.1.4 (hp) which is fine

ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4 metric 1
default via 192.168.1.1 dev eth0 proto static


route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 * 255.255.255.0 U 1 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

ping dkshm
PING dkshm (192.168.1.16) 56(84) bytes of data.
From localhost.localdomain (192.168.1.4) icmp_seq=2 Destination Host Unreachable
From localhost.localdomain (192.168.1.4) icmp_seq=3 Destination Host Unreachable


This machine (192.168.1.16) was working fine all the past 3 months. (its a new machine).
The 2 network icons on the top r.h.s on (192.168.1.16)....does not show any Red cross
Machine dkshm (192.168.1.16)...can ping itself but cannot ping 192.168.1.4 (the othe machine).
I have changed cables, changes slots in the hub...but the issue yet remains.
The strange thing is that even if the ethernet cables on dkshm are removed THE NETWORK ICON on the top does not show a RED CROSS. Its as if the machine is NETWORKED TO ITSELF.

[george_toolan]

Oh stop pinging yourself. That's only using the loopback device ;-)

Next thing try traceroute instead of ping.

If you have two machines and one router

default 192.168.1.2 0.0.0.0 UG 0 0 0 eth0
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

So what's the IP address of your router? *.1 or *.2?

[navneethr]

Thanks George. I take your suggestion about not pinging myself. Thanks for the explaination too...Sorry about that.
Honeslty I dont think this is a router...It seems to be DLink Hub which has just about 8 outlets...
But will check and let you know.
I really was not sure about the IP address of the hub...I just started using 192.168.1.2 after reading about it somewhere on the net and it worked without me having to do anything.
That is my other concern....How did it work automatically without me having to put in a password etc?
I dont think this hub is a secure way ...
But once again I will check and let you know..Sorry I am not too good in networking...Just about managing things..
Thanks for your help..Best WIshes and Have a good day.
WIll revert asap.

[george_toolan]

A network switch usually doesn't require any configuration and why would you need a password?

You do however have some of "router" in your network and an internet connection or you wouldn't be here ;-)

quick and dirty hack:

route add default gw 192.168.1.1

working now? If it doesn't try

route add default gw 192.168.1.2

on both machines.

You can look up the syntax for ip route as an exercise.

[stevea]

Thanks for all the anti-help & FUD George.

If you'd bothered to read you'd see that both systems have 192.168.1.1 as their default gateways.

No, ping DOES NOT use the loopback unless your /etc/hosts or name server resolves to 127.0.0.1.
Instead the icmp goes up & down the local stack, but not to the PHY layer, and does require correct
IP resolution.
=========


No the useful questions are these .
Most wired ent interfaces have some LEDs that are lit IF you have a good connection. Are they ?
Post the result of
ip link
for both please.

How does each system get it's IP address ? (DHCP vs local configuration)
How are he two systems connected ? (presumable cables to a HUB or SWITCH in the router).
Can each/either system ping the router at 192.168.1.1 ?

[navneethr]

The issue is resolved...Thanks to your tips and suggestions from all of you. I noticed that the gateway values were wrong on one of the machines..On one machine it was 192.168.1.2 and the other 192.168.1.1...On correcting it...rebooting the machines ...all works fine...The configuration was done manually by myself...not via DHCP.

Thanks a ton for all your help...Best Wishes..and Have a good day.....You all helped me to solve a really vexing problem...

[george_toolan]

If you'd bothered to read you'd see that both systems have 192.168.1.1 as their default gateways.

You really should have your eyes checked ;-)

[stevea]

Originally Posted by george_toolan

You really should have your eyes checked ;-)

Yes ! I do ~2x a year and it doesn't help (enough). Eyesight is not a strong skill here.

George - I do really like you and your intentions to help others, and I DO appreciate that you have the best of intentions - but do you really think than making up BS about the loopback helps anyone ? Or even directing ppl to change things like gateway that can have ZERO impact on the LAN packets ?

The other problem with this thread, and your suggestion George. Even if the gateway was wrong - this has ABSOLUTELY NO IMPACT on the packets directed to the local LAN. Like the OPs ping fails.

Let me search and avoid using eyeysight ...
Post #7 says one system has ...

ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.16 metric 1
default via 192.168.1.2 dev eth0 proto static

and the other system has ...

ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.4 metric 1
default via 192.168.1.1 dev eth0 proto static

which means that any IP address that resolves to 192.168.1.* (like all the the ping fails) IS NOT ROUTED and the gateway setting has ZERO IMPACT.

=====

So in this thread we have the blind leading the blind, critiqued by the very nearsighted. I could suggest that "in the land of the blind the nearsighted guy is king". I could accurately point out that changing the Gateway cannot possibly accomplish any effective change in this problem, yet that is exactly what the OP claim is effective.


Next time I suggest the OP throw salt over his shoulder, verify the time on a stopped clock, cross his fingers, pluck the petals from a daisy counting - "you ARP my IPs, you ARP them not", then try again. That's at least as good as GeorgeTs suggestions and perhaps better than mine.


"The average man does not get pleasure out of an idea because he thinks it is true; he thinks it is true because he gets pleasure out of it." - H L Mencken

[navneethr]

Steve thank you for your comments and analysis. I thought it was me changing the gw values which I noticed was different in one of them...that did the trick. But it seems that Steve is right...These values existed for several months and it yet worked... I am sorry I thought correcting those values solved my issue..
There was one more thing that I did which may have solved the issue...But since I did both of them simultaneously I thought the GW address change really did the trick.
I went into the BIOS menu to check if the LAN was enabled on the machine giving problems. I noticed that LAN was enabled under peripheral configurations. So that was not the issues...But while exiting the BIOS menu I reset all the options...May THIS did the trick.. really not sure.. *but am glad everything is back to normal". . I can surely tell you that I never changed any BIOS settings on this machine for nearly a month. The network just stopped all of a sudden...
The weird thing was the network icons were showing everything OK even when there was no cable...This has really baffled me..I was going to send this attachment but then the problem resolved. But here it is anyways...
thanks, oll of you for helping me solve the problem...Your advice and suggestions have thrown a lot of light on my limited knowledge. Most important it somehow solved my issue...When what a reilef...