Dulpicate IP not logging

[Matthew Couper]

Ran into a problem yesterday when a duplicate IP was set on a workstation as a production machine.
It was quickly found and fixed (I carelessly did the IP change) but there was nothing logged in the syslog to suggest there was a dulpicate IP on the network.

the only hint of an error was

Aug 11 17:00:57 janus syslog: libtt[17622]: ttdt_Xt_input_handler(): tttk_messag
e_receive(): TT_ERR_NOMP^INo ttsession process is running, probably because tt_o
pen() has not been called yet. If this code is returned from tt_open() it means
ttsession could not be started, which generally means ToolTalk is not installed
on this system.

as this is not a very discriptive message it took me a little bit to realize my mistake.
Now the question is, how do I go about fixing the logging issue, is ToolTalk required? And just what is ToolTalk?

This on an HP-UX 11.0 N-Class Server

[Robert-Jan Goossens]

Hi Steve,

Check this doc.

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000063204412

Document description: libtt: ttdt_Xt_input_handler(): TT_ERR_NOMP errors in syslog
Document id: KBRC00000037

Kind regards,
Robert-Jan.

[Matthew Couper]

OK, that does explain the ToolTalk message (I have a couple CDE sessions I personally use, everyone else telnets) and gives me information of how to manage it. Thanks for that link!

But, it does not help with syslog not logging that there is an IP conflict. Nothing was even displayed on the console

[Patrick Wallek]

I don't think an IP conflict is something that can be logged.

How is the system to know that there is someone else that has the same IP? The system itself can't.

[Jeff Schussele]

Hi Steve,

Just exactly what were you expecting to see in the log or on the console? The only way the system would ever discover the dupe was if it tried to send soemthing to it's own IP - forcing an ARP broadcast & in that case the system would use localhost (127.0.0.1) anyway and nothing would ever be broadcast out.

What would see it immediately would be a switch if it was connected to both and/or the gateway router for that subnet.
About the only thing you *might* be able to find in the logs would be an ARP or AARP message broadcast from the router that would complain about dupe MAC addresses for the IP.

It's really up to devices that maintain ARP tables to alert about dupes. So unless the *other* system somehow broadcast an ARP request for that IP, your system will never know - unless another device alerts it.

My 2 cents,
Jeff

[Matthew Couper]

You would *think* that if another machine on the network was trying to grab the same IP there would be *something* to indicate it as current connections get dropped on the IP level.
Something like a "A network conflict has been detected with MAC address 0x08000935C99D" would show up somewhere on the HP side.

[Jeff Schussele]

Oh & a piece of advice...

If you unsure about whether an IP is in use or not before you assign it, then ping the broadcast address - usually xxx.xxx.xxx.255 - from a host in the subnet & if you *don't* see a reply from an IP, then it's not in use at that time. But NOTE, that does *not* mean it hasn't been assigned to something. It could have & that device is not up at the time.

Rgds,
Jeff

[Jeff Schussele]

Yes - that's the way it works in MicroSlop land, but that's because the M$ TCP/IP stack is half brain-dead. M$ system are fairly stupid i.e. they don't use or care about localhost - 127.0.0.1 & when sending something to themselves they broadcast ARP requests & then when they see a response from something other than themselves they go - WHOA we have a problem Houston. That's all fine & dandy, but it also puts a greater traffic load on the network that really doesn't need to be their. Why broadcast anything if you know the traffic isn't going to leave the host?
But hey, has logic ever been a major factor in Micro$oft decisions?

Cheers,
Jeff

[Matthew Couper]

What I'm looking for apperently gets logged in /var/adm/nettl.LOG00 using
# netfmt -Nvf /var/adm/nettl.LOG000

This is what it looks like there

***********************************STREAMS/UX*******************************@#%
Timestamp : Wed Aug 11 CDT 2004 17:00:48.579117
Process ID : [ICS] Subsystem : STREAMS
User ID ( UID ) : -1 Log Class : ERROR
Device ID : 0 Path ID : 0
Connection ID : 0 Log Instance : 0
Location : 00123
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
168 17:00:48 118186501 1 T.. 5316 11 ...trying to be our address 010.001.001.030!


Is there a way to have a simular error echo into /var/admin/syslog/syslog.log?