[Dxspider-support] Daily user disconnections

Wed Nov 2 20:35:13 GMT 2016

Thanks, Lee.

"Back in the day"... when this was all largely a telnet session that was
VISIBLE to the users, those of them who understood DOS could pretty much
acclimate to the idea that... okay, I type things at this console prompt...
I see my connection... there are commands I need to know... not too bad.

But then we put sexy user interfaces in-front-of that telnet session... and
the users no longer needed to know the commands... or even be aware that
there's a telnet session behind this at all.  That's pretty much when all
these problems came up as hams (many who are ECiLO - Extra Class in License
Only... or "over-night sensations") no longer understood how anything works.

One Extra Class ham recently contacted us to complain about his radio.  You
see, it has the International icon for "On/Off"... and then had another
button that said "Power".  He was irritated that the radio was not turned
on or off when he pressed the "Power" button.

Bottom line is... you can lead the horses to water, but you can't make them
drink.  I think what you've done with CC Cluster there is a really good
approach for overcoming ignorance.  (no offense intended to anyone)

Mike, WA9PIE

On Wed, Nov 2, 2016 at 1:48 PM, Lee Sawkins via Dxspider-support <
dxspider-support at dxcluster.org> wrote:

> Hi Mike
>
> I see users all the time on my own CC Cluster node that try to have
> multiple connections with the same SSID.  What I have done is to modify
> their SSIDs when they log in by adding a zero, if possible.  ie if a user
> logs in as VE7XX, and then makes another connection, the node assigns him
> the call VE7XX-0 and if he makes a third connection I assign that one
> VE7XX-00.  If as user connects as VE7XX-1, his second connection is
> VE7XX-01.  There can be no third connection as VE7XX-001 as other software
> will not allow a three digit SSID.  If a user logs in as VE7XX-16, there
> can be no second connection as VE7XX-016.  I have been doing this for quite
> some time.  No one seems to even noticed, as I have not even had one
> comment about this.  What it does show me is that many users have three
> stable connections to my node at times, SSID no number, SSID-0 and
> SSID-00.  I even have some users attempting to make 4 or even more
> connections without an SSID.  I locked one guy out for this many months
> ago, and guess what, he hasn't noticed and continues to try and connect
> multiple times.  If a user is not trying to make multiple connects, what I
> see is that when one connection is made with a modified SSID, then the
> other connection immediately drops.  This is caused by the users software
> thinking the connection is gone and the node still thinking he is connected.
>
> Lee
>
> ------------------------------
> *From: *"Michael Carper, Ph.D. via Dxspider-support" <
> dxspider-support at dxcluster.org>
> *To: *"The DXSpider Support list" <dxspider-support at dxcluster.org>
> *Cc: *"Michael Carper, Ph.D." <mike at wa9pie.net>
> *Sent: *Wednesday, November 2, 2016 12:49:03 PM
>
> *Subject: *Re: [Dxspider-support] Daily user disconnections
>
> Lee,
>
> This thread goes back several months, but I found something that I thought
> I'd share with you.
>
> I was watching the login/logout activity on my cluster.  I reached out to
> one of the users who I can see that will logout... and immediately login
> (and there are about 10% of my connected users who do this).  I wanted to
> find out if it was a software problem with HRD.
>
> The user I reviewed was constantly logging out... logging in.
>
> Turns out... after investigating... he had HRD installed on two computers
> (which is fine)... and he was attempting to connect using the same call
> from both computers to my cluster.  He was using the "Reconnect on
> disconnect" option on both.
>
> So when the second instance of HRD connected... it logged out the previous
> one... and logged in from the new one... and this process kept repeating
> itself in an alternating manner indefinitely.
>
> My plan is to contact the users on my cluster and provide them a document
> about using SSIDs and see if that helps the remaining users.
>
> Mike, WA9PIE
>
> On Sat, Apr 23, 2016 at 9:11 PM, Lee Sawkins <ve7cc at shaw.ca> wrote:
>
>> You might not like to hear this, but HRD is the source of my frequent
>> user disconnects.   My HRD users are coming and going all the time.  I have
>> complained about this before, but nothing has ever been done.  It appears
>> if the node does not reply to HRD immediately the program will disconnect.
>> ALL other user client programs are stable and do not do this.
>>
>> Lee VE7CC
>>
>> ------------------------------
>> *From: *"Michael Carper, Ph.D." <mike at wa9pie.net>
>> *To: *"The DXSpider Support list" <dxspider-support at dxcluster.org>
>> *Sent: *Saturday, April 23, 2016 11:39:52 PM
>> *Subject: *Re: [Dxspider-support] Daily user disconnections
>>
>>
>> I don't have that line in my crontab... but I still have frequent user
>> disconnections.  I haven't yet figured it out.
>>
>> Mike, WA9PIE
>>
>> On Sat, Apr 23, 2016 at 4:47 PM, ei6iz.Brendan Minish <
>> ei6iz.brendan at gmail.com> wrote:
>>
>>> It's been bugging me for a while that ei7mre seems to kick off users
>>> every day, despite the cluster remaining running
>>> Today I did a bit of digging and this seems to coincide exactly with the
>>> cronjob that  is run by the system  from
>>> cmd/crontab at 3AM
>>> the offending entry appears to be
>>>
>>> 0 3 * * * Spot::daily()
>>>
>>> is this because the job called is taking too long and it's in the main
>>> thread? or do I have a problem elsewhere I should be investigating?
>>> Do I risk really messing things up if I change the schedule of this job
>>> to run at a time when I might be awake, to allow me to do a bit more
>>> debugging
>>>
>>> ei7mre runs on a Centos7 VM with adequate resources (20G of SSD backed
>>> Storage, 1G ram)  and the dxspider process never actually crashes (up-time
>>> is 250 days at present)
>>> ei7mre typically has ~ 140 Users at weekends these days and never feels
>>> in the least bit sluggish, very light CPU load (0.04) most of the time
>>>
>>>
>>> --
>>> 73
>>> Brendan EI6IZ
>>>
>>>
>>> ___________________________________________
>>
>> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at dxcluster.org
> http://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.tobit.co.uk/pipermail/dxspider-support/attachments/20161102/b0e4821c/attachment.html>