socket woes

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kerravon86 wrote:

> --- In hercules-390@..., "kerravon86" <kerravon86@...>
> wrote:
[...]

> > attempt number 16262: getsockname: rc 0, len 16, listening on  
> 127.0.0.1:65534
> > attempt number 16263: getsockname: rc 0, len 16, listening on
> 127.0.0.1:49157
> > attempt number 16264: getsockname: rc 0, len 16, listening on
> 0.0.0.0:49158
> > address has changed!
>
> Tried again today and got the same thing:
>
> attempt number 4232: getsockname: rc 0, len 16, listening on
> 127.0.0.1:65533
> attempt number 4233: getsockname: rc 0, len 16, listening on
> 127.0.0.1:65534
> attempt number 4234: getsockname: rc 0, len 16, listening on
> 127.0.0.1:49157
> attempt number 4235: getsockname: rc 0, len 16, listening on
> 0.0.0.0:49158 address has changed!

(...more of the same...)


I think I see a pattern here!

Do you see it too?  :)


[...]
> Why do other people have low port numbers?


Perhaps this might explain things:

  http://support.microsoft.com/kb/929851

  "To comply with Internet Assigned Numbers Authority (IANA)
   recommendations, Microsoft has increased the dynamic client
   port range for outgoing connections in Windows Vista and in
   Windows Server 2008. The new default start port is 49152,
   and the default end port is 65535. This is a change from the
   configuration of earlier versions of Microsoft Windows that
   used a default port range of 1025 through 5000."


and:

  http://support.microsoft.com/kb/314053

  "TcpTimedWaitDelay "

    Key: Tcpip\Parameters
    Value Type: REG_DWORD - Time in seconds
    Valid Range: 30-300 (decimal)
    Default: 0x78 (120 decimal)

    "Description: This parameter determines the time that a
     connection stays in the TIME_WAIT state when it is closing.
     As long as a connection is in the TIME_WAIT state, the socket
     pair cannot be re-used. This is also known as the "2MSL" state.
     According to RFC793, the value should be two times the maximum
     segment lifetime on the network. See RFC793 for more
information."

   "Note: In Microsoft Windows 2000, the default value is 240
    seconds. For Windows XP and Microsoft Windows Server 2003, the
    default was changed to 120 seconds for the IPv4 stack to increase
    performance. The default value for the IPv6 stack is 240
seconds."


Try changing your
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
\TcpTimedWaitDelay" value to something like 1 or 2 seconds (just
while we're testing) and then try your test (fishbug) again.

If that helps, all we might need to do to fix the problem might be
something as simple as adding a 'setsockopt' call (after the 'bind')
to enable the SO_REUSEADDR option. <shrug>




Note: I found the following web page to be somewhat interesting as
well:

  http://smallvoid.com/article/winnt-tcpip-max-limit.html




p.s. I also agree with your assessment that this issue is, upon
second thought, probably on-topic rather than off-topic like I
originally thought it might be.

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSk1VPUj11/TE7j4qEQKEBQCghe4xfJ2CHOoRC2Ow6MpAHhv4SxMAnjeY
hefEAXuvij8/RCz/LaSH775V
=Hf9N
-----END PGP SIGNATURE-----

[somitcw-2]

--- In hercules-390@...,
 "kerravon86" <kerravon86@...> wrote:
- - - snipped - - -
> Why do other people have low port numbers?
> BFN.  Paul.

   On my Windows XP PRO, Windows assigns low
port numbers.

   On my Windows Vista Home Premium, Windows
uses higher port numbers.

   Did you used netstat -an before testing
to see what was in use before the test?
Add -bo to see owning program.
netstat -abno

[kerravon86]

--- In hercules-390@..., "somitcw" <somitcw@...> wrote:
>
> netstat -abno

What a lot of crap I have on my system! Anyway, I
saved it to a file before my latest run. Some of
the numbers are very close, but no exact match.

Here's an excerpt.

attempt number 1878: getsockname: rc 0, len 16, listening on 127.0.0.1:65531
attempt number 1879: getsockname: rc 0, len 16, listening on 127.0.0.1:65532
attempt number 1880: getsockname: rc 0, len 16, listening on 127.0.0.1:65533
attempt number 1881: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
attempt number 1882: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
attempt number 1883: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
address has changed!

C:\Windows\system32>grep 4915 \scratch\temp2.txt
File \scratch\temp2.txt:
  TCP    0.0.0.0:49152          0.0.0.0:0              LISTENING       536
  TCP    0.0.0.0:49153          0.0.0.0:0              LISTENING       1056
  TCP    0.0.0.0:49154          0.0.0.0:0              LISTENING       1124
  TCP    0.0.0.0:49155          0.0.0.0:0              LISTENING       636
  TCP    0.0.0.0:49156          0.0.0.0:0              LISTENING       624
  TCP    [::]:49152             [::]:0                 LISTENING       536
  TCP    [::]:49153             [::]:0                 LISTENING       1056
  TCP    [::]:49154             [::]:0                 LISTENING       1124
  TCP    [::]:49155             [::]:0                 LISTENING       636
  TCP    [::]:49156             [::]:0                 LISTENING       624
  UDP    0.0.0.0:49152          *:*                                    1816
  UDP    [::]:49153             *:*                                    1816


 Can not obtain ownership information

x: Windows Sockets initialization failed: 5
  TCP    [::]:49152             [::]:0                 LISTENING       536
 [wininit.exe]
  TCP    [::]:49153             [::]:0                 LISTENING       1056
  Eventlog
 [svchost.exe]
  TCP    [::]:49154             [::]:0                 LISTENING       1124
  Schedule
 [svchost.exe]
  TCP    [::]:49155             [::]:0                 LISTENING       636
 [lsass.exe]
  TCP    [::]:49156             [::]:0                 LISTENING       624
 [services.exe]
  TCP    [::1]:5679             [::]:0                 LISTENING       3488
  WcesComm

[kerravon86]

--- In hercules-390@..., "Fish" <fish@...> wrote:
>
>   "TcpTimedWaitDelay "
>
>     Valid Range: 30-300 (decimal)

> Try changing your
> "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
> \TcpTimedWaitDelay" value to something like 1 or 2 seconds (just
> while we're testing) and then try your test (fishbug) again.

Ok, I don't have this variable. I could add it
though, but I've not done that before, and I
don't want to reboot right now anyway.

Secondly, the minimum is 30 seconds. I am
reluctant to find out what happens when I do
something that is documented as being wrong.
I have enough trouble with my computer even
when I'm doing everything by the book.

Thirdly, can't I simply wait for the default
time and then try again? I've just tried again
after being at work all day and got the same
result.

BFN.  Paul.

[Steve And Grace Bovy]

--- In hercules-390@... <mailto:hercules-390%40yahoogroups.com>
, "Fish" <fish@...> wrote:
>
> "TcpTimedWaitDelay "
>
> Valid Range: 30-300 (decimal)

> Try changing your
> "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
> \TcpTimedWaitDelay" value to something like 1 or 2 seconds (just
> while we're testing) and then try your test (fishbug) again.

Ok, I don't have this variable. I could add it
though, but I've not done that before, and I
don't want to reboot right now anyway.

Secondly, the minimum is 30 seconds. I am
reluctant to find out what happens when I do
something that is documented as being wrong.
I have enough trouble with my computer even
when I'm doing everything by the book.

Thirdly, can't I simply wait for the default
time and then try again? I've just tried again
after being at work all day and got the same
result.

BFN. Paul.

**************************

From Fish >> (Previous email)

If that helps, all we might need to do to fix the problem might be
something as simple as adding a 'setsockopt' call (after the 'bind')
to enable the SO_REUSEADDR option. <shrug>

>> Actually Fish has a great idea.  

I have written a simple windows socket server that used the
Automatic anonymous port feature that we are using here.

I never thought about the fact that "the system assigned port"
Might still be in a un-usable state.   This is a very real possibility.

I can not imagine the herc would cycle thru port # quick enough
To wrap around itto a re-use condition.  

I was responsible for a tcp server on an ibm mainframe using the sas/c
Bsd/socket library.  We used our own well-known port #.  But we used
To hit the re-use problem all the time, because in development work
You have to re-cycle the server often.  The easy fix was to add the
Re-use address option.

I think adding this will not hurt anything and it could solve some
Of our strange intermitent failure problems.  We should add it
To fishbug and see if it fixes the problem on Pauls system :)

[kerravon86]

--- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:
>
> If that helps, all we might need to do to fix the problem might be
> something as simple as adding a 'setsockopt' call (after the 'bind')
> to enable the SO_REUSEADDR option. <shrug>

The new Windows version of the program allows me
to switch to Watcom C++ for yet another independent
reference (and I don't need to set all that
environment stuff either). So after testing with
MSC, I switched to Watcom C. Both have the same
results.

C:\devel\develop>cvs diff -c -r 1.1 fishtest.c
Index: fishtest.c
===================================================================
RCS file: c:\cvsroot/develop/fishtest.c,v
retrieving revision 1.1
diff -c -r1.1 fishtest.c
*** fishtest.c  4 Jul 2009 00:30:33 -0000       1.1
--- fishtest.c  4 Jul 2009 00:37:42 -0000
***************
*** 34,39 ****
--- 34,41 ----
       int len, rc;
       struct sockaddr_in  addr;
       struct sockaddr_in  xxx;
+      BOOL bOptVal = TRUE;
+      int bOptLen = sizeof(BOOL);

       len = sizeof xxx;

***************
*** 50,55 ****
--- 52,61 ----
  sockaddr_in )) < 0)
           return sockerr( _T("bind") );

+      if (setsockopt(sock, SOL_SOCKET, SO_REUSEADDR,
+                     (char *)&bOptVal, bOptLen) != 0)
+          return sockerr( _T("setsockopt") );
+
       if (listen( sock, 5 ) < 0)
           return sockerr( _T("listen") );


C:\devel\develop>wcl386 -q fishtest.c

C:\devel\develop>fishtest
attempt number 1: getsockname: rc 0, len 16, listening on 0.0.0.0:51072
address has changed!

C:\devel\develop>fishtest
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:51073
attempt number 2: getsockname: rc 0, len 16, listening on 0.0.0.0:51074
address has changed!

C:\devel\develop>fishtest
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:51075
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:51076
attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:51077
address has changed!


BFN.  Paul.

[kerravon86]

--- In hercules-390@..., "Fish" <fish@...> wrote:

>
>  
>   http://support.microsoft.com/kb/929851
>
>   "To comply with Internet Assigned Numbers Authority (IANA)
>    recommendations, Microsoft has increased the dynamic client
>    port range for outgoing connections in Windows Vista and in
>    Windows Server 2008. The new default start port is 49152,
>    and the default end port is 65535. This is a change from the
>    configuration of earlier versions of Microsoft Windows that
>    used a default port range of 1025 through 5000."

Ok, I decided to put things back to how they used
to be in the good old days with this:

fixports.bat:

netsh int ipv4 set dynamicport tcp start=1025 num=3975
netsh int ipv4 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport tcp start=1025 num=3975


And lo and behold, I was able to cycle through these
"virgin ports".

attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1842
attempt number 3961: getsockname: rc 0, len 16, listening on 127.0.0.1:1843
attempt number 3962: getsockname: rc 0, len 16, listening on 127.0.0.1:1844
attempt number 3963: getsockname: rc 0, len 16, listening on 127.0.0.1:1845
attempt number 3964: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 3965: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 3966: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3967: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3968: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3969: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3970: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3971: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3972: getsockname: rc 0, len 16, listening on 127.0.0.1:1858
attempt number 3973: getsockname: rc 0, len 16, listening on 127.0.0.1:1859
attempt number 3974: getsockname: rc 0, len 16, listening on 127.0.0.1:1860
attempt number 3975: getsockname: rc 0, len 16, listening on 127.0.0.1:1861
attempt number 3976: getsockname: rc 0, len 16, listening on 127.0.0.1:1862

Getting tired of success, I decided to close my Windows
Mail (ex-Outlook Express), which has invoked a problem
with fishbug before.

And lo and behold,

attempt number 7935: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 7936: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 7937: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 7938: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 7939: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 7940: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 7941: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 7942: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 7943: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

that put an end to the roaring success.

Set it off again and:

attempt number 3954: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3955: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3956: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3957: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3958: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3959: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1854
attempt number 3961: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

So, the act of closing Windows Mail appears to have introduced
a "rogue port".

So the obvious questions now are:

Who? Why? When? What? Where? Which?

BFN.  Paul.

[Steve And Grace Bovy]

--- In hercules-390@... <mailto:hercules-390%40yahoogroups.com>
, "Fish" <fish@...> wrote:
>
>
> http://support.microsoft.com/kb/929851
<http://support.microsoft.com/kb/929851>
>
> "To comply with Internet Assigned Numbers Authority (IANA)
> recommendations, Microsoft has increased the dynamic client
> port range for outgoing connections in Windows Vista and in
> Windows Server 2008. The new default start port is 49152,
> and the default end port is 65535. This is a change from the
> configuration of earlier versions of Microsoft Windows that
> used a default port range of 1025 through 5000."

Ok, I decided to put things back to how they used
to be in the good old days with this:

fixports.bat:

netsh int ipv4 set dynamicport tcp start=1025 num=3975
netsh int ipv4 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport tcp start=1025 num=3975

And lo and behold, I was able to cycle through these
"virgin ports".

attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1842
attempt number 3961: getsockname: rc 0, len 16, listening on 127.0.0.1:1843
attempt number 3962: getsockname: rc 0, len 16, listening on 127.0.0.1:1844
attempt number 3963: getsockname: rc 0, len 16, listening on 127.0.0.1:1845
attempt number 3964: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 3965: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 3966: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3967: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3968: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3969: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3970: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3971: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3972: getsockname: rc 0, len 16, listening on 127.0.0.1:1858
attempt number 3973: getsockname: rc 0, len 16, listening on 127.0.0.1:1859
attempt number 3974: getsockname: rc 0, len 16, listening on 127.0.0.1:1860
attempt number 3975: getsockname: rc 0, len 16, listening on 127.0.0.1:1861
attempt number 3976: getsockname: rc 0, len 16, listening on 127.0.0.1:1862

Getting tired of success, I decided to close my Windows
Mail (ex-Outlook Express), which has invoked a problem
with fishbug before.

And lo and behold,

attempt number 7935: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 7936: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 7937: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 7938: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 7939: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 7940: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 7941: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 7942: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 7943: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

that put an end to the roaring success.

Set it off again and:

attempt number 3954: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3955: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3956: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3957: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3958: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3959: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1854
attempt number 3961: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

So, the act of closing Windows Mail appears to have introduced
a "rogue port".

So the obvious questions now are:

Who? Why? When? What? Where? Which?

BFN. Paul.

*******************************************************

Try using the set socket re-use option as fish suggested,
And see if it has any effect :)  

[Steve And Grace Bovy]

--- In hercules-390@... <mailto:hercules-390%40yahoogroups.com>
<mailto:hercules-390%40yahoogroups.com>
, "Fish" <fish@...> wrote:
>
>
> http://support.microsoft.com/kb/929851
<http://support.microsoft.com/kb/929851>
<http://support.microsoft.com/kb/929851
<http://support.microsoft.com/kb/929851> >
>
> "To comply with Internet Assigned Numbers Authority (IANA)
> recommendations, Microsoft has increased the dynamic client
> port range for outgoing connections in Windows Vista and in
> Windows Server 2008. The new default start port is 49152,
> and the default end port is 65535. This is a change from the
> configuration of earlier versions of Microsoft Windows that
> used a default port range of 1025 through 5000."

Ok, I decided to put things back to how they used
to be in the good old days with this:

fixports.bat:

netsh int ipv4 set dynamicport tcp start=1025 num=3975
netsh int ipv4 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport udp start=1025 num=3975
netsh int ipv6 set dynamicport tcp start=1025 num=3975

And lo and behold, I was able to cycle through these
"virgin ports".

attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1842
attempt number 3961: getsockname: rc 0, len 16, listening on 127.0.0.1:1843
attempt number 3962: getsockname: rc 0, len 16, listening on 127.0.0.1:1844
attempt number 3963: getsockname: rc 0, len 16, listening on 127.0.0.1:1845
attempt number 3964: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 3965: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 3966: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3967: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3968: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3969: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3970: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3971: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3972: getsockname: rc 0, len 16, listening on 127.0.0.1:1858
attempt number 3973: getsockname: rc 0, len 16, listening on 127.0.0.1:1859
attempt number 3974: getsockname: rc 0, len 16, listening on 127.0.0.1:1860
attempt number 3975: getsockname: rc 0, len 16, listening on 127.0.0.1:1861
attempt number 3976: getsockname: rc 0, len 16, listening on 127.0.0.1:1862

Getting tired of success, I decided to close my Windows
Mail (ex-Outlook Express), which has invoked a problem
with fishbug before.

And lo and behold,

attempt number 7935: getsockname: rc 0, len 16, listening on 127.0.0.1:1846
attempt number 7936: getsockname: rc 0, len 16, listening on 127.0.0.1:1847
attempt number 7937: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 7938: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 7939: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 7940: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 7941: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 7942: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 7943: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

that put an end to the roaring success.

Set it off again and:

attempt number 3954: getsockname: rc 0, len 16, listening on 127.0.0.1:1848
attempt number 3955: getsockname: rc 0, len 16, listening on 127.0.0.1:1849
attempt number 3956: getsockname: rc 0, len 16, listening on 127.0.0.1:1850
attempt number 3957: getsockname: rc 0, len 16, listening on 127.0.0.1:1851
attempt number 3958: getsockname: rc 0, len 16, listening on 127.0.0.1:1852
attempt number 3959: getsockname: rc 0, len 16, listening on 127.0.0.1:1853
attempt number 3960: getsockname: rc 0, len 16, listening on 127.0.0.1:1854
attempt number 3961: getsockname: rc 0, len 16, listening on 0.0.0.0:1855
address has changed!

So, the act of closing Windows Mail appears to have introduced
a "rogue port".

So the obvious questions now are:

Who? Why? When? What? Where? Which?

BFN. Paul.

*******************************************************

Try using the set socket re-use option as fish suggested,
And see if it has any effect :)

**********************

Oh sorry, please ignore my previous stupid email,
I did not notice in your diff that you did indeed use the option !! :)  

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kerravon86 wrote:

[...]
> So, the act of closing Windows Mail appears to have
> introduced a "rogue port".
>
> So the obvious questions now are:
>
> Who? Why? When? What? Where? Which?

I have no idea.  :(

However... Since you're using VS2005 whereas I'm using VS2008, there
exists the possibility that there's a bug in VS2005 that doesn't
exist in VS2008 SP1. It's unlikely IMO (?), but we should check it.

Do this: download the version that I built using VS2008 SP1 and give
it a try. I've uploaded it to the group's Files area under the
following name:


  sockbug.zip
  socket woes research, July 2009
  http://tech.groups.yahoo.com/group/hercules-390/files/


If it works, then it's a bug in VS2005 that has been fixed in VS2008
SP1.

If it still fails then it's obviously something else which we haven't
identified yet.

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSlEH7kj11/TE7j4qEQImXQCgyYrnHGDVU4o2+xH1QDiAdRIxQqgAoKcR
qbutFLDOlhbXE9esE8SXGErj
=oQYm
-----END PGP SIGNATURE-----

[kerravon86]

--- In hercules-390@..., "Fish" <fish@...> wrote:

>
> > So, the act of closing Windows Mail appears to have
> > introduced a "rogue port".
> >
> > So the obvious questions now are:
> >
> > Who? Why? When? What? Where? Which?
>
> I have no idea.  :(
>
> However... Since you're using VS2005 whereas I'm using VS2008, there
> exists the possibility that there's a bug in VS2005 that doesn't
> exist in VS2008 SP1.

I've reproduced the problem on 3 different compilers.
Surely that is sufficient to eliminate the compiler?

> It's unlikely IMO (?), but we should check it.
>
> Do this: download the version that I built using VS2008 SP1 and give
> it a try.

 Directory of C:\scratch\xxxx\sockbug\bin

06/07/2009  09:31 AM    <DIR>          .
06/07/2009  09:31 AM    <DIR>          ..
02/07/2009  06:31 PM             8,192 sockbug.exe
02/07/2009  06:31 PM           273,408 sockbug.pdb
05/07/2009  12:53 PM               689 _Fish README.txt
               3 File(s)        282,289 bytes
               2 Dir(s)   5,108,113,408 bytes free

C:\scratch\xxxx\sockbug\bin>sockbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3362
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3363
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3364
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3365
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3366
attempt number 6: getsockname: rc 0, len 16, listening on 127.0.0.1:3367
attempt number 7: getsockname: rc 0, len 16, listening on 127.0.0.1:3368
attempt number 8: getsockname: rc 0, len 16, listening on 127.0.0.1:3369
attempt number 9: getsockname: rc 0, len 16, listening on 127.0.0.1:3370
attempt number 10: getsockname: rc 0, len 16, listening on 127.0.0.1:3371
attempt number 11: getsockname: rc 0, len 16, listening on 127.0.0.1:3372
attempt number 12: getsockname: rc 0, len 16, listening on 127.0.0.1:3373
attempt number 13: getsockname: rc 0, len 16, listening on 127.0.0.1:3374
attempt number 14: getsockname: rc 0, len 16, listening on 127.0.0.1:3375
attempt number 15: getsockname: rc 0, len 16, listening on 127.0.0.1:3376
attempt number 16: getsockname: rc 0, len 16, listening on 127.0.0.1:3377
attempt number 17: getsockname: rc 0, len 16, listening on 127.0.0.1:3378
attempt number 18: getsockname: rc 0, len 16, listening on 127.0.0.1:3379
attempt number 19: getsockname: rc 0, len 16, listening on 127.0.0.1:3380
attempt number 20: getsockname: rc 0, len 16, listening on 127.0.0.1:3381
attempt number 21: getsockname: rc 0, len 16, listening on 127.0.0.1:3382
attempt number 22: getsockname: rc 0, len 16, listening on 127.0.0.1:3383
attempt number 23: getsockname: rc 0, len 16, listening on 127.0.0.1:3384
attempt number 24: getsockname: rc 0, len 16, listening on 127.0.0.1:3385
attempt number 25: getsockname: rc 0, len 16, listening on 127.0.0.1:3386
attempt number 26: getsockname: rc 0, len 16, listening on 127.0.0.1:3387
attempt number 27: getsockname: rc 0, len 16, listening on 127.0.0.1:3388
attempt number 28: getsockname: rc 0, len 16, listening on 127.0.0.1:3389
attempt number 29: getsockname: rc 0, len 16, listening on 127.0.0.1:3390
attempt number 30: getsockname: rc 0, len 16, listening on 127.0.0.1:3391
attempt number 31: getsockname: rc 0, len 16, listening on 127.0.0.1:3392
attempt number 32: getsockname: rc 0, len 16, listening on 127.0.0.1:3393
attempt number 33: getsockname: rc 0, len 16, listening on 127.0.0.1:3394
attempt number 34: getsockname: rc 0, len 16, listening on 127.0.0.1:3395
attempt number 35: getsockname: rc 0, len 16, listening on 127.0.0.1:3396
attempt number 36: getsockname: rc 0, len 16, listening on 127.0.0.1:3397
attempt number 37: getsockname: rc 0, len 16, listening on 127.0.0.1:3398
attempt number 38: getsockname: rc 0, len 16, listening on 127.0.0.1:3399
attempt number 39: getsockname: rc 0, len 16, listening on 127.0.0.1:3400
attempt number 40: getsockname: rc 0, len 16, listening on 127.0.0.1:3401
attempt number 41: getsockname: rc 0, len 16, listening on 127.0.0.1:3402
attempt number 42: getsockname: rc 0, len 16, listening on 127.0.0.1:3403
attempt number 43: getsockname: rc 0, len 16, listening on 127.0.0.1:3404
attempt number 44: getsockname: rc 0, len 16, listening on 127.0.0.1:3405
attempt number 45: getsockname: rc 0, len 16, listening on 0.0.0.0:3406
address has changed!


Note that since my close of Windows Mail, it appears
that sockets have been "corrupted" a lot more.

Note that I didn't need to install the VS2008
runtime. It's presumably automatically supplied
with Windows Vista.

> If it works, then it's a bug in VS2005 that has been fixed
> in VS2008 SP1.
>
> If it still fails then it's obviously something else which
> we haven't identified yet.

Which would be the best Windows conference to ask a
question in?

BFN.  Paul.

[Steve And Grace Bovy]

I would like to setup/install herc x64 on a windows 2003 server.
 
But I need some guidance on how to setup the networking ??
 
Can anyone describe the software and install steps ??
 
Does Herc X64 use winpcap  ??
 
Does it use a 32 bit version or a 64 bit version ???
 
Is there a 64 bit version of winpcap ??
 
Were and or how do i get 64 bit versions of the fish winpcap bridge
libraries ???
 
Thanks for your help and assistance :)


[Non-text portions of this message have been removed]

[Ivan Warren]

Steve And Grace Bovy wrote:

> I would like to setup/install herc x64 on a windows 2003 server.
>  
> But I need some guidance on how to setup the networking ??
>  
> Can anyone describe the software and install steps ??
>  
> Does Herc X64 use winpcap  ??
>  
> Does it use a 32 bit version or a 64 bit version ???
>  
> Is there a 64 bit version of winpcap ??
>  
> Were and or how do i get 64 bit versions of the fish winpcap bridge
> libraries ???
>  
> Thanks for your help and assistance :)
>
>  

You shouldn't have any difficulties doing this.. I'm doing this on a
Vista 64 environment without any issues..

Anyway,

You *DO* need the 64 bit version of WinpCap.. I don't know where it is,
but I don't remember having any problems googling it.

Fish's Tun/Tap emulation has a 64 bit version as well.. It is shipped
with the 32 bit version (it is under an underlying directory in the ZIP
file). Copy the 64 bit DLLs to your herc directory or to a globally
available directory (Personally, I simply put those under
Windows\system32 so I don't have to worry about them).

Make sure you use a *recent* version of herc. There was a change made to
hercules so that it would get the right DLL names when running 64 bit.

Once I had done this, I didn't have any problems running CTCI and/or LCS
emulation on my 64 bit Vista.

I think it should be the same for 64 bit W2K3.

--Ivan


[Non-text portions of this message have been removed]

[g. desbiens]

Here is what worked for me on Windows 7 Ultimate Beta 64-bit. It may also apply to Win 2003.

- Get and install winpcap 4.0.2 (x86 and x64 compatible)

http://www.winpcap.org/install/default.htm

- Download and copy these files to c:\Windows\system (copying to Hercules install directory should also work):

from : http://www.softdevlabs.com/Hercules/FishLib-2.7.1.564-bin.zip

FishLib32.dll
FishLib64.dll

from : http://www.cbttape.org/~fish/CTCI-W32_3.2.1.160_bin.zip

FishPack64.dll
FWPCUtil.exe
TunTap64.dll

- Install:

http://www.softdevlabs.com/Hercules/vcredist_x86.exe

and

http://www.softdevlabs.com/Hercules/vcredist_x64.exe

I hope I'm not forgetting anything. Good luck.

Regards,
Guy.

--- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:

>
> I would like to setup/install herc x64 on a windows 2003 server.
>  
> But I need some guidance on how to setup the networking ??
>  
> Can anyone describe the software and install steps ??
>  
> Does Herc X64 use winpcap  ??
>  
> Does it use a 32 bit version or a 64 bit version ???
>  
> Is there a 64 bit version of winpcap ??
>  
> Were and or how do i get 64 bit versions of the fish winpcap bridge
> libraries ???
>  
> Thanks for your help and assistance :)
>
>
> [Non-text portions of this message have been removed]
>

[Steve And Grace Bovy]

Steve And Grace Bovy wrote:

> I would like to setup/install herc x64 on a windows 2003 server.
>
> But I need some guidance on how to setup the networking ??
>
> Can anyone describe the software and install steps ??
>
> Does Herc X64 use winpcap ??
>
> Does it use a 32 bit version or a 64 bit version ???
>
> Is there a 64 bit version of winpcap ??
>
> Were and or how do i get 64 bit versions of the fish winpcap bridge
> libraries ???
>
> Thanks for your help and assistance :)
>
>

You shouldn't have any difficulties doing this.. I'm doing this on a
Vista 64 environment without any issues..

Anyway,

You *DO* need the 64 bit version of WinpCap.. I don't know where it is,
but I don't remember having any problems googling it.

Fish's Tun/Tap emulation has a 64 bit version as well.. It is shipped
with the 32 bit version (it is under an underlying directory in the ZIP
file). Copy the 64 bit DLLs to your herc directory or to a globally
available directory (Personally, I simply put those under
Windows\system32 so I don't have to worry about them).

Make sure you use a *recent* version of herc. There was a change made to
hercules so that it would get the right DLL names when running 64 bit.

Once I had done this, I didn't have any problems running CTCI and/or LCS
emulation on my 64 bit Vista.

I think it should be the same for 64 bit W2K3.

--Ivan

Thank You Ivan,  :)  

[Steve And Grace Bovy]

Here is what worked for me on Windows 7 Ultimate Beta 64-bit. It may also
apply to Win 2003.

- Get and install winpcap 4.0.2 (x86 and x64 compatible)

http://www.winpcap.org/install/default.htm
<http://www.winpcap.org/install/default.htm>

- Download and copy these files to c:\Windows\system (copying to Hercules
install directory should also work):

from : http://www.softdevlabs.com/Hercules/FishLib-2.7.1.564-bin.zip
<http://www.softdevlabs.com/Hercules/FishLib-2.7.1.564-bin.zip>

FishLib32.dll
FishLib64.dll

from : http://www.cbttape.org/~fish/CTCI-W32_3.2.1.160_bin.zip
<http://www.cbttape.org/~fish/CTCI-W32_3.2.1.160_bin.zip>

FishPack64.dll
FWPCUtil.exe
TunTap64.dll

- Install:

http://www.softdevlabs.com/Hercules/vcredist_x86.exe
<http://www.softdevlabs.com/Hercules/vcredist_x86.exe>

and

http://www.softdevlabs.com/Hercules/vcredist_x64.exe
<http://www.softdevlabs.com/Hercules/vcredist_x64.exe>

I hope I'm not forgetting anything. Good luck.

Regards,
Guy.

>>>  Thank you very much  !!!!! <<<<<

--- In hercules-390@... <mailto:hercules-390%40yahoogroups.com>
, "Steve And Grace Bovy" <sg.bovy@...> wrote:

>
> I would like to setup/install herc x64 on a windows 2003 server.
>
> But I need some guidance on how to setup the networking ??
>
> Can anyone describe the software and install steps ??
>
> Does Herc X64 use winpcap ??
>
> Does it use a 32 bit version or a 64 bit version ???
>
> Is there a 64 bit version of winpcap ??
>
> Were and or how do i get 64 bit versions of the fish winpcap bridge
> libraries ???
>
> Thanks for your help and assistance :)
>
>
> [Non-text portions of this message have been removed]
>