Getting own IP on Windows fails
Bastien Chevreux
I'm using this little snippet from the Tcl cookbook (aka Wiki :)
proc getIPAddr {} {
set me [socket -server xxx -myaddr [info hostname] 0]
set ip [lindex [fconfigure $me -sockname] 0]
close $me
return $ip
}
# tried it also without -myaddr
to get my own IP address. This works great with Unix, unfortunately, it
hangs with Windows (NT 4.0 which gets an IP with DHCP). The proc never
returns and the wish process which runs it eats approximately 50% of the
CPU. Any idea what I'm doing wrong?
Salut,
Bastien
--
Bastien Chevreux -- Life Science Information Manager
MWG Biotech AG -- Anzinger Strasse 7a -- D-85560 Ebersberg; Germany
Phone: +49 8092 8289 309 -- Fax: +49 8092 8289 310
Jeff Hobbs
...
> proc getIPAddr {} {
> set me [socket -server xxx -myaddr [info hostname] 0]
> set ip [lindex [fconfigure $me -sockname] 0]
> close $me
> return $ip
> }
> # tried it also without -myaddr
>
> to get my own IP address. This works great with Unix, unfortunately, it
> hangs with Windows (NT 4.0 which gets an IP with DHCP). The proc never
> returns and the wish process which runs it eats approximately 50% of the
> CPU. Any idea what I'm doing wrong?
Have you let it run at least 2 minutes (the default timeout for
DNS on Windows)? I'm not sure why that would be a problem anyway.
Using 8.3.3.3, I have no problem on a Win2K box set up with DHCP:
(hobbs) 50 % getIPAddr
192.168.3.186
(hobbs) 51 % time {getIPAddr} 10
5000 microseconds per iteration
--
Jeff Hobbs The Tcl Guy
Senior Developer http://www.ActiveState.com/
Tcl Support and Productivity Solutions
Bastien Chevreux
> [...]
> Have you let it run at least 2 minutes (the default timeout for
> DNS on Windows)? I'm not sure why that would be a problem anyway.
> Using 8.3.3.3, I have no problem on a Win2K box set up with DHCP:
8.3.3.3. I let it run even 20 minutes, to no avail. But it's the system
that seems a little bit ... misconfigured. Could have to do something with
rights, I don't know. When loging in as user (with admin rights, though),
wish will show the described problems on this machine. When loging in as
real admin (NT), it works on this machine. When loging in as user on
other machines, it works too.
My only problem now is that there's no way for me to check whether a
machine will show these symptoms or not - as soon as the 'socket ...'
command is encountered, wish hangs forever.
I hate it, but it seems that it'll a point for the 'Known issues' section
of my programs.
Darren New
> machine will show these symptoms or not - as soon as the 'socket ...'
> command is encountered, wish hangs forever.
Make sure it's the [socket] command and not the [info hostname].
See if you can create a listening socket at all. If so, see if you can
connect to it. If either of these fails, see if you can connect to a
listening socket on that machine created with a known-good program (like
an FTP servers say) from another machine. Etc. Because it certainly
sounds like a hosed TCP configuration more than anything.
--
Darren New
San Diego, CA, USA (PST). Cryptokeys on demand.
Bastien Chevreux
>> My only problem now is that there's no way for me to check whether a
>> machine will show these symptoms or not - as soon as the 'socket ...'
>> command is encountered, wish hangs forever.
>Make sure it's the [socket] command and not the [info hostname].
[info hostname] works wonderfully, it's really the socket command that
fouls up.
>See if you can create a listening socket at all. If so, see if you can
>connect to it. If either of these fails, see if you can connect to a
>listening socket on that machine created with a known-good program (like
>an FTP servers say) from another machine. Etc. Because it certainly
>sounds like a hosed TCP configuration more than anything.
I can (either as NT admin or with another userid). It has nothing to do
with DHCP or so, as I presumed previously. So, I think it has got to be
something with NT rights. I'll investigate that as soon as our NT expert
is back from vacation next week.
What _really_ bothers me is that I can't prevent the lockup, either the
socket works or tcl never returns. I tried using an 'after'-event to catch
it: to no avail, tcl just doesn't respnd anymore.
I'd classify this as a genuine tcl bug and will post it to SF as soon as I
have figured out how one can reproduce it.