osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Checking refusal of a network connection


On 01Jun2019 12:57, Dennis Lee Bieber <wlfraed at ix.netcom.com> wrote:
>On Sat, 1 Jun 2019 15:33:43 +0200, Markus Elfring <Markus.Elfring at web.de>
>declaimed the following:
>
>	I don't know "strace" (I'd likely be running WireShark to capture all
>traffic for investigation).

Sure, but that means you need to winnow it from any other traffic. The 
advantage of strace is that it watches the programme itself, and shows 
(in this case) the network system calls. It is great for seeing what the 
programme is doing/trying to do at the basic level. And, like wireshark, 
language independent - all runtimes have to go through the OS to get 
stuff done.  I've debugged third party java apps this way because the 
issue was a basic one like this.

>>connect(4, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = 0
>
>>connect(3, {sa_family=AF_INET, sin_port=htons(37351), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 ECONNREFUSED (Connection refused)
>
>	Without seeing the code, I'd be suspicious of that difference. The
>latter is asking for a TCP/UDP family connection, whereas the first is a
>UNIX domain socket. To my knowledge they are not compatible types.

They're certainly distinct address spaces. In other regards they're 
pretty compatible - you listen/connect the same way. A UNIX socket is 
just IPC within the kernel instead of over the network.

However, the former connect is to the OS name service (hostname lookup - 
it will mediate to the /etc/hosts file, DNS, NIS or whatever other name 
services may be set up). The latter is his connection attempt to his 
service.

So this difference is expected and on the surface it looks correct.

Cheers,
Cameron Simpson <cs at cskk.id.au>