Re-reading "SERVICES" file
PaulRS
can get my mail client to work by editing the "SERVICES" file in
\MPTN\ETC changing the "25/tcp" to "587/tcp"and rebooting.
However, I have a dialup that still uses SMTP port 25.
I want to be able to switch by simple editing without have to reboot.
So my question is: "What is happening at reboot that gets the
\MPTN\ETC|SERVICES file read? What program would I need to stop,
restart, etc. to get this file re-read without having to reboot? Is
this possible in OS2 without a reboot?.
(By the way it works in Win2k simply by editing their SERVICES file
back and forth without a reboot. This must mean that W2K must do a
fresh read of SERVICES at every SMTP send)
--
Trevor Hemsley
587 is a standard SMTP+SSL port so it should be just a matter of changing your
mailer to point to it - you shouldn't need to muck about with the services file
at all.
What mailer are you using?
--
Trevor Hemsley, Brighton, UK
Trevor dot Hemsley at ntlworld dot com
Frank Beythien
> My ISP has changed the port for sending SMTP mail from 25 to 587. I
> can get my mail client to work by editing the "SERVICES" file in
> \MPTN\ETC changing the "25/tcp" to "587/tcp"and rebooting.
>
> However, I have a dialup that still uses SMTP port 25.
>
> I want to be able to switch by simple editing without have to reboot.
> So my question is: "What is happening at reboot that gets the
> \MPTN\ETC|SERVICES file read? What program would I need to stop,
> restart, etc. to get this file re-read without having to reboot? Is
> this possible in OS2 without a reboot?.
Why don't you change your mail client to use port 587 with smtp?
--
Frank Beythien fBeythien AT gmx.de
PaulRS
Client is MR2ICE - No option on ports
--
PaulRS
Client is MR2ICE - No option on ports It works when I change
"SERVICES" file. This was Nick Secants fix as he no longer owns
rights to MR2ICE
--
PaulRS
wrote:
Opps - Nick Knight's fix (at Secant) I contacted him when the ISp
changed the port. This was his "off the record" work-around. It does
work in both the OS/2 and Win versions. Now I want to loose the need
to reboot.
--
Jim Moe
>>
>> Why don't you change your mail client to use port 587 with smtp?
>
> Client is MR2ICE - No option on ports
Have you tried adding the port number to the end of the URL? Like so:
--
jmm (hyphen) list (at) sohnen-moe (dot) com
(Remove .AXSPAMGN for email)
PaulRS
<jmm-list...@sohnen-moe.com> wrote:
> On 12/01/09 05:11 pm, PaulRS wrote:
> >>
> >> Why don't you change your mail client to use port 587 with smtp?
> >
> > Client is MR2ICE - No option on ports
>
> Have you tried adding the port number to the end of the URL? Like so:
>
> mail.example.com:587
>
I just tried it. No-go! MR2ICE looks for the port # that was read to
??somewhere?? from the SERVICES file.
--
baden.ku...@gmail.com
I just checked and confirmed this is the way it also
works on OS/2. I also use MR/2 and I had to change to
port 587 from 25 in "\MPTN\ETC\services" a few years
back with 3.0. Now I use 4.5 and it behaves the same.
I just changed back to 25, opened MR/2, and nothing was
sent. I closed MR/2, changed back to 587, and when I
restarted MR/2, the message was sent.
I guess if you had batch program renaming two
"services", and then starting your desired mailer, that
would be easiest. IIRC, there is also a configuration
or command file that is executed when you switch
between dial-up and ethernet connections.
I hope this helps,
lin Baden
PaulRS
Your suggestion is EXACTLY what I have been trying to do. The problem
is that in OS/2 the SERVICES file seems to be read ONLY at startup.
In other words a reboot is necessary to change the SMTP port
assignment. What I want to do is get SERVICES read again without a
reboot. I can change SERVICES back and forth now (PORT 587 or PORT
25) but have to reboot in order for MR2ICE to access SMTP through the
selected PORT. I want to restart ??SOME?? program that obviously runs
at boot-up that reads the SERVICES file with the goal of switching
SMTP ports for Inet dialup (port25) or Verizons new SMTP port (587)
broadband.
I am still looking for someone who can help here.
--
Steven Levine
> I just checked and confirmed this is the way it also
> works on OS/2. I also use MR/2 and I had to change to
> port 587 from 25 in "\MPTN\ETC\services" a few years
> back with 3.0. Now I use 4.5 and it behaves the same.
> I just changed back to 25, opened MR/2, and nothing was
> sent. I closed MR/2, changed back to 587, and when I
> restarted MR/2, the message was sent.
If you want to avoid editing services, you can override the port
numbers from the mr/2 command line.
Steven
--
---------------------------------------------------------------------
Steven Levine <ste...@earthlink.bogus.net>
eCS/Warp/DIY etc. www.scoug.com www.ecomstation.com
---------------------------------------------------------------------
Doug Bissett
wrote:
...snip...
> In other words a reboot is necessary to change the SMTP port
> assignment. What I want to do is get SERVICES read again without a
> reboot. I can change SERVICES back and forth now (PORT 587 or PORT
> 25) but have to reboot in order for MR2ICE to access SMTP through the
> selected PORT. I want to restart ??SOME?? program that obviously runs
> at boot-up that reads the SERVICES file with the goal of switching
> SMTP ports for Inet dialup (port25) or Verizons new SMTP port (587)
> broadband.
>
> I am still looking for someone who can help here.
I have never even heard about changing the Services file, until you
posted about it.
PORT 587 is supposed to be capable of using either a secure
connection, or a non-secure connection. There is a program called
STunnel, which can be used to communicate with a secure connection. It
works much like a PROXY server between an e-mail program, that
doesn't understand secure connections, and a server that does. In your
case, you would set it up to use STunnel when using PORT 587, and
don't use STunnel when you need to use PORT 25. The e-mail program
would always use PORT 25, and it would depend on whether you start
STunnel, or not, whether the server is accessed using PORT 25 (not
running), or PORT 587 (running).
> http://download.smedley.info/stunnel-4.26-os2-20090403.zip
Hope this helps...
--
From the eComStation of Doug Bissett
dougb007 at telus dot net
(Please make the obvious changes, to e-mail me)
PaulRS
<ste...@nomail.earthlink.net> wrote:
> On Fri, 4 Dec 2009 08:04:30 UTC, "baden.ku...@gmail.com"
> <baden.ku...@gmail.com> wrote:
>
> > I just checked and confirmed this is the way it also
> > works on OS/2. I also use MR/2 and I had to change to
> > port 587 from 25 in "\MPTN\ETC\services" a few years
> > back with 3.0. Now I use 4.5 and it behaves the same.
> > I just changed back to 25, opened MR/2, and nothing was
> > sent. I closed MR/2, changed back to 587, and when I
> > restarted MR/2, the message was sent.
>
> If you want to avoid editing services, you can override the port
> numbers from the mr/2 command line.
>
> Steven
>
The command line switch toi which you refer is /Pxxx and it is stated
as selecting and alternate POP3 port instead of 110. I need to change
the SMTP port.
--
PaulRS
Just a bit of INFO: My ISP, Verizon, switched their SMTP port from 25
to 587 to discourage SPAM from persons not on the Verizon network.
This happened in September-October.
I will certainly look into your potiential solution. Nick Knight,
author of Mr2ICE, gave me the "services" file solution as a
work-around. It DOES work well with the Windows version of MR2ICE -
Services (under windows 2K) is read before the smtp port is accessed
each time. So, all I have to do is switch between two "services"
files with a simple batch file depending on wheter I need port 25
(another ISP dialup) or the Verizon broadband ISP (port 587).
--
Steven Levine
wrote:
Hi,
> The command line switch toi which you refer is /Pxxx and it is stated
> as selecting and alternate POP3 port instead of 110. I need to change
> the SMTP port.
Sorry about that. I thought that SMTP port override had been
implemented, but I guess not.
Rich Walsh
> "What is happening at reboot that gets the \MPTN\ETC|SERVICES file
> read? What program would I need to stop, restart, etc. to get this
> file re-read without having to reboot? Is this possible in OS2
> without a reboot?.
Here's a real W-A-G:
Create a new directory (perhaps "x:\MPTN\DIALUP") and copy
'resolv', 'protocol', 'hosts' and 'services' from x:\MPTN\ETC.
Of course, modify 'services' to point SMTP to port 25.
Next, open a couple of OS/2 commandline sessions, then CD to
the dialer's & MR2ICE's working directories. In each, enter
"SET ETC=x:\MPTN\DIALUP". Now, start the dialer, then MR2ICE,
then try to send.
If this actually works :-) you can then try starting the
dialer normally with only MR2ICE having a modified environment.
If it doesn't work, you may want to try killing cntrl.exe,
editing the file, then restarting it (yet another W-A-G).
--
== == almost usable email address: Rich AT E-vertise.Com == ==
___________________________________________________________________
|
| DragText v3.9 with NLS support
Rich Walsh | A Distinctly Different Desktop Enhancement
Ft Myers, FL | http://e-vertise.com/dragtext/
___________________________________________________________________
Paul Ratcliffe
> If it doesn't work, you may want to try killing cntrl.exe,
> editing the file, then restarting it (yet another W-A-G).
You can't kill CNTRL.EXE
Even if you could, it wouldn't make any difference, as it has absolutely
nothing to do with the issue in question.
Paul Ratcliffe
> Your suggestion is EXACTLY what I have been trying to do. The problem
> is that in OS/2 the SERVICES file seems to be read ONLY at startup.
It isn't.
> In other words a reboot is necessary to change the SMTP port assignment.
It isn't.
> What I want to do is get SERVICES read again without a reboot.
You can. Applications do this by default when they call the getservbyname()
call built into TCP32DLL.DLL (and similar).
> I can change SERVICES back and forth now (PORT 587 or PORT
> 25) but have to reboot in order for MR2ICE to access SMTP through the
> selected PORT.
I find that hard to believe. Presumably it uses the above mentioned call.
If it's caching something, then something must still be running. I have
no knowledge of MR2ICE at all though.
> I want to restart ??SOME?? program that obviously runs
> at boot-up that reads the SERVICES file with the goal of switching
> SMTP ports for Inet dialup (port25) or Verizons new SMTP port (587)
> broadband.
There is NO program to restart that runs at boot-up. The only one that has
any bearing on it is the one you are using.
PaulRS
Let me give you the symptoms:
Verizon DSL changed SMTP Port to 587 to limit 3rd party SPAM
I edited "SERVICES" 'smtp 25/tcp' to 'smtp 587/tcp'
ATTGLOBAL Dialup uses Port 25.
For this I have the original "SERVICES" file ('smtp 25/tcp')
I have a batch file that renames these two files with the one to be
used ending up named "SERVICES"
Now, the computer is booted. It boots using the Port 587 "SERVICES"
file - the email service I use most.
If I DON'T use MR2ICE at this boot (i.e. it has not run so no
possible orphan thread is left) and switch the SERVICES file to the
one for ATTGLOBAL dialup (Port 25), then use the Dialer. MR2 sits
there until it times out trying to send an email.
If I switch "SERVICES" to the one I want to use and Reboot. It
works. To switch back I also have to reboot.
My "guess" was that the "SERVICES" file is not being read each time
an email is sent. However, somehow, by a reboot" MR2ICE gets the
right port from "SERVICES" file.
You say this is hard to believe . . . I guess you could experiment by
changing your "SERVICES" file 'smtp 25/tcp' line to some OTHER random
port and see if you client will send mail. My guess is that
IT WILL SEND because somehow it still believes the port is 25.
However, if you reboot it will not send because it is trying to send
to the random port.
I'm just trying to figue this out . . . .
Paul RS
--
PaulRS
<dougb007!SP...@telus.net> wrote:
> On Fri, 4 Dec 2009 18:04:48 UTC, "PaulRS" <prs...@Zverizon.net>
> wrote:
>
> ...snip...
> PORT 587 is supposed to be capable of using either a secure
> connection, or a non-secure connection. There is a program called
> STunnel, which can be used to communicate with a secure connection. It
> works much like a PROXY server between an e-mail program, that
> doesn't understand secure connections, and a server that does. In your
> case, you would set it up to use STunnel when using PORT 587, and
> don't use STunnel when you need to use PORT 25. The e-mail program
> would always use PORT 25, and it would depend on whether you start
> STunnel, or not, whether the server is accessed using PORT 25 (not
> running), or PORT 587 (running).
>
> > http://download.smedley.info/stunnel-4.26-os2-20090403.zip
>
> Hope this helps...
I downloaded and tried the listed program, but could not get it to
work. It may either be that (1) it does not work in my situation or
(2) I don't quite understand setting up the "conf" file. It looks
like it was made for linux.
My changes: I "comma out" all the services (ftp, etc.) but the ssmpt
section and the added my numbers for "connect" and "accept" - program
ran, but no mail transfer. I also reversed "connect" and "accept"
ports to see if I screwed up - still did not work. Do you have any
suggestions for a proper "conf" file?
PaulRS
--
m...@privacy.net
To use stunnel you would need to change your MR2/ICE congifuration as well
as setup stunnel properly. Stunnel runs as a server on your PC and you
would need to have MR2/ICE refer to 127.0.0.1 for your SMTP server and
have a coresponding accept for port 25 in your stunnel cfg file. You
woould then have stunnel connect to the actual SMTP server on the secure
port and handle the encryption for you.
-- Dave
-----------------------------------------------------------
dhdurgee<at>verizon<dot>net
-----------------------------------------------------------
James J. Weinkam
>
> You say this is hard to believe . . . I guess you could experiment by
> changing your "SERVICES" file 'smtp 25/tcp' line to some OTHER random
> port and see if you client will send mail. My guess is that
> IT WILL SEND because somehow it still believes the port is 25.
> However, if you reboot it will not send because it is trying to send
> to the random port.
>
its strengths and weaknesses. However, I thought it might be interesting to
try your suggestion using Seamonkey.
Here's what I did:
First I remmed out the two smtp 25/... lines in \mptn\etc\services. Next I
rebooted. Then I fired up Seamonkey and sent myself a test message. It was
sent and received without a problem.
I then edited services again, this time changing the smtp lines to
smtp 26/... (an unused port). Again, I shut down, rebooted, and sent myself
a test message. Again it was sent and received without a problem.
It appears that Seamonkey is able to use port 25 regardless of what if
anything services has to say about it. This is no doubt due to the fact the
the outgoing smtp port can be set in Seamonkey and defaults to 25. Moreover
you can change the setting without having to shut down the program, much less
reboot.
It sounds like you age up against a deficiency in MR2ICE.
Another possible explanation for the behavior you describe may be that the lines
submission 587/tcp #Submission
submission 587/udp #Submission
further out in the services file are nullifying your smtp 587/... lines.
I suggest that you try remming or deleting those. It may also be worth trying
putting the lines in their correct numerical position although I would hope
that isn't necessary.
Doug Bissett
wrote:
This works with PMMail, for GMAIL:
=======================
socket = l:TCP_NODELAY=0
socket = r:TCP_NODELAY=0
client = yes
output = W:/APPS/PMMAIL/BIN/stunnel.log
verify = 0
debug = 4
[pop-gmail]
accept = localhost:110
connect = pop.gmail.com:995
;# protocol = pop3
[smtp-gmail]
accept = localhost:25
connect = smtp.gmail.com:465
;# protocol = smtp
====================
GMail uses port 465, while you apparently need port 587. I don't think
you need to change MR/2 to use address 127.0.0.1, as suggested
elsewhere, but PMMail may do that for me. The log file location will
need to be changed to match your system. If you do need to direct MR/2
to localhost (I would use that name, rather than 127.0.0.1 just for
readability), you would need to change it back to the real address,
when on a dialup, without STunnel. Of course that also means that you
need to have the localhost entry in the \MPTS\ETC\HOSTS file, and the
line:
SET USE_HOSTS_FIRST=1
in your CONFIG.SYS. Both should be there, unless you have messed
around with them.
There are a few other reasons why STunnel might not run, so try it
from a command line, to see if there are any error messages.
PaulRS
wrote:
MR2ICE is hard-coded to look up the port in SERVICES. However, in the
OS/2 version it appears to be somewhere other than the text file:
SERVICES. Wherever that is, changing SERVICES and having whatever a
reboot does gives MR2 the right port. Is was the author (now
ex-author who sold MR2) that had me messing with the "SERVICES" file.
Seamonkey obviously uses the port named in its config files and DOES
NOT LOOK IT UP. My best guess is that MR2 is getting the port from
wherever the reboot reading of the SERVICES file put it. Remember: it
works as the author suggested BUT ONLY after a reboot.
--
Dave Yeo
>> Another possible explanation for the behavior you describe may be that the lines
>> >
>> > submission 587/tcp #Submission
>> > submission 587/udp #Submission
>> >
>> > further out in the services file are nullifying your smtp 587/... lines.
>> >
>> > I suggest that you try remming or deleting those. It may also be worth trying
>> > putting the lines in their correct numerical position although I would hope
>> > that isn't necessary.
> MR2ICE is hard-coded to look up the port in SERVICES. However, in the
> OS/2 version it appears to be somewhere other than the text file:
> SERVICES. Wherever that is, changing SERVICES and having whatever a
> reboot does gives MR2 the right port. Is was the author (now
> ex-author who sold MR2) that had me messing with the "SERVICES" file.
> Seamonkey obviously uses the port named in its config files and DOES
> NOT LOOK IT UP. My best guess is that MR2 is getting the port from
> wherever the reboot reading of the SERVICES file put it. Remember: it
> works as the author suggested BUT ONLY after a reboot.
>
>
Did you try commenting out the submission lines?
Dave
Jim Moe
>>
>> I downloaded and tried the listed program, but could not get it to
>> work. It may either be that (1) it does not work in my situation or
>> (2) I don't quite understand setting up the "conf" file. It looks
>> like it was made for linux.
>
> =======================
> socket = l:TCP_NODELAY=0
> socket = r:TCP_NODELAY=0
> client = yes
> output = W:/APPS/PMMAIL/BIN/stunnel.log
> verify = 0
> debug = 4
>
> [pop-gmail]
> accept = localhost:110
> connect = pop.gmail.com:995
> ;# protocol = pop3
>
> [smtp-gmail]
> accept = localhost:25
> connect = smtp.gmail.com:465
> ;# protocol = smtp
> ====================
> GMail uses port 465, while you apparently need port 587. I don't think
> you need to change MR/2 to use address 127.0.0.1, as suggested
>
Yes. PMMail does that for you.
After setting up the stunnel configuration and starting stunnel, the
connection is:
mr/2 <-> localhost:stunnel <-> stunnel:remote-host <-> remote-host-SMTP.
So mr/2 would have the "host name" entry either as "localhost" or
"127.0.0.1" to connect to the unencrypted port on stunnel. stunnel then
establishes an encrypted session with the remote host. stunnel provides
the en-/decryption services for the session.
Trevor Hemsley
<prs...@Zverizon.net> wrote:
> MR2ICE is hard-coded to look up the port in SERVICES. However, in the
> OS/2 version it appears to be somewhere other than the text file:
> SERVICES.
There is something odd here. I don't have MR2ICE but I just did a quick
experiment here like this:
telnet your.isp.mail.server smtp
(works, gets me a sendmail banner and I type 'quit' to exit)
edit %etc%\services and change 'smtp 25/tcp' and 'smtp 25/udp' to 125 and save
it
telnet your.isp.mail.server smtp
(fails because it uses port 125)
edit %etc%\services and revert the above changes
telnet again
(works again)
No reboots needed.
I then went on and wrote a little program that invoked getservbyname() and it
returns the correct values whenever %etc%\services is changed. Mr2ice which I
downloaded and set up to talk to my local mail server continues to use port 25
which is what %etc%\services said at my last boot. I tried adding setservent(0)
and endservent() calls to my little program but those made no difference to
mr2ice.
My conclusion, mr2ice is broken.
I hated the interface anyway :(
PaulRS
Your experiment with MR2ICE came to the RIGHT conclusion, BUT the work
around of editing "SERVICES" does work with it ONLY AFTER a Reboot.
WHY??? MR2ICE is getting it's Port from somewhere? It is the Reboot
that resets this 'mystery spot' by reading the "SERVICES" file. That
is why my original post thought a rereading might reset this 'mystery
spot' [This is all conjecture on my part based on my experimantal
observations]
PaulRS
--
James J. Weinkam
>
> Your experiment with MR2ICE came to the RIGHT conclusion, BUT the work
> around of editing "SERVICES" does work with it ONLY AFTER a Reboot.
> WHY??? MR2ICE is getting it's Port from somewhere? It is the Reboot
> that resets this 'mystery spot' by reading the "SERVICES" file. That
> is why my original post thought a rereading might reset this 'mystery
> spot' [This is all conjecture on my part based on my experimantal
> observations]
Is it possible that MR2ICE allocates some shared memory on first invocation in
which it stores the port it is using and other things such as whether an
instance is running at the moment and which it does not free but refers to on
subsequent invocations?
PaulRS
wrote:
> PaulRS wrote:
I had thought about that and checked by Rebooting with SERVICES set to
PORT 587. In the reboot, I did not start MR2 before I tswitched the
"SERVICES" file to Port 25. When I started MR2 it was sending smtp to
port 587 - the one that was set when I booted. SO, it is getting the
port from another source.
--
Steven Levine
wrote:
H,
> Is it possible that MR2ICE allocates some shared memory on first invocation in
> which it stores the port it is using and other things such as whether an
> instance is running at the moment and which it does not free but refers to on
> subsequent invocations?
It doesn't do anything like that.
I'm still trying to figure out why Paul needs the reboot. A edited
services and restarting mr2ice should suffice. mr2ice makes the usual
getservbyname call to find the smtp service and fails back to port 25
if the call fails.
J de Boyne Pollard
P> - the one that was set when I booted. SO, it is getting
P> the port from another source.
There are lots of clueful people all saying the same thing, here.
Trevor Hemsley put it best. It looks like MR/2 ICE is broken, and
wouldn't get the GNKSOA-MUA.
<URL:http://homepage.ntlworld.com./jonathan.deboynepollard/Proposals/
gnksoa-mua.html#PreferSubmissionToRelay>
Properly written applications really do call getservbyname_r() or
getservbyname() to translate a string such as "smtp" to a port number
such as 25. And those functions really do look in %ETC%\SERVICES .
And there really is no cache of that file's contents that persists
across processes. (Others have already mentioned endservent(), which
stops a single process from holding the file open and of course has no
meaning across processes.) I write with some authority on this,
having written my own drop-in replacements for TCPIPDLL.DLL,
TCPIP32.DLL, and TCP32DLL.DLL .
But, more importantly, properly written MUAs don't look up "smtp" in
the services database in the first place, because they know that
that's the service for SMTP _Relay_, not SMTP _Submission_. The IANA
assigned name for SMTP Submission is "submission", as M. Weinkam
pointed out. And as xe also pointed out, it is a deficiency in MR/2
ICE that you are up against here. It's looking up the wrong string.
It isn't letting you manually specify the right string. And,
according to your and M. Hemsley's tests, it's secretly stashing the
answers that it gets from the lookup, somewhere else. (More on this
later.)
M. Bisset has already given you the best _local fix_ for this
behaviour: run an SMTP Submission server on port 25 on a loopback IP
address (*not* a publicly reachable one) on your own machine, and have
that server store and forward to the real SMTP Submission service that
you are wanting to use; or just have some form of pass-through SMTP
proxy on that port and IP address. You could use one of several
programs do to this. stunnel, as mentioned, is one. Bob Eager's
SMTP server and client are another. My Internet Utilities are a
third.
(You could even do it with the SENDMAIL that comes bundled with IBM OS/
2. This would involve using a second Sendmail configuration file,
though. Sendmail configuration files are notorious for being
illegible by humans, with one having as much chance of getting a
working configuration file by manual editing as one would have by
dumping the line noise from a non-error-correcting modem into a file.
And the instructions for setting up a simple submission-to-smarthost
service provided by the Sendmail company presume the existence of a
Sendmail macro language that isn't in the IBM OS/2 port, and address a
version of Sendmail that post-dates the version that IBM ported. So
this fourth option isn't a particularly appealing or convenient one.)
Another local fix would be to just run your own fully fledged MTS, and
not even bother forwarding to your ISPs' MTSes. (That comes with the
penalty of being treated by many people as a third-class Internet
citizen for running a first-class host, of course.) Again, there are
softwares available for doing that. (Again, IBM's port of Sendmail is
one, albeit far from the most convenient.) I do exactly this, myself,
using my own softwares of course.
If you want a temporary fix or a service fix, however, your only
option is to go back to the people who actually know the MR/2 ICE
code, and ask them _where the program is privately stashing its copy
of this information_. As M. Ratcliffe has already said, the only
program that has bearing here is MR/2 ICE itself. This brings us back
to the point made earlier. A lot of people have said the same thing
several times, now. You're not going to get anything new by simply
asking the same question again and again. The only possibly new point
not yet made is that it's always possible that a persistent MR/2 ICE
process is being started via your startup folder, which of course
_will_ look up the port number at startup time and remember it
thenceforth, by simple dint of continuing to run. That's a fairly
simple explanation of the observed behaviour, which I hope someone
here has already checked for. (-: The program's documentation does
state that it is written to hand off work to an already running copy
of the program.
PaulRS
Thankyou for your full and logical reply. I appreciate your knowledge
on the subject. Mr. Nick Knight sold the rights to MR2ICE and would
have fixed some of these problems, but is not legally able to do so.
The buyer has evidently orphanned it. We all know MR2 is lacking in
not allowing configuration of ports. This discussion also has shown
that it is doing some things in unorthodox ways.
I have kept this discussion going for my own education (as well as
others entering into this discussion). My appearance of asking the
same questions has been to answer those suggesting "possible"
solutions and "experiments" when I do not know EXACTLY WHEN they have
entered this thread. It was started over a week ago. - Really, I am
not trying to 'beat a dead horse.'
Personally, I have used MR2 since 1998 in earlier developing versions.
I have all my past mail archived under it on CD's. Therefore, I want
to keep using it as long as I can. My main broadband provider now
uses Port 587. I boot OS/2 with SERVICES set to this port (Mr.
Knight's graciously suggested work-around when he is legally prevented
from fixing the problem). This accounts for 95% of my email use. The
other 5% is the dialup and Port 25. Obviously my simplest solution is
to continue to Reboot and abandoned any thought of "hot" switching
under OS/2.
I found that the ATTGLOBAL dialup does not like to "handshake" with
stunnel. It reacts that same way as when I try to SMTP to this
account through the VERIZON-DSL ISP - It rejects it. MR2 sends mail
when I dial ATTGLOBAL directly from either the ATTGLOBAL dialer or
other (Linux) dialers on Port 25. (I followed the suggested
stunnel.conf example given earlier in this thread.)
Again, thankyou for your full explaination, knowledge, and time taken
to respond. My curiosity is still interested in trying to discover
where MR2 gets this port ONLY after a reboot. There is nothing
started by MR2 or MR2 related at reboot. It is all in it's own
directory that can be moved/removed by moving/deleting the directory.
Nothing of it runs at startup until I start it the first time. SO
- I am thinking that OS/2 boot programs must store these ports
SOMEWHERE and this is where MR2, in a most unorthodox way, gets it's
SMTP port number. As stated earlier in this thread, the Windows
Version (which I also use) works without a reboot (in this
work-around) by modifying the Windows SERVICES. The OS/2 version does
not. If you have any more WISDOM and if OS/2 and where OS/2 boot
files may read SERVICES and stash ports, I would be interested in your
knowledge here.
Thanks to YOU all who have responded to this "thread" and furthered my
education - the REAL strength of newsgroups..
Paul
--
Paul Ratcliffe
> - I am thinking that OS/2 boot programs must store these ports
> SOMEWHERE
You've already been told by more than one person that this doesn't happen.
WHY do you keep harping on about it?
> and this is where MR2, in a most unorthodox way, gets it's
> SMTP port number.
Why don't you just ask Nick Knight then?
> If you have any more WISDOM and if OS/2 and where OS/2 boot
> files may read SERVICES and stash ports, I would be interested in your
> knowledge here.
For God's sake, how many times do you need to be told?
Trevor Hemsley
<ab...@orac12.clara34.co56.uk78> wrote:
> On 8 Dec 2009 17:56:05 GMT, PaulRS <prs...@Zverizon.net> wrote:
>
> > - I am thinking that OS/2 boot programs must store these ports
> > SOMEWHERE
>
> You've already been told by more than one person that this doesn't happen.
> WHY do you keep harping on about it?
Maybe because the results seem to back him up?
Can you explain these results any other way? Maybe there's a bug in my test
program?
[F:\csrcos2\getsmtp]cat testsmtp.cpp
#include <netdb.h>
#include <types.h>
#include "stdio.h"
#include "string.h"
int main( int argc, char *argv[] )
{
int rc;
int s;
struct servent *sp;
sp = getservbyname("smtp", "tcp");
if (sp == NULL)
{
printf("getservbyname returned null\n");
}
else
{
printf("smtp port is %d\n", ntohs(sp->s_port));
}
setservent(0);
endservent();
return( 0 );
}
[V:\csrcos2\getsmtp]grep -i smtp %etc%\services
smtp 25/tcp #Simple Mail Transfer
smtp 25/udp #Simple Mail Transfer
smtps 465/tcp #smtp protocol over TLS/SSL (was ssmtp)
smtps 465/udp #smtp protocol over TLS/SSL (was ssmtp)
# # Boris B. Maiden <Boris_...@smtp.microcom.com>
[V:\csrcos2\getsmtp]testsmtp
smtp port is 25
[V:\csrcos2\getsmtp]e %etc%\services
[V:\csrcos2\getsmtp]grep -i smtp %etc%\services
smtp 125/tcp #Simple Mail Transfer
smtp 125/udp #Simple Mail Transfer
smtps 465/tcp #smtp protocol over TLS/SSL (was ssmtp)
smtps 465/udp #smtp protocol over TLS/SSL (was ssmtp)
# # Boris B. Maiden <Boris_...@smtp.microcom.com>
[V:\csrcos2\getsmtp]testsmtp
smtp port is 25
It's not picking up the change from port 25 to 125 when I edit %etc%\services.
Trevor Hemsley
<Trevor....@mytrousers.ntlworld.com> wrote:
> On Fri, 11 Dec 2009 12:14:51 UTC in comp.os.os2.misc, Paul Ratcliffe
> <ab...@orac12.clara34.co56.uk78> wrote:
>
> > On 8 Dec 2009 17:56:05 GMT, PaulRS <prs...@Zverizon.net> wrote:
> >
> > > - I am thinking that OS/2 boot programs must store these ports
> > > SOMEWHERE
> >
> > You've already been told by more than one person that this doesn't happen.
> > WHY do you keep harping on about it?
>
> Maybe because the results seem to back him up?
Interestingly, repeating this test on my other OS/2 system shows that it works
correctly there. Makes me think that there is a bug in some versions of the
code.
PaulRS
<Trevor....@mytrousers.ntlworld.com> wrote:
> On Fri, 11 Dec 2009 13:46:12 UTC in comp.os.os2.misc, "Trevor Hemsley"
> <Trevor....@mytrousers.ntlworld.com> wrote:
>
> > On Fri, 11 Dec 2009 12:14:51 UTC in comp.os.os2.misc, Paul Ratcliffe
> > <ab...@orac12.clara34.co56.uk78> wrote:
> >
> > > On 8 Dec 2009 17:56:05 GMT, PaulRS <prs...@Zverizon.net> wrote:
> > >
> > > > - I am thinking that OS/2 boot programs must store these ports
> > > > SOMEWHERE
> > >
> > > You've already been told by more than one person that this doesn't happen.
> > > WHY do you keep harping on about it?
> >
> > Maybe because the results seem to back him up?
>
> Interestingly, repeating this test on my other OS/2 system shows that it works
> correctly there. Makes me think that there is a bug in some versions of the
> code.
>
Sorry to "offend" Mr. Radcliff, but to use a NY idiom: "it is what it
is!" What is happening IS happening.
My system is OS/2 4.52 (Merlin2) with all the updates that were last
available on line via Software Choice and the German site:
www.warpupdates.mynetcologne.de/ Also, FixPak 4 (I did not do
FixPak5)
Device Driver XRD003
FixPak 4 XRC004
MTPS WR08708 Also fix for this for Dialer Problems
TCPIP UN02334
USB Upgrade
It is interesting that you find one OS/2 system works and one does not
with your test. Thanks for your "extra-measure" of interest.
Paul
--
Steven Levine
<Trevor....@mytrousers.ntlworld.com> wrote:
Hi Trevor,
> Maybe because the results seem to back him up?
I suspect a TCP/IP stack defect on older stacks.
FWIW, there appears to be a defect in the OpenWatcom headers. I had
to reorder the includes to be
#include <stdio.h>
#include <string.h>
#include <types.h>
#include <netdb.h>
Other than this wcl386 built a working exe with honored changes to
services immediately. I even tried
// setservent(0);
// endservent();
and the code continued to work as expected. This is with
Version numbers of TCP/IP protocol drivers:
SOCKETS.SYS: 6.3100
AFOS2.SYS: 6.3100
AFINET.SYS: 6.3100
However, on another box which is not quite as up to date and is
running
Version numbers of TCP/IP protocol drivers:
SOCKETS.SYS: 6.2004
AFOS2.SYS: 6.2000
AFINET.SYS: 6.2013
The test app fails as Paul describes. Theseus and psfiles agree that
services is not open, so there must be some caching going on.
The older stack has another interesting defect. Running the test app
over a telnet connection traps in TNLS16.DLL.
Trevor Hemsley
<ste...@nomail.earthlink.net> wrote:
> On Fri, 11 Dec 2009 13:46:12 UTC, "Trevor Hemsley"
> <Trevor....@mytrousers.ntlworld.com> wrote:
>
> Hi Trevor,
>
> > Maybe because the results seem to back him up?
>
> I suspect a TCP/IP stack defect on older stacks.
Me too but I was surprised to get differert results on my two boxes because I
thought they were the same level of everything!
> Other than this wcl386 built a working exe with honored changes to
> services immediately. I even tried
>
> // setservent(0);
> // endservent();
I only added those two in desperation "clutch at straws" mode to try to see if
they made any difference (they didn't).
Steven Levine
<Trevor....@mytrousers.ntlworld.com> wrote:
Hi Trevor,
> > // setservent(0);
> > // endservent();
>
> I only added those two in desperation "clutch at straws" mode to try to see if
> they made any difference (they didn't).
I figured that. I experimented with moving these calls to the top of
the code with no change in behavior. FWIW, as I read the docs,
setservent is intended to be used before the getsrv... functions. Of
course, if the stack is not caching the values, this will not change
the behavior we are seeing.
J de Boyne Pollard
TH> try to see if they made any difference (they didn't).
As is expected. As I wrote before, they only mean something within a
single process. They won't affect what you're doing, which of course
involves two separate processes.
J de Boyne Pollard
... are largely irrelevant. (-: Look at the versions and datestamps
of your TCP*.DLL DLLs. They are where the code lives.
SL> Theseus and psfiles agree that services is not open [...]
It's not necessarily held open once the call has returned, note. You
need to check that the file is not opened and closed by the call.
SL> The older stack has another interesting defect. Running
SL> the test app over a telnet connection traps in TNLS16.DLL.
You're using the 16-bit DLLs, aren't you? There is a mechanism that
is capable of causing this behaviour with 16-bit DLLs. One would have
to check the segment flags in the 16-bit DLLs' headers to see whether
this mechanism is a possibility. Dump your DLLs with the executable
dumping utility of your choice and look for 16-bit segments that are
marked as shareable and read-write.
Steven Levine
<J.deBoyn...@Tesco.NET> wrote:
Hi,
> ... are largely irrelevant. (-: Look at the versions and datestamps
> of your TCP*.DLL DLLs. They are where the code lives.
The protocol drivers and the protocol DLLs are typically installed as
a unit so I prefer to refer to these.
> It's not necessarily held open once the call has returned, note. You
> need to check that the file is not opened and closed by the call.
My point was that the code appeared to be caching the data rather than
holding the file open. There was a DHCP defect that held autoexec.bat
open with interesting side effects.
> You're using the 16-bit DLLs, aren't you?
32-bit protocol DLLs and 16-bit application DLLs, so that's probably
the reason. One of these days, I'll install the 32-bit applications
on this box.
> to check the segment flags in the 16-bit DLLs' headers to see whether
> this mechanism is a possibility. Dump your DLLs with the executable
> dumping utility of your choice and look for 16-bit segments that are
> marked as shareable and read-write.
This does not appear to be the case for TNLS16.DLL.
J de Boyne Pollard
JdeBP> of your TCP*.DLL DLLs. They are where
JdeBP> the code lives.
SL> The protocol drivers and the protocol DLLs are typically
SL> installed as a unit so I prefer to refer to these.
That doesn't make them any the more relevant, or their version numbers
any the more meaningful (or useful for M. PaulRS to compare xyr files
against). They are not the files where the code lives.
JdeBP> You're using the 16-bit DLLs, aren't you?
SL> 32-bit protocol DLLs and 16-bit application DLLs, [...]
There's not really any such distinction. Even aside from the fact that
a distinction between "protocol" and "application" is a false
dichotomy, since many network "protocols" are just ordinary
application code, the fact of the matter is that the DLLs themselves
are a complete hodge-podge. IBM added new 16-bit functions in the 32-
bit DLLs, for example, that weren't in the 16-bit DLLs. And they
contain some functions that have little to no logical connection with
networking, such as getpid(). It's really quite a mish-mash. I could
go on at some length.
JdeBP> One would have to check the segment flags
JdeBP> in the 16-bit DLLs' headers to see whether this
JdeBP> mechanism is a possibility. Dump your DLLs
JdeBP> with the executable dumping utility of your
JdeBP> choice and look for 16-bit segments that are
JdeBP> marked as shareable and read-write.
SL> This does not appear to be the case for TNLS16.DLL.
Your aversion to looking at your TCP*.DLL DLLs is strong, given that
you've resisted twice in one message. It doesn't however, change the
fact that those are the files where the code and data live for the
functions being discussed. So *those* are the files that you should
be checking for shareable read-write segments. Overcome your phobia
of TCP*.DLL and have a look. (-: If there's a shareable read-write
data segment or two there, then there's a plausible explanation for
how getservbyname() retains data across processes with those DLLs,
made all the more plausible by the fact that with the 32-bit DLLs
there are no such shareable read-write segments, and the behaviour
complained of is not observed.
PaulRS
<J.deBoyn...@Tesco.NET> wrote:
>
> Your aversion to looking at your TCP*.DLL DLLs is strong, given that
> you've resisted twice in one message. It doesn't however, change the
> fact that those are the files where the code and data live for the
> functions being discussed. So *those* are the files that you should
> be checking for shareable read-write segments. Overcome your phobia
> of TCP*.DLL and have a look. (-: If there's a shareable read-write
> data segment or two there, then there's a plausible explanation for
> how getservbyname() retains data across processes with those DLLs,
> made all the more plausible by the fact that with the 32-bit DLLs
> there are no such shareable read-write segments, and the behaviour
> complained of is not observed.
As the original poster I have been following your discussions since.
I must say they are far above my head. However, it may be helpful
(???) to list the TCP8.DLL's my system is using that is having the
problem. I thought I got all the latest upgrades before IBM shut off
OS/2 - However, by date, some are pretty old. I retrieved the list
below with ">dir tcp*.dll /s/p"
Directory of I:\MPTN\DLL
9-18-01 5:48p 19293 0 tcp32dll.dll
7-10-98 11:22a 473116 0 TcpDial.dll
7-10-98 11:22a 9428 0 TcpDialr.dll
5-21-04 11:15a 98611 0 tcpip32.dll
9-18-01 5:48p 14344 0 tcpipdll.dll
5-21-04 11:21a 36474 0 tcpmri.dll
6 file(s) 651266 bytes used
Directory of I:\TCPIP\dll
5-21-04 4:22p 292407 0 TCPOOCS.DLL
5-21-04 4:22p 41497 0 TCPOOCSJ.DLL
9-17-01 3:15p 503845 61 TCPOOCSX.DLL
5-21-04 4:22p 96361 0 TCPUNX.DLL
4 file(s) 934110 bytes used
Maybe this helps OR NOT.
Paul
--
baden.ku...@gmail.com
> On Thu, 17 Dec 2009 12:35:26 UTC, J de Boyne Pollard
>
FYI, my system which works exactly like you wish
yours would, has:
MR2I.exe ver 2.37
C:\OS2\INSTALL\SYSLEVEL.OS2
Convenience Package - OS/2
Warp 4 Base Operating System
Version 4.52 Component ID 5639A6101
Type 0C
Current CSD level: XR04502
Prior CSD level: XR04502
C:\IBMCOM\SYSLEVEL.TRP
IBM OS/2 LAN Adapter and Protocol Support
Version 5.40 Component ID 5639A5700
Current CSD level: WR08610
Prior CSD level: WR08600
Version numbers of TCP/IP protocol drivers:
SOCKETS.SYS: 6.1002
AFOS2.SYS: 6.1000
AFINET.SYS: 6.1001
good luck,
Baden
PaulRS
>
> FYI, my system which works exactly like you wish
> yours would, has:
>
> MR2I.exe ver 2.37
>
> C:\OS2\INSTALL\SYSLEVEL.OS2
> Convenience Package - OS/2
> Warp 4 Base Operating System
> Version 4.52 Component ID 5639A6101
> Type 0C
> Current CSD level: XR04502
> Prior CSD level: XR04502
>
> C:\IBMCOM\SYSLEVEL.TRP
> IBM OS/2 LAN Adapter and Protocol Support
> Version 5.40 Component ID 5639A5700
> Current CSD level: WR08610
> Prior CSD level: WR08600
>
> Version numbers of TCP/IP protocol drivers:
> SOCKETS.SYS: 6.1002
> AFOS2.SYS: 6.1000
> AFINET.SYS: 6.1001
>
> good luck,
> Baden
>
>
Interesting . . . In running "syslevel" comparing what you have, it
appears that OLDER is working better than newer. However, I did not
get any of the Version numbers of the TCP/IP protocol Drivers with
"SYSLEVEL"
In the syslevel.os2 and syslevel.trp this is what I got
I:\OS2\INSTALL\SYSLEVEL.OS2
Convenience Package
OS/2 Warp 4 Base Operating System
Version 4.52 Component ID 5639A6101
Type 0C
Current CSD level: XR0C004
Prior CSD level: XR04503
I:\IBMCOM\SYSLEVEL.TRP
IBM OS/2 LAN Adapter and Protocol Support
Version 6.01 Component ID 5639A5700
Current CSD level: WR08708
Prior CSD level: WR08701
Paul
--
Dave Yeo
> Interesting . . . In running "syslevel" comparing what you have, it
> appears that OLDER is working better than newer. However, I did not
> get any of the Version numbers of the TCP/IP protocol Drivers with
> "SYSLEVEL"
Use inetver.exe. The newest 6.31 versions are on Hobbes somewhere
Dave
PaulRS
wrote:
Thanks Dave - Looks like I got the newer INET Versions too!
[I:\]inetver
Version numbers of TCP/IP protocol drivers:
SOCKETS.SYS: 6.3100
AFOS2.SYS: 6.3100
AFINET.SYS: 6.3100
--