Re: Sunfire V100 reports "dc0: failed to force tx and rx to idle state"?

I'd mentioned dc0 problems quite a while back, and they're still an issue.

Just did a fresh install of 4.0 from the release CD on a Sunfire V100,and as soon as I did "ifconfig dc1 up", I got this message:

dc0: failed to force tx and rx to idle state

This time I hadn't even gotten around to setting up the network orforcing the speed and duplex, so it's not what I'd previously suspected...

I would still like to know what causes this, and whether it's something to worry about.

dc0: failed to force tx and rx to idle state

Sunfire V100 running OpenBSD 3.7 Sparc64 freshly installed offvia the official CD, is reporting "dc0: failed to force tx and rx toidle state".

Is this just cosmetic, or an actual problem?

Looking at the source code for the dc drive, this seems to be related tosetting speed and duplex (I lock the interfaces to 100/full).

I have an identical machine running 3.6, does not show this message,only the machines upgraded to 3.7 give this warning.

Strange hardware errors? Consider a PROM Firmware upgrade

Every so often we run into a machine, physically identical to other boxes successfully converted, that fails in weird ways -- network and drive controllers not found, sporadic failure to recognize drives, etc.

Sometimes the problem turns out to be an actual hardware problem,
other times the root cause is the firmware version, either OBP
(OpenBoot PROM) or (less commonly) POST. The Sparc64 project page
hints at such issues, but does not go into details.

Sun provides a "Standalone PROM Update Utility" on CDROM, as well as
documentation on upgrading firmware:
http://sunsolve.sun.com/data/802/802-3233/pdf/802-3233-25.pdf

It is technically possible to update the PROM from a netboot server.
If you don't already have a netboot server, an alternative (suggested by Mike Scher) for systems without a CDROM drive is to keep a bootable SCA drive, containing a 32-bit Solaris and the latest prom update utility in the root partition.

OpenBSD Sparc64 on Sunfire V120

OpenBSD works amazingly well on "our" new SunFire V100 hardware.

With my pre-existing netboot buildout, doing a network installation on the SunFire was quick and easy -- faster than the Solaris network installation, if not quite as self-completing as my "fire and forget" firewall build boot :)

There are a number of security enhancements inherent in OpenBSD by which we can justify this admittedly unusual choice of operating system for DNS and other specialized applications where security is more important than "normalization"

Kevin


(P.S. FreeBSD 5.0 for Sparc64 supports most of the same modern Solaris systems as OpenBSD (Oddly, no Ultra-2 SCSI support, but FreeBSD does work on E220/E250) and offers SMP support for systems that have multiple CPUs)

Solaris login exploit seen in the wild

A little birdie just told me that the Solaris/Sparc exploit for the buffer overflow in /bin/login is 'in the wild'. I have also received a binary executable of the exploit.

Available now to 'black hats' is a remote exploit overflowing the TTYPROMPT variable. A local exploit should also be expected, allowing anybody who can execute code on an unpatched solaris host to become superuser.

Any internet-accessible Solaris host with port 23 open that has not already been patched should be assumed to have been compromised. Internal hosts are also at risk if not patched.

All of the outsourced hosts with which I am familiar (the ones we audited back in '99) either block telnet entirely, or reject telnet login attempts from arbitrary internet addresses via 'tcp wrappers'. This 'protection' is not an excuse not to apply the Sun patch.