Folks, a thought: could this be a badly-bahaving ARP cache on his LAN somewhere? I'm not sure if that could be a culprit, but it sounds like the devices are confused as to where the other devices are, but once the routing is active, everything works correctly. Jamie, can you packet-sniff from another box to see if packets are being mis-directed in the case where it takes the extra minute to connect?? tcpdump, iptraf, or similar tools should do you good here... there is a new packet sniffer I found referenced in the latest Linux Journal, will try to provide a link... APS is here: http://www.swrtec.de/clinux/ I tried it and liked it, but found it odd that Linux Journal just now reported on it, when its web page indicates that it is migrating into another project called "OOPS"... strange, looks like OOPS is not ready yet tho. Good luck!
Ben B PS - or alternatively, if the machine which fails had a default gateway set to something that is NOT on the LAN, those packets might circular, looking for their gateway, until they find their destination locally, no? On Mon, 2003-03-24 at 08:03, Linux Rocks ! wrote: > So... I just tried to connect to the firewall box (test) by its IP address, > and there was no delay. I left that connection open, and tried by its > hostname (test), and it also connected with no delay. So... It apears that if > I have any telnet connection open to the box from my workstation it will > connect right up when using the hostname, its just the initial connection by > its hostname. Maybe Ill setup a DNS server on the new firewall/gateway box... > that may solve the issue, but I still think somethings screwwy on my > workstation... > > Jamie _______________________________________________ Eug-LUG mailing list [EMAIL PROTECTED] http://mailman.efn.org/cgi-bin/listinfo/eug-lug
