Subject: | |
From: | |
Reply To: | |
Date: | Thu, 29 Nov 2007 19:12:04 -0600 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
I couldn't find how to capture ipv6 packets but I disabled it to see if
it makes any difference. Actually I still get the same
cvs [login aborted]: connect to
neutralino.physics.uiowa.edu(128.255.34.167):2401 failed: No route to host
message. telnet is also giving similar problem:
telnet neutralino.physics.uiowa.edu 2401
Trying 128.255.34.167...
telnet: Unable to connect to remote host: No route to host
:
Maxim kovgan wrote:
> Can you try and capture any ipv6 packets trying to leave your computer
> when you're trying to login into cvs or to do other things with cvs ?
>
>
> IF you find anything running, disable ipv6.
> (refer to your distribution's manual on how to do this.)
>
> Cheers.
>
>
>
>
> Taylan Yetkin wrote:
>> Hi,
>> ifconfig in the host returns:
>>
>> eth0 Link encap:Ethernet HWaddr 00:19:D1:25:1F:C9
>> inet addr:128.255.34.167 Bcast:128.255.35.255
>> Mask:255.255.252.0
>> inet6 addr: fe80::219:d1ff:fe25:1fc9/64 Scope:Link
>> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
>> RX packets:190785 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:55961 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:100
>> RX bytes:57983176 (55.2 MiB) TX bytes:11357915 (10.8 MiB)
>> Base address:0xecc0 Memory:dffe0000-e0000000
>>
>> 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:5670 errors:0 dropped:0 overruns:0 frame:0
>> TX packets:5670 errors:0 dropped:0 overruns:0 carrier:0
>> collisions:0 txqueuelen:0
>> RX bytes:10405386 (9.9 MiB) TX bytes:10405386 (9.9 MiB)
>>
>> while netstat -nr returns
>>
>>
>> Kernel IP routing table
>> Destination Gateway Genmask Flags MSS Window
>> irtt Iface
>> 128.255.32.0 0.0.0.0 255.255.252.0 U 0
>> 0 0 eth0
>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0
>> 0 0 eth0
>> 0.0.0.0 128.255.32.1 0.0.0.0 UG 0
>> 0 0 eth0
>>
>>
>> Taylan
>>
>>
>>
>> Maxim kovgan wrote:
>>> Taylan Yetkin wrote:
>>>> Both ping and traceroute the host from fermi machines returns
>>>> success. I need some time to understand the use of tcpdump.
>>>> thanks,
>>>> Taylan
>>>
>>> can you post your ifconfig of the listening interface ?
>>>
>>>
>>> a routing table would be nice too:
>>> netstat -nr
>>>
>>> you can of course scramble the IP addresses.
>>>
>>>
>>>
>>>>
>>>> Maxim kovgan wrote:
>>>>> John Summerfield wrote:
>>>>>> Maxim kovgan wrote:
>>>>>>> John Summerfield wrote:
>>>>>>>> Taylan Yetkin wrote:
>>>>>>>>> Hi,
>>>>>>>>> I installed a cvs repository in my local SL machine and trying
>>>>>>>>> to connect
>>>>>>>>> it
>>>>>>>>> from fermi machines. I get the following error:
>>>>>>>>>
>>>>>>>>> [cmswn085> cvs login
>>>>>>>>> Logging in to
>>>>>>>>> :pserver:[log in to unmask]:2401/var/lib/
>>>>>>>>> cvsroot
>>>>>>>>> CVS password:
>>>>>>>>> cvs [login aborted]: connect to
>>>>>>>>> neutralino.physics.uiowa.edu(128.255.34.167):2401 failed: No
>>>>>>>>> route to hos
>>>>>>>>> t
>>>>>>>>
>>>>>>>> This is a routing/firewall problem. the cvs command asks for
>>>>>>>> the password before trying to connect.
>>>>>>>>
>>>>>>>> 07:02 [summer@numbat ~]$ cvs -d
>>>>>>>> :pserver:anoncvs@localhost:2401/var/lib/ login
>>>>>>>> Logging in to :pserver:anoncvs@localhost:2401/var/lib
>>>>>>>> CVS password:
>>>>>>>> cvs [login aborted]: connect to [localhost]:2401 failed:
>>>>>>>> Connection refused
>>>>>>>> 07:03 [summer@numbat ~]$
>>>>>>>
>>>>>>> It's most probably tcpwrappers
>>>>>>
>>>>>> No. That allows a connexion, then rejects it. You don't get "no
>>>>>> route" or "refused messages."
>>>>>
>>>>> AFAIK tcpwrappers refuse too.
>>>>> but I somehow missed the no route to.. :)
>>>>> and you're right! it needs some investigation:
>>>>>
>>>>> 1. ping to the host
>>>>> 2. traceroute to the host.
>>>>>
>>>>> if you sporadically get the no route problem, it means you have
>>>>> ... a routing problem :)
>>>>>
>>>>> after you finished up with it, you can continue and trouble shoot.
>>>>> routing problem can be cause by your university/enterprise
>>>>> firewall too.
>>>>>
>>>>>
>>>>> you can also investigate with tcpdump, which is a great sniffer.
>>>>>
>>>>> Good luck!
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> "reset" is more probable.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>
|
|
|