Jump to content
SNS Users' Forums
  • Announcements

    • Eric Newbauer

      Follow SNS on Twitter!

      Get notifications via Twitter! Looking for instant updates? We're now also announcing new versions and beta programs via Twitter. Follow Studio Network Solutions on Twitter. Thanks!

Recommended Posts

Just updated my working OS X 10.6.4/globalSan 4.0.204 driver to this new 4.1 beta and I can no longer connect. Getting this error:

Code E3FF8207. Missing some required parameters. Please check the error detection and authentication parameters.

First installed the 4.1 beta over the 4.0.204 and rebooted. Got same message. Then uninstalled 4.1 Beta, uninstalled 4.0.204 (via their respective uninstallers), rebooted and reinstalled 4.1 beta. Rebooted.

No luck.

Rebooted my Synology 410J with the iScsi-target, changed authentication from none to password, and back again.

Target is set up with header error detection. Tried without. Always same error.

Still unable to connect. Wired and wireless.

Any suggestions? Before reverting to 4.0.204

Share this post


Link to post
Share on other sites

I am working from a ordinary user account. No admin priviliges, but I was asked for an admin account and password during the install.

Is there a difference installing from ordinary user account and admin account if I authenticate with an admin account from my usual account??

Share this post


Link to post
Share on other sites

Please check to see if you have some leftover preferences files -- you may have several. Check in /Library/Preferences/ for files that look like com.sns.globalSAN.plist or iSCSIConfig.plist

Share this post


Link to post
Share on other sites

Just uninstalled all files on my mac with sns in filename. Used terminal command "find / -iname *sns*" and a program called Find Any File (as root).

This after running unistallers for both 4.1 beta and 4.0.204. Emptying trash before rebooting.

Then logging in as administrator, installing 4.1 beta, rebooting. Same error. Uninstalling everything again. Rebooting.

Then installing 4.0.204 from ordinary user account and rebooting. Voila, iScsi-target reappearing.

All I could find in /var/log/kernel.log was:

kernel[0]: GLO Warning: Error 32 while receiving BHS.
kernel[0]: GLO Warning: Receiving thread has stopped with error 32.

On 4.0.204 now, works fine.

Did quite a few installs and reboots for this 4.1 without success. If you have any suggestions I could try to troubleshoot. But since I'm at UTC+1 it's going to be a few hours until next time..

Share this post


Link to post
Share on other sites

Same error here.

Started by uninstalling 4.0 with the 4.0 uninstaller and then installing 4.1.

Preferences were retained even though I specified not. I deleted them both through preferences and via the command line but the error persists.

Share this post


Link to post
Share on other sites

Me too!

I've had trouble with hangs using 4.0 (204) on one machine, so I was excited to see 4.1 Beta announcement, but I'm running into the same issues others are describing. I've also tried the 4.1 BETA on a different machine that never had any previous version of globalSAN iSCSI Initiator on it, so it's not left over prefs that's causing it.

These are the kernel logs I'm seeing

Nov 7 09:37:16 themacbook kernel[0]: GLO Warning: Error 32 while receiving BHS.

Nov 7 09:37:16 themacbook kernel[0]: GLO Warning: Receiving thread has stopped with error 32.

The user-facing error is:

Code E3FF8207. Missing some required parameters. Please check the error detection and authentication parameters.

FWIW, I compared the plist with a plist from another machine with 4.0 that's able to connect (I still get hangs connecting from that machine, but it connects without incident which is further than I'm getting with 4.1 Beta 264) and other than the UUID for the target (which I assume to randomly generated when the target is added to the prefs pane) they're identical.

I'm wondering... sort of thinking aloud... has anyone outside SNS gotten 4.1 beta to work? Is it possible there's some file that's missing from the beta installer?

Jour

Share this post


Link to post
Share on other sites

For those of you who have posted and haven't specified what kind of target you're using, could you please let us know?

Also, we've switched to a different iSCSI naming convention, which may be causing some of the problems. (It's possible that the target isn't yet ready for the naa identifier.) Please try this and let us know your results:

In globalSAN's preference pane, where you see your Initiator Name:

1. Replace the naa prefix with the eui prefix

2. Remove last 16 symbols in the naa identifier:

For example, if your naa identifier looks like:

naa.0bd23d26d76a491895f4b102ed579ecc

Use the identifier:

eui.0bd23d26d76a4918

Share this post


Link to post
Share on other sites

Eric,

I am not sure what you mean by "naa identifier".

To start from scratch I did the following:

1) Uninstalled (Full uninstall), rebooted, no "globalSAN iSCSI" visible in System Preferences. OK.

2) Installed the beta, rebooted, now "globalSAN iSCSI" is visible in System Preferences. OK.

3) Click "globalSAN iSCSI" to show the settings

4) Click unlock which lets me enter my administrator password

5) Now the initiator prompts me with "Warning! The Initiator Name is blank, which...".

6) If I click generate I get an id like "naa.7c46...". Is it important to generate or can I just use a name like "MyMac"?

7) I follow your instructions and changed naa to eui and also I skipped the last 16 characters, my id now reads "eui.7c4611b1e1aa4589".

8) After accepting the identifier name the dialog locks so I have to click unlock again and enter my admin password.

9) Click "+" and "Portal, enter the ip for my QNAP NAS, click Add. The pane on the left correctly find my three available targets (all disconnected).

10) Choose one of the targets, and enter an alias name. Is the syntax impoortant? I use "MyPhotos". As error detection I use "Header only (recommended)". No authentication.

11) Mark the address and click Connect. Connection error like all others in this topic.

What else can I do? (Except going back to the earlier version). Can I supply you with more information to help pinpointing the problem?

I have the latest updates for Mac OS X (10.6.4), and also for my NAS (QNAP TS-439II PRO). The Mac is a Macmini3.1 (Late 2009). 2.66 GHz CPU and 8 GB RAM.

/QForestMan

Share this post


Link to post
Share on other sites

Hmmmm. OK, so we've had quite a large number of people download the 4.1 beta over the last few days, and aside from this thread the board's been pretty quiet. So far, we know that the Synology 410J and the QNAP TS-439II PRO are affected, though maybe not in all cases are those targets having trouble.

Anyone else?

If you're having the trouble described in this thread, you can help us analyze the problem by doing the following:

  1. Open the Terminal application.
  2. Start the command:
    sudo tcpdump -i en0 -s 0 -W /globalsan.dump
    (Please note, that you need to be logged in under an administrative account and you will need to provide your password when prompted.)
  3. From the globalSAN Preference Pane, try to connect to your target.
  4. After the error message is displayed that the target cannot be connected, press Ctrl+C in the Terminal window.
    After these steps, the globalsan.dump file will be created in the root of your drive.
  5. Attach that file in a new email. In your email, provide the following information:
    • This thread's URL
    • Your target's mfr and model and firmware version
    • Version of OS X
    • 32 or 64-bit mode

[*] Send the email with attachment and all required information to iscsi@studionetworksolutions.com

You may also want to appeal to the manufacturer of your target to enlist their help in resolving such problems. We've worked with other manufacturers who have connected with us on past issues...

Share this post


Link to post
Share on other sites

Tried the eui change, no luck, sent the email with the network dump.

Hmmmm. OK, so we've had quite a large number of people download the 4.1 beta over the last few days, and aside from this thread the board's been pretty quiet. So far, we know that the Synology 410J and the QNAP TS-439II PRO are affected, though maybe not in all cases are those targets having trouble.

Anyone else?

If you're having the trouble described in this thread, you can help us analyze the problem by doing the following:

  1. Open the Terminal application.
  2. Start the command:
    (Please note, that you need to be logged in under an administrative account and you will need to provide your password when prompted.)
  3. From the globalSAN Preference Pane, try to connect to your target.
  4. After the error message is displayed that the target cannot be connected, press Ctrl+C in the Terminal window.
    After these steps, the globalsan.dump file will be created in the root of your drive.
  5. Attach that file in a new email. In your email, provide the following information:
    • This thread's URL
    • Your target's mfr and model and firmware version
    • Version of OS X
    • 32 or 64-bit mode

[*] Send the email with attachment and all required information to iscsi@studionetworksolutions.com

You may also want to appeal to the manufacturer of your target to enlist their help in resolving such problems. We've worked with other manufacturers who have connected with us on past issues...

Share this post


Link to post
Share on other sites

All,

We have provided an updated build to a handful of users who have provided a TCP dump, and we're waiting for their feedback to let us know if the problem is resolved.

From what we can infer on the forum, the scope of this problem is extremely narrow. Again, if you're having problems with this beta (or even if you're not having problems with this beta!) we need your information to help us understand and resolve this issue more quickly.

Thanks!

Share this post


Link to post
Share on other sites

FYI: Seeing an identical problem trying to access my Netgear ReadyNAS device.

I'll try to forward the tcpdump over the weekend.

Update: TCP Dump report sent as requested

Hmmmm. OK, so we've had quite a large number of people download the 4.1 beta over the last few days, and aside from this thread the board's been pretty quiet. So far, we know that the Synology 410J and the QNAP TS-439II PRO are affected, though maybe not in all cases are those targets having trouble.

Anyone else?

If you're having the trouble described in this thread, you can help us analyze the problem by doing the following:

  1. Open the Terminal application.
  2. Start the command:
    (Please note, that you need to be logged in under an administrative account and you will need to provide your password when prompted.)
  3. From the globalSAN Preference Pane, try to connect to your target.
  4. After the error message is displayed that the target cannot be connected, press Ctrl+C in the Terminal window.
    After these steps, the globalsan.dump file will be created in the root of your drive.
  5. Attach that file in a new email. In your email, provide the following information:
    • This thread's URL
    • Your target's mfr and model and firmware version
    • Version of OS X
    • 32 or 64-bit mode

[*] Send the email with attachment and all required information to iscsi@studionetworksolutions.com

You may also want to appeal to the manufacturer of your target to enlist their help in resolving such problems. We've worked with other manufacturers who have connected with us on past issues...

Share this post


Link to post
Share on other sites

With the new build I was able to discern a configuration error from the now useful error messages and successfully make a connection. But after several hours the connection unexpectedly dies. It cannot be disconnected or reconnected at that point. Seems to be about the same issue as always.

Share this post


Link to post
Share on other sites

I logged in to my Syno DS410J via ssh and dumped the /var/log/messages. When trying to connect (as I did starting this string, top post) I could see in this log that my Syno gave the following error:

Nov 13 18:27:29 kernel: [ 5743.580000] SessionType key not received in first login request.
Nov 13 18:27:29 kernel: [ 5743.580000] iSCSI Login negotiation failed.
Nov 13 18:27:29 kernel: [ 5743.590000] iSCSI Login negotiation failed.

Same setup, no passwords, only header error correction.

Seems like the globalSAN connector may not be sending the sessiontype key?

Share this post


Link to post
Share on other sites

With the new build I was able to discern a configuration error from the now useful error messages and successfully make a connection. But after several hours the connection unexpectedly dies. It cannot be disconnected or reconnected at that point. Seems to be about the same issue as always.

Any change? If this happens again and the connected LUN is visible in Finder, please try ejecting it and then re-connecting the LUN in globalSAN. Please let us know if you were able to force eject the drive.

Share this post


Link to post
Share on other sites

Any change? If this happens again and the connected LUN is visible in Finder, please try ejecting it and then re-connecting the LUN in globalSAN. Please let us know if you were able to force eject the drive.

The drive disappears from finder when the connection faults and the connection gets a little yellow circle in the preferences pane.

Share this post


Link to post
Share on other sites

I installed globalSAN-4.1.0.247-101110-171745, and at first it seemed to work, i.e. I could connect and also read/write small files to the iSCSI disk. Copying my 83 GB iPhoto library also went well (at least no error reports). However, iPhoto'09 could not open the library on the iSCSI disk. After that Finder hangs and my only option is to actually do a hard reboot (holding the power button and then restart).

When I was up and running again, I could see my two iSCSI drives in Finder. If I click on the one that only contained small files I could see the contents and also do som reading/writing.

However when I click on the iSCSI drive with the large iPhoto library Finder again HANGS! Once again restating the hard way.

That leads me to suspect that the driver now has messed things up with the iSCSI drive. I have not yet tried to reformat the drive, but it seems as the only solution. At some time I could also see the yellow dot in System Settings, however Finder was still dead, so NO, I could NOT eject the drive.

Any new versions to test? Should I try reformat and see what happens? (thankfully I did more than one backup of the drive before testing)

/QForestMan

Share this post


Link to post
Share on other sites

Hi.

I installed globalSAN-4.1.0.247 and I could connect to my iscsi target.

This version will be fully tested at the weekend.

EDIT: Target is a Synology NAS DS209 , using DSM 3.0-1354.

Greetz

Jas

Share this post


Link to post
Share on other sites

Hi.

Target is a Synology NAS DS209 , using DSM 3.0-1354.

Short test seems to be successful, copying several smaller files to the target and opening them works fine.

Long run tests @ the weekend. :)

Thx for your work!

Greetz

Jas

Share this post


Link to post
Share on other sites

Hi Eric,

as already pointed out in my other thread, Solaris/OpenSolaris/OpenIndiana COMSTAR doesn't work with 4.1 (247) due to an invalid request at login. I have searched a bit for the parameters that COMSTAR wouldn't negotiate to anything other than the iSCSI specs defaults and found this on the OSol storage-discuss forum:

We allow ImmediateData=yes, but not InitialR2T=yes. This means that the only kind of "unsolicited first burst" we support is the Immediate Data in the SCSI WRITE command PDU itself.

We only allow MaxConnections=1, i.e. there is no support for multiple connections per session (MC/S) at this time.

We will negotiate only for DataPDUInOrder=yes

We only negotiate for ErrorRecoveryLevel=0

We only negotiate for MaxOutstandingR2T=1.

As far as I could see, GlobalSAN 4.1 (247) does send a DataPDUInOrder=No to the target, which might be the reason for not being able to log in. I know that I already sent you this via e-mail, but maybe this is also of interest for others, so I will just post what GlobalSAN 4.0 (204) and GlobalSAN 4.1 (247) will send to the target upon login:

GlobalSAN 4.1 (247)

InitiatorName=iqn.2010-06.de.stephanbudach:mosx
SessionType=Discovery
AuthMethod=None
InitialR2T=Yes
MaxConnections=1
ImmediateDate=Yes
MaxOutstandingR2T=1
DataPDUInOrder=No
DataSequenceInOrder=Yes
ErrorRecoveryLevel=0
MaxRecvDataSegmentLength=65536
MaxBurstLength=262144
FirstBurstLength=262144
DefaultTime2Wait=0
DefaultTime2Remain=0
OFMArker=No
IFMarker=N0
HeaderDigest=None
DataDigest=None

=> Login Response: invalid request during login

GlobalSAN 4.0 (204)

HeaderDigest=CRC32, None
DataDigest=CRC32, None
SessionType=Discovery
InitiatorName=iqn.2010-06.de.stephanbudach:mosx
DefaultTime2Wait=0
DefaultTime2Remain=0
ErrorRecoveryLevel=0

=> Login Response: Success

Why not keeping it simple and stick with the iSCSI spec defaults - I guess that this would provide the best interoperability with all kinds of iSCSI targets.

On the other hand, the reasons for these additional requests in 247 were added to gain more performance specifically from your own storage products and no one could argue against that, but it would be really nice, if you could then make these optimizations configurable.

Cheers,

budy

P.S. Another quick test with GlobalSAN 4.1Beta (246) shows that the lack of the AuthMethod=None request in the login command, leads to a successful login into the portal and that the target could be connected. The overall speed though was disappointing.

Edited by budy

Share this post


Link to post
Share on other sites

Hi there,

FYI

Using QNAP TS-410 Version 3.3.6 build 1109T with 4.1.0.247 BETA under 10.6.5 x64

QNAP was added as a portal with two targets sharing the same IP, header CRC. Using friendly initiator naming naa.something-something (minus included). Targets set persistent.

Experienced several system-wide hangs during CPU-intensive tasks (x64 apps) only hard reboot helped.

Disabled for a while as need finish the project, will try again.

Let me know if there is any particular test needed.

Arseny

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×