Thank you for your reply. So you mean it is independent of my centos

server ip address range or it just shows the ip addresses in the range of my centos self ip address? (as I don't have a priori information about that remote node unknown ip address)

As much as I'm reluctant to respond given past history on this mailing list I'll give the benefit of the doubt ...

Firstly the only way you are going to see this (assuming a switched network which seems sane these days) is if that node is eliciting information form other systems - depending on what it is doing this may or may not be true... but if not true you'll never see it ...

Now I know english is not your native language but it's important we agree on some terms else we'll be talking past each other with nothing to gain... as such for the purposes of this I'm going to assume you mean 'independent of my centos server ip range' to mean in a different subnet (ie 192.168.1.0/24 when your system is in 192.168.0.0/24) but connected to the same physical network local broadcast area...

In order to look for this traffic with tcpdump it'll be best to filter out your local network to reduce the noise:

tcpdump not net 192.168.0.0/24

This assumes that your server is in that network ... amend appropriately for your situation...

Now if that system is attempting any sort of communication itself you are likely to see ARP requests like:

10:14:13.976075 ARP, Request who-has 192.168.1.254 tell 192.168.1.10, length 42

Reading the above you can see the gateway for that network (192.168.1.254) being requested by the host 192.168.1.10 ... and if this was the case we'd have found our mystery host ...

Now if you need to give the host a 'push' into communicating (in case it's otherwise quiet) you can try doing a ping of the broadcast address 255.255.255.255 which *depending on the configuration* it might respond to (most systems default to responding) ... since the system is on a different subnet though it's likely it won't respond directly to you but it may try and talk to the gateway to route to you and then hopefully you might get an ARP request as above ...

It is possible the host doesn't actually have a gateway configured at all though in which case it won't respond to IP packets outside of its local subnet and obviously won't be ARPing for a gateway ...

In that case your best bet is to carry out the tcpdump still and parse it for any unexpected IP addresses....

If your network is small enough and you have a managed switch you could also make a list of known MAC addresses via a broadcast ping and then look at the switch tables to see what MAC addresses have been learned ... find whichever MAC address (assuming that the device has made any attempt to contact something at all on the network...) is in there that's not on your list and see which port it's assigned to and cable trace .... That won't get you an IP directly as per your OP but you could then check the system...

Is this an academic question or do you have specific issue you're trying to solve?

Running 'arp -n' on a machine that you think might receive packets from the unknown host might also do the job.

K

Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 19

On Tue, May 28, 2013 at 6:38 PM, Kahlil Hodgson < kahlil.hodgson@dealmax.com.au> wrote:

Also the arpwatch program might help if you are trying to track down mysterious devices popping up on your network.

+1 for arpwatch

You beat me to mentioning it. ;)

K

Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 1925

On Wed, May 29, 2013 at 8:14 AM, Kahlil Hodgson < kahlil.hodgson@dealmax.com.au> wrote:

...

Running 'arp -n' on a machine that you think might receive packets from the unknown host might also do the job.

K

Kahlil (Kal) Hodgson GPG: C9A02289 Head of Technology (m) +61 (0) 4 2573 0382 DealMax Pty Ltd (w) +61 (0) 3 9008 5281

Suite 1415 401 Docklands Drive Docklands VIC 3008 Australia

"All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer." -- IBM maintenance manual, 19

---

CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

...

...

Also the arpwatch program might help if you are trying to track down mysterious devices popping up on your network.

+1 for arpwatch

You beat me to mentioning it. ;)

Arpwatch is nice and in the syslog the unusual system would be called out as a bogon assuming a different network scope... If it didn't have regular attempted communication though you'll still need a way of 'enticing' it into doing so... And until it's understood what arpwatch is doing (or for targeted as opposed to automated alerts) still think that manual investigation with tcpdump and wireshark would be more beneficial...

Perhaps a stupid idea: I didn't see where the OP indicated they did not know which physical machine this is, but I understood it to be unknown on the network.

So, if I"m right, just go to the machine and do ifconfig or similar.

I think the safe assumption is this would not be possible or at the least was not the point of the OP given that he was looking for a tool on a CentOS server to do this...