Bad IPv6 address
Paul Koning
On my Linux system, when I have a connection to a target with IPv6, the address shown in /sys/class/iscsi_session/device/connection*/target_address is invalid. For example, I've seen fc00:00:00:00:10:127:137:101 which is not a valid address (wrong number of bytes).
I can work around this by padding each component to 4 bytes, but that seems like a kluge.
I see this in Linux 2.6.18 (RHEL5). Is this an old bug that's been fixed?
paul
Mike Christie
> I'm not sure if this is the right place to report this...
>
> On my Linux system, when I have a connection to a target with IPv6, the address shown in /sys/class/iscsi_session/device/connection*/target_address is invalid. For example, I've seen fc00:00:00:00:10:127:137:101 which is not a valid address (wrong number of bytes).
>
I do not think there is a target_address file. Is it address or
persistent_address?
What is wrong with the address? Are the zeros that got dropped leading
or trailing ones? I thought you could drop the leading ones according to
http://www.ietf.org/rfc/rfc2373.txt. The 00s are weird.
And if it is the persistent_address and you work at dell, do you work on
EQL targets? If so, could you take a trace of what the target is sending
the initiator during sendtargets discovery? The persistent_address just
prints out the string the target returned to us during discovery for the
portal's address.
Mike Christie
>What made me look at this is the fact that I was getting errors connecting to this address. But now that I'm trying it again, it works just fine. So it's clearly a false alarm, sorry about that.
>
Ah, if you are having problems it might be a bug or just laziness on the
iscsiadm side.
If the target passed us "fc00:00:00:00:10:127:137:101" but you passed in
"fc00:0000:0000:0000:0010:0127:0137:0101" to some iscsiadm commands it
might fail, because iscsiadm expects that you pass in the value you see
printed out of the iscsiadm node mode command. It is dumb and lazy with
ipv6 and just does strcmp and does not expand or simplify ipv6 addrs
when matching.
I will fix that up.
Paul Koning
On Apr 8, 2011, at 8:41 PM, Mike Christie wrote:
> On 04/08/2011 10:58 AM, Paul Koning wrote:
>> I'm not sure if this is the right place to report this...
>>
>> On my Linux system, when I have a connection to a target with IPv6, the address shown in /sys/class/iscsi_session/device/connection*/target_address is invalid. For example, I've seen fc00:00:00:00:10:127:137:101 which is not a valid address (wrong number of bytes).
>>
>
> I do not think there is a target_address file. Is it address or persistent_address?
Typo, I should have said persistent_address
>
> What is wrong with the address? Are the zeros that got dropped leading or trailing ones? I thought you could drop the leading ones according to http://www.ietf.org/rfc/rfc2373.txt. The 00s are weird.
Yes, it does look that way. The examples in RFC 3720 show omitted leading zeroes, too. What made me look at this is the fact that I was getting errors connecting to this address. But now that I'm trying it again, it works just fine. So it's clearly a false alarm, sorry about that.
> And if it is the persistent_address and you work at dell, do you work on EQL targets? If so, could you take a trace of what the target is sending the initiator during sendtargets discovery? The persistent_address just prints out the string the target returned to us during discovery for the portal's address.
Yes, I'm involved with EQL devices. I should be able to set up a capture. Then again, as I mentioned, it sure looks like I misinterpreted the data and the value there is actually fine.
paul
Paul Koning
On Apr 9, 2011, at 12:33 AM, Mike Christie wrote:
> On 04/08/2011 07:52 PM, Paul Koning wrote:
>> What made me look at this is the fact that I was getting errors connecting to this address. But now that I'm trying it again, it works just fine. So it's clearly a false alarm, sorry about that.
>>
>
> Ah, if you are having problems it might be a bug or just laziness on the iscsiadm side.
No, I was trying some other commands, like telnet or ping6, and must have made some dumb mistakes because it looked like I was having connectivity issues. Either that or my network was flaky. Nothing to do with iscsi after all.
paul