milo wong | 25 May 09:58 2015
Picon

Can anybody tell me how do we force a login redirect in software array TGT?

I have already acknowledged the way to config a login redirect in TGT as below:

tgtadm --op update --mode target --tid 1 --name RedirectAddress --value 10.76.0.30
tgtadm --op update --mode target --tid 1 --name RedirectPort --value 3260
tgtadm --op update --mode target --tid 1 --name RedirectReason --value Temporary
tgtadm --op show --mode target --tid 1
RedirectAddress=10.76.0.30
RedirectPort=3260
RedirectReason=Temporary

But I don't know how to make it do that redirect in my testing, really needs help here.

Thank you in advance!

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
justopeniscsi | 23 May 09:53 2015

ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery

    Hello open-iscsi members,
          now  I meet the question,  this  question  log  is below:
May 23 15:21:24 linuxhost kernel: connection14:0: detected conn error (1021)
May 23 15:21:24 linuxhost kernel: connection14:0: detected conn error (1021)
May 23 15:21:25 linuxhost iscsid: Kernel reported iSCSI connection 14:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
May 23 15:21:25 linuxhost iscsid: Kernel reported iSCSI connection 14:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)
May 23 15:21:28 linuxhost iscsid: connection14:0 is operational after recovery (1 attempts)May 23 15:21:28 linuxhost iscsid: connection14:0 is operational after recovery (1 attempts)
May 23 15:21:57 linuxhost kernel: connection12:0: detected conn error (1021)  

       my test environment: 
                    target :   system: Red Hat Enterprise Linux Server release 6.4     target driver:  stgt 1.0.55
                    initiator:    system:  Red Hat Enterprise Linux Server release 6.4
       my test tools:
                    fio
       now I have changed below iscsi config
                change  node.session.cmds_max = 128          to      node.session.cmds_max = 32

                   change     node.session.queue_depth = 32        to      node.session.queue_depth = 8

                   change     scsi device timeout,                             echo  300  > /sys/block/sdm/device/timeout

        but  the error still  happen

                  I should how to resolve this question?

       

        Thanks in advance and regards



--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Christian Seiler | 21 May 20:41 2015
Picon

[PATCH] Fix small typo in iscsid.conf

Hi there,

I've recently started co-maintaining the open-iscsi package in Debian
and was going through the list of bugs in Debian's bugtracker.

I'm attaching a patch to fix a small typo in iscsid.conf. The original
bug report can be found under:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=627908
(I set the git author of the attached patch to be the reporter of the bug.)

Christian

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Ancoron Luciferis | 7 May 14:06 2015

Reconnects and I/O errors with Synology iSCSI targets

Hi,

I currently have some trouble with LUNs exposed by Synology boxes.

As of Linux kernel 3.19, the max_sectors_kb value always is 32767 for
any LUN, which results into errors on the Synology target side and
reconnects on the Linux initiator side:

On the Synology target:

iSCSI: Unable to allocate memory for iscsi_cmd_t->iov_data.
iSCSI: iSCSI: Close -
I[iqn.1993-08.org.debian:01:99bdf6552818][192.168.xxx.78],
T[iqn.2000-01.com.synology:yyy.mylun.7e92dd8012]
iSCSI: iSCSI: Single CHAP security negotiation completed sucessfully.
iSCSI: iSCSI: Login -
I[iqn.1993-08.org.debian:01:99bdf6552818][192.168.xxx.78],
T[iqn.2000-01.com.synology:yyy.mylun.7e92dd8012][192.168.xxx.91:3260]

On the Linux initiator side:

Kernel reported iSCSI connection 4:0 error (1020 -
ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)
connection4:0: detected conn error (1020)
iscsid: connection4:0 is operational after recovery (1 attempts)

In some cases, e.g. when stacking a LUN with LUKS encryption, I also see
a lot of I/O errors at the client side (in this example, I created an
ext3 file-system on it):

sd 11:0:0:1: [sdj] UNKNOWN(0x2003) Result: hostbyte=0x0e driverbyte=0x00
sd 11:0:0:1: [sdj] CDB: opcode=0x2a 2a 00 00 00 1a 00 00 1e 08 00
blk_update_request: I/O error, dev sdj, sector 6656
Buffer I/O error on dev dm-0, logical block 64, lost async page write
Buffer I/O error on dev dm-0, logical block 65, lost async page write
Buffer I/O error on dev dm-0, logical block 66, lost async page write
Buffer I/O error on dev dm-0, logical block 67, lost async page write
Buffer I/O error on dev dm-0, logical block 68, lost async page write
Buffer I/O error on dev dm-0, logical block 69, lost async page write
Buffer I/O error on dev dm-0, logical block 70, lost async page write
Buffer I/O error on dev dm-0, logical block 71, lost async page write
Buffer I/O error on dev dm-0, logical block 72, lost async page write
Buffer I/O error on dev dm-0, logical block 73, lost async page write
sd 11:0:0:1: [sdj] UNKNOWN(0x2003) Result: hostbyte=0x0e driverbyte=0x00
sd 11:0:0:1: [sdj] CDB: opcode=0x2a 2a 00 3e 78 c5 50 00 40 00 00
blk_update_request: I/O error, dev sdj, sector 1048102224
...
buffer_io_error: 6835 callbacks suppressed

I suspect this is due to the fact that the Synology target does not
present any meaningful block limits, e.g.:

# sg_vpd -p bl /dev/sdj
Block limits VPD page (SBC):
  Write same no zero (WSNZ): 0
  Maximum compare and write length: 0 blocks
  Optimal transfer length granularity: 0 blocks
  Maximum transfer length: 0 blocks
  Optimal transfer length: 0 blocks
  Maximum prefetch length: 0 blocks
  Maximum unmap LBA count: 0
  Maximum unmap block descriptor count: 0
  Optimal unmap granularity: 0
  Unmap granularity alignment valid: 0
  Unmap granularity alignment: 0
  Maximum write same length: 0x0 blocks

What bothers me most is that "Maximum transfer length" is set to zero,
which from my understanding of the spec means that no limits apply,
hence the Linux initiator is correctly not applying any limit here.

However, at the target side, I can see the following limits:

For block-level LUNs:
# cat /sys/kernel/config/target/core/.../attrib/hw_max_sectors
128
# cat /sys/kernel/config/target/core/.../attrib/max_sectors
128

...and for file-level LUNs:
# cat /sys/kernel/config/target/core/.../attrib/hw_max_sectors
1024
# cat /sys/kernel/config/target/core/.../attrib/max_sectors
1024

According to a sector size of 512 bytes, I should be safe with 64
respectively 512 for the value of max_sectors_kb. I have tested
extensively with heavy load and different scenarios (e.g. formatting,
iozone single and multi-threaded tests) that after lowering that value
on the initiator side seems to resolve the problem.

However, while testing I also came up with the following limits for
max_sectors_kb:

fileio: 4096
iblock: 512

...which to me does not make much sense, except if the sector size would
be 4096, which it isn't (at least not reported):
$ cat /sys/block/sdj/queue/hw_sector_size
512

So, I am puzzled. Can someone help me making sense out of this?

Btw., the DI VPD of the LUNs are:

# sg_vpd -p di_lu /dev/sdj
Device Identification VPD page:
  Addressed logical unit:
    designator type: NAA,  code set: Binary
      0x600140520cc460dd155ed32b5db631d3
    designator type: T10 vendor identification,  code set: ASCII
      vendor id: SYNOLOGY
      vendor specific: iSCSI Storage:20cc460d-155e-32b5-b631-3e5d006efbd2
    designator type: Logical unit group,  code set: Binary
      Logical unit group: 0x0

Is there a way to _configure_ attributes for specific SCSI devices?

Thanx for any help! :)

Regards,

	Ancoron

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Johannes Thumshirn | 11 May 13:38 2015
Picon

[PATCH] iscsiuio: Fix lookup of IPv6 router address

When iscsiuio performs a lookup in it's routing table
for the default router, nothing is returned as ndpc_request()
didn't understand the 'GET_DEFAULT_ROUTER_ADDR' request.
The solution is to add the request and return the default router
address.

Signed-off-by: Johannes Thumshirn <jthumshirn@...>
---
 iscsiuio/src/uip/ipv6_ndpc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/iscsiuio/src/uip/ipv6_ndpc.c b/iscsiuio/src/uip/ipv6_ndpc.c
index 62d1c21..8422d7e 100644
--- a/iscsiuio/src/uip/ipv6_ndpc.c
+++ b/iscsiuio/src/uip/ipv6_ndpc.c
 <at>  <at>  -413,6 +413,9  <at>  <at>  int ndpc_request(struct uip_stack *ustack, void *in, void *out, int request)
 			(struct ipv6_addr *)((struct ndpc_reqptr *)in)->ipv6,
 			(struct mac_address *)((struct ndpc_reqptr *)in)->eth);
 		break;
+	case GET_DEFAULT_ROUTER_ADDR:
+		ipv6_get_default_router_ip_addrs(ipv6c, *(struct ipv6_addr **)out);
+		break;
 	case GET_HOST_ADDR:
 		*(struct ipv6_addr **)out = ipv6_find_longest_match(ipv6c,
 							(struct ipv6_addr *)in);
-- 
2.3.7

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Chris Leech | 14 May 00:12 2015
Picon

[RFC PATCH 0/4] Make iSCSI network namespace aware

I've had a few reports of people trying to run iscsid in a container, which
doesn't work at all when using network namespaces.  This is the start of me
looking at what it would take to make that work, and if it makes sense at all.

The first issue is that the kernel side of the iSCSI netlink control protocol
only operates in the initial network namespace.  But beyond that, if we allow
iSCSI to be managed within a namespace we need to decide what that means.  I
think it makes the most sense to isolate the iSCSI host, along with it's
associated endpoints, connections, and sessions, to a network namespace and
allow multiple instances of the userspace tools to exist in separate namespaces
managing separate hosts.

It works well for iscsi_tcp, which creates a host per session.  There's no
attempt to manage sessions on offloading hosts independently, although future
work could include the ability to move an entire host to a new namespace like
is supported for network devices.

This is only about the structures and functionality involved in maintaining the
iSCSI session, the SCSI host along with it's discovered targets and devices has
no association with network namespaces.

These patches are functional, but not complete.  There's no isolation enforced
in the kernel just yet, so it relies on well behaved userspace.  I plan on
fixing that, but wanted some feedback on the idea and approach so far.

Thanks,
	Chris

Chris Leech (4):
  iscsi: create per-net iscsi nl kernel sockets
  iscsi: sysfs filtering by network namespace
  iscsi: make all netlink multicast namespace aware
  iscsi: set netns for iscsi_tcp hosts

 drivers/scsi/iscsi_tcp.c            |   7 +
 drivers/scsi/scsi_transport_iscsi.c | 264 +++++++++++++++++++++++++++++-------
 include/scsi/scsi_transport_iscsi.h |   2 +
 3 files changed, 222 insertions(+), 51 deletions(-)

-- 
2.1.0

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

pat bogle | 11 May 23:31 2015
Picon

Urgent Requirement for Openstack Developer - Irvine, CA

Hi ,

Please go through the given requirement and reply with your updated resume and also please fill up the contact details found in the job description.

 

Full name:

Total IT experience:

Solution Architect experience:

OpenStack experience:

Salary:

Current location:

Availability:

Relocation (Yes/No):

Visa/Work status:

Phone:

Email:

Skype id:

Best time for phone interview:

Education details :

 

Open Stack Developer

Location: Irvine, CA

Type: Fulltime / Permanent

Salary: DOE

 

Note: Travel will be required within CA, fully paid for by the client

 

Minimum Requirements

9+ years working experience with a broad range of Infrastructure solutions

5+ years in a Infrastructure Architecture or equivalent role with a focus on distributed technical designs and implementations

2+ years of working experience with OpenStack

Broad knowledge of Virtualization Platforms ( OpenStack, Solaris LDOMS)

Experience in Pre-Engineered systems like Exadata, VBlock etc is a plus

Experience with analyzing and documenting Technology solutions and mapping them to business TCO and ROI Analysis

 

Technical Skills:

Strong knowledge and a expert-level experience on a broad range of

infrastructure technologies such as Red Hat Server platforms, Solaris, HP-UX, Windows, Web Servers (IIS or Apache), Directory Services, High Availability configurations, Virtualization ( OpenStack) and Collaboration tools.

Expert knowledge of and experience with enterprise scale technologies

Strong scripting knowledge through experience with various scripting languages (Perl/Bash/Python)

Deep understanding of supporting technologies in SAN, Backup, Web, Middleware, Database, and surrounding infrastructure support technologies

Understands and can apply knowledge of enterprise networking and Database to infrastructure solutions

Experience in tools like Chef, Puppet will be desirable

Practical knowledge and experience in service orchestration and provisioning solutions.

Strong knowledge of storage technologies and trends (IBM, EMC, Hitachi)

Provide Configuration Management leadership for infrastructure domains.

Practical knowledge and a large experience of infrastructure services delivery techniques

Practical knowledge and a large experience of Internet facing environments

Familiarity with Enterprise Architecture concepts and best practices

Familiarity with Infrastructure Technology Service Management (ITSM)frameworks

 

 

Thanks and Regards,

Pat

Marketing Manager

Global Systems LLC

Clarksville ,MD

Office:  214-306-6701

Fax    :  214- 975-1222

pat-QkGzz680Og6rG/iDocfnWg@public.gmane.org

www.globalsyst.com

Yahoo IM – pat_b20723

 

A Certified Woman-Owned Business Enterprise (WBE)

A Certified Minority-Business Enterprise (MBE)

We are very committed. If you are unable to reach me, please contact 240-764-4952.

 

** Specialized in : BA, QA, Java, ERP Application, Project Management, SharePoint and have great technical talent and established clients, please contact us for our REFERRAL policy**

 

 

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Felipe Gutierrez | 9 May 19:05 2015

Broken pipe on my target. Is there any option on my initiator to fix it?

Hi, I am using jscsi.org target and open-iscsi initiator. Through NFS I can copy a bunch of files and it seems ok. When I execute a virtual machine from vmware (vmware -> NFS -> open-iscsi -> target jscsi) the target throws a broken pipe some times. THe initiator reestabilish the connection, but this broken pipe is corrupting my VM file system.

On a good work my target sends SCSIResponseParser PDU and after that receives SCSICommandParser PDU from the initiator. When the broken pipe is up to happen the target sends SCSIResponseParser PDU and does not receive SCSICommandParser PDU. Instead of it, the target receives after 5 seconds NOPOutParser PDU, and sends  NOPInParser PDU. After 60 seconds my target receives TaskManagementFunctionRequestParser PDU with OpCode: 0x2, which means to abort the task. So, the target do what the initiator is asking. The broken pipe happens ans a nes connections is estabilished.

My question is, why the initiator does not keep the comunication after the SCSIResponseParser PDU sent by the target? Is there any way to see if this message is wrong? Or any initiator log error?
Here is the target debug.

(228)19:19:01 DEBUG [main] fullfeature.WriteStage - PDU sent 4:   ParserClass: SCSIResponseParser
  ImmediateFlag: false
  OpCode: 0x21
  FinalFlag: true
  TotalAHSLength: 0x0
  DataSegmentLength: 0x0
  InitiatorTaskTag: 0x28000010
  Response: 0x0
  SNACK TAG: 0x0
  StatusSequenceNumber: 0xc8a
  ExpectedCommandSequenceNumber: 0xc6e
  MaximumCommandSequenceNumber: 0xc6e
  ExpDataSN: 0x0
  BidirectionalReadResidualOverflow: false
  BidirectionalReadResidualUnderflow: false
  ResidualOverflow: false
  ResidualUnderflow: false
  ResidualCount: 0x0
  Bidirectional Read Residual Count: 0x0

(273)19:19:06 DEBUG [main] connection.TargetSenderWorker - Receiving this PDU:
  ParserClass: NOPOutParser
  ImmediateFlag: true
  OpCode: 0x0
  FinalFlag: true
  TotalAHSLength: 0x0
  DataSegmentLength: 0x0
  InitiatorTaskTag: 0x29000010
  LUN: 0x0
  Target Transfer Tag: 0xffffffff
  CommandSequenceNumber: 0xc6e
  ExpectedStatusSequenceNumber: 0xc8b

(144)19:19:06 DEBUG [main] connection.TargetSenderWorker - connection.getStatusSequenceNumber: 3211
(167)19:19:06 DEBUG [main] connection.TargetSenderWorker - Sending this PDU:
  ParserClass: NOPInParser
  ImmediateFlag: false
  OpCode: 0x20
  FinalFlag: true
  TotalAHSLength: 0x0
  DataSegmentLength: 0x0
  InitiatorTaskTag: 0x29000010
  LUN: 0x0
  Target Transfer Tag: 0xffffffff
  StatusSequenceNumber: 0xc8b
  ExpectedCommandSequenceNumber: 0xc6e
  MaximumCommandSequenceNumber: 0xc6e

(228)19:19:11 DEBUG [main] connection.TargetSenderWorker - Receiving this PDU:
  ParserClass: NOPOutParser
  ImmediateFlag: true
  OpCode: 0x0
  FinalFlag: true
  TotalAHSLength: 0x0
  DataSegmentLength: 0x0
  InitiatorTaskTag: 0x2a000010
  LUN: 0x0
  Target Transfer Tag: 0xffffffff
  CommandSequenceNumber: 0xc6e
  ExpectedStatusSequenceNumber: 0xc8c


....
...
...
...
(228)19:20:02 DEBUG [main] connection.TargetSenderWorker - Receiving this PDU:
  ParserClass: TaskManagementFunctionRequestParser
  ImmediateFlag: true
  OpCode: 0x2
  FinalFlag: true
  TotalAHSLength: 0x0
  DataSegmentLength: 0x0
  InitiatorTaskTag: 0x36000010
  LUN: 0x0
  Referenced Task Tag: 0x6b000010
  CommandSequenceNumber: 0xc6e
  ExpectedStatusSequenceNumber: 0xc98
  RefCmdSN: 0xab6
  ExpDataSN: 0x0


Thanks, Felipe

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Chris Leech | 8 May 07:14 2015
Picon

[PATCH] iscsi_ibft: filter null v4-mapped v6 addresses

I've had reports of UEFI platforms failing iSCSI boot in various
configurations, that ended up being caused by network initialization
scripts getting tripped up by unexpected null addresses (0.0.0.0) being
reported for gateways, dhcp servers, and dns servers.

The tianocore EDK2 iSCSI driver generates an iBFT table that always uses
IPv4-mapped IPv6 addresses for the NIC structure fields.  This results
in values that are "not present or not specified" being reported as
::ffff:0.0.0.0 rather than all zeros as specified.

The iscsi_ibft module filters unspecified fields from the iBFT from
sysfs, preventing userspace from using invalid values and making it easy
to check for the presence of a value.  This currently fails in regard to
these mapped null addresses.

In order to remain consistent with how the iBFT information is exposed,
we should accommodate the behavior of the tianocore iSCSI driver as it's
already in the wild in a large number of servers.

Tested under qemu using an OVMF build of tianocore EDK2.

Signed-off-by: Chris Leech <cleech@...>
---
 drivers/firmware/iscsi_ibft.c | 36 +++++++++++++++++++++---------------
 1 file changed, 21 insertions(+), 15 deletions(-)

diff --git a/drivers/firmware/iscsi_ibft.c b/drivers/firmware/iscsi_ibft.c
index 071c2c9..7279123 100644
--- a/drivers/firmware/iscsi_ibft.c
+++ b/drivers/firmware/iscsi_ibft.c
 <at>  <at>  -186,8 +186,20  <at>  <at>  struct ibft_kobject {

 static struct iscsi_boot_kset *boot_kset;

+/* fully null address */
 static const char nulls[16];

+/* IPv4-mapped IPv6 ::ffff:0.0.0.0 */
+static const char mapped_nulls[16] = { 0x00, 0x00, 0x00, 0x00,
+                                       0x00, 0x00, 0x00, 0x00,
+                                       0x00, 0x00, 0xff, 0xff,
+                                       0x00, 0x00, 0x00, 0x00 };
+
+static int address_not_null(u8 *ip)
+{
+	return (memcmp(ip, nulls, 16) && memcmp(ip, mapped_nulls, 16));
+}
+
 /*
  * Helper functions to parse data properly.
  */
 <at>  <at>  -445,7 +457,7  <at>  <at>  static umode_t ibft_check_nic_for(void *data, int type)
 		rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_IP_ADDR:
-		if (memcmp(nic->ip_addr, nulls, sizeof(nic->ip_addr)))
+		if (address_not_null(nic->ip_addr))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_SUBNET_MASK:
 <at>  <at>  -456,21 +468,19  <at>  <at>  static umode_t ibft_check_nic_for(void *data, int type)
 		rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_GATEWAY:
-		if (memcmp(nic->gateway, nulls, sizeof(nic->gateway)))
+		if (address_not_null(nic->gateway))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_PRIMARY_DNS:
-		if (memcmp(nic->primary_dns, nulls,
-			   sizeof(nic->primary_dns)))
+		if (address_not_null(nic->primary_dns))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_SECONDARY_DNS:
-		if (memcmp(nic->secondary_dns, nulls,
-			   sizeof(nic->secondary_dns)))
+		if (address_not_null(nic->secondary_dns))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_DHCP:
-		if (memcmp(nic->dhcp, nulls, sizeof(nic->dhcp)))
+		if (address_not_null(nic->dhcp))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_ETH_VLAN:
 <at>  <at>  -536,23 +546,19  <at>  <at>  static umode_t __init ibft_check_initiator_for(void *data, int type)
 		rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_INI_ISNS_SERVER:
-		if (memcmp(init->isns_server, nulls,
-			   sizeof(init->isns_server)))
+		if (address_not_null(init->isns_server))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_INI_SLP_SERVER:
-		if (memcmp(init->slp_server, nulls,
-			   sizeof(init->slp_server)))
+		if (address_not_null(init->slp_server))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_INI_PRI_RADIUS_SERVER:
-		if (memcmp(init->pri_radius_server, nulls,
-			   sizeof(init->pri_radius_server)))
+		if (address_not_null(init->pri_radius_server))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_INI_SEC_RADIUS_SERVER:
-		if (memcmp(init->sec_radius_server, nulls,
-			   sizeof(init->sec_radius_server)))
+		if (address_not_null(init->sec_radius_server))
 			rc = S_IRUGO;
 		break;
 	case ISCSI_BOOT_INI_INITIATOR_NAME:
-- 
2.1.0

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Lee Duncan | 1 Apr 19:23 2015
Picon

[PATCH 0/1] Fix super-small ARP tables in iscsiuio

From: Lee Duncan <lduncan@...>

The iscsiuio coprocess uses the uIP user-land
network stack, which is designed to work
with 8-bit non-threaded microprossers. Because
of this, the ARP table size is quite small.

When iscsiuio is using ARP and IPv6 it can
run out of ARP-table space.

This simple patch just doubles the size of the
IPv6 and IPv6 ARP tables. This is bcause the plan
is to do away with the user-land iscsiuio
process soon, anyway, so there's no use in
being more clever right now.

Lee Duncan (1):
  ARP table too small when switches involved.

 iscsiuio/src/uip/ipv6.h   | 2 +-
 iscsiuio/src/uip/uipopt.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

-- 
1.8.5.2

--

-- 
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Thomas Dwyer III | 31 Mar 19:44 2015

[PATCH] Support binding a socket to a specific local IP address

Currently, open-iscsi ignores iface.ipaddress whether or not iface.net_ifacename is configured. This can be problematic if/when a network interface is configured with multiple IP addresses and a target only allows connections from one of them. This patch adds support for iface.ipaddress, calling bind() and/or setsockopt(SO_BINDTODEVICE) depending on which iface parameters are changed from their default values. In other words, the following combinations are now permitted (1 & 2 are current behavior, 3 & 4 are new behavior):

  1. Neither of iface.net_ifacename and iface.ipaddress are configured. The code lets the operating system choose an appropriate local IP address and interface based on the portal address.
  2. Only iface.net_ifacename is configured. The code calls setsockopt(SO_BINDTODEVICE) and then lets the operating system choose an appropriate local IP address.
  3. Only iface.ipaddress is configured. The code calls bind() and lets the operating system choose an appropriate interface.
  4. Both of iface.net_ifacename and iface.ipaddress are configured. The code calls both bind() and setsockopt(SO_BINDTODEVICE). The administrator must ensure that the combination of iface.net_ifacename and iface.ipaddress is an appropriate configuration.

Thanks for your consideration.


Regards,
Tom.III

--
You received this message because you are subscribed to the Google Groups "open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Attachment (open-iscsi-network.diff): text/x-diff, 2135 bytes

Gmane