possible problem with scp/ssh/telnet

[Paul Allen Newell]

[inline]

On 8/12/2012 4:12 PM, David G. Miller wrote:
> Paul Allen Newell <pnewell <at> cs.cmu.edu> writes:
>
>
> <SNIP>
>
>> it is logging errors and I see the following:
>>
>> Aug 11 23:43:43 yoyo kernel: [ 779.725071] <IPTABLES: LOG REJECT>
>> IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:1e:8c:c3:21:d6:08:00
>> SRC=192.168.2.14 DST=192.168.2.255 LEN=229 TOS=0x00 PREC=0x00 TTL=128
>> ID=33554 PROTO=UDP SPT=138 DPT=138 LEN=209
> <SNIP>
> Just a quick lesson in reading IP tables logs.  For first level connection
> debugging I find the following pieces of information in the log to be most
> useful:
>
> SRC=IP address of the sending system
> DST=IP address of the destination system
>
> Do an ifconfig (Linux) or ipconfig (Windows) to see what the IP address is for
> both end points.  Verifying these lets you make sure the problem isn't DNS.

Dave:

Thanks for reply.

I checked ifconfig/ipconfig, plus verified the hosts file on both 
machines. I also checked the tcp/ip settings on the Windows side. 
Everything looks correct and certainly has not changed.

>
> PROTO=The protocol for the communication.  Typically one of UDP, TCP or ICMP.
> ssh and telnet  use TCP so these log entries are for something else.

Missed that, thanks. I was just so happy to get a log on the two 
machines that I didn't check the PROTO. I did a quick rescan of the 
messages and there are no TCP entries as a PROTO. Yeah, I am confused

>
> SPT=Source port.  Can be interesting if you have outbound firewall filter rules
> (most people don't).
> DPT=Destination port.  Identifies the service requested at the destination.
> Look in /etc/services for definitions.  ssh is service (or port 22) and telnet
> is service (or port) 23.  Your log entries are to port 138 so, again, nothing to
> do with ssh or telnet.

Okay, more confusion as I am not seeing any port 22.

As mentioned in an earlier email today, everything is up and running so 
I can't do any more "tests when in failure mode".

My take on this is that I should treat the info in the logs to be not 
relevant, especially when I was able to prove Ed's thesis that the 
problem is on the cygwin/WinXP side given powering down the Fedora box 
and just running a self-referential ssh on the cygwin side generated the 
"connection refused" error.

I'm going to take the risk of not putting a question mark at the end of 
that sentence as I really hope that I have got this right

Paul
>
> Cheers,
> Dave
>