Hi. On Fri, 13 Oct 2000, Gerhard Sittig wrote: [snip]

This is some braindead MS system with a failed DHCP attempt or some other "auto config" (i.e. not knowingly configured) network stuff.

Called APIPA

Somebody at MS had the bright idea to say "if we don't have / don't get an address, we simply dice us one." That's when they use the IPs you can see above. Watch the "wide" netmask and the broadcast for "the other unconfigured machines"! Seems MS wants to cope with ignorant environments and even run when not setup correctly ...

Better would be to power the system automatically down?

Sadly I couldn't find any reference to where those IPs come from. RFC1918 addresses are explicitely reserved at the registrars. Those MS fallbacks seem not to be. Do they collide in some future time with some other "customer"? Or are they registered and reserved and I'm just too blind to see? And - most important to solve the problem - is there a chance to teach those WinDoze machines the expected behaviour of "when you don't get an address, you don't have one"? I'm sick of seeing those things happen and realizing it's quite difficult to tell which machine has the problem (to go there and fix it) -- since the IP is so strange and out of the local subnet there won't be ARP entries pointing to the MAC of the NIC involved. One has to wait for the Doze user to call and whine "my computer can't see the net" (unless they're used to it and don't complain but boot again, instead).

You can find those adresses on whois: whois -h whois.arin.net "169.254.0.0" Netname: LINKLOCAL Netblock: 169.254.0.0 - 169.254.255.255 They are specifically reserved for that purpose, but I couldn't find a RFC on it. But here is a list from my router with relevant denied routes: # localhost deny ip 127.0.0.0 0.255.255.255 any # rfc 1918 deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any # reserved blocks deny ip 0.0.0.0 0.255.255.255 any deny ip 1.0.0.0 0.255.255.255 any deny ip 2.0.0.0 0.255.255.255 any deny ip 5.0.0.0 0.255.255.255 any deny ip 7.0.0.0 0.255.255.255 any deny ip 23.0.0.0 0.255.255.255 any deny ip 27.0.0.0 0.255.255.255 any deny ip 31.0.0.0 0.255.255.255 any deny ip 36.0.0.0 1.255.255.255 any deny ip 39.0.0.0 0.255.255.255 any deny ip 41.0.0.0 0.255.255.255 any deny ip 42.0.0.0 0.255.255.255 any deny ip 49.0.0.0 0.255.255.255 any deny ip 50.0.0.0 0.255.255.255 any deny ip 58.0.0.0 1.255.255.255 any deny ip 60.0.0.0 0.255.255.255 any deny ip 67.0.0.0 0.255.255.255 any deny ip 68.0.0.0 3.255.255.255 any deny ip 72.0.0.0 7.255.255.255 any deny ip 80.0.0.0 15.255.255.255 any deny ip 96.0.0.0 15.255.255.255 any deny ip 112.0.0.0 8.255.255.255 any deny ip 120.0.0.0 3.255.255.255 any deny ip 124.0.0.0 1.255.255.255 any deny ip 126.0.0.0 0.255.255.255 any deny ip 197.0.0.0 0.255.255.255 any deny ip 218.0.0.0 1.255.255.255 any deny ip 220.0.0.0 3.255.255.255 any # former class E deny ip 240.0.0.0 15.255.255.255 any # microsoft APIPA deny ip 169.254.0.0 0.0.255.255 any greetings olli -- -------------------------------------- Oliver Hensel http://www.ohensel.de/ Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

On Sat, 14 Oct 2000, Gerhard Sittig wrote:

On Sat, Oct 14, 2000 at 15:01 +0200, Oliver Hensel wrote:

...

Hi.

On Fri, 13 Oct 2000, Gerhard Sittig wrote: [snip]

...

Somebody at MS had the bright idea to say "if we don't have / don't get an address, we simply dice us one." That's when they use the IPs you can see above. Watch the "wide" netmask and the broadcast for "the other unconfigured machines"! Seems MS wants to cope with ignorant environments and even run when not setup correctly ...

Better would be to power the system automatically down?

No, just to not scream out into the net "who else doesn't have a valid config?". It's just that simple: If you don't get one, you don't have one. And without an IP you just dont take part in networking conversations.

Yes, true. But it's meant specifically for those small offices with up to 10 hosts who don't have a network admin. Since MS is "upgrading" NetBEUI to TCP/IP (which is good, IMHO), every host needs an IP. But the customer shouldn't have to know or even think about IPs. I don't subscribe to the World According To Microsoft (TM)(R)(C), but I can think of situations where this can be useful. Greetings olli -- -------------------------------------- Oliver Hensel http://www.ohensel.de/ Training + Consulting Unix - Linux - Firewalls - Security --------------------------------------

Hi *! * Gerhard Sittig wrote on Sat, Oct 14, 2000 at 15:37 +0200:

On Sat, Oct 14, 2000 at 15:01 +0200, Oliver Hensel wrote:

...

But here is a list from my router with relevant denied routes:

[ ... snipped ... ]

This list is of quite an enourmous length. And I already thought my 4 entry list (3x RFC1918 plus multicast) was sufficient ...

Anyone out there with a reference as to where they all come from and what they are made for?

I have some text posted to some mailinglist; sorry, I don't know who the author was. The idea was to block all defnitly not assigned nets, which needs maintainance of course. This list is exactly the same as posted in this thread (so it may be the same author :)), but I saved this links: http://www.isi.edu/in-notes/iana/assignments/ipv4-address-space http://www.cert.org/tech_tips/whois_by_ipaddr.html maybe it helps.

Anyone with a clue about what's the difference between "private addresses for isolated test environments" and "linklocal addresses for those who don't want to or cannot setup something"? I'm interested.

Well, just a guess. M$ went to ARIN (or whatever) and requested a net called LINKLOCAL just if it were supposed for "ordinary" networking but isn't assigned somewhere. This seems to be not that old, the whois told: Record last updated on 30-Aug-2000 oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

Hi friends all: Tried to find some $MS info on the issue, and guess what? I found it. There is all of it at the place. Not bad those $MS documenting, when they like to. Desire that we got it easier here at Linux. Exciting as it is. Guess that IANA has got some info on the ip range 169.254.x.x also, because is their responsability. ____________________ You need the Win98 CD and will find it at: \Tools\Reskit\Help\Rk98book.chm (HTML Help format) Chapter 15: Network Adapters and Protocols / Microsoft TCP/IP Protocol ** Win95 with winsock2 reacts the same. ** Suppose ME will do as well. Here it goes as is at [Windows 98 Resource Kit Book Online / Microsoft TCP/IP Protocol] just copy pasted related info block. With some highlighted HOW TO's at the end, from the $MS point of view. ____________________ **Configuring IP Addresses Using Automatic Private IP Addressing With Windows 98, Microsoft TCP/IP provides a new mechanism for automatic IP address assignment for simple LAN-based network configurations, called automatic private IP addressing. With automatic private IP addressing, DHCP clients can automatically assign themselves an IP address if a DHCP server is not present. This might happen, for example, on very small networks without a DHCP server, or on any size network if a DHCP server is temporarily down. The DHCP client can use B-node NetBIOS naming to assign the adapter a unique IP address from a special address space. These IP addresses must lie in the following range: 169.254.x.x These addresses are used only for private, internal addressing and are not valid for hosts that are visible on the global Internet. After the adapter has been assigned an IP address, the computer can use the TCP/IP protocol to communicate with any other computer that is connected to the same LAN hub and that also uses automatic private IP addressing. However, the computer cannot communicate with computers on other subnets, or with computers that do not use automatic private IP addressing. A Windows 98 computer that is configured for automatic private IP addressing can assign itself a private IP address if either of the following circumstances applies: A computer that is not configured as a laptop can assign itself a private IP address at boot time if the computer does not have a valid DHCP lease, and no DHCP server is found on the network. If the computer is configured as a laptop, the computer can assign itself a private IP address if no DHCP server is found on the network, regardless of whether it has a DHCP lease. This is useful, for example, for a computer that is sometimes located on a network with a DHCP server, and sometimes located on a network without a DHCP server. In either case, if a DHCP server is later found, the computer stops using the private IP address and instead uses the IP address assigned by the DHCP service. Automatic private IP addressing is automatically enabled. You might want to disable it in the following cases: * Your network uses routers. * Your network is connected to the Internet without a NAT or proxy server. Unless you have turned DHCP messages off, DHCP messages inform you when you change between DHCP addressing and automatic private IP addressing. If you do accidentally turn DHCP messages off, you can turn them back on by changing the value of the registry entry PopupFlag from 00 to 01 in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP You must reboot for the change to take effect. You can also determine whether your computer is using automatic private IP addressing by using winipcfg, as the following procedure explains. To determine whether automatic private IP addressing is currently enabled Click Start, click Run, type winipcfg, and then click More info. The resulting screen identifies your IP address and other information. Look at the box immediately beneath your adapter address. If the name of the box is “IP Autoconfiguration Address” and the IP address lies in the 169.254.x.x range, automatic private IP addressing is enabled. If, on the other hand, the name of the box is “IP Address,” automatic private IP addressing is not currently enabled. You can disable automatic private IP addressing in one of two ways: You can manually configure TCP/IP by following the procedure outlined in the section “Manually Configuring IP Addresses” later in this chapter. However, this method also disables DHCP. You can disable automatic private IP addressing (but not DHCP) by editing the registry. You disable automatic private IP addressing but not DHCP by adding the IPAutoconfigurationEnabled registry entry with a value of DWORD 0x0 in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP Use the Registry Editor to add this entry, then shut down and restart the computer. ____________________ ____________________ As of HOW TO FIND _windozes_ LURKING on the net FOR some IP to use: [Must re/enable DHCP Messages and reboot _windoze_ machines to see pop-ups informing] AS YOU READ ABOVE: Unless you have turned DHCP messages off, DHCP messages inform you when you change between DHCP addressing and automatic private IP addressing. If you do accidentally turn DHCP messages off, you can turn them back on by changing the value of the registry entry PopupFlag from 00 to 01 in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP You must reboot for the change to take effect. ____________________ ____________________ As of HOW TO DISABLE _windozes_ LURKING on the net FOR some IP to use: [(aka) disable Automatic Private IP Addressing] You can disable automatic private IP addressing (but not DHCP) by editing the registry. You disable automatic private IP addressing but not DHCP by adding the IPAutoconfigurationEnabled registry entry with a value of DWORD 0x0 in the following registry location: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VxD\DHCP Use the Registry Editor to add this entry, then shut down and restart the computer. ____________________ ____________________ Hey, be aware that Regedit is sometimes very nasty. ____________________ ____________________ Stefan Suurmeijer wrote:

On Fri, 13 Oct 2000, Gerhard Sittig wrote:

...

On Fri, Oct 13, 2000 at 15:30 +0000, Geordon VanTassle wrote:

...

Oct 12 22:44:05 moat kernel: martian source 8e3ffea9 for fffffea9, dev eth1 Oct 12 22:44:05 moat kernel: ll header: ff ff ff ff ff ff 00 10 a4 aa da e2 08 00 Oct 12 22:44:05 moat kernel: Packet log: input REJECT eth1 PROTO=17 169.254.63.142:137 169.254.255.255:137 L=96 S=0x00 I=11008 F=0x0000 T=128 (#69)

This is some braindead MS system with a failed DHCP attempt or some other "auto config" (i.e. not knowingly configured) network stuff.

Somebody at MS had the bright idea to say "if we don't have / don't get an address, we simply dice us one." That's when they use the IPs you can see above. Watch the "wide" netmask and the broadcast for "the other unconfigured machines"! Seems MS wants to cope with ignorant environments and even run when not setup correctly ...

Sadly I couldn't find any reference to where those IPs come from. RFC1918 addresses are explicitely reserved at the registrars. Those MS fallbacks seem not to be. Do they collide in some future time with some other "customer"? Or are they registered and reserved and I'm just too blind to see?

Hmmm, I saw that failed DHCP attempts resulted in bogus IP addresses, never noticed that it was always the same (range of) ip adresses. Thanks for pointing that out. A whois lookup tells us that 169.254.0.0/16 are IANA addresses reserved for use with "Link Local Networks." I haven't found any more information about the purpose of that range, maybe someone else on this list knows.

As you can read above.

Stefan

-- HTH Best regards, Eduardo Carriles [-- Better a smile than a flame --] (Long time SuSE-Linux [preferred distro] user). [-- Se me nota mucho? -- Notices me much?] [-- Have a lot of fun...]