well, go and search for the firewalls on the way now. with a clear conscience. :) Taylan Yetkin wrote: > 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 > assuming your interface of question is eth0: tcpdump -vvv -i eth0 -w results.tcpdump ip6 this will run as much as you want, and will print how many packets has it got, once in a while. when you have enough, you stop it with ^C, and go and watch the results of the capture via wireshark, or ethereal or any other graphical tool. regards. > 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. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> > -- Maxim Kovgan, Distributed Systems and Data Mining Laboratory Computer Science, Technion http://dsl.cs.technion.ac.il