Opened 12 years ago

Closed 8 years ago

#10173 closed defect (obsolete)

Mistake with iSCSI authentication causes Segmentation Fault => fixed in svn/next maintenance release

Reported by: Steltek Owned by:
Component: other Version: VirtualBox 4.1.8
Keywords: iscsi segmentation fault Cc:
Guest type: Linux Host type: Linux

Description (last modified by aeichner)

While toying around with iSCSI support recently, I noticed that VirtualBox crashes very quickly at the slightest problem with the SCSI target data (like wrong authentication credentials).

The UI displays an error stating:

Failed to determine the accessibility state of the medium .

Callee RC: NS_ERROR_CALL_FAILED (0x800706BE)

The console where the VirtualBox command was run shows 'Segmentation Fault', the kernel log outputs: [ 6613.591346] VBoxSVC[17042]: segfault at b677b008 ip b73f6626 sp b67783fc error 4 in[b737d000+153000] [ 6621.900797] VirtualBox[16970]: segfault at 9d12af8 ip 09d12af8 sp bff4829c error 15

After this crash, it is impossible tostart VirtualBox again until one manually removes all references to the iSCSI volume from the VM's XML config file. (VirtualBox will keep crashing the same way until this is done.)

In addition to that, VirtualBox loses the state of running VMs after this crash (all VMs are shown as 'Powered Off' even though some are running). The only way around this seems to be to shut down all VMs and all VirtualBox related processes, and start everything again.

Host: Debian GNU/Linux wheezy/testing Kernel: Linux server 3.1.0-1-686-pae #1 SMP Tue Jan 10 05:42:54 UTC 2012 i686 GNU/Linux

Attachments (1)

trace.pcap (41.0 KB ) - added by Steltek 12 years ago.
Network trace with iSCSI users 'test', 'testServer1' and 'testserver1' and password 'testtesttest' for all.

Download all attachments as: .zip

Change History (10)

comment:1 by Steltek, 12 years ago

Update: Even specifying correct credentials causes the crash. Specifying an invalid target ID seems to be OK (no crash there).

comment:2 by Steltek, 12 years ago

Update2: When not using CHAP authentication, everything seems to work OK. Rechecking the authentication I noticed that even when giving the correct credentials, the iSCSI server refuses them (as if VirtualBox did not submit them correctly):

Feb 20 00:38:00 kernel: [5976226.290100] rx_data returned 0, expecting 48.
Feb 20 00:38:00 kernel: [5976226.294757] iSCSI - Login negotiation failed from [x.x.x.x]

The username is in this format: MyUsername2
The password is in this format: Simplepasswor

Could there be a problem with the length of these? (The storage system accepts and uses similar username/passwords when used with Debian's open-iscsi initiator, so the problem appears to be with VirtualBox.)

comment:3 by aeichner, 12 years ago

Description: modified (diff)

Sorry that it took so long to reply. I confirmed the crash when using wrong credentials, the fix will be in the next maintenance release, thanks for the report. However I can't reproduce the problem you have when using correct credentials, everything works as epxected. I'm using a 3.2.6 kernel instead of 3.1.0 though, could be a bug in the target but it would be great if you could attach a packet trace too be sure it is not a bug in VirtualBox.

comment:4 by aeichner, 12 years ago

Summary: Mistake with iSCSI authentication causes Segmentation FaultMistake with iSCSI authentication causes Segmentation Fault => fixed in svn/next maintenance release

comment:5 by Steltek, 12 years ago

My turn to be late. ;) I've done some more testing and narrowed down the authentication problem with correct credentials to an upper case letter in the username. I'm attaching the network trace of my tests.

All tests use the password 'testtesttest' and go toward the iSCSI Target

The first test users the username 'test' and succeeded. I then renamed the user on the target, causing VirtualBox to fail (should've removed the disk there first but forgot). The second username was 'testServer1', and when adding it to VirtualBox, it immediately crashed and I had to manually remove it from the config files again. The third test username was 'testserver1' (all lower case), and that one worked again.

As mentioned before, I am using the same username format within Debian directly and without any problem (using open-iscsi as initiator there), so the target appears to be fine with it. Only VirtualBox fails to authenticate against these targets. (Could there be code that lower-cases the username somewhere?)

I also did a fourth test (not traced) with the credentials 'testserver1/testtestTest' (upper case in the PW) and that one worked without any problems, so the problem only appears when there is an upper case letter in the username.

by Steltek, 12 years ago

Attachment: trace.pcap added

Network trace with iSCSI users 'test', 'testServer1' and 'testserver1' and password 'testtesttest' for all.

comment:6 by Technologov, 12 years ago

Maybe it makes sense to label this bug as fixed...

comment:7 by Steltek, 12 years ago

Actually I just upgraded to 4.1.12 and there seems to be a regression there as it just crashed again. (It didn't crash in 4.1.10 as far as I could see.)

comment:8 by gatos, 12 years ago

Any news on this? It still crashes with v4.1.18 using OSX as host. It also crashed with 4.1.10 (I upgraded to 4.1.18 hoping there would be a solution).

comment:9 by aeichner, 8 years ago

Resolution: obsolete
Status: newclosed

Please reopen if still relevant with a recent VirtualBox release.

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use