Jochen,
I see that this has been discussed before. Maybe you want to follow/re-open this thread on NetApp Communities: http://communities.netapp.com/message/4679
-Stefan
-----Original Message----- From: Funke, Stefan Sent: 23 June 2009 10:58 To: Willeke, Jochen; toasters@mathworks.com Subject: RE: Netapp SDK -- HTTP Port 1023
Hi Jochen!
I've been playing with manage-ontap-SDK-3.5P1 to test that. I used modified perl samples (manage-ontap-sdk-3.5P1/src/sample/perl) to monitor ports used while connecting to the storage controller and never got a source port <1023.
However, if you look at the libraries you'll find something like:
# # If we are being asked to use a reserved port (we # are doing hosts.equiv authentication), then we search to # find an available port number below 1024. # if ( $self->get_style() eq "HOSTS" ) { my $lowport; for ($lowport=1023; $lowport > 0; $lowport--) { $thisport=pack($sockaddr, &AF_INET,$lowport); if (bind(S,$thisport)) { last; }
So I guess you are using hosts.equiv based authentication against the storage controller. To ensure that only root can authenticate as a 'host', ports <1024 are a good way to enforce that. Switching to a user/password authentication model could be a fast workaround. Changing the background functions of the API could be another way.
-Stefan
-----Original Message----- From: Willeke, Jochen [mailto:Jochen.Willeke@wincor-nixdorf.com] Sent: 22 June 2009 14:59 To: toasters@mathworks.com Subject: Netapp SDK -- HTTP Port 1023
Hi toasters,
we are in the need to use the netapp SDK through a firewall. While trying this we found out, that the SDK uses TCP Port 1023 as the source port. Sadly our firewall defines HTTP source-ports from 1024-upward and therefore denies the transit :(
Has anybody came across this issue and has an idea if this behavior can be changed?
Best Regards and thanks in advance
Jochen Willeke