[CentOS] Possible to run iscsi-target and initiator on same server?

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.