Linux-Development-Sys Digest #535, Volume #6 Fri, 26 Mar 99 16:14:10 EST
Contents:
Security issues (Michael Schuerig)
Re: RS485 Linux: Must toggle DTR quickly (Gerard van der Sel)
generic SCSI for ATAPI devices (SUMIT)
Problem adding a hook into kernel (Andy Vogel)
Re: RS485 Linux: Must toggle DTR quickly (Tony Williams)
Re: Using Linux TCP/IP source for an embedded uP? (John Sheehy)
Re: Devloping Linux apps on NT? (Lewis Perin)
Re: Building Linux ([EMAIL PROTECTED])
Re: Devloping Linux apps on NT? ("Seyed Razavi")
Re: Devloping Linux apps on NT? ("Seyed Razavi")
Re: How about /dev/web? (Bill Anderson)
Re: RS485 Linux: Must toggle DTR quickly (Ralph Goff)
Re: RS485 Linux: Must toggle DTR quickly ("Tewpin Andrey (ôÀÐÉÎ áÎÄÒÅÊ)")
Re: RS485 Linux: Must toggle DTR quickly ("Rufus V. Smith")
Re: How about /dev/web? (Nix)
Re: RS485 Linux: Must toggle DTR quickly (Stephen Tell)
sleep_on (Wlmet)
adding a user (Aaron Faby)
Re: no setuid for scripts (Frank Sweetser)
Re: Devloping Linux apps on NT? (steve mcadams)
From: [EMAIL PROTECTED] (Michael Schuerig)
Subject: Security issues
Date: Fri, 26 Mar 1999 17:18:23 +0100
Most of the stuff on security I've seen is concerned with administrative
issues, that I'm not particularly intersted in. Rather, I'd like to get
an idea of the programming side of things: What do I have to do to
ensure my programs aren't easily exploitable? Any pointers, where I can
get started?
Thanks,
Michael
--
Michael Schuerig
mailto:[EMAIL PROTECTED]
http://www.schuerig.de/michael/
--
From: Gerard van der Sel [EMAIL PROTECTED]
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 Linux: Must toggle DTR quickly
Date: Fri, 26 Mar 1999 15:55:29 +0100
Reply-To: [EMAIL PROTECTED]
Olav Woelfelschneider wrote:
Keywords: RS485-Network, Linux
I try to run a small RS485 network off the serial port of a PC. The PC polls
some gadgets with microcontrollers in them.
The PC is coupled via a RS232-RS485 converter which uses DTR to
switch between transmit and receive. (I use the half-duplex approach with
only one pair of wires.)
Well there is a software solution. Since you are using halduplex
protocol I persume that transmit is coupled with receive through the
rs485. When you get an receive interrupt from the last character you can
savely turn the transmitter of :-).
So no extra hardware is necessary
--
Met vriendelijke groet,
Gerard van der Sel
Mailto:[EMAIL PROTECTED]
"De dinosaurussen hadden hun komeet, wij hebben de Windows computer" -
me
"The box said: 'install on Windows 95, NT 4.0 or better'.
So I installed it on Linux."
--
From: SUMIT [EMAIL PROTECTED]
Subject: generic SCSI for ATAPI devices
Date: Fri, 26 Mar 1999 08:23:47 -0800
Hi
I am running 2.0.36, trying to play around with a CD-RW drive on
the 2nd IDE-channel. I have enabled ide-scsi emulation and booting
through LILO with the following parameter.
hdd=ide-scsi
The problem is that when I read the results back, sg_header.result
is not getting set. i.e. If a command results in Check condition,
sg_header.result should say 2. But it is still 0 though I can
see SENSE information in the sense buffer !
Any ideas ?
Thanks in advance.
Sumit
--
From: Andy Vogel [EMAIL PROTECTED]
Subject: Problem adding a hook into kernel
Date: Fri, 26 Mar 1999 16:53:59 GMT
Hiya,
I've added a hook into the IP source code (2.0.36) - following some
example code from other kernel mods. I defined my function hook it
netsyms.c and everything, but the problem is when I compile and boot the
kernel my new hook/variable isn't there!
When I do a "make vmlinux" the System.map that's created has my hook
listed, but a "ksyms -a" doesn't list it, and as a result my module code
can't see it.
Am I missing something simple?
Thanks
Andy
--
From: Tony Williams [EMAIL PROTECTED]
Crossposted-To: comp.arch.embedded
Subject: Re: RS485 Linux: Must toggle DTR quickly
Date: Fri, 26 Mar 1999 14:59:22 + (GMT)
In article [EMAIL PROTECTED],
Peter [EMAIL PROTECTED] wrote:
They do give the "all sent" info but only as a status bit - you cannot
program an interrupt from it.
The main problem here is hardware: none of the 16450, 16550 and
other UART give the information "char completely sent", they just
give the information "Tx serialisator empty"...
I had a very similar problem in "2-wire" RS-485
comms, where each Tx/Rx only gets switched into
Tx when required, and *must* drop back into an
Rx'er asap. 5-byte packets into an 8-byte fifo.
With a receiver hanging on the line you simply
receive your own outgoing bytes, and as soon as
the last byte ends, smack it back into Rx, an