Bug#634794: cdrom eject button has stopped working

[Mark Hobley]

--- On Wed, 20/7/11, Jonathan Nieder  wrote:

> Could you attach full output from "dmesg" (so we can see
> what model of CD-ROM we are talking about)?

There is nothing in dmesg about the drive, but the system has been up a while. 
Is there some way I can query for the cdrom drive information?

I found this in /proc/sys/dev/cdrom/info, if it means anything:

CD-ROM information, Id: cdrom.c 3.20 2003/12/17

drive name: sr0
drive speed:32
drive # of slots:   1
Can close tray: 1
Can open tray:  1
Can lock tray:  1
Can change speed:   1
Can select disk:0
Can read multisession:  1
Can read MCN:   1
Reports media changed:  1
Can play audio: 1
Can write CD-R: 0
Can write CD-RW:0
Can read DVD:   0
Can write DVD-R:0
Can write DVD-RAM:  0
Can read MRW:   1
Can write MRW:  1
Can write RAM:  1

# hdparm /dev/sr0

/dev/sr0:
 HDIO_DRIVE_CMD(identify) failed: Input/output error
 IO_support=  0 (default) 
 readonly  =  0 (off)
 readahead = 256 (on)
 HDIO_GETGEO failed: Inappropriate ioctl for device

# hdparm -I

/dev/sr0:
HDIO_DRIVE_CMD(identify) failed: Input/output error

I'll have to shutdown to refresh dmesg, or maybe open up the case and have a 
look.

Mark.




--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1311131494.83478.yahoomailclas...@web26502.mail.ukl.yahoo.com

Bug#634794: cdrom eject button has stopped working

[Mark Hobley]

Package: linux-2.6
Version: 2.6.39-2
Severity: normal
File: linux

The cdrom eject button appears to have stopped working and the eject command
does not work either.

eject /dev/cdrom

This just returns to a prompt, and the drive stays closed. It used to
work before when the drives all had /dev/hd* names. This must have happened
when the devices became renamed. The cdrom works fine otherwise, but I have
to use a special tool (made from a paperclip) to extract the discs now.

A system trace reveals:

open("/dev/sr0", O_RDWR|O_NONBLOCK) = 3
ioctl(3, CDROMEJECT, 0x802) = -1 EIO (Input/output error)

I'm not sure what model drive it is at this time, but it is an IDE one
connected via a ribbon cable to the motherboard.

-- Package-specific info:
** Version:
Linux version 2.6.39-2-486 (Debian 2.6.39-2) (b...@decadent.org.uk) (gcc 
version 4.4.6 (Debian 4.4.6-3) ) #1 Wed Jun 8 10:50:02 UTC 2011

** Command line:
auto BOOT_IMAGE=Linux ro root=805 ipv6.disable=1 quiet

** Not tainted

** Kernel log:
[3210188.319343] sr 1:0:0:0: [sr0]  Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
[3210188.319356] sr 1:0:0:0: [sr0]  Sense Key : Illegal Request [current] 
[3210188.319366] sr 1:0:0:0: [sr0]  Add. Sense: Illegal mode for this track
[3210188.319389] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a 60 00 00 40 00
[3210188.319406] end_request: I/O error, dev sr0, sector 59776
[3210188.319418] Buffer I/O error on device sr0, logical block 7472
[3210188.319431] Buffer I/O error on device sr0, logical block 7473
[3210188.319439] Buffer I/O error on device sr0, logical block 7474
[3210188.319446] Buffer I/O error on device sr0, logical block 7475
[3210188.319453] Buffer I/O error on device sr0, logical block 7476
[3210188.319460] Buffer I/O error on device sr0, logical block 7477
[3210188.319467] Buffer I/O error on device sr0, logical block 7478
[3210188.319473] Buffer I/O error on device sr0, logical block 7479
[3210188.319480] Buffer I/O error on device sr0, logical block 7480
[3210188.319487] Buffer I/O error on device sr0, logical block 7481
[3210219.104064] ata2: lost interrupt (Status 0x50)
[3210219.104115] ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 
frozen
[3210219.104130] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a a0 00 00 40 00
[3210219.104160] ata2.00: cmd a0/01:00:00:00:fc/00:00:00:00:00/a0 tag 0 dma 
131072 in
[3210219.104163]  res 40/00:03:00:08:00/00:00:00:00:00/a0 Emask 0x4 
(timeout)
[3210219.104171] ata2.00: status: { DRDY }
[3210219.104216] ata2: soft resetting link
[3210219.284262] ata2.00: configured for MWDMA2
[3210219.284379] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210224.260084] ata2: soft resetting link
[3210224.440255] ata2.00: configured for MWDMA2
[3210224.448079] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210224.448088] ata2.00: limiting speed to MWDMA2:PIO3
[3210229.416084] ata2: soft resetting link
[3210229.596278] ata2.00: configured for MWDMA2
[3210229.596397] ata2.00: TEST_UNIT_READY failed (err_mask=0x2)
[3210229.596404] ata2.00: disabled
[3210229.596456] ata2: soft resetting link
[3210229.752154] ata2: EH complete
[3210229.752262] sr 1:0:0:0: [sr0] Unhandled error code
[3210229.752269] sr 1:0:0:0: [sr0]  Result: hostbyte=DID_BAD_TARGET 
driverbyte=DRIVER_OK
[3210229.752279] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a a0 00 00 40 00
[3210229.752296] end_request: I/O error, dev sr0, sector 60032
[3210229.752306] quiet_error: 22 callbacks suppressed
[3210229.752313] Buffer I/O error on device sr0, logical block 7504
[3210229.752324] Buffer I/O error on device sr0, logical block 7505
[3210229.752331] Buffer I/O error on device sr0, logical block 7506
[3210229.752338] Buffer I/O error on device sr0, logical block 7507
[3210229.752344] Buffer I/O error on device sr0, logical block 7508
[3210229.752351] Buffer I/O error on device sr0, logical block 7509
[3210229.752357] Buffer I/O error on device sr0, logical block 7510
[3210229.752364] Buffer I/O error on device sr0, logical block 7511
[3210229.752371] Buffer I/O error on device sr0, logical block 7512
[3210229.752379] Buffer I/O error on device sr0, logical block 7513
[3210229.752447] sr 1:0:0:0: [sr0] Unhandled error code
[3210229.752452] sr 1:0:0:0: [sr0]  Result: hostbyte=DID_BAD_TARGET 
driverbyte=DRIVER_OK
[3210229.752460] sr 1:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 3a 60 00 00 02 00
[3210229.752474] end_request: I/O error, dev sr0, sector 59776

** Model information
not available

** Loaded modules:
Module  Size  Used by
tun17630  0 
snd_via82xx22532  0 
snd_ac97_codec 83728  1 snd_via82xx
ac97_bus   12462  1 snd_ac97_codec
snd_pcm_oss35824  0 
snd_mixer_oss  17649  1 snd_pcm_oss
snd_pcm52675  3 snd_via82xx,snd_ac97_codec,snd_pcm_oss
snd_page_alloc 12841  2 snd_via82xx,snd_pcm
snd_mpu401_uart13299  1 snd_via82xx
snd_seq_midi   12744  0 
snd_rawmidi 

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

A strange thing has just happened. I plugged the dongle in to get some 
information from it, and when I ran hciconfig, it showed as "up running":

hciconfig -a 
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
UP RUNNING PSCAN 
RX bytes:754 acl:0 sco:0 events:26 errors:0
TX bytes:368 acl:0 sco:0 commands:25 errors:0
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH HOLD SNIFF 
Link mode: SLAVE ACCEPT 
Name: 'Accel-OB2'
Class: 0x4a0100
Service Classes: Networking, Capturing, Telephony
Device Class: Computer, Uncategorized
HCI Version: 2.0 (0x3)  Revision: 0x44
LMP Version: 2.0 (0x3)  Subversion: 0x3
Manufacturer: Cambridge Silicon Radio (10)

I don't know why that has happened. I normally just get a timeout error, so it 
looks like this problem is not always consistent. I have not updated my system, 
since I last reported HCI Timeout.

My mobile phone is now temporarily visible to my computer, but I cannot see the 
computer from the mobile phone, so I am unable to initiate a transfer from the 
mobile phone. I don't know how to take the device out of invisibility mode, and 
when I try, it will probably revert back to giving HCI timeout, but hey ... 
this is the first time I have seen this half working since I upgraded bluez.

Mark.



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308780800.31280.yahoomailclas...@web26508.mail.ukl.yahoo.com

Bug#525220: Nano Tiny USB 2.0 Bluetooth Adapter

[Mark Hobley]

There are some mass market USB Bluetooth Dongles available, which are badged as 
"NANO TINY USB 2.0 BLUETOOTH ADAPTER DONGLE EDR WIRELESS". These adapters have 
a part number 500792110001, and a package barcode of 200529837. These 
devices are available from Ebay, and from large online retailers such as Amazon.

When plugged into a computer, these devices identify themselves as "Cambridge 
Silicon Radio" and carry an identity of 0a12:0001.

On investigation, it appears that these devices actually contain an AS3620QA1 
microchip made by "Accel Semiconductor Corporation" in China. The first three 
bytes of the MAC address reflect these as being made by Accel Semiconductor 
Corporation.

Currently, these devices do not work in Linux and cause an HCI Timeout error 
(as reported in Kernel bug #10126, Debian bug #525220 and Launchpad #460743).

It appears that several people have been "stung" by non operation of these 
devices.

Is is likely that support for these will be included in a future version of the 
kernel or are Accel Semiconductor devices a non working dead end for us?

Mark.



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308774157.20191.yahoomailclas...@web26503.mail.ukl.yahoo.com

Bug#525220: Bluetooth problem caused by fake dongles?

[Mark Hobley]

--- On Wed, 22/6/11, Ben Hutchings  wrote:

> There is a standard USB 'device class' for Bluetooth
> adapters, which are all handled by the 'btusb' driver.

Right. So does that mean that there is a chance that these devices might work 
in future? Or do we need to be shopping round for replacement adapters? If so 
what should we be looking for?



--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308755220.45466.yahoomailclas...@web26505.mail.ukl.yahoo.com

Bug#525220: Bluetooth problem caused by fake dongles?

[Mark Hobley]

--- On Tue, 21/6/11, Alexander Heinz  wrote:

> The USB IDs corresponds to CSR but the
> chip label says ASC AS3620QA. This is a counterfeit.
> 
> Is very easy to tell. Just open your dongle and check the
> label on the chip.

Bloody hell Alex. I just took your advise and opened the dongle. And woah! It 
does say ASC AS3620QA. Presumably, these are bluetooth chips, but they do work 
with the CSR driver. That is a shock. I deliberately chose these dongles 
because they were advertised as being CSR.

I wonder if we can get an ASC AS3620QA driver (or is it likely that someone 
will develop one?), or have I been sold some dead ducks?

Mark.




--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308690444.34276.yahoomailclas...@web26504.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I attached a system trace against #628454, so hopefully, someone can interpret 
this and tell us what is going wrong.





--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308682410.4644.yahoomailclas...@web26502.mail.ukl.yahoo.com

Bug#525220: Bluetooth problem caused by fake dongles?

[Mark Hobley]

--- On Tue, 21/6/11, Alexander Heinz  wrote:

> I also have a problem with Bluetooth. I have recently
> bought a new USB dongle in the store (instead of on ebay)
> that does not seem to have this problem. The funny thing is
> that the USB IDs are identical, so the two devices claim to
> be identical as well.
> 
> What also makes me wonder is the fact the MAC address of my
> dongle does not seem to be unique. I have several dongles,
> all of them have the address 00:1F:81:00:01:1C. Google for
> it and you will find more people that have dongles with the
> same address.

Yeah. Mine has that address. I bought a batch of them, so I will check the 
others. I planned to use them on several computers in the same building, so I 
hope that duplicate mac addresses is not going to be a problem.

> Is it possible that all of us have bought counterfeit
> dongles?

My mobile phone showed up as present on one of the release candidate kernels, 
so mine is not fake.

We could always borrow a friends laptop that runs Micros~1youknowwhat and test 
the dongles for operation.






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1308681962.32226.yahoomailclas...@web26506.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I upgraded the kernel to 2.6.39-1 from experimental and rebooted the system. 
Initially, After typing hcitool inq, the system showed that my mobile phone was 
present, so it appeared as though bluetooth was at least momentarily partially 
working. However, from the mobile phone, the computer was not listed, as if the 
computer was somehow hidden.

I upgraded bluez to version 4.93-1 from Debian experimental, in the hope that 
this might fix the visibility problem.

However, bluetooth now appears to be broken again. Following a reboot of the 
computer:

hciconfig -a
 
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
DOWN 
RX bytes:59 acl:0 sco:0 events:5 errors:0
TX bytes:15 acl:0 sco:0 commands:36 errors:31
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: 
Link mode: SLAVE ACCEPT 

I now try to bring the interface into operational mode, and the timeout
error reoccurs:

hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

dmesg shows squillions of errors as follows:

[.nn] hci_cmd_timer: hci0 command tx timeout

So it appears that there might also be bugs in bluez which are aggrevating this 
problem. BLUETOOTH IS NOT OPERATIONAL.

Mark.






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/17011.91974...@web26507.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I have just tested this again with experimental kernel 2.6.39-rc4-486 (Debian 
2.6.39~rc4-1~experimental.1). The problem is still occuring with that kernel 
build:

# hciconfig -a
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
DOWN 
RX bytes:68 acl:0 sco:0 events:6 errors:0
TX bytes:18 acl:0 sco:0 commands:36 errors:30
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: 
Link mode: SLAVE ACCEPT

# hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

Mark.




--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/323722.1514...@web26508.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

A! When I try to bring the device into operational mode, the timeout error 
occurs, so I guess this is still not fixed in 2.6.38-rc6-486:

hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

Mark.






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/653221.13235...@web26507.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I have just tested this again with kernel version 2.6.38-rc6-486.

This time, no timeout occurs with hciconfig:

hciconfig -a hci0

hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
DOWN 
RX bytes:342 acl:0 sco:0 events:10 errors:0
TX bytes:33 acl:0 sco:0 commands:11 errors:1
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: 
Link mode: SLAVE ACCEPT

However, the device does not appear in the hcitool list at this time:

hcitool dev
Devices:

(There is nothing here)

I am still investigating this issue.

Mark.









--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/119223.54072...@web26501.mail.ukl.yahoo.com

Bug#525220: Fw: Re: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

--- On Sat, 11/12/10, Ben Hutchings  wrote:

> Please report this bug upstream at  under
> product 'Drivers', component 'Bluetooth'.  Let us know
> the bug number or URL so we can track it.

Issue tracking numbers relating to this bug are:

Linux kernel team #10126
Launchpad #460743
Redhat #519176





  

signature.asc
Description: This is a digitally signed message part

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I have retested this again. This time with experimental kernel version  
2.6.37-rc5 (Debian 2.6.37~rc5-1~experimental.1).

The timeout error is still occuring, so the latest attempts at fixing this have 
not worked. THE KERNEL IS STILL BROKEN:

hciconfig -a
 
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
UP RUNNING 
RX bytes:413 acl:0 sco:0 events:18 errors:0
TX bytes:67 acl:0 sco:0 commands:21 errors:4
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: RSWITCH HOLD SNIFF PARK 
Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)







--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/548440.6431...@web26503.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

I have just tested this with the experimental kernel version 2.6.36-rc5-486.
I am still getting the timeout error:

hciconfig -a hci0  
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
UP RUNNING 
RX bytes:59 acl:0 sco:0 events:5 errors:0
TX bytes:15 acl:0 sco:0 commands:7 errors:2
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: 
Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/995094.29733...@web26507.mail.ukl.yahoo.com

Bug#525220: Bluetooth trouble with hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

--- On Mon, 16/8/10, mailsanm...@gmx.li  wrote:

> I have the same problem with the same type of Bluetooth
> dongle (even my MAC address is the same). Were you able to
> work around this problem? Do you have any working
> combination of kernel and bluez that enables you to actually
> use this dongle?

Hi Alex. I have not yet obtained a workaround for this and bluetooth is still 
broken for me. 

You could try building a kernel from the latest kernel sources from kernel.org. 
If you do achieve success with this, please let me know.

I will probably wait now until a newer kernel becomes available in Sid before I 
retest. I will eventually be switching to a source based build, so that I can 
deal with issues like this on the fly.


Mark.







--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/734860.66911...@web26508.mail.ukl.yahoo.com

Bug#525220: Bluetooth Device: hci_cmd_task: hci0 command tx timeout

[Mark Hobley]

Moritz Muehlenhoff wrote:
> The next release of Debian (6.0, code name Squeeze) will be based
> on 2.6.32. Please test the current 2.6.32 from unstable/testing and tell
> us whether the problem persists.

Hello Moritz. I am testing with kernel 2.6.32-5-486

I am getting the timeout here, so I reckon this is still broken in Squeeze.

# hciconfig -a   
hci0:   Type: BR/EDR  Bus: USB
BD Address: 00:1F:81:00:01:1C  ACL MTU: 1021:4  SCO MTU: 180:1
UP RUNNING 
RX bytes:330 acl:0 sco:0 events:8 errors:0
TX bytes:24 acl:0 sco:0 commands:16 errors:8
Features: 0xff 0x3e 0x09 0x76 0x80 0x01 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
Link policy: 
Link mode: SLAVE ACCEPT 
Can't read local name on hci0: Connection timed out (110)

# dmesg
[127422.591465] hci_cmd_task: hci0 command tx timeout

# lsusb
Bus 003 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle 
(HCI mode)

I tried updating to bluez-4.69, which I downloaded from an upstream source and 
compiled myself, but the problem still persists.

Mark.









--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/638868.87901...@web26504.mail.ukl.yahoo.com

Bug#540074: netfilter leaking traffic when long chains defined

[Mark Hobley]

Right, I am trying to capture some traffic using:

tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 
10.0.0.8 ))'

Oops. that should read:

tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 
10.0.0.0/8 ))'






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540074: netfilter leaking traffic when long chains defined

[Mark Hobley]

Right, I am trying to capture some traffic using:

tcpdump -f -xx '( port 8000 ) and (( ! src net 10.0.0.0/8 ) or ( ! dst net 
10.0.0.8 ))'

This will capture traffic from the live system, which is using service port 
8000, rather than test port , which is from test. (On the live system the 
service port number is 8000, rather than , and the script has been modified 
to reflect this).

netstat -a reveals:

tcp0  0 neptune.markhobley:8000 118-168-141-172.dy:3388 ESTABLISHED

I am not getting any output against host 118.168.141.172 after an interval of 
10 minutes. I was expecting to see some kind of "keep alive" here, or the 
connection to timeout (via the idle timer) and close. I am not seeing this via 
tcpdump. Does that occur at a lower level than tcpdump?

I am getting malicious traffic showing from other hosts, but unfortunately 
tcpdump logs the traffic before the filter, so this has to be ignored.

It would be useful here, if I could log only traffic that passes the filter. 
Can I do this?

Currently to determine traffic passing the filter, I have to look for an 
incoming packet that causes a response from the application. These are 
infrequent, but I expect to find one over a period of several days.

I will try and rig this up for permanent monitoring, and post a follow up over 
the next few days.

Mark.






--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540074: netfilter leaking traffic when long chains defined

[Mark Hobley]

Hello Bastian.

Re: Bug#540074: netfilter leaking traffic when long chains defined

Sorry for the delay. For some reason I did not get a copy of your email, and I 
just found your messages on an internet archive.

tcp 0 0 10.0.0.8: 118.168.141.172:3388 ESTABLISHED

This is an established connection. No evidence where the packets come
from.

Right. Port  is a listening port (in this case listening for http requests 
(provided by didiwiki), so presumably the host at 118.168.141.172 made a 
connection, even though it is not in the address whitelist, as far as I can 
tell.

For details of configuration scripts and test data, refer to bug #534963

This is not nearly complete. Please show the _complete_ config.

That is the complete configuration, as far as I can tell. What element of the 
configuration do you believe is missing?

> please use a sniffer and record the packets going through.

The service port  is being used frequently by computers on the internal 
LAN. I have tcpdump that I could use here, but I only want to log only packets 
coming in externally (ie not coming from 10.0.0.*) for the purpose of this 
report. Do you know of a way of achieving that or is there another sniffer that 
you suggest that I use?

Thanks in advance.

Mark.







--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#540074: netfilter leaking traffic when long chains defined

[Mark Hobley]

Package: linux-image-2.6-486
Version: 2.6.26+17+lenny1
Severity: normal
File: linux

There appears to be traffic leaking across the netfilter when a long chain of
valid ip addresses are used.

I am getting connections being established from outside of the valid address
list. For example:

netstat -a --numeric-users
tcp 0 0 10.0.0.8: 118.168.141.172:3388 ESTABLISHED

This problem incorrectly reported on #534963 against iptables. This
reopens against kernel, as advised by Laurence Lane.

For details of configuration scripts and test data, refer to bug #534963.

Mark.

-- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (990, 'stable'), (50, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-486
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6-486 depends on:
ii  linux-image-2.6.26-2-486  2.6.26-17  Linux 2.6.26 image on x86

linux-image-2.6-486 recommends no packages.

linux-image-2.6-486 suggests no packages.

-- no debconf information




-- 
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#488022: New findings.

[Mark Hobley]

Raúl Sánchez Siles  wrote:

Make paravirt feature depends on 586/pentium (upstream), since not all 486 
support the cpuid needed infrastructure, again upstream advice would be 
needed.

Disable paravirtualization in Debian kernel for 486. This is somewhat 
thorny. Is paravirtualization absolutely needed on this architecture flavour?

Drop support for processors without cpuid, this include most low-end 
embedded/industrial 486 processors.

I think the problem here, is that we should not be making decisions based on 
"cpuid". It would be far better to utilize features based on build options.

The problem with cpuid, is that you can potentially have binary code that tests 
ok on one computer, but behaves differently on another. There are a whole lot 
of headaches relating to this, especially in organizations that have different 
processors in different machines, but the machines are all supposed to be 
compatible with each other.

(I don't recommend the use of Processor Supplementary Instructions and 
Processor Supplementary Features at all.)

if cpuid="Microsoft Sales Laptop" then
  crashes=minimal_except_when_bill_gates_is_on_television
else
  # Customers computer
  random_crash_with("Blue Screen of Death")
endif

It would be far better to let the system installer choose which features to use 
at build time. Power to the administrator! :)

Mark.







--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#506345: linux-image-2.6-486: Facility to allow falsified information in /proc/cpuinfo

[Mark Hobley]

Package: linux-image-2.6-486
Version: 2.6.26+16
Severity: wishlist


It would be useul to have the facility to provide a generic entry in 
/proc/cpuinfo rather than revealing processor specific information.

This could possibly be done via a boot option, such as

cpuinfo=486 or cpuinfo=pentium

This would enable the computer to act as a generic base level computer 
for a specific architecture, providing backward compatibility with 
lower level machines. This would enable a machine to appear as a generic 
486 machine or as a generic Pentium machine, without revealing the machine is
actually a higher level machine 686 machine (or using an IBM compatible 
processor, supplied by an alternative manufacturer such as a Cyrix 686, 
or an AMD K6 or AMD K7.)

One of the problems that I am encountering is that build and runtime 
systems appear to be taking information from /proc/cpuinfo, and this is 
influencing compiler or program behaviour.

All of my machines are using 486 (IA-32) compatible processors. However, 
not all machines are true 486 machines. I have 586, 686 and K7 series 
processors on some machines, and the processors are made by various 
manufacturers (such as Intel, Cyrix and AMD.)

I require all machines to behave with "lowest common denominator" 
behaviour, and for all compiled binaries to be generic enough to move 
across machines. I am finding that distribution provided binaries, and 
third party provided build scripts are detecting that the machine doing 
the build is a 686, and is utilizing features for that architecture, 
even though the target architecture is generic 486.

I know that a workaround for this would be to modify all of the build 
scripts in every single package, and find a way of rebuilding the entire
Debian distribution from source, but I feel that a falsified /proc/cpuinfo
would be much less of a headache.

I propose that the boot time switch cpuinfo=pentium provides the following 
falsified information in /proc/cpuinfo:

vendor_id   : GenuineIntel
cpu family  : 5
model   : 2
model name  : Pentium 75 - 200

Maybe the vendor_id, model and model name could be simply be set to 
"Unknown" or "Generic" if the boot switch is used. I am not sure what 
effect this would have, but hopefully it would mean generic behaviour.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
  Damn!! This bit is wrong!

Kernel: Linux 2.6.26-1-486
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash

Versions of packages linux-image-2.6-486 depends on:
ii  linux-image-2.6.26-1-486  2.6.26-8   Linux 2.6.26 image on x86

linux-image-2.6-486 recommends no packages.

linux-image-2.6-486 suggests no packages.

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#500158: linux-image-2.6.26-1-486: Upgrade from Debian Etch to Debian Lenny may cause a kernel halt

[Mark Hobley]

Package: linux-image-2.6.26-1-486
Version: 2.6.26-5
Severity: important


As Debian is upgraded from Debian Etch to Debian Lenny, the kernel may 
halt with an error as the system is restarted:

Booting the Kernel.

BUG Int 6: CR2 
EDI c0363f8c  ESI 4000  EBP c0363f88  ESP c036f44
EBX   EDX 0006  ECX   EAX 4000
err   EIP c0112b6f  CS c0370060   flg 00010092

Stack: c0363f90 c0363f8c c0363f88 c0363f94 c0363f90 c0363f8c c0363f88 c037294f
   c0363f94 c0375293 03bef000  c03fea40 4000 005a29b7 
   c000 0009f000 03bef000  00d0 c03ba410  

This was observed on an IBM compatible computer using a traditional Intel
Pentium compatible processor.


-- Package-specific info:
** Version:
Linux version 2.6.26-1-486 (Debian 2.6.26-4) ([EMAIL PROTECTED]) (gcc version 
4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 Thu Aug 28 11:14:57 UTC 2008

** Command line:
auto BOOT_IMAGE=Linux ro root=305

** Not tainted

** Kernel log:

No kernel log provided. A different machine is being used to report the 
error.

linux-image-2.6.26-1-486 recommends no packages.

Versions of packages linux-image-2.6.26-1-486 suggests:
ii  lilo  1:22.8-6   LInux LOader - The Classic OS load

-- debconf information excluded



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]