Text 10527, 241 rader
Skriven 2013-09-29 13:53:48 av Jon Justvig (1:261/38)
Ärende: Fidonews Vol 30 no 39 Page: 5
=====================================
The Guide to Unhappiness, or Communication Problems
Ulrich Schroeter, 2:244/1120
If you've just lost your Bossnode or your uplink, you have the
possibility to gain more frustration.
In todays Fidonet world of major FoIP links, you're searching
for an uplink who is able to support you with an IP link.
With a majority of BinkD installations, the maximum has been
done, to support you for your unhappiness.
Step I. Write a netmail to your new Bossnode of your choice.
Ask him to apply you a link. As you've still running
as Point #13, thats sufficient and if this point
number is still not assigned, you'd be delighted to
get this point number. Notify the new Bossnode, that
you'll call his system frequently.
Step II. The Bossnode assigns the requested Point number,
adds all the links, Tosser, Ticker, Tracker, Session-
passwords, sends you a welcome netmail, attaches
the newest Nodelist as Fattach, same with current
Pointlist and still awaits your next call.
Step III. (2 hours are enough to receive a first reply)
Calling the new Bossnodes system.
Nothing ...
(Ok, Bossnode still didn't read my netmail ...)
Step IV. Bossnode still has set a reply on hold for delivery.
But damn - mails on hold haven't been picked up by the
new downlink in his last connection attempt :-P
Step V. (Ok, 120 min's later, sleepyheads are still awake.
Give it a new try ...)
Calling the new Bossnodes system.
Nothing ...
(Oh boy, still have the time today to do all the
reconfiguration, but still got no response so far)
Step VI. The new Bossnodes still noticed the latest call
from his new Point configured. But all the mails and
files set on hold had not been transfered yet in
the Points connection attempt. Sounds like an old
Crosspoint problem, that requires a dummy packet
to be delivered, to trigger transfer of mails and
files that awaits delivery.
Ok, logfile shows the current IP the point calls from.
Adding the dns hostname into Binkd config for the new
Point with password set to "-" and setting the Crash
flavor. Give it a try to send a crash mail.
But Binkd still reports
[#] trying <current dns hostname>...
[#] unable to connect: {10060} Connection timed out
results as expected. The point has not opened the
default Binkd port in the firewall ...
Removing the dns hostname from config ...
How can I send the Point a message, who still awaits
my response? The response that still sits in my
outbound since about 12 hours?
Ok, the mailer presents my systemname, my location,
my sysopname ... maybe the new Point reads my
short message ?!?
Hi .13, please call voice #######
Mail still resides in outbound for delivery
Step VII. (New day - new try ...)
Calling the new Bossnodes system.
Nothing ...
(Damn - what a lazy sysop ... now had approx 24 hours
time to add me as new point and sending me a
response, but still no success :-P )
Step VIII. The new Bossnodes still noticed the last call.
Hopefuly the Point looks into his logfiles to
notice my short message ....
awaiting a call ...
Step IX. (4 hours later ... for a Sunday a good time to give
it a try again)
Calling the new Bossnodes system.
Nothing ...
(??? Did Fidonet still died that silently, that a big
Hub doesn't respond to my netmail?)
Step X. Mhh. the last call now sends my short message the
2nd time, but still no phone call yet.
The point must be blind ...
Ok, Binkley outbound ... mails sets on hold.
Should I give a try with bundles set to "Normal" and
"Direct" ?
Ok, give it a try.
Writing a couple of netmails, reporting the problems
identified, setting the Flag "Direct" on the first
mail, and leave it "Normal" on the 2nd netmail.
For better analysis, a more frequent calling would
become helpful, but ok. Leave the Point a modified
short message:
"Please send Freq FILES in your next call"
Step XI. (late evening ... give it the last try for today)
Calling the new Bossnodes system.
Nothing ...
(mhh. Maybe the sysop is on a short weekends trip?
ok, tommorow is a new working weekday)
Step XII. ??? ... Its possible, that the Point still tries
to contact other potential new Bossnodes, but
probably he still has no luck connecting to any
system?
So I write an echomail in the local sysops chatter
echo. Asking around if another bossnode has
received a request from a Point #13 searching for
a new Bossnode, but all his calls goes dev/nul
despite the fact, mail is sitting on hold ...
Step XIII. (new day, working weekday ... the new Bossnode
should have returned from his short vacation)
Calling the new Bossnodes system.
Nothing ...
(Ok, maybe the Bossnode reads his mails in the
evening ...)
Step XIV. Still received a message in the sysops chatter
that the Point still has sent a request to at
least one another potential Bossnode, but
all his calls still results the same way -
No mails delivered.
If someone has contact to Point #13 please
leave him a message, that may system still has
mail waiting for him.
Step XV. (new day, working weekday, 2nd try ...)
Calling the new Bossnodes system.
Nothing ...
(Ok, maybe the Bossnode reads his mails in the
evening ...)
Step XVI. Damn, no Binkd configuration parameter around
that pushes the waiting mail on hold in the
next Points session?
Maybe an updated Binkd revision has a bugfix
implemented? to circumvent this dummy packet
problem?
The Point still sent no email address,
no phone number in his initial request for
a new point number ...
Maybe he did published an email address in
one of his posts in one of the echo areas?
Ok, give it a try ...
Searching the Fidobase MySQL database from the
Fidonet-History-Project for older mails from
this Point ...
SELECT count(id) FROM fidobase.echo_e
where fromname='<username>';
Result: 78
Wouw ...
Displaying the mails shows only the shortest
possible footer ... Greetings, <nickname>
But the posts in two specific echoes gives an
indication that the Point was in contact with two
sysops I'm knowing well.
Writing my results to the sysops chatter in the
hope that the known sysops had contact with the
Point in the past.
Step XVII. (new day, working weekday, late evening ...)
Calling the new Bossnodes system.
Nothing ...
(tock tock tock ... anybody out there?)
Step XVIII. No one still responded to my sysop chatters mails.
No success by naming the two known sysops that they
may had contact with the Point in the past.
Asking around if someone may have an idea to
get the Point on the hook ... or maybe he
get success at anothers Bossnode system?
Step XIX. (another day ...)
Calling the new Bossnodes system.
Nothing ...
(frustration ON)
Step XX. Why in hell, the Point didn't read his mailer logs?
Why in hell he buyed the oneway ticket to ride?
Step XXI. (...)
Calling the new Bossnodes system.
Nothing ...
(frustration DOUBLE-ON)
Step XXII. Ok, studying the Binkd config again.
Yesterday I've read in a history log about
an added parameter Send-If-Pwd and a TRF log entry
fixed around 2005. But my revision is realy new.
From June this year ... Hmm.
Reading again the sample Binkd config line by line
after I didn't find anything in a global file
search of Binkd documentation about TRF and dummy
packet. What is this Send-If-Pwd for?
Hmm. Re-reading the short description again and
again.
# Don't send (only receive) files if no password
# for an inbound session
Hmm. I've added the new pointnumber with a session
password, but the Point still calls with his old AKA.
As the Point didn't send a One-Time-Password in his
request I cannot add a session password in the binkd
config for the Points old AKA as I have no chance to
get the One-Time-Password transfered over to him :-P
so he can temporarely configure his system, to send
a session password, so SEND-IF-PWD becomes true :-O
Ok, I think I've found the source of the problems
discovered in the last few days ...
Give it a try ...
Setting SEND-IF-PWD on Remark in Binkd config and
waiting until the Point calls again my system.
Hours later ....
Step XXIII. (...)
Calling the new Bossnodes system.
HEY, whats that ? tons of mails and files ...
the session doesn't want to finish ...
still more and more files ...
Summary: If you want to get the ultimate unhappiness,
you send your request to as many sysops as
possible
:-)
FIDONEWS Vol 30 No 39 Page 5 September 30, 2013
-----------------------------------------------------------------
--- BBBS/Li6 v4.10 Dada-1
* Origin: Prism bbs (1:261/38)
|