Resolution on source IP address 169.254.* source addresses

[jeffc () SHORE NET (Jeffrey D. Carter)]

My message a couple of weeks ago about Port 137 scanning activity had a
related oddity in the traces: several of the scans, rather than simply
being a sequence of 3 packets from a single source, appearred to be
interleaved series of packets from 2 sources, one of the a
169.254.* address.

Feb 15 22:16:50 drop in udp 202.72.156.37:137 209.58.151.30:137 (78)
Feb 15 22:16:52 drop in udp 202.72.156.37:137 209.58.151.30:137 (78)
Feb 15 22:16:52 drop in udp 169.254.4.114:137 209.58.151.30:137 (78)
Feb 15 22:16:53 drop in udp 202.72.156.37:137 209.58.151.30:137 (78)
Feb 15 22:16:53 drop in udp 169.254.4.114:137 209.58.151.30:137 (78)

I have confirmed that this is the signature of a 'multi-homed' Windows
machine (in my case, Windows 98SE) issuing a netbios lookup via nbtstat.

The machine creates queries with source addresses for all local IP
addresses, and then (in this case) sends them out the 'appriopriate'
interfaces given the routing rules. Since Windows aggressively binds
protocols to adapters, my notebook is multihomed since it has a
built-in modem (Dialup Adapter) and a Firewire (iLink 1394) adapter.
The Dialup Adapter is not assigned an IP address until activated, but
some oddity in the way things are configured by Windows, a 169.254
address is assigned to the Firewire port. There are probably other
'adapter' types that result in the same behavior (IrDA doesn't seem
to, for example).

Jeff Carter
jeffc () shore net