Curious Polarbar op change?

[Mike Luther]

For years I have been using the older PolarBar last 'stable' OS/2 operation to
only check a couple of Email accounts that have either no traffic or only a
single message or two a year in them. This is on an MCP2 latest everything
system that for a long time now has been running on Jav 1.42 and also has, for
certain specific purposes Java 1.18 on it.

Last week for the first time, the whole program and operation still runs just
fine, but it takes over a minute to load! Even if it is the very first object
I select from a cold boot! There have been no changes in this system at this
time and since then that should have anything to do with this. Also, in this
case, I have Panda's still fully functional virus checker for OS/2 that still
works for at least disk and op system checking, including .JAR files and so
on. Even with the still as daily virus file update, it reports nothing bad on
this whole box. Nothing else on the whole box seems slow. Nothing in a
Theseus look at memory in use seems to indicate anything unusual is going on.
As well, there is plenty of disk space for anything going on here, plus no
disk analysis suggests anything wrong. That said, even from a cold boot and
then a Netstat -r trace before PolarBar start shows nothing wrong. However,
when I first then start PolarBar, then do a Netstat -r on it after it has
loaded, I see both a 66.76.2.132 and 66.76.2.133 hit which Whois traces to
ABUSE1394-ARIN which suggests that it is hitting this at ***@suddenlink.net,
of which suddenlink is the IP service for this box.

Polarbar is not set up at all to automatically connect to check for mail on
startup in this case. On this same box, Post Road Mailer which is still on it
as well as the latest general release for PMMail show none of this issue.

I have looked at all the Java files and PolarBar data and executable files
carefully and none of them show any 'modification' as if they might have been
'morphed' or corrupted 'somehow' at all, as well as the Panda OK check.

I have seen comments that there are new Java nasty things that have been
suggested might be facing Windows boxes. This system has nothing in it that
would link it to Windows, Odin, and no Netbios over OS/2 install at all.

Any thoughts here?

Thanks!

[Dave Yeo]

Post by Mike Luther
I have seen comments that there are new Java nasty things that have been
suggested might be facing Windows boxes. This system has nothing in it
that would link it to Windows, Odin, and no Netbios over OS/2 install at
all.
Any thoughts here?

Java1.4.2 is a Windows program using a modified Odin to run so it may be
possible for something to take advantage of a Java flaw.
Have you tried using iptrace to see what it is sending?
Dave

[Mike Luther]

Thanks Dave ..

Post by Dave Yeo
Java1.4.2 is a Windows program using a modified Odin to run so it may be
possible for something to take advantage of a Java flaw.
Have you tried using iptrace to see what it is sending?
Dave

I need a bit more help. OK, I ran "iptrace" during the delayed load time in
an OS/2 window. I hit the enter key when it finished. That did produce a
file IPTRACE.DMP which as I watched it, curiously had 32 hit items go through
the remarks of the iptrace operation when this was being done. I then used
the command I thought I recalled as "ipformat -x" which did produce the file
IPTRACE.ENC from the dump file. Fuzzy mind time for Mikey here. Both of
those trace files are not 'organized' that I can 'read' them.

There must be some 'read-it' tool that I have forgotten how to access or use
that will let me step through what you are teaching me to study. A bit
further help here?

Thanks Dave!

[John Small]

Post by Mike Luther
Thanks Dave ..

Post by Dave Yeo
Java1.4.2 is a Windows program using a modified Odin to run so it may be
possible for something to take advantage of a Java flaw.
Have you tried using iptrace to see what it is sending?
Dave

I need a bit more help. OK, I ran "iptrace" during the delayed load time in
an OS/2 window. I hit the enter key when it finished. That did produce a
file IPTRACE.DMP which as I watched it, curiously had 32 hit items go through
the remarks of the iptrace operation when this was being done. I then used
the command I thought I recalled as "ipformat -x" which did produce the file
IPTRACE.ENC from the dump file.

I think the "-x" may be the error. According to the help for ipformat,
the "-x" causes the the ouput format to be that which a Network
General sniffer (not necessarily a human) can read it.

Try it without the "-x".

You might also want to try iptrace with an interface parameter, like:
iptrace lan0
Without the interface paramter you will get all traffic, including
that on the loopback interface which you may not want.

[Mike Luther]

Post by John Small
Try it without the "-x".
iptrace lan0
Without the interface paramter you will get all traffic, including
that on the loopback interface which you may not want.

Done and that got me a readable text file. Let's switch this branch reply to
my answer to PGAGA to keep the yappit text low, OK, chuckle...

[PGAGA]

Saturday, December 17, 2011

Hi Mike!

You might try addressing this to the Polarbar forum -
https://groups.google.com/forum/#!forum/polarbar-mailer.

Post by Mike Luther
For years I have been using the older PolarBar last 'stable' OS/2 operation

I assume you mean 1.25e - if not you should upgrade to 1.25e. There
are issues with the previous 1.25 releases.

Post by Mike Luther
Last week for the first time, the whole program and operation still runs just
fine, but it takes over a minute to load!  Even if it is the very first object
I select from a cold boot!  There have been no changes in this system at this
time and since then that should have anything to do with this.  Also, in this
case, I have Panda's still fully functional virus checker for OS/2 that still
works for at least disk and op system checking, including .JAR files and so
on.  Even with the still as daily virus file update, it reports nothing bad on
this whole box.  Nothing else on the whole box seems slow.  Nothing in a
Theseus look at memory in use seems to indicate anything unusual is going on.
  As well, there is plenty of disk space for anything going on here, plus no
disk analysis suggests anything wrong.  That said, even from a cold boot and
then a Netstat -r trace before PolarBar start shows nothing wrong.  However,
when I first then start PolarBar, then do a Netstat -r on it after it has
loaded, I see both a 66.76.2.132 and 66.76.2.133 hit which Whois traces to
  of which suddenlink is the IP service for this box.

Sounds like the change is not caused by your box.

I cannot be much help since I use the latest PBM Daily with the latest
mail.jar most of the time. I know that because of changes by
providers from whom I am accessing my email I have had to use Stunnel
on all four of the operating systems with which I use PBM.

Phil

[Mike Luther]

Thanks Phil ..

Post by PGAGA
Saturday, December 17, 2011
Hi Mike!
I assume you mean 1.25e - if not you should upgrade to 1.25e. There
are issues with the previous 1.25 releases.

Yes, already done, version 2261.zip is in use.

Post by PGAGA

Post by Mike Luther
I see both a 66.76.2.132 and 66.76.2.133 hit which Whois traces to
of which suddenlink is the IP service for this box.

Sounds like the change is not caused by your box.

Yep, you are correct. The only contacts that wait and wait and wait here are
to those addresses which are the DNS primary and secondary server addresses
for Suddenlink that are in use here.

Post by PGAGA
I cannot be much help since I use the latest PBM Daily with the latest
mail.jar most of the time. I know that because of changes by
providers from whom I am accessing my email I have had to use Stunnel
on all four of the operating systems with which I use PBM.

I do use Stunnel for them all the time for PRM and for PMMail. However, is
there a special setup issue that goes for PolarBar that I am missing? And in
this case, recall that I have already posted that I've been using this same
setup for years now with no problen like this. As well, I just checked this
issue with another completely different box and it has the same delay that
showed up suddenly on this one!

Hmmmmmmmmmmm.. I wonder? Could this be somehow caused by an issue with IPV6
and that the Java interface to PolarBar could somehow have a timing issue
which isn't letting the DNS search for 'something' complete per the alloted
'time' to do this? Or, interestingly, is this a bad puppy DNS request to hit
some IP site to do something we wouldn't want to be doing, in OS/2, exactly
what we might be facing with the recent 'Java' box hacking attempts I've sort
of seen reported? That might now actually be an issue to us OS/2 folks as
well?

I used the command "ipformat > iptrace.txt" to generate the output file which
shows some 32 pops to get this DNS reply without an answer until it comes back
about a minute later from Suddenlink. Or .. wherever? That report text file
is about 32K in size and 958 lines long in text. Plus if I look at this with
IPSpeed enabled, what is going on is 'send' after 'send' to the IP with no
reply, no reply until the 'answer' comes back.

And there is nothing like this showing up on the same boxes for PRM or PMMail
at all..

Inquiring mind wants to know, and thoughts here please?

[Dave Yeo]

Post by Mike Luther
I used the command "ipformat > iptrace.txt" to generate the output file
which shows some 32 pops to get this DNS reply without an answer until
it comes back about a minute later from Suddenlink. Or .. wherever?
That report text file is about 32K in size and 958 lines long in text.
Plus if I look at this with IPSpeed enabled, what is going on is 'send'
after 'send' to the IP with no reply, no reply until the 'answer' comes
back.
And there is nothing like this showing up on the same boxes for PRM or
PMMail at all..
Inquiring mind wants to know, and thoughts here please?

Perhaps try a different DNS server? Perhaps 208.67.222.222, an alternate
root who's name slips my mind right now.
Dave

[Steve Wendt]

Post by Dave Yeo
Perhaps try a different DNS server? Perhaps 208.67.222.222, an alternate
root who's name slips my mind right now.

Google has a pretty fast one, with an easy to remember IP: 8.8.8.8

[Will Honea]

Post by Steve Wendt

Post by Dave Yeo
Perhaps try a different DNS server? Perhaps 208.67.222.222, an alternate
root who's name slips my mind right now.

Google has a pretty fast one, with an easy to remember IP: 8.8.8.8

I've been bitten by several ipv6 related bugs lately. Qwest recently pushed
an "upgrade" for their DSL routers (private label Actiontec units) that
incorporated a bunch of ipv6 functionality. Unfortunately, they forgot to
tell you how to disable ipv6 DNS searches even if the ipv4 request returned
a valid ipv6 address - about as useful as molasses in the gear box at 20
below - and it took me a week to kill that function.

I had to drop PolarBar a while back when the mail server hosting my accounts
changed their protocol and PBM headers were all rejected. Daily builds
didn't help and it looks to be a Java issue as old versions still work.

[Shmuel (Seymour J.) Metz]

Post by Will Honea
I had to drop PolarBar a while back when the mail server hosting my
accounts changed their protocol and PBM headers were all rejected.

What are you trying to say? There's nothing in SMTP corresponding to
rejecting a header. Do you mean that you got a 5yz response to EOD
with text mentioning a header? If so, what was the text? If not, what
rejection response did you get and what command did it follow?

My guess would be that the failure had nothing to do with headers but
was related to a change in authentication procedures. Did you send a
HELO command or EHLO, and, if an EHLO copmmand, what was the response?
Were you sending on port 587 to an MSA or on port 25 to an MTA?

[Will Honea]

Post by Shmuel (Seymour J.) Metz

Post by Will Honea
I had to drop PolarBar a while back when the mail server hosting my
accounts changed their protocol and PBM headers were all rejected.

What are you trying to say? There's nothing in SMTP corresponding to
rejecting a header. Do you mean that you got a 5yz response to EOD
with text mentioning a header? If so, what was the text? If not, what
rejection response did you get and what command did it follow?
My guess would be that the failure had nothing to do with headers but
was related to a change in authentication procedures. Did you send a
HELO command or EHLO, and, if an EHLO copmmand, what was the response?
Were you sending on port 587 to an MSA or on port 25 to an MTA?

Agreed: auth problem. I tried every option one the list but never got
anywhere. I also began having a bunch problems with doing anything after
some Java updates (same problems on Windows after Java 1.6.whatever) so I
just moved everyone to something else.

[Mike Luther]

Hello treasured friend!

Post by Will Honea
I've been bitten by several ipv6 related bugs lately. Qwest recently pushed
an "upgrade" for their DSL routers (private label Actiontec units) that
incorporated a bunch of ipv6 functionality. Unfortunately, they forgot to
tell you how to disable ipv6 DNS searches even if the ipv4 request returned
a valid ipv6 address - about as useful as molasses in the gear box at 20
below - and it took me a week to kill that function.
I had to drop PolarBar a while back when the mail server hosting my accounts
changed their protocol and PBM headers were all rejected. Daily builds
didn't help and it looks to be a Java issue as old versions still work.

Has nothing to do with PolarBar and Java 1.42, as now seen. I was going to be
able to go to another location and auto-hit a different DNS server after
today, but as of this morning here on 12/20/2011 with Suddenlink, the
'problem' has solved itself! The 'normal' about six seconds for PolarBar to
open against the Suddenlink News server showed up again all by itself on any
of the test boxes I can try it with here in College Station in the 'normal
about six seconds flat! As well, the complete interject to that spam check
network disappeared too!

My guess is that for some reason there, as you suggested, was a change in
their mail server which 'thought' that the PBM or whatever java probe to load
it for OS/2 was a bad boy. And now, I have no way of carrying this research
further to see what in the heck was going on.

Oh well. As much as for me, what I was trying to do was to help us all here
if 'something' noxious was being a probiscus on usn'z here in OS/2ziee.

Thanks again for your suggestion Will. I sorta think, absent of real proof,
that it was sure close to correct.