iSCSI target returns "Device type is not supported by server", discovery fails.

Status: New -> Confirmed
Importance: Undecided -> Low.

This bug affects, but then it isn't that important to affect. So low.

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1034015/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

on amd64

Low affection for whom?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.5kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. Please only remove that one tag and leave the other tags. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-rc1-quantal/

Just tested 3.5.0-030500-generic - same behaviour

Could this be an open-iscsi bug and not a kernel issue?

It may be of help that this problem is persistent also on Scientific Linux 6.3 with kernel 2.6.32-279.el6.x86_64 and iscsiadm 2.0-872.41.el6

@roysk

The thing about inquiry data is that it's incumbent on the target to provide
what the initiator has asked of it. What is open-iscsi connecting to, another SAN,
if so which make and model? If it's not a HW SAN could you setup an software
iSCSI target server and connect with the existing open-iscsi tool set to see
if the short inquiry phenomenon follows the SAN or the the client?

In my experience, these sort of faults usually are the result of a SCSI target
that's not quite ready. Sure it may be fully provisioned, but if the SAN is busy
serving other requests, *it's operating system* can starve out the target and
cause unpredictable results. It's an equal opportunity offender, affecting
software iSCSI targets and inefficient HW SAN firmware (also software :).

Getting 36 bytes of inquiry data is trivial, something is really wrong if we can't
get even that from the target.

https://en.wikipedia.org/wiki/SCSI_Inquiry_Command

If you are using a software target to begin with, consider adding cgroups to
ensure it has a minimum of CPU time to perform it's tasks in a timely manner;
or simply decreasing the net workload on the system and see if that improves
reliability.

So here's your problem, which I identified by running wireshark on the pcap
(very helpful, thanks for providing), typing 'iscsi' to filter on that only
and identified the inquiry exchange.

The inquiry cmd open-iscsi send looks fine. The response from the target
however...

0060 00 00 00 00 00 00 7f 00 05 00 00 00 00 00 00 00 ........ ........
0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0080 00 00 00 00 00 00 00 00 00 00 ........ ..

Definitely no make and model information there...

Wireshark was so kind as to translate it for me.

Peripheral: 0x7f, Qualifier: Device type is not supported by server, Device Type: Unknown or no device type
011. .... = Qualifier: Device type is not supported by server (0x03)
...1 1111 = Device Type: Unknown or no device type (0x1f)

So sure it's advertising a lun, but when we reach out in touch it we get garbage.

This is decidedly SAN side. That Centos "works" at all is simply a race condition *or*
it has a quirk allowance for your SAN, which you have yet to articulate.

Contact your SAN vendor to determine why it's responding this way.

My bad, it's a SANRAD (never heard of it, I though you were using some slang)

http://www.sanrad.com/

Let us know what they think of that pcap you provided, that was very helpful.

Pending results of https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1034015/comments/11 .

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

[Expired for open-iscsi (Ubuntu) because there has been no activity for 60 days.]