Re: Possible to run iscsi-target and initiator on same server?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Oct 12, 2009, at 12:48 PM, C Linus Hicks <linush@xxxxxxxxxxx> wrote:

> On Sun, 2009-10-11 at 17:14 -0400, C Linus Hicks wrote:
>
>> strace output:
>> ---
>> -------------------------------------------------------------------
>    ----- Cut a bunch of lines ----
>> socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 6
>> socket(PF_NETLINK, SOCK_RAW, 0)         = 7
>> bind(7, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
>> getsockname(7, {sa_family=AF_NETLINK, pid=28308, groups=00000000}, [137438953484 
>> ]) = 0
>> sendto(7, "\24\0\0\0\22\0\1\3\365\201\321J\0\0\0\0\0\0\0\0", 20, 0,  
>> {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
>> recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000 
>> }, msg_iov(1)=[{"\370\0\0\0\20\0\2\0\365\201\321J\224n 
>> \0\0\0\0\4\3\1\0\0\0I\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0,  
>> msg_flags=0}, 0) = 1004
>> recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000 
>> }, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\365\201\321J\224n 
>> \0\0\0\0\0\0\1\0\0\0I\0\1\0\0\0\0\0"..., 4096}], msg_controllen=0,  
>> msg_flags=0}, 0) = 20
>> sendto(7, "\24\0\0\0\26\0\1\3\366\201\321J\0\0\0\0\0\0\0\0", 20, 0,  
>> {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 20
>> recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000 
>> }, msg_iov(1)=[{"<\0\0\0\24\0\2\0\366\201\321J\224n 
>> \0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1"..., 4096}],  
>> msg_controllen=0, msg_flags=0}, 0) = 196
>> recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000 
>> }, msg_iov(1)=[{"@\0\0\0\24\0\2\0\366\201\321J\224n\0\0\n 
>> \200\200\376\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}],  
>> msg_controllen=0, msg_flags=0}, 0) = 192
>> recvmsg(7, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000 
>> }, msg_iov(1)=[{"\24\0\0\0\3\0\2\0\366\201\321J\224n 
>> \0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0"..., 4096}],  
>> msg_controllen=0, msg_flags=0}, 0) = 20
>> close(7)                                = 0
>> socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 7
>> ioctl(7, SIOCGIFHWADDR, {ifr_name="lo",  
>> ifr_hwaddr=00:00:00:00:00:00}) = 0
>> ioctl(7, SIOCGIFHWADDR, {ifr_name="eth2", ifr_hwaddr=00:1d: 
>> 92:b4:50:6e}) = 0
>> close(7)                                = 0
>> setsockopt(6, SOL_SOCKET, SO_BINDTODEVICE, "eth2\0", 5) = 0
>> setsockopt(6, SOL_TCP, TCP_NODELAY, [1], 4) = 0
>> setsockopt(6, SOL_SOCKET, SO_RCVBUF, [524288], 4) = 0
>> getsockopt(6, SOL_SOCKET, SO_RCVBUF, [4296015872], [4]) = 0
>> setsockopt(6, SOL_SOCKET, SO_SNDBUF, [524288], 4) = 0
>> getsockopt(6, SOL_SOCKET, SO_SNDBUF, [4296015872], [4]) = 0
>> fcntl(6, F_GETFL)                       = 0x2 (flags O_RDWR)
>> fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK)    = 0
>> connect(6, {sa_family=AF_INET, sin_port=htons(3260),  
>> sin_addr=inet_addr("10.200.1.6")}, 128) = -1 EINPROGRESS (Operation  
>> now in progress)
>> poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=0,  
>> events=0}], 3, 250) = 0 (Timeout)
>> poll([{fd=6, events=POLLOUT}], 1, 1)    = 0 (Timeout)
>  --------- Cut a bunch more lines --------
>
> I believe the problem is evident from the strace. He binds the  
> socket to
> eth2 based on querying the MAC address. That means he will only  
> receive
> packets on eth2 and since the network layer has determined that origin
> and destination are the same, it's passing the traffic across the
> loopback interface. Thus he will never see a response from the ietd
> daemon.
>
> If my interpretation is correct, then the two possibilities I see are
> that this is either a design restriction or a bug.

I don't understand why he was using external ip addresses for a  
loopback connection. He should just have used 127.0.0.1 in the  
iscsid.conf and allowed it in the initiators.allow and targets.allow  
and been done with it.

Nobody should bother with MAC addressing it's iSCSI not FCoE or ATAoE  
so MAC addresses are irrelevant, it can even run over P2P connections  
with no MAC addressing.

-Ross

_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux