Sign in with
Sign up | Sign in
Your question

Server broadcasting to a 169.X address

Last response: in Windows 2000/NT
Share
Anonymous
August 15, 2005 12:55:22 PM

Archived from groups: microsoft.public.win2000.advanced_server (More info?)

I have this strange problem I've been trying to track down. I'm not
entirely sure this is where this should go, but I'm not aware of any
other forum to post this in.

I implemented a new firewall unit the other week. Lately, I've been
paying more attention to the logs. In the Intrusion Detection System
log, I keep seeing this message:
Date: 08/15 08:50:45 Name: ICMP Destination Unreachable (Communication
Administratively Prohibited)
Priority: 3 Type: Misc activity
IP info: 192.168.0.5:123 -> 169.254.122.72:123
References: none found

In the Firewall log:
08:52:31 eth0 eth1 ICMP
192.168.0.5:137----> 169.254.122.72:137
-------

For some reason or the other, the 192. address is sending netbios
requests to the 169 address. I can't figure out why. I made sure that
there were no errant/bad records in DNS, disabled netbios on that NIC,
even deleted the 2nd nic from the server since it's not running
Multihomed anymore. Still, there firewall log shows that even every 2-3
seconds, and the intrusion log shows the 1st error every so often.

There were no records of this over the weekend, and they started back up
this morning around 0815, which is when most employees get on the network.

Suggestions/advice?

thanks
Anonymous
August 29, 2005 7:28:16 PM

Archived from groups: microsoft.public.win2000.advanced_server (More info?)

the domain is creating a [00h]Workgroup and [1Eh]Normal Group Name
record for itself in WINS. The problem I have, is that those records are
being created with a 169.254.122.x IP, and filling the logs with entries
when the 192.168.0.X server tries to send netbios requests to that address.

no ideas?

Nathan Thomas Sr wrote:
> I have this strange problem I've been trying to track down. I'm not
> entirely sure this is where this should go, but I'm not aware of any
> other forum to post this in.
>
> I implemented a new firewall unit the other week. Lately, I've been
> paying more attention to the logs. In the Intrusion Detection System
> log, I keep seeing this message:
> Date: 08/15 08:50:45 Name: ICMP Destination Unreachable (Communication
> Administratively Prohibited)
> Priority: 3 Type: Misc activity
> IP info: 192.168.0.5:123 -> 169.254.122.72:123
> References: none found
>
> In the Firewall log:
> 08:52:31 eth0 eth1 ICMP
> 192.168.0.5:137----> 169.254.122.72:137
> -------
>
> For some reason or the other, the 192. address is sending netbios
> requests to the 169 address. I can't figure out why. I made sure that
> there were no errant/bad records in DNS, disabled netbios on that NIC,
> even deleted the 2nd nic from the server since it's not running
> Multihomed anymore. Still, there firewall log shows that even every 2-3
> seconds, and the intrusion log shows the 1st error every so often.
>
> There were no records of this over the weekend, and they started back up
> this morning around 0815, which is when most employees get on the network.
>
> Suggestions/advice?
>
> thanks
>
>
Anonymous
August 30, 2005 3:32:02 PM

Archived from groups: microsoft.public.win2000.advanced_server (More info?)

"Nathan Thomas Sr" <nathan_nospam_@mvp97.com> wrote in message
news:o riQX8MrFHA.2212@TK2MSFTNGP15.phx.gbl...
> the domain is creating a [00h]Workgroup and [1Eh]Normal Group Name
> record for itself in WINS. The problem I have, is that those records are
> being created with a 169.254.122.x IP, and filling the logs with entries
> when the 192.168.0.X server tries to send netbios requests to that
> address.
>
> no ideas?
>
> Nathan Thomas Sr wrote:

No, no ideas - but - 169.254.122.x looks like the type of ip address that a
pc generates for itself when it fails to get an ip address from the dhcp
server. Does the server have more than one network card?

Unlikely to be related, but when I googled on 169.254 I came across the
following article:
http://securityresponse.symantec.com/avcenter/venc/data...

I hope you get to the bottom of it,

Brian.

www.cryer.co.uk/brian
Related resources
Anonymous
August 30, 2005 4:46:26 PM

Archived from groups: microsoft.public.win2000.advanced_server (More info?)

Server does have a 2nd nic, but it is disabled. I'm going to pull it out
at the end of the month during scheduled downtime/maintenance and see
what happens.

The box is fully patched, and has current AV dats, and nothing has shown
during network scans, or AV+heuristics scan.

Strange, boggling, and annoying.

Brian Cryer wrote:
> "Nathan Thomas Sr" <nathan_nospam_@mvp97.com> wrote in message
> news:o riQX8MrFHA.2212@TK2MSFTNGP15.phx.gbl...
>
>>the domain is creating a [00h]Workgroup and [1Eh]Normal Group Name
>>record for itself in WINS. The problem I have, is that those records are
>>being created with a 169.254.122.x IP, and filling the logs with entries
>>when the 192.168.0.X server tries to send netbios requests to that
>>address.
>>
>>no ideas?
>>
>>Nathan Thomas Sr wrote:
>
>
> No, no ideas - but - 169.254.122.x looks like the type of ip address that a
> pc generates for itself when it fails to get an ip address from the dhcp
> server. Does the server have more than one network card?
>
> Unlikely to be related, but when I googled on 169.254 I came across the
> following article:
> http://securityresponse.symantec.com/avcenter/venc/data...
>
> I hope you get to the bottom of it,
>
> Brian.
>
> www.cryer.co.uk/brian
>
>
>
March 7, 2011 8:16:14 PM

The answer is really simple - once you figure it out. I had this problem TWICE in one week in two different locations recently. The first one cost me a full day of head-scratching.

That oddball address, which is usually a '169.254 .x.x' 255.255.0.0 address, can appear when there is an electrical connectivity problem between the PC (or other device) and the DHCP server or whatever device the PC is immediately connected to (switch, hub, etc).

The cause can be either a defective NIC, switch/hub port, patch cord or nothing more than a flakey connection for the patch cord. My solution in both cases was to simply refresh the patch cord connection on both ends (several times).

I had numerous devices connected through the switches and none of the other devices had issues, so that narrowed the problem down to the connection between the PC and the switch port.

God, I love this stuff!

Skyhawk
March 7, 2011 8:28:19 PM

Meant to say "was to simply refresh the patch cord connection on both ends (several times just to be sure I had a good physical/electrical connection)."

!