-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does this work on OS X 10.12.3 - Sierra? Unable to get any targets... #89
Comments
Your target names: "iqn.com.sgmsys-10" and "iqn.com.sgmsys-11" are invalid names. iSCSI requires a date corresponding to when the naming authority was registered. For example, your initiator has an IQN: "iqn.1993-08.org.debian:01:6af387c68d" (with a date as shown in bold). The target needs to have the same format. I'm surprised it works with any initiator, as it is a violation of the iSCSI specification. |
I tried the following with the same errors: iqn.1998-01.com.sgmsys Windows shows the unit providing the following with only the above configured in Areca: and the same shows up in Debian (Jesse) and RHEL 7 with iscsiadm. I do not have, nor receive the hex string after the colon after the target. I'm sure this is just to make the target unique. The Areca 5040 unit web interface is very vague. It does not show the full names. I have to go to Win or Nix and use discovery to display all the target names from the unit. I understand the devs are following a standard, but it would be nice to 'loosen' the naming convention for obvious reasons (even if it were a custom setting in a .config). I can use the same 'non-standard' naming conventions on my QNAP iSCSI as well, and the QNAP sees and connects with the Areca over iSCSI when configured to do so without the name issue mentioned. Any other information or Mac utilities (prefer terminal) would be greatly appreciated. V/r, |
iqn.1998-01.com.sgmsys,192.168.0.1:3260 iscsictl: The specified target name is not a valid IQN or EUI-64 identifier. . . Any other ideas? V/r, |
It looks like the ':' is also required at the moment. So this for example
should work:
iqn.1998-01.com.sgmsys:target0
Since the colon is optional per RFC3721, we'll remove that from the
validation code in the next build. The date has to stay though.
…On Wed, Apr 12, 2017 at 8:28 AM, n0nuf2 ***@***.***> wrote:
iqn.1998-01.com.sgmsys,192.168.0.1:3260
iscsictl: The specified target name is not a valid IQN or EUI-64
identifier. . .
Any other ideas?
V/r,
n0nuf
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#89 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AEH_Qz7btSaSOSFlz0Pu774NGAOHLPdvks5rvBqUgaJpZM4M5lIO>
.
|
######### Raid Set IDE Channels Volume Set(Ch/Drv#) Volume State Capacity FYI: target0 is a single disk, target1 is 2-disk RAID1, target2 is 4-disk RAID5. ######### iscsictl add discovery-portal 192.168.0.9 ######### iscsictl list targets ######### iscsictl list target-config iqn.1998-01.com.sgmsys-09:target0 ######### iscsictl login iqn.1998-01.com.sgmsys-09:target0,192.168.0.9:3260 So, with that information, are you able to guide me further? Windows and Nix still see them, mount them, and can use them. Can you help me get these usable in OS X Sierra? Thank you for your time. V/r, |
Here's a snippet from the system.log: Apr 10 18:10:09 n0nufs-Mac-mini com.apple.xpc.launchd[1] (com.github.iscsi-osx.iscsid[1542]): Service exited with abnormal code: 35 |
Use Wireshark to capture the traffic between your machine and the NAS when you connect. After you see the "initiator error" stop the capture and post it here. Are you saying that globalSAN doesn't connect either? |
Hello. iqn.1998-01.com.sgmsys:target1 <inactive, static> iscsictl login iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 iscsictl logout iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 . . . Commands used are: iscsictl add discovery-portal 192.168.0.6 iscsictl add target iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 iscsictl login iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 iscsictl logout iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 iscsictl remove target iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 iscsictl modify discovery-config -SendTargets disable Does this further assist your in determining what is going on? Information appreciated, Thank you. V/r, |
Try the attached build and let me know if that works out (change .ZIP extension to .DMG and install as usual) |
GE (good evening). I am downloading now. I will uninstall previous version before installing. I just saw that you asked: "Are you saying that globalSAN doesn't connect either?" globalSAN would work for a bit and then crash. Didn't matter which SAN/NAS I attached. Same results. Soon as I start moving large amounts of data it was done. Since going to Sierra, it is just throwing a class error and won't start. I stopped wasting time on it. It was an expensive "sure, that's nice, but now what..." that isn't reliable for me on my system(s). Everything works fine on Windows/Linux/BSD, so I know my hardware is operational. Will post results. Thank you for your assistance. V/r, |
I would caution you with the logic of "It works in Windows/Linux/BSD..." so therefore it must not be your target. There are a number of non-compliant targets out there, and quite a few initiators that have "relaxed" their protocol in order to work with all of the stuff out there. For instance, globalSAN has a "always send session" option which technically shouldn't be required by the standard -- some targets are fussy and so globalSAN included that option. We've already seen one instance - namely target naming - where your target didn't stick to the standard. So please try to keep an open mind as we move forward and we'll fix the actual problem. |
One more thing -- the Wireshark data you posted -- that data did not show login at all. It only showed discovery activity. Based on that I fixed an issue, which may be occurring during login also. However, it may still not work. In which case, please post a Wireshark capture that includes login. I would suggest starting the capture, login, then stop capture. Thanks. |
Also, I keep getting a bunch of "Permission Denied" messages as user or as root. Is there a clear or clean command? Only way to get rid of this is to shut SAN and MAC down and then bring them back up. Last login: Thu Apr 27 22:10:45 on console n0nufs-Mac-mini:~ n0nuf$ iscsictl add target iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 n0nufs-Mac-mini:~ n0nuf$ iscsictl login iqn.1998-01.com.sgmsys-09:target0,192.168.0.6:3260 WireShark: Frame 2762: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits) on interface 0 Still nothing to connect to. V/r, |
Try removing the configuration file and see if the permissions issue goes away. rm /Library/Preferences/com.github.iscsi-osx.iSCSIInitiator.plist Also, you don't have to add/remove targets each time. You can either add them manually, or let discovery add them for you. It's described in the Wiki. |
After some fiddling, I was able to get 2 LUNs found and attached. Several issues with that. Got them reformatted and began transferring data to one of them. Then KP. Dump below: Anonymous UUID: B843F51F-D6B2-B550-571B-EC80E15578E6 Sun Apr 30 23:25:16 2017 *** Panic Report *** Backtrace (CPU 0), Frame : Return Address BSD process name corresponding to current thread: kernel_task Mac OS version: Kernel version: System uptime in nanoseconds: 5087345649782 I have a pcap file but it is 35MB zipped. Will have to try to split is or start over to get this to you as github only allows 10MB. These are the commands and responses that I was using . Still have a lot of permission denied. V/r, |
GE nsinenian: I have only captured the login/out packets and have attached that pcap to this post. The commands at the bottom are the commands that I have run to connect to storage. Notice that I did NOT use the :target0 (colon) parameter. I believe you allowed this to be omitted in the code you posted for me to try. Transfer rate on a 1Gbps wire (eth) connection is about 1GB per minute. I did have to install/remove the pkg several times as I was experimenting as well as use launchctl unload -w /Library/LaunchDaemons/com.github.iscsi-osx.iscsid.plist to kill the process at one point as it killed Finder. I have also included a screenshot of Areca 5040 RAID config in case it is helpful. I deleted 3 volumes and created a single 8TB RAID5 (7TB usable) volume for this test. I was able to Partition/Erase the new drive as exFAT 7TB successfully (I don't believe the array understands NIX/MAC partitions). On a 8GB file, I was able to xfer 3.54 GB before the transfer died at 3.54GB. The process is currently locked up and I will have to deal with it again IOT cancel it. Where do we go from here to troubleshoot? V/r, ===
|
BTW. Apologize for formatting. Don't know why plain text is getting set to large/bold. V/r, |
Also, appears the amount of data transferred is random before it dies. This time died at 39MB. |
Ok, so now your issue seems to be similar to #83 . A handful of people are experiencing this (as far I know) but we have not been able to determine why. I have a suspicion based on the kernel crash logs you posted, so please try the attached build and let me know if you still experience crashes (change extension to DMG and install as before). |
It appears the new code will successfully connect to multiple iSCSI devices: iscsictl add target iqn.1998-01.com.sgmsys-09,192.168.0.16:3260 iscsictl add target iqn.2004-04.com.qnap:ts-870pro:iscsi.qnap.e0c776,192.168.0.6:3260 Even deleting the plist file, I still get 'permission denied' occasionally until I power cycle all the Mac. And, the process of copying files often causes the system to Panic using either device. Using iscsiadm from Debian Linux 8.5 VM on the Mac, I was able to move 15+ TB to the devices successfully. What can I do now? V/r, |
The two problems you cite are known issues. I'm closing this thread -- please follow #87 and #83 for more information on updates. For the system panic, it appears to be in some cases related to sleep --- if you can disable sleep on your machine and re-try the transfer, let us know if the panics stop at #83 |
iSCSI device is ARECA 5040. Works fine with all Linux and Windows. Need initiator to work on Mac. Turned off SIP and ran csrutil disable. Only thing that seems to work is dynamic discovery via IP, and then nothing. No response/No output.
Debian reports login to iqn.com.sgmsys-10, portal: 192.168.x.x successful.
None of the commands on iscsictl report anything except "... is not a valid IQN or EUI-64 Identifier".
I've installed from: iSCSIInitiator-1.0.0-beta5.dmg that I downloaded yesterday.
All of these commands (replaced with my info work on Debian, yes, a different OS):
Install iSCSI Initiator on your system
apt install -y open-iscsi
Find your Initiator IQN
cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1993-08.org.debian:01:6af387c68d
Discover targets on 10.0.0.44
iscsiadm -m discovery -t sendtargets -p 10.0.0.44
10.0.0.44:3260,1 iqn.1992-04.com.emc:cx.apm00240108337.a0
Confirm iSCSI status
iscsiadm -m node -o show
Login to target
iscsiadm -m node --login
Logout of target
iscsiadm -m node --logout
Confirm active session
iscsiadm -m session -o show
Examine available partitions
fdisk -l
So, is this package not complete to establish a connection to iSCSI and then attach and use the storage? Am I missing something? Had bought GlobalSAN, but that was an expensive waste as it continuously failed and now don't run. I've gotta be missing something. I can use this functionality on every other OS. As you know, these are your commands that come up:
Usage: iscsictl add target , [-interface ]
iscsictl remove target [,]
I have 2 LUNs: iqn.com.sgmsys-10 and iqn.com.sgmsys-11.
Assistance/help appreciated.
V/r,
n0nuf
The text was updated successfully, but these errors were encountered: