Has anyone made a patch or done any work on RFC2385 support for Linux? I'm
willing to code the subset of it that I need if there's a general consensus
that my approach is reasonable.
I don't plan to add a table of IPs/ports and have the kernel automatically
invoke authentication for those IPs/ports. This is mostly because I don't
need this functionality, but if it's felt that this is the only way to go,
then I'll reconsider my plans.
I plan to add a socket option. You use it after you bind for inbound TCP
connections and before you connect for outbound. You simply set the key to be
used on the connection in the sockopt call. There would also be an option to
allow/disallow unkeyed connections (should the key be optional or mandatory).
Also, a get socket option would allow you to determine whether the key was
being used or not.
One limitation of this approach is that for inbound connections, you can't
have a different password for multiple hosts that might connect to you.
My interest for this is mostly for Zebra to be able to make secure BGP
connections, so I would also contribute a patch for Zebra to support this
feature on Linux.
Am I wasting my time? Is there interest?
--
David Schwartz
<[email protected]>
There is no reason to not be doing this MD5 garbage in
userspace. Whoever thought to do this in the protocol
itself was smoking something.
And if people want encryption they can use ipsec. And if
ipsec is broken it should be fixed because adding a new
abomination to MD5.
Maybe I'm missing something, but I see no reason this MD5
stuff belongs in the protocol and not in the APP.
> And if people want encryption they can use ipsec. And if
> ipsec is broken it should be fixed because adding a new
> abomination to MD5.
>
> Maybe I'm missing something, but I see no reason this MD5
> stuff belongs in the protocol and not in the APP.
Not only that MD5 shouldn't be the one. The crypto folks prefer SHA and for
good reasons.
> My interest for this is mostly for Zebra to be able to make secure BGP
> connections, so I would also contribute a patch for Zebra to support this
> feature on Linux.
For minimal versions of secure ?
Since this memo was first issued (under a different title), the MD5
algorithm has been found to be vulnerable to collision search attacks
[Dobb], and is considered by some to be insufficiently strong for
this type of application.
You'll also find that with SACK it doesn't fit in the tcp header..
On Fri, 15 Mar 2002 14:53:06 -0800 (PST), David S. Miller wrote:
>There is no reason to not be doing this MD5 garbage in
>userspace. Whoever thought to do this in the protocol
>itself was smoking something.
This same argument would apply to TCP itself, wouldn't it?
>Maybe I'm missing something, but I see no reason this MD5
>stuff belongs in the protocol and not in the APP.
How can a TCP-using application authenticate a RST?
DS
>Not only that MD5 shouldn't be the one. The crypto folks prefer SHA and for
>good reasons.
There is no problem with MD5 that makes it unsuitable for this particular
application. A SHA signature would enlarge each packet, further reducing the
effective MTU. This would increase the cost of what was intended to be a
simple mechanism to solve a specific problem (spoofed SYNs/RSTs).
What it comes down to is simply whether you care whether Linux machines can
interoperate with Cisco's BGP authentication scheme. This feature would be
very useful to me, so I personally do care, even if the scheme is not the
best possible scheme.
DS
From: David Schwartz <[email protected]>
Date: Fri, 15 Mar 2002 15:11:39 -0800
On Fri, 15 Mar 2002 14:53:06 -0800 (PST), David S. Miller wrote:
>There is no reason to not be doing this MD5 garbage in
>userspace. Whoever thought to do this in the protocol
>itself was smoking something.
This same argument would apply to TCP itself, wouldn't it?
Not at all.
>Maybe I'm missing something, but I see no reason this MD5
>stuff belongs in the protocol and not in the APP.
How can a TCP-using application authenticate a RST?
Ignoring valid RST frames is illegal. If this RFC says to drop valid
RST frames just because the MD5 is bad, this RFC breaks TCP.
Franks a lot,
David S. Miller
[email protected]
From: David Schwartz <[email protected]>
Date: Fri, 15 Mar 2002 15:13:59 -0800
There is no problem with MD5 that makes it unsuitable for this
particular application. A SHA signature would enlarge each packet,
further reducing the effective MTU. This would increase the cost of
what was intended to be a simple mechanism to solve a specific
problem (spoofed SYNs/RSTs).
Ignoring valid RST frames breaks TCP.
> From: David Schwartz <[email protected]>
> Date: Fri, 15 Mar 2002 15:13:59 -0800
>
> There is no problem with MD5 that makes it unsuitable for this
> particular application. A SHA signature would enlarge each packet,
> further reducing the effective MTU. This would increase the cost of
> what was intended to be a simple mechanism to solve a specific
> problem (spoofed SYNs/RSTs).
>
> Ignoring valid RST frames breaks TCP.
If they don't have the right MD5 frame they are not valid. The RFC came
about because people discovered RST spoofing cisco backbone routers was
a great way to remove unwanted ISP's. Then people discovered that spoofing
icmp df framesizes down to 68 bytes worked anyway and the whole MD5 thing
went to shit.
Later crypto folks showed that MD5 is not always good enough
Finally if you are patient and extremely irritating you can capture BGP
sessions, predict the next time the other end will initiate that sequence
number and do BGP replay games. Fortunately thats extremely hard.
IPSEC has a lot more going for it, but most cisco's still only support the
MD5 stuff. However if you can get/set IP/TCP options in user space you
could I guess do it that way
Alan
From: Alan Cox <[email protected]>
Date: Fri, 15 Mar 2002 23:40:21 +0000 (GMT)
> Ignoring valid RST frames breaks TCP.
If they don't have the right MD5 frame they are not valid.
If there is an error in the network stack there is no way for
a remote TCP to fix things. Making RST frames more complex
guarentees that more error conditions will not be broken out of.
A RST must, in order to function properly, be as simple and non-error
prone as possible. MD5 signatures are totally against that.
This is why PAWS timestamp, etc. checks are DISABLED for RST frames.
Only the sequence number is verified, but that is it.
IPSEC has a lot more going for it, but most cisco's still only
support the MD5 stuff.
I frankly don't care what Cisco's do or do not do.
I don't care if Cisco made a rotten decision. I'm not going to let
Cisco's mistakes crap up Linux's networking.
Either use IPSEC or fix its' deficiencies.
> A RST must, in order to function properly, be as simple and non-error
> prone as possible. MD5 signatures are totally against that.
Duh wakey wakey Dave
> Either use IPSEC or fix its' deficiencies.
What do you think Ipsec does with an RST frame with an incorrect IP-AH
MD5 signature ? Exactly the same thing.
I'm not saying the RFC is a good idea (tho its a needed patch to use Linux
for backbone routing sanely with most vendors BGP kit). Your argument about
the RST frame is however pure horseshit
Alan
From: Alan Cox <[email protected]>
Date: Fri, 15 Mar 2002 23:59:36 +0000 (GMT)
What do you think Ipsec does with an RST frame with an incorrect
IP-AH MD5 signature ? Exactly the same thing.
IPsec is fundamentally different because it encapsulates all IP
traffic, not just TCP. The packet is killed at IP if it doesn't
pass the signature.
I'm not saying the RFC is a good idea (tho its a needed patch to
use Linux for backbone routing sanely with most vendors BGP
kit). Your argument about the RST frame is however pure horseshit
I totally disagree.
Look, TCP is the last place more complexity needs to exist.
Errors in logic in TCP need to be dealt with by breaking the
connection and spitting a RST out, and it must be done in a
way that is as easy to verify as possible.
IPSEC getting the signature wrong is more akin to getting bitstream
corruptions from your networking card for a certain sequence of bytes.
>I'm not saying the RFC is a good idea (tho its a needed patch to use Linux
>for backbone routing sanely with most vendors BGP kit). Your argument about
>the RST frame is however pure horseshit
>
>Alan
I don't think it's a good idea either, and I'm sorry this turned into an
argument over the merits of RFC2385. I don't like it, and that's one of the
reasons I didn't suggest a thorough implementation. I just want enough to
solve the particular problem that I have, which is that Zebra on Linux can't
interoperate with Cisco BGP implementations using MD5 authentication.
There is some merit to the argument that one shouldn't crap up a network
stack just because someone else did. The question is, is interoperability
worth this small piece of crap. I personally think it is, but I'm prejudiced
since I happen to need it.
I'm trying to decide if I need it badly enough to make it worth the effort
it would take to implement it. One factor that would go into that decision is
whether the patch would have a chance at being accepted into the kernel or
whether at least kernel hooks to allow it to be implemented as a module might
be accepted.
DS
> Errors in logic in TCP need to be dealt with by breaking the
> connection and spitting a RST out, and it must be done in a
> way that is as easy to verify as possible.
The two are no different. Someone at cisco stuffed an IP authentication
header in the TCP frame. Its stupid, but the RST argument is not a real one
> IPSEC getting the signature wrong is more akin to getting bitstream
> corruptions from your networking card for a certain sequence of bytes.
Ditto the TCP bad MD5 sum and a tcp checksum error.
I've actually got a more constructive suggestion for the zebra folks.
Route the BGP crap through a netlink tap device, mangle and unmangle the
tcp frames in luserspace. Saves doing TCP in userspace, saves screwing up
Dave's nice networking stack.
You'll still need to kill SACK support to make it fit
From: David Schwartz <[email protected]>
Date: Fri, 15 Mar 2002 15:53:51 -0800
One factor that would go into that decision is whether the
patch would have a chance at being accepted into the kernel
Hmmm... ignoring whether rfc2385 is stupid or not, don't
we have crypto issues if we put something using MD5 into the tree?
> One factor that would go into that decision is whether the
> patch would have a chance at being accepted into the kernel
>
> Hmmm... ignoring whether rfc2385 is stupid or not, don't
> we have crypto issues if we put something using MD5 into the tree?
MD5 is authentication not encryption. We already use it extensively.
Alan
From: Alan Cox <[email protected]>
Date: Sat, 16 Mar 2002 00:12:48 +0000 (GMT)
I've actually got a more constructive suggestion for the zebra folks.
Route the BGP crap through a netlink tap device, mangle and unmangle the
tcp frames in luserspace. Saves doing TCP in userspace, saves screwing up
Dave's nice networking stack.
You'll still need to kill SACK support to make it fit
Another solution could involve a netfilter module to mangle
the packets.
On Fri, 15 Mar 2002 15:45:27 -0800 (PST), David S. Miller wrote:
>>What do you think Ipsec does with an RST frame with an incorrect
>>IP-AH MD5 signature ? Exactly the same thing.
>IPsec is fundamentally different because it encapsulates all IP
>traffic, not just TCP. The packet is killed at IP if it doesn't
>pass the signature.
You are certainly correct that the IP layer is a better place to implement
authentication checksums.
>>I'm not saying the RFC is a good idea (tho its a needed patch to
>>use Linux for backbone routing sanely with most vendors BGP
>>kit). Your argument about the RST frame is however pure horseshit
>I totally disagree.
>Look, TCP is the last place more complexity needs to exist.
>Errors in logic in TCP need to be dealt with by breaking the
>connection and spitting a RST out, and it must be done in a
>way that is as easy to verify as possible.
I don't follow the logic of this argument. When you receive the initial SYN,
you'll either be able to confirm its checksum or not. Once you can confirm
the checksum, you know that the key is the same on both ends, so there's no
fear that a valid subsequent RST will be rejected.
There is an issue at the connection establishment phase. If you receive a
packet with a bad checksum, what do you do? There is some complexity here,
but the obvious solutions work. If one end can correctly sign a packet, you
know they will correctly accept a packet. Until you have received a packet
whose checksum you have validated, you accept unvalidatable packets.
>IPSEC getting the signature wrong is more akin to getting bitstream
>corruptions from your networking card for a certain sequence of bytes.
It really comes down to the question of what is or isn't a valid RST and
whether TCP option specifications have the 'right' to override other
provisions of the TCP specification.
DS
On Fri, 15 Mar 2002 15:57:48 -0800 (PST), David S. Miller wrote:
>From: Alan Cox <[email protected]>
>Date: Sat, 16 Mar 2002 00:12:48 +0000 (GMT)
>
>I've actually got a more constructive suggestion for the zebra folks.
>Route the BGP crap through a netlink tap device, mangle and unmangle the
>tcp frames in luserspace. Saves doing TCP in userspace, saves screwing up
>Dave's nice networking stack.
>
>You'll still need to kill SACK support to make it fit
>
>Another solution could involve a netfilter module to mangle
>the packets.
The problem is that this is intended to be used on machines that are routing
very high volumes of packets on multiple FEs. So the implementation would
have to be minimal cost for packets it didn't need to intercept. So I'd need
to hook into a kernel module or userspace through a filter.
Does ipchains/iptables support to filter selected packets through userspace
work? If it does, this might be an acceptable solution.
DS
> >Another solution could involve a netfilter module to mangle
> >the packets.
>
> The problem is that this is intended to be used on machines that are routing
> very high volumes of packets on multiple FEs. So the implementation would
Dave's suggestion is netfilter - and netfilter is fast enough I think. You
only need filters on stuff you have already decided is for your IP too.
Hi folks,
I'm playing with an usb-ethernet device and it seems to me
it receive correct frames, but when i pass them to the
upper layer they just disappear. I passed complete junk to
the IP layer expecting it to scream, but surprisingly (to me)
nothing happened.
How am i supposed to get a feedback from the upper layers?
Petko
> upper layer they just disappear. I passed complete junk to
> the IP layer expecting it to scream, but surprisingly (to me)
> nothing happened.
>
> How am i supposed to get a feedback from the upper layers?
Keep an eye on /proc/net/snmp
Alan Cox wrote:
>>How am i supposed to get a feedback from the upper layers?
>
> Keep an eye on /proc/net/snmp
It isn't very readable format.. Any other way or i have to
read the code and see what the messages mean?
Petko
> > Keep an eye on /proc/net/snmp
>
> It isn't very readable format.. Any other way or i have to
> read the code and see what the messages mean?
Read the SNMP specification - its dumped by standard SNMP MIB entry
On Sat, 16 Mar 2002 10:52:10 -0800,
Petko Manolov <[email protected]> wrote:
>Alan Cox wrote:
>>>How am i supposed to get a feedback from the upper layers?
>>
>> Keep an eye on /proc/net/snmp
>
>It isn't very readable format.. Any other way or i have to
>read the code and see what the messages mean?
Quick and dirty script to neatly format /proc/net/snmp. BTW, there is
a mismatch in the ICMP list on 2.4.17, 26 headers and 27 values :(.
cat > /tmp/$$a <<\****
while(<>) {
chop;
(@f) = split;
if (++$line % 2) {
@head = @f;
}
else {
for ($i = 0; $i <= @f; ++$i) {
printf "%-25s%s\n", $head[$i], $f[$i];
}
}
}
****
cat /proc/net/snmp | perl /tmp/$$a
rm /tmp/$$a
On Sun, 17 Mar 2002, Keith Owens wrote:
> On Sat, 16 Mar 2002 10:52:10 -0800,
> Petko Manolov <[email protected]> wrote:
> >Alan Cox wrote:
> >>>How am i supposed to get a feedback from the upper layers?
> >>
> >> Keep an eye on /proc/net/snmp
> >
> >It isn't very readable format.. Any other way or i have to
> >read the code and see what the messages mean?
>
> Quick and dirty script to neatly format /proc/net/snmp. BTW, there is
> a mismatch in the ICMP list on 2.4.17, 26 headers and 27 values :(.
BTW. I dont't know how it looks in 2.4.x but in 2.2.x format
/proc/net/snmp and /proc/net/snmp6 is diffrent. Is it bug or feacture ? :)
kloczek
--
-----------------------------------------------------------
*Ludzie nie maj? problem?w, tylko sobie sami je stwarzaj?*
-----------------------------------------------------------
Tomasz K?oczko, sys adm @zie.pg.gda.pl|*e-mail: [email protected]*
On Fri, Mar 15, 2002 at 10:57:11PM +0000, David S. Miller wrote:
>
> There is no reason to not be doing this MD5 garbage in
> userspace. Whoever thought to do this in the protocol
> itself was smoking something.
I did a lot of this using an iptables module. Iptables lends itself very
well to these kind of things. Toy code at http://ds9a.nl/sps/
> Maybe I'm missing something, but I see no reason this MD5
> stuff belongs in the protocol and not in the APP.
Some of the idea is cool. You can give a host a 'key' and tell your packet
filter to have it pass packets signed with that key. This way you can grant
or disable access on a very low level without depending on IP addresses,
which can be spoofed.
Regards,
bert
--
http://www.PowerDNS.com Versatile DNS Software & Services
http://www.tk the dot in .tk
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
From: Mike Fedyk <[email protected]>
Date: Sun, 17 Mar 2002 21:06:18 -0800
... You'd have to use netfilter to mark the correct packets, then route on
that mark to the dummy interface.
How is that more efficient?
You can bind sockets to specific devices under Linux, this does not
require netfilter.
I got the following from a 2.5.7 machine.
hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
bug: kernel timer added twice at c01e6925.
hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
bug: kernel timer added twice at c01e6925.
The first two occured at about the same time. The second two occured the
next day. HDC is a WDC WD307AA ATA drive. The controller is a PIIX4 (82371AB)
using DMA (UDMA33).
The relevant section of the system map is :
c01e52c0 T do_rw_taskfile
c01e5450 T do_taskfile
c01e55b0 T set_multmode_intr
c01e5610 T set_geometry_intr
c01e5670 T recal_intr
c01e56b0 T task_no_data_intr
c01e5720 t task_in_intr
c01e5840 t pre_task_out_intr
c01e5940 t task_out_intr
c01e5a90 t pre_bio_out_intr
c01e5af0 t bio_mulout_intr
c01e5ce0 t task_mulin_intr
c01e5e70 T ide_cmd_type_parser
c01e5ff0 t ide_init_drive_taskfile
c01e6010 T ide_wait_taskfile
c01e6120 T ide_raw_taskfile
c01e6180 t ide_wait_cmd
c01e6210 T ide_cmd_ioctl
c01e6420 T ide_task_ioctl
c01e64e0 t init_hwif_data
c01e66a0 T drive_is_flashcard
c01e67d0 T __ide_end_request
c01e68c0 T ide_set_handler
c01e6940 t ata_pre_reset
c01e6a00 T ata_capacity
c01e6a40 t ata_special
This looks harmless, like something was set twice.
--
David Schwartz
<[email protected]>
Looking for news feed peering arrangements in Northern California
Email for info
On Thu, 21 Mar 2002, David Schwartz wrote:
>
> I got the following from a 2.5.7 machine.
>
> hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
> bug: kernel timer added twice at c01e6925.
> hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
> bug: kernel timer added twice at c01e6925.
Same here, IDE guys knows about it. But it's still open :-(
Here's some dust :
Linux version 2.5.7 ([email protected]) (gcc version 3.0.3) #1 Tue Mar 19 17:41:44 PST 2002
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 0000000010000000 (usable)
BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
256MB LOWMEM available.
On node 0 totalpages: 65536
zone(0): 4096 pages.
zone(1): 61440 pages.
zone(2): 0 pages.
Kernel command line: auto BOOT_IMAGE=2.5.7 ro root=305 BOOT_FILE=/boot/vmlinuz-2.5.7
Initializing CPU#0
Detected 999.563 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 1992.29 BogoMIPS
Memory: 256796k/262144k available (1349k kernel code, 4960k reserved, 347k data, 208k init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
CPU: Before vendor init, caps: 0183f9ff c1c7f9ff 00000000, vendor = 2
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
CPU: After vendor init, caps: 0183f9ff c1c7f9ff 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: After generic, caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: Common caps: 0183f9ff c1c7f9ff 00000000 00000000
CPU: AMD Athlon(tm) Processor stepping 02
Enabling fast FPU save and restore... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.40 (20010327) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
Linux NET4.0 for Linux 2.4
Based upon Swansea University Computer Society NET3.039
Initializing RT netlink socket
PCI: PCI BIOS revision 2.10 entry at 0xfb350, last bus=1
PCI: Using configuration type 1
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router VIA [1106/0686] at 00:07.0
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
usb.c: registered new driver hub
Starting kswapd
BIO: pool of 256 setup, 14Kb (56 bytes/bio)
biovec: init pool 0, 1 entries, 12 bytes
biovec: init pool 1, 4 entries, 48 bytes
biovec: init pool 2, 16 entries, 192 bytes
biovec: init pool 3, 64 entries, 768 bytes
biovec: init pool 4, 128 entries, 1536 bytes
biovec: init pool 5, 256 entries, 3072 bytes
Installing knfsd (copyright (C) 1996 [email protected]).
pty: 256 Unix98 ptys configured
Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabled
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
block: 256 slots per queue, batch=32
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
eepro100.c:v1.09j-t 9/29/99 Donald Becker http://www.scyld.com/network/eepro100.html
eepro100.c: $Revision: 1.36 $ 2000/11/17 Modified by Andrey V. Savochkin <[email protected]> and others
PCI: Found IRQ 11 for device 00:14.0
PCI: Sharing IRQ 11 with 00:07.2
PCI: Sharing IRQ 11 with 00:07.3
eth0: Intel Corp. 82557 [Ethernet Pro 100], 00:02:B3:11:E5:92, IRQ 11.
Board assembly 721383-016, Physical connectors present: RJ45
Primary interface chip i82555 PHY #1.
General self-test: passed.
Serial sub-system self-test: passed.
Internal registers self-test: passed.
ROM checksum self-test: passed (0x04f4518b).
Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 204M
agpgart: Detected Via Apollo Pro KT133 chipset
agpgart: AGP aperture is 32M @ 0xd4000000
Uniform Multi-Platform E-IDE driver ver.:7.0.0
ide: system bus speed 33MHz
VIA Technologies, Inc. Bus Master IDE: unknown IDE controller on PCI slot 00:07.1, vendor=1106, device=0571
VIA Technologies, Inc. Bus Master IDE: chipset revision 16
VIA Technologies, Inc. Bus Master IDE: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:pio, hdd:pio
hda: WDC WD205BA, ATA DISK drive
hdb: CD-ROM 50X L, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hda: 40088160 sectors (20525 MB) w/2048KiB Cache, CHS=39770/16/63
hdb: ATAPI 50X CD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.12
Partition check:
hda: [PTBL] [2495/255/63] hda1 hda2 < hda5 hda6 hda7 >
Linux Kernel Card Services 3.1.22
options: [pci] [cardbus] [pm]
uhci.c: USB Universal Host Controller Interface driver v1.1
PCI: Found IRQ 11 for device 00:07.2
PCI: Sharing IRQ 11 with 00:07.3
PCI: Sharing IRQ 11 with 00:14.0
uhci.c: USB UHCI at I/O 0xd400, IRQ 11
hcd.c: new USB bus registered, assigned bus number 1
hub.c: USB hub found at /
hub.c: 2 ports detected
PCI: Found IRQ 11 for device 00:07.3
PCI: Sharing IRQ 11 with 00:07.2
PCI: Sharing IRQ 11 with 00:14.0
uhci.c: USB UHCI at I/O 0xd800, IRQ 11
hcd.c: new USB bus registered, assigned bus number 2
hub.c: USB hub found at /
hub.c: 2 ports detected
NET4: Linux TCP/IP 1.0 for NET4.0
IP Protocols: ICMP, UDP, TCP, IGMP
IP: routing cache hash table of 2048 buckets, 16Kbytes
TCP: Hash tables configured (established 16384 bind 32768)
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
ds: no socket drivers loaded!
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 208k freed
Adding Swap: 530104k swap-space (priority -1)
NFS: NFSv3 not supported.
nfs warning: mount version older than kernel
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 02)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 22)
00:07.1 IDE interface: VIA Technologies, Inc. Bus Master IDE (rev 10)
00:07.2 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.3 USB Controller: VIA Technologies, Inc. UHCI USB (rev 10)
00:07.4 Host bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 30)
00:07.5 Multimedia audio controller: VIA Technologies, Inc. AC97 Audio Controller (rev 20)
00:14.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
01:00.0 VGA compatible controller: ATI Technologies Inc Rage 128 RF
/dev/hda:
Model=WDC WD205BA, FwRev=16.13M16, SerialNo=WD-WM9491746366
Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }
RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=40
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=-66060037, LBA=yes, LBAsects=40088160
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 *udma4
/dev/hdb:
Model=CD-ROM 50X L, FwRev=15, SerialNo=
Config={ SpinMotCtl Removeable DTR<=5Mbs DTR>10Mbs nonMagnetic }
RawCHS=0/0/0, TrkSize=0, SectSize=0, ECCbytes=0
BuffType=unknown, BuffSize=0kB, MaxMultSect=0
(maybe): CurCHS=0/0/0, CurSects=0, LBA=yes, LBAsects=0
IORDY=on/off, tPIO={min:600,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: *mdma0 *mdma1 mdma2 udma0 udma1 *udma2
name value min max mode
---- ----- --- --- ----
acoustic 0 0 254 rw
address 0 0 2 rw
bios_cyl 2495 0 65535 rw
bios_head 255 0 255 rw
bios_sect 63 0 63 rw
bswap 0 0 1 r
current_speed 0 0 69 rw
failures 0 0 65535 rw
ide_scsi 0 0 1 rw
init_speed 0 0 69 rw
io_32bit 0 0 3 rw
keepsettings 0 0 1 rw
lun 0 0 7 rw
max_failures 1 0 65535 rw
multcount 16 0 16 rw
nice1 1 0 1 rw
nowerr 0 0 1 rw
number 0 0 3 rw
pio_mode write-only 0 255 w
slow 0 0 1 rw
unmaskirq 0 0 1 rw
using_dma 0 0 1 rw
wcache 0 0 1 rw
name value min max mode
---- ----- --- --- ----
current_speed 0 0 69 rw
dsc_overlap 1 0 1 rw
ide_scsi 0 0 1 rw
init_speed 0 0 69 rw
io_32bit 0 0 3 rw
keepsettings 0 0 1 rw
nice1 1 0 1 rw
number 1 0 3 rw
pio_mode write-only 0 255 w
slow 0 0 1 rw
unmaskirq 0 0 1 rw
using_dma 1 0 1 rw
- Davide
It is not harmless, it can be fatal. Leaving a dangling interrupt handler
set for the next device is a bad thing. I know what it is and where but
how and why is an issue to be resolved.
Regards,
Andre Hedrick
LAD Storage Consulting Group
On Thu, 21 Mar 2002, David Schwartz wrote:
>
> I got the following from a 2.5.7 machine.
>
> hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
> bug: kernel timer added twice at c01e6925.
> hdc: ide_set_handler: handler not null; old=c01e5af0, new=c01e5af0
> bug: kernel timer added twice at c01e6925.
>
> The first two occured at about the same time. The second two occured the
> next day. HDC is a WDC WD307AA ATA drive. The controller is a PIIX4 (82371AB)
> using DMA (UDMA33).
>
> The relevant section of the system map is :
>
> c01e52c0 T do_rw_taskfile
> c01e5450 T do_taskfile
> c01e55b0 T set_multmode_intr
> c01e5610 T set_geometry_intr
> c01e5670 T recal_intr
> c01e56b0 T task_no_data_intr
> c01e5720 t task_in_intr
> c01e5840 t pre_task_out_intr
> c01e5940 t task_out_intr
> c01e5a90 t pre_bio_out_intr
> c01e5af0 t bio_mulout_intr
> c01e5ce0 t task_mulin_intr
> c01e5e70 T ide_cmd_type_parser
> c01e5ff0 t ide_init_drive_taskfile
> c01e6010 T ide_wait_taskfile
> c01e6120 T ide_raw_taskfile
> c01e6180 t ide_wait_cmd
> c01e6210 T ide_cmd_ioctl
> c01e6420 T ide_task_ioctl
> c01e64e0 t init_hwif_data
> c01e66a0 T drive_is_flashcard
> c01e67d0 T __ide_end_request
> c01e68c0 T ide_set_handler
> c01e6940 t ata_pre_reset
> c01e6a00 T ata_capacity
> c01e6a40 t ata_special
>
> This looks harmless, like something was set twice.
>
> --
> David Schwartz
> <[email protected]>
> Looking for news feed peering arrangements in Northern California
> Email for info
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On 12:36 17 Mar 2002, Keith Owens <[email protected]> wrote:
| printf "%-25s%s\n", $head[$i], $f[$i];
Just a remark on a piece of code I see done a lot,
when formatting things for printf in columns, do this:
print "%-25s %s\n", ...
note! ----^
This _guarentees_ a space between one field ond the next. Ps and ls are
examples of commands whose output is regularly mangled in this way by
wide column values. Enforcing a single space between fields in the format
string avoids this. If the extra width bugs you, notch the %-25s down one.
There's plenty of formatting out there subject to this problem; let's
not help it with examples.
Cheers,
--
Cameron Simpson, DoD#743 [email protected] http://www.zip.com.au/~cs/
Disclaimer: Opinions expressed here are CORRECT, mine, and not PSLs or NMSUs..
- Larry Cunningham <[email protected]>
Davide Libenzi wrote:
>
>
> name value min max mode
> ---- ----- --- --- ----
> acoustic 0 0 254 rw
> address 0 0 2 rw
> bios_cyl 2495 0 65535 rw
> bios_head 255 0 255 rw
> bios_sect 63 0 63 rw
> bswap 0 0 1 r
> current_speed 0 0 69 rw
> failures 0 0 65535 rw
> ide_scsi 0 0 1 rw
> init_speed 0 0 69 rw
> io_32bit 0 0 3 rw
> keepsettings 0 0 1 rw
> lun 0 0 7 rw
> max_failures 1 0 65535 rw
> multcount 16 0 16 rw
> nice1 1 0 1 rw
Please try to set this nice1 stuff to 0 I would be glad
to know whatever this helps.
On Fri, 22 Mar 2002, Martin Dalecki wrote:
> Davide Libenzi wrote:
>
> >
> >
> > name value min max mode
> > ---- ----- --- --- ----
> > acoustic 0 0 254 rw
> > address 0 0 2 rw
> > bios_cyl 2495 0 65535 rw
> > bios_head 255 0 255 rw
> > bios_sect 63 0 63 rw
> > bswap 0 0 1 r
> > current_speed 0 0 69 rw
> > failures 0 0 65535 rw
> > ide_scsi 0 0 1 rw
> > init_speed 0 0 69 rw
> > io_32bit 0 0 3 rw
> > keepsettings 0 0 1 rw
> > lun 0 0 7 rw
> > max_failures 1 0 65535 rw
> > multcount 16 0 16 rw
> > nice1 1 0 1 rw
>
> Please try to set this nice1 stuff to 0 I would be glad
> to know whatever this helps.
I have these messages at boot. I'll rebuild the kernel with nice1
defaulted to 0 and let's see what happens. Anyway it's a good tip, i've
the cdrom on the same ide interface on my hd ...
- Davide
Davide Libenzi wrote:
> On Fri, 22 Mar 2002, Martin Dalecki wrote:
>
>
>>Davide Libenzi wrote:
>>
>>
>>>
>>>name value min max mode
>>>---- ----- --- --- ----
>>>acoustic 0 0 254 rw
>>>address 0 0 2 rw
>>>bios_cyl 2495 0 65535 rw
>>>bios_head 255 0 255 rw
>>>bios_sect 63 0 63 rw
>>>bswap 0 0 1 r
>>>current_speed 0 0 69 rw
>>>failures 0 0 65535 rw
>>>ide_scsi 0 0 1 rw
>>>init_speed 0 0 69 rw
>>>io_32bit 0 0 3 rw
>>>keepsettings 0 0 1 rw
>>>lun 0 0 7 rw
>>>max_failures 1 0 65535 rw
>>>multcount 16 0 16 rw
>>>nice1 1 0 1 rw
>>
>>Please try to set this nice1 stuff to 0 I would be glad
>>to know whatever this helps.
>
>
> I have these messages at boot. I'll rebuild the kernel with nice1
> defaulted to 0 and let's see what happens. Anyway it's a good tip, i've
> the cdrom on the same ide interface on my hd ...
Just grep for nice1 through the kernel and you should find
where it get's defaulted :-).
find /usr/src/linux -name "*.[ch]" -exec grep nice1 /dev/null {} \;
From: Alan Cox <[email protected]>
Date: Sat, 16 Mar 2002 01:43:05 +0000 (GMT)
Dave's suggestion is netfilter - and netfilter is fast enough I
think. You only need filters on stuff you have already decided is
for your IP too.
After some thinking, the TAP idea is even nicer as it guarentees zero
overhead, make it such that you only route the BGP stuff over the
device having the TAP attached (make a dummy eth alias just for this
purpose).
On Sun, Mar 17, 2002 at 08:09:49PM -0800, David S. Miller wrote:
> From: Alan Cox <[email protected]>
> Date: Sat, 16 Mar 2002 01:43:05 +0000 (GMT)
>
> Dave's suggestion is netfilter - and netfilter is fast enough I
> think. You only need filters on stuff you have already decided is
> for your IP too.
>
> After some thinking, the TAP idea is even nicer as it guarentees zero
> overhead, make it such that you only route the BGP stuff over the
> device having the TAP attached (make a dummy eth alias just for this
> purpose).
>
... You'd have to use netfilter to mark the correct packets, then route on
that mark to the dummy interface.
How is that more efficient?