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
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:0
On Apr 8, 2011, at 10:28 AM, Paul Koning wrote:
> On Apr 8, 2011, at 1:22 PM, Rustad, Mark D wrote:
>
>> Ulrich,
>>
>> On Apr 7, 2011, at 11:35 PM, Ulrich Windl wrote:
>>
>>> I just wonder how safe the code is:
>>>
>>> Doesn't the difference of two unsigned ints give an unsigned value? The
>>
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
add
On Apr 8, 2011, at 1:22 PM, Rustad, Mark D wrote:
> Ulrich,
>
> On Apr 7, 2011, at 11:35 PM, Ulrich Windl wrote:
>
>> I just wonder how safe the code is:
>>
>> Doesn't the difference of two unsigned ints give an unsigned value? The
>> assigning an unsigned int to a signed int will definitely
Ulrich,
On Apr 7, 2011, at 11:35 PM, Ulrich Windl wrote:
> I just wonder how safe the code is:
>
> Doesn't the difference of two unsigned ints give an unsigned value? The
> assigning an unsigned int to a signed int will definitely reduce the range...
Actually, that isn't true. There are 2^32 p
