iPXE appears to fail to connect to Starwind

[ArneLovius]

Hi,

I'm trying (and failing) to get iPXE to connect to a Starwind iSCSI target,

I am chain booting undionly.0 from wdslinux, setting the root path and syslog address from DHCP using the ipxe user class.

To increase the logging, I built undionly from git with syslog and iscsi debug options, however I'm a little out of my depth trying to work out why it isn't working.

Any suggestions would be very gratefully received

the starwind log is here http://pastebin.com/6VyTpefh

the syslog output is here http://pastebin.com/rQuB9rnC

Thanks

Arne

[robinsmidsrod]

I see this information in your Starwind log:

Code:

2/17 19:00:22.464 1dbc C[44], LIN: T5.
2/17 19:00:29.472 1984 C[44], LIN: recvData returned 10054
2/17 19:00:29.472 1984 C[44], LIN: *** 'recv' thread: recv failed 10058.

I have no idea what that means, and I think you'll have to get in touch with the Starwind people to make sense of it. Maybe iPXE is sending an iSCSI packet Starwind doesn't understand, and it subsequently freaks out and drops the connection.

I would suggest you try to perform a packet trace on your Starwind machine and look closely at the packet that causes this behavior to happen.

[ArneLovius]

While I can understand that it does look on the surface as if its a problem with the iSCSI target, I upgraded Starwind to latest and ran another test

I had a closer look at the timings; taking the first line of each log snippet to be in sync (the same operation)

2/18 11:47:04.782 1f54 Params: >>> DataSequenceInOrder=Yes.
2/18 11:47:04.813 1bfc T[1,1]: session 0x1, connection 0x1 : end of stage 1, next stage 3.
2/18 11:47:04.813 1bfc C[1], IN_LOGIN: Event - LOGIN_ACCEPT.
2/18 11:47:04.813 1bfc C[1], LIN: T5.
2/18 11:47:11.842 1f54 C[1], LIN: recvData returned 10054
2/18 11:47:11.842 1f54 C[1], LIN: *** 'recv' thread: recv failed 10058.
2/18 11:47:11.842 1bfc Tgt: close 'iqn.2008-08.com.starwindsoftware:192.168.53.15-20g': 0 session(s) opened, 1 more allowed.

2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: iSCSI 0x1aa44 ignoring DataSequenceInOrder=Yes
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: iSCSI 0x1aa44 entering operational negotiation
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: iSCSI 0x1aa44 entering full feature phase
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: SCSI 0x1abe4 waiting for unit to become ready
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: SCSI 0x1abe4 unit is ready
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: Registered SAN device 0x80
2013-02-18 11:47:03 Kernel.Notice 192.168.53.155 .xclaimprojects.com ipxe: tftp://192.168.53.15/boot%5Cx86%5Cwdsnbp.com...Downloaded "boot\x86\wdsnbp.com"
2013-02-18 11:47:03 Kernel.Info 192.168.53.155 .xclaimprojects.com ipxe: ok
2013-02-18 11:47:03 Kernel.Notice 192.168.53.155 .xclaimprojects.com ipxe: Executing "boot\x86\wdsnbp.com"

Could this actually be that the iSCSI connection is being made (from the "Registered SAN device 0x80" and dropped as it goes back into the WDS part?

I am using WDSLinux to provide a PXE boot menu, I then use DHCP with the ipxe user class to provide "root path", and it then goes back to the WDSLinux menu

Cheers

Arne

[robinsmidsrod]

What is this WDSLinux thing you're talking about? I've never heard about it before...

And without a packet trace it is pure guessing, at this point.

Where exactly is it stopping in the boot sequence?

[ArneLovius]

WDSLinux :-)

http://www.syslinux.org/wiki/index.php/WDSLINUX