Skip to content
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

targetcli problem with normalize_wwn() in utils.py #139

Open
Aleksey-Maksimov opened this issue Sep 18, 2018 · 4 comments
Open

targetcli problem with normalize_wwn() in utils.py #139

Aleksey-Maksimov opened this issue Sep 18, 2018 · 4 comments

Comments

@Aleksey-Maksimov
Copy link

Hello

In rtslib/utils.py there is a function normalize_wwn():

def normalize_wwn(wwn_types, wwn):

There is a line checking WWN/WWPN here:

'naa': lambda wwn: re.match(r"naa\.[125][0-9a-fA-F]{15}$", wwn),

In my opinion, this line should be changed as follows:

'naa': lambda wwn: re.match("naa\.[0-9a-fA-F]{16}$", wwn),

Otherwise, the targetcli utility in Debian 9 has a problem.

This targetcli utility uses the package https://packages.debian.org/ru/stretch/python3-rtslib-fb, in which the normalize_wwn() function is called from the script /usr/lib/python3/dist-packages/rtslib_fb/utils.py

The targetcli utility checks WWPN when adding initiators in LIO.

Hyper-V virtual machines have a WWPN like "c003ff9bfee40008", "c003ff9bfee4000a" on Virtual FC HBA (connect to SAN via NPIV) ...

If we are trying to add Hyper-V VMs as the initiators in Debian 9 LIO via targetcli tool, we get the error “WWN not valid as: naa”

@maurizio-lombardi
Copy link
Collaborator

Thanks for the report, I am going to have a look and fix it.

@maurizio-lombardi
Copy link
Collaborator

naa': lambda wwn: re.match(r"naa.[125][0-9a-fA-F]{15}$", wwn),
In my opinion, this line should be changed as follows:
'naa':lambda wwn: re.match("naa\.[0-9a-fA-F]{16}$",wwn),

Hmmm, this would accept everything and probably is not the correct thing to do.
For example: if the first nibble is 0 the name is to be considered invalid,
0x7 - 0xb are reserved and we should print an error.
Probably the correct thing to do is to introduce support for "EUI-64 Mapped" ( 0xc to 0xf).

In other words, something like this (not tested):

'naa': lambda wwn: re.match(r"naa\.[125c-fC-F][0-9a-fA-F]{15}$", wwn)

@friedkiwi
Copy link

This might be a really old issue, but I've recently ran into the same issue when trying to export LUNs to my IBM mainframe. The WWN it uses is c05076d1c4001001.

'naa': lambda wwn: re.match(r"naa.[125c-fC-F][0-9a-fA-F]{15}$", wwn)

@maurizio-lombardi I can confirm that this works

@maurizio-lombardi
Copy link
Collaborator

@friedkiwi the reason I didn't push the change back then was because no one tested if it works or introduce any regression. Now that you are able to test this we can move this thing forward. If you want to submit a pull request just go for it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants