Sun-Spots Digest, v6n152
William LeFebvre
Sun-Spots-Request at RICE.EDU
Fri Jul 29 01:45:52 AEST 1988
SUN-SPOTS DIGEST Tuesday, 26 July 1988 Volume 6 : Issue 152
Today's Topics:
Re: getting ethernet address of a physical interface (2)
Re: New 386i comes with root passworded
Re: Ringing the bell
Re: postscript printers under 4.0
Re: Revenge of the 68881
Re: getting ethernet address of a physical interface
Re: "My Mac can do it, why can't the Sun?"
calentool bug
892MB disks shudder during fsck
Problem Connecting a Printer to a Sun
386i dvitool problems
Sun Monitor Extension Cables?
tftpboot programs?
Send contributions to: sun-spots at rice.edu
Send subscription add/delete requests to: sun-spots-request at rice.edu
Bitnet readers can subscribe directly with the CMS command:
TELL LISTSERV AT RICE SUBSCRIBE SUNSPOTS My Full Name
Recent backissues are available via anonymous FTP from "titan.rice.edu".
For volume X, issue Y, "get sun-spots/vXnY". They are also accessible
through the archive server: mail the request "send sun-spots vXnY" to
"archive-server at rice.edu" or mail the word "help" to the same address
for more information.
----------------------------------------------------------------------
Date: Thu, 14 Jul 88 10:35:10 EDT
From: Charlie C. Kim <cck at cunixc.cc.columbia.edu>
Subject: Re: getting ethernet address of a physical interface (1)
Reference: v6n136
The question was how do you get the ethernet address of a physical
interface. The only viable solution is not pretty.
One response suggested searching the /etc/ethers-yp databases with
"ethers" routines. This is a workable, but ugly solution. In particular,
don't really want to deal with putting the ethernet address in
yp-/etc/ethers unless it is absolutely necessary.
One response suggested looking through the arp table (e.g. arp -a);
however, the ethernet address(es) of a system's interfaces are not
generally in it's own arp table.
Another idea, assuming you are using NIT, is to push out a packet and pick
up the ethernet address from the packet (a very very ugly idea).
So, it seems that the only solution that works generally is to scan the
ifnet list to find the proper interface. This should work on most 4.x
based machines. Drew Perkins at CMU sent me the details so I didn't have
to figure them out.
There are two data structures of relevance. In side the "softc" for each
ethernet driver, arpcom (if_ether.h) is defined for the generic ethernet
characteristics. arpcom contains the ethernet hardware address and a
ifnet structure (if.h - important to note that the ifnet structure is
first in arpcom). The ifnet structure, for our purposes, contains the
device name and unit number.
When you "attach" an ethernet interface, the ifnet structure in arpcom is
passed down to the if module and linked into the "ifnet" list. But this
actually results in a list of arpcom structures (for the active
interfaces). Given this, it is trivial to scan the ifnet list to find the
ethernet addresses of particular (ones or groups of) interfaces:
struct ifnet *pif;
for (pif=ifnet; pif != NULL; pif = pif->if_next)
if (wanted_interface(pif->if_name, pif->if_unit) {
struct arpcom *ac = pif; /* yes, coerce */
wanted_etheraddr_is(ac->ac_enaddr);
}
Of course, this assumes you can read the kernel memory space. I was
afraid this was going to be the "best" solution--I much prefer solutions
that go through well defined interfaces like an ioctl as done in Ultrix.
Sun should define an ioctl or equivalent mechanism to allow one to do
this!
To reiterate, while in most cases, one should not be worrying about the
particular ethernet address of a physical interface, there ARE good
reasons for wanting to do so in some very special cases (for instance
network management and dealing with protocols not in the kernel).
Charlie C. Kim
User Services
Columbia University
------------------------------
Date: Thu, 14 Jul 88 10:16:48 EST
From: riedl at purdue.edu
Subject: Re: getting ethernet address of a physical interface (2)
Reference: v6n136
In the LE interface code there is a case to handle a SIOCGIFADDR ioctl. I
haven't tried it, but it appears to copy the address from the interface
into the ioctl data area.
John Riedl
{ucbvax,decvax,hplabs}!purdue!riedl -or- riedl at mordred.Purdue.EDU
------------------------------
Date: 14 Jul 88 15:48:16 GMT
From: dmk at njin.rutgers.edu (David Katinsky)
Subject: Re: New 386i comes with root passworded
Reference: v6n136
The initial root password on the 386i is its `hostid`. This value is
displayed during a "k2" boot or poweron. In order to boot single user with
the partitions writeable you have to boot with some special flags. I
think these are -bsw. Lastly, if you boot up into single-user, read-only
mode, the command `mount -o remount /` probably would do the right thing
to make / writeable.
dmk
David M. Katinsky
dmk at njin.rutgers.edu {wherever}!rutgers!dmk
------------------------------
Date: 14 Jul 88 10:07:14 GMT
From: Ian Phillipps <mcvax!camcon!igp at uunet.uu.net>
Subject: Re: Ringing the bell
Reference: v6n131
Don Dwiggins {scgvaxd,crash}!ashtate!dwiggins:
> routines for ringing the console bell; they work even if the "visual bell"
> is turned on, so you can get "beeped" even if you're not watching the
> screen.
Only one snag - if you're "rlogin" to another machine, it beeps on the
remote machine's console. Not always audible!
UUCP: ...!ukc!camcon!igp | Cambridge Consultants Ltd | Ian Phillipps
or: igp at camcon.uucp | Science Park, Milton Road |
Phone: +44 223 358855 | Cambridge CB4 4DW, England |
------------------------------
Date: Wed, 13 Jul 88 14:32:12 BST
From: Paul Hudson <mcvax!moncam!paul at uunet.uu.net>
Subject: Re: postscript printers under 4.0
Don't you believe a word of it. As far as I can see the PostScript support
for troff in 4.0 consists *only* of postscript compatible width tables!
(see the man page for troff. This is not what was implied by the
pre-release blurb).
However, hacking C/A/T output to postscript can't be that hard .... :-)
(A quick hack would be quite easy. Is there one around? If not, I might be
persuaded to hack one up).
We have a Postscript troff anyway, so this isnot a problem for us.
Paul Hudson
Snail mail: Monotype ADG Email: ...!ukc!acorn!moncam!paul
Science Park, paul at moncam.co.uk
Milton Road,
Cambridge,
CB4 4FQ
------------------------------
Date: Thu, 14 Jul 88 15:41:45 EDT
From: bernhold at qtp.ufl.edu
Subject: Re: Revenge of the 68881
Valdis Kletnieks mentioned that in an effort to get X11R2 running and
using his new 68881's, he recompiled using the -fswitch option.
My own experience with floating point intensive quantum chemistry codes
running on a 3/280 with FPA is that the -fswitch compiled code runs about
half to a third as fast as the -ffpa compiled code. -fswitch seems to be
actually only marginally faster than a -f68881 compiled code! And if I
remember some quickie benchmarks I did about a year ago, using -fswitch on
an 3/50 with a 68881 is pretty much between the -f68881 code and the
-fsoft code.
Has anyone else seen this behavior? More importantly, can anyone explain
it? This seems like a terribly large amount of overhead to me.
Dave Bernholdt bernhold at qtp.ufl.edu
Quantum Theory Project bernhold at ufpine.bitnet
------------------------------
Date: Thu, 14 Jul 88 17:00:37 EDT
From: Charlie C. Kim <cck at cunixc.cc.columbia.edu>
Subject: Re: getting ethernet address of a physical interface
Well, I should have waited a couple of hours before posting the responses,
it turns out there is a way to do this cleanly. It is somewhat documented
in if(4n) and nit_if(4) for sun os 4.0, but you have to sorta know what is
going on to figure it out.
----------
> From: cs%kanawha at sun.com
Short answer: this is fixed in SunOS 4.1 (ifconfig will tell you). As to
how to do it in 4.0, it goes something like this:
open /dev/nit
do an NIOCBIND ioctl on the interface
do an SIOCGIFADDR ioctl to fetch the Ethernet address (a struct
ether_addr is returned in sa_data[])
In SunOS 3.x, it's considerably simpler: just do an SIOCGIFADDR ioctl on
an AF_UNSPEC socket.
Carl
---- END OF FORWARDED MESSAGE ---
Caveat: ifr_data contains a struct sockaddr (at least under SunOS 4.0)
The following code fragment assumes "s" holds a file descriptor opened
on /dev/nit and has been bound. (c.f. man pages for nit).
{
struct ifreq ifr;
struct sockaddr *sa;
strcpy(ifr.ifr_name, "il0"); /* device name */
if (ioctl(s, SIOCGIFADDR, &ifr) < 0) {
perror("ioctl: SIOCGIFADDR");
exit(1);
}
sa = (struct sockaddr *)ifr.ifr_data;
/* sa->sa_data is a struct ether_addr - e.g. array of 6 octets */
printf("%x %x %x %x %x %x\n",
sa->sa_data[0] & 0xff, sa->sa_data[1] & 0xff,
sa->sa_data[2] & 0xff, sa->sa_data[3] & 0xff,
sa->sa_data[4] & 0xff, sa->sa_data[5] & 0xff);
}
Charlie C. Kim
User Services
Columbia University
------------------------------
Date: Thu, 14 Jul 88 15:06:57 PDT
From: deborah at sun.com (Deborah Gronke Bennett)
Subject: Re: "My Mac can do it, why can't the Sun?"
I improved showSelection so the shelltool is the correct size for the
selected area. Here is the modified shell script for showSelection:
#!/bin/csh -f -e
# show current text selection in a Suntools vi window
shelltool -Wh `wc -l /tmp/winselection | sed s-/tmp/winselection--` vi /tmp/winselection
Note I'm using the "-" delimiter in the sed rather than the usual "/" character.
-deborah
------------------------------
Date: Thu, 14 Jul 88 17:09:47 -0400
From: Henry B.J. Krempel <krempel at pacrat.npac.syr.edu>
Subject: calentool bug
Has anyone noticed a problem in calentool where appointments disappear
every once in a while. I'm not sure what version I'm running, but it's a
version that includes calenmail, so isn't too old.
Henry B. J. Krempel <krempel at pacrat.npac.syr.edu>
Northeast Parallel Architectures Center (NPAC)
Syracuse University
250 Machinery Hall
Syracuse, N.Y. 13244
------------------------------
Date: Thu, 14 Jul 88 16:55:44 EDT
From: flynn at pixel.cps.msu.edu (Patrick Flynn)
Subject: 892MB disks shudder during fsck
We have a new 4/280 with 2 Hitachi DK815-10 892 MB disks running SunOS
4.0. It's been up for a couple of weeks, and things are running smoothly,
except:
During the fsck phase of the boot process, I noticed that one of the
drives was visibly vibrating (up+down motions of about 1/4" or so). This
vibration was accompanied by the normal sort of whizzing sounds you hear
when the disk is seeking all over the place. I think the fsck was
checking the largest partition on the disk (635 MB) when all this
vibration occurred. There wasn't any noticeable vibration when the
smaller partitions were being checked.
I was rather disturbed at the amplitude of these vibrations. I wouldn't
be worried if the thing was just making the normal sounds, but I didn't
expect to see so much motion.
Am I worrying too much? Are these drives mounted on nice bouncy rubber
things or something? If the drive is shaking loose, what can I do to fix
it? We paid sun to install the 2 drives, so I wasn't involved in the
installation.
Thx in advance.
Pat Flynn, flynn at cpsvax.cps.msu.edu, flynn at cps.msu.edu, FLYNN at MSUEGR.BITNET
Department of Computer Science
Michigan State University
------------------------------
Date: 14 Jul 88 12:34:16 GMT
From: drd!mark at uunet.uu.net (Mark Lawrence)
Subject: Problem Connecting a Printer to a Sun
We just purchased and NEC LC-890 PostScript laserprinter and I've been
busy trying to make it work on my Sun 3/50. We intend to use it for
output from Frame and IDE's StP which both generate ascii postscript
files.
The problem I *think* I'm having is getting the XON/XOFF flow control to
work. Running the RS-232 interface at 9600 or 19200 bps and using
Asente's and McCormack's Usenix paper which comes as a part of the X
distribution as a test document, the first and sometimes the second page
of the document gets printed and the rest seems to get shunted off into
postscript purgatory. I've set flag bit TANDEM and local mode bit LDECCTQ
which tty(4) implies should make software flow control work and I've made
sure the printer is set up to do that.
Running the interface at 1200 bps solves the problem (the whole document
gets printed out).
The other possibilties I've considered are that the cable is bad (not
likely -- if it works, it works) and that the 3/50 just isn't gutsy enuf
to respond to the software flow control in a timely manner. I hooked up
to the 3/50 because it happened to have ports available. With a little
juggling of devices and locations, I could manage to get a serial port on
a 3/260. Anybody think that would really make a difference?
Mark
DRD Corporation | [uunet!apctrc,romed,tulsun]!drd!mark
6111 East Skelly Drive Suite 415 | apctrc!drd!mark at uunet.UU.NET
Tulsa, OK 74135 (918)664-9010 | mlawrence at jarsun1.ZONE1.COM
------------------------------
Date: Thu, 14 Jul 88 13:42:22 edt
From: lorraine at msc2.tn.cornell.edu (Peter Lorraine)
Subject: 386i dvitool problems
We are planning to purchase Sun 386i/250 and have had one on loan from Sun
for evaluation purposes. I've made TeX from the web2c distribution and
have it aliased to virtex on plain.fmt. The compatability problems arise
with dvitool. The pk fonts in the distribution I have (which works fine
on a 3/60) are garbled horribly on the 386i. At certain magnifications
they come out backwards! I believe this is due to certain byte reversal
problems between the 386i and 680x0 series machines. Has anyone worked
past this problem or fixed the appropriate file to get a working dvitool?
Our overall impression of the 386i has been positive but with several
caveats. The floating point speed on a linpack-type benchmark has
been ~.256 MFlops for double-precision. The integer benchmarks under
fortran with and without optimization come out slower than on a 3/50!
This, I have been told by Sun, is the compiler's fault and that a similar
c benchmark would show the 386 to be a 5 mip machine. The beta version of
the OS does screen updates and scrolling very slowly and the beta f77 has
problems reading files. Hopefully these are fixed in the first customer
shipped versions ( I have been assured they are).
Thanks,
Peter Lorraine
(lorraine at msc2.tn.cornell.edu)
[[ I would have thought that the PK format specified the byte ordering.
In fact, I'm almost positive it does. --wnl ]]
------------------------------
Date: Thu, 14 Jul 88 16:07:54 EDT
From: Daniel R. Ehrlich <ehrlich at blitz.cs.psu.edu>
Subject: Sun Monitor Extension Cables?
Does anyone know if there is a way to extend the B&W (or color for that
matter) video/keyboard cables on a Sun? I have already talked with
Artecon, but there box is only good for 25 feet. I need something in the
100 foot range. Any hints or pointers would be appreciated. Please reply
to me via e-mail and I will summarize back to SUN-SPOTS. Thanks.
--Dan Ehrlich
------------------------------
Date: Thu, 14 Jul 88 17:07:15 CDT
From: jonwest at rosevax.rosemount.com
Subject: tftpboot programs?
Would someone either point me to some documentation or enlighten me on
what exactly /tftpboot/ndboot.* are? What exactly do they do (I know
roughly what they do but I want some specifics), how do you create a
custom boot program, etc ...
Please reply via e-mail. Thanks.
Jon Westbrock
Rosemount Inc.
jonwest at rosevax.Rosemount.COM
------------------------------
End of SUN-Spots Digest
***********************
More information about the Comp.sys.sun
mailing list