We've tested with a Windows 2008 R2 iSNS server and noticed that all targets were listed with port 0 as the port number instead of 3260. We captured a wireshark trace and compared to another iSNS target and noticed the port was little endian in our case and big endian in the working case. The following patch fixed the issue for us:
I'm a little confused because based on a quick glance at RFC 4171 section 6.3.2 (http://tools.ietf.org/html/rfc4171#section-6.3.2) I would have expected a shift to be required, however we confirmed that the implementation matches the working iSNS target when implemented as above and the value passed to htonl is the one displayed in the Windows iSNS server as the port number for each target.
Hi, Thanks for creating this project!
We've tested with a Windows 2008 R2 iSNS server and noticed that all targets were listed with port 0 as the port number instead of 3260. We captured a wireshark trace and compared to another iSNS target and noticed the port was little endian in our case and big endian in the working case. The following patch fixed the issue for us:
I'm a little confused because based on a quick glance at RFC 4171 section 6.3.2 (http://tools.ietf.org/html/rfc4171#section-6.3.2) I would have expected a shift to be required, however we confirmed that the implementation matches the working iSNS target when implemented as above and the value passed to htonl is the one displayed in the Windows iSNS server as the port number for each target.
Thanks again for creating the project.