Hi Martin..

//Resending.. I think I played around with the 5D "Uplinks" part too much.//

Ah, could that explain why all your posts of the 30th were in
triplicate :-)

Could be. But I'm *not* going to mess around with Uplinks anymore. The strange thing was that after adding a new Uplink in the list (but not fully configuring it, because I really don't have another uplink) and replying to about 5 messages or so, the Poll reported "nothing to send".

When I polled again after a few seconds, I saw a pkt go off, but then I saw an BinkP error in the log, and the session just froze - and not disconnecting. I disconnected manually. Here is a glimpse of events:


30.03.19 23:12:45 SESS Session established, remote reports "secure"
30.03.19 23:12:45 SEND Sending 0688AD71.pkt (5774 bytes)
30.03.19 23:12:45 RDON Receive complete
30.03.19 23:12:45 SEND Sending 0688AD70.pkt (5852 bytes)
30.03.19 23:12:46 SENT File 0688AD71.pkt sent
30.03.19 23:12:46 DELE Deleted 0688AD71.pkt
30.03.19 23:12:47 BERR BinkP Error: Unexpected command frame (6) in WaitOK state
30.03.19 23:12:58 DISG Disconnecting

30.03.19 23:22:14 SESS Session established, remote reports "secure"
30.03.19 23:22:14 SDON Send complete
30.03.19 23:22:14 RECV Receiving cdbccb47.pkt (6282 Bytes)
30.03.19 23:22:15 BERR BinkP Error: Unexpected data frame during init
30.03.19 23:22:43 UBRK User requests abort

30.03.19 22:53:55 BNUL TIME Sun, 31 Mar 2019 04:53:52 +0300
30.03.19 22:53:55 RVER binkd/1.1a-99/OS2 binkp/1.1
30.03.19 22:53:55 RAKA 2:221/0 - Nothing to send
30.03.19 22:53:55 RAKA 2:221/1 - Sending 5697 bytes in 1 files
30.03.19 22:53:55 RAKA 2:221/360 - Nothing to send
30.03.19 22:53:56 BNUL TRF 0 0
30.03.19 22:53:56 BNUL OPT EXTCMD GZ BZ2
30.03.19 22:53:56 SESS Session established, remote reports "non-secure" 30.03.19 22:53:56 SEND Sending 0688AD6E.pkt (5697 bytes)
30.03.19 22:53:56 RDON Receive complete
30.03.19 22:54:43 UBRK User requests abort

In between, I had started rewriting/reposting (via Forwards) to the echo. And.. it appears that all my rewrites were actually processed. Sorry about the panic. But I never had the BinkP error before.

--- Thunderbird 2.0.0.24 (Windows/20100228)
* Origin: - nntp://rbb.fidonet.fi - Lake Ylo - Finland - (2:221/360)

...and here is what I *think* was the beginning of the problem:

[Note the "Bad address". Maybe that was the result of the incomplete *new* Uplink config.]

30.03.19 22:43:48 BNUL TIME Sun, 31 Mar 2019 04:43:45 +0300
30.03.19 22:43:48 RVER binkd/1.1a-99/OS2 binkp/1.1
30.03.19 22:43:48 RAKA 2:221/0 - Nothing to send
30.03.19 22:43:48 RAKA 2:221/1 - Sending 5697 bytes in 1 files
30.03.19 22:43:48 RAKA 2:221/360 - Nothing to send
30.03.19 22:43:48 BERR BinkP Error: Bad address
30.03.19 22:43:48 DISG Disconnecting

--- Thunderbird 2.0.0.24 (Windows/20100228)
* Origin: - nntp://rbb.fidonet.fi - Lake Ylo - Finland - (2:221/360)

Sunday March 31 2019 19:06, August Abolins wrote to August Abolins:

...and here is what I *think* was the beginning of the problem:

[Note the "Bad address". Maybe that was the result of the incomplete *new* Uplink config.]

30.03.19 22:43:48 BNUL TIME Sun, 31 Mar 2019 04:43:45 +0300
30.03.19 22:43:48 RVER binkd/1.1a-99/OS2 binkp/1.1
30.03.19 22:43:48 RAKA 2:221/0 - Nothing to send
30.03.19 22:43:48 RAKA 2:221/1 - Sending 5697 bytes in 1 files
30.03.19 22:43:48 RAKA 2:221/360 - Nothing to send
30.03.19 22:43:48 BERR BinkP Error: Bad address
30.03.19 22:43:48 DISG Disconnecting

This is how it goes here...

===
31 Mar 04:43:45 [1464] SYS August's Point
31 Mar 04:43:45 [1464] ZYZ August Abolins
31 Mar 04:43:45 [1464] LOC Bancroft ON CANADA
31 Mar 04:43:45 [1464] VER TCMBinkP/0.71 binkp/1.1
31 Mar 04:43:45 [1464] addr: 2:221/1.58@fidonet
31 Mar 04:43:45 [1464] remote passed bad address: `2:221/1.58@fidonet 0:0/0@'
31 Mar 04:43:45 [1464] done (from 2:221/1.58@fidonet, failed, S/R: 0/0 (0/0 bytes))
31 Mar 04:43:45 [1464] session closed, quitting...
===

'Tommi

---
* Origin: * Rampton Birds Box * Lake Ylo * Finland * (2:221/360)

By Tommi Koivula : August Abolins on 3/31/2019 12:55 PM

This is how it goes here...

===
[1464] remote passed bad address: `2:221/1.58@fidonet 0:0/0@'
[1464] done (from 2:221/1.58@fidonet, failed, S/R: 0/0 (0/0 bytes))
31 Mar 04:43:45 [1464] session closed, quitting...
===

Hmmm.. that 2nd "0:0/0@ " looks like the result of my fiddling with Winpoint's Uplink options.

Thanks for confirming this.

Looks like even if I did have an actual 4D number + some text for the 5D part, Winpoint sends all the othernet addresses and your system could balk at that.

I may move to OpenXP.

--- Thunderbird 2.0.0.24 (Windows/20100228)
* Origin: - nntp://rbb.fidonet.fi - Lake Ylo - Finland - (2:221/360)

On 2019 Mar 31 21:57:10, you wrote to Tommi Koivula:

Looks like even if I did have an actual 4D number + some text for the 5D part, Winpoint sends all the othernet addresses and your system could

balk

at that.

all FTN mailers present all configured addresses... they're supposed to... for one thing, it is how you can pickup mail for more than one of your addresses in the same connection instead of having to make multiple connections with address switching...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... RELIABLE SOURCE: Person starting slanderous rumour.
---
* Origin: (1:3634/12.73)

Hello mark,

all FTN mailers present all configured addresses... they're supposed
to... for one thing, it is how you can pickup mail for more than one of your addresses in the same connection instead of having to make multiple connections with address switching...

Thank you for being patient with me. This Bink-stuff is quite new to me.


../|ug

--- WinPoint Beta 5 (359.1)
* Origin: Reluctantly Revisiting Fidonet (2:221/1.58)

On 2019 Mar 31 21:52:06, you wrote to me:

all FTN mailers present all configured addresses... they're supposed
to... for one thing, it is how you can pickup mail for more than one
of your addresses in the same connection instead of having to make
multiple connections with address switching...

Thank you for being patient with me.

it is OK, august... we can forget a lot of stuff over time... that old "use it or lose it" thing, ya know? :)

This Bink-stuff is quite new to me.

it isn't a bink thing... all FTN mailers do this ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... Nothing is foolproof to a sufficiently talented fool.
---
* Origin: (1:3634/12.73)

Hello mark,

This Bink-stuff is quite new to me.

it isn't a bink thing... all FTN mailers do this ;)

The last time I did any of this was dial-up, and it was just one feed. Never used tcp/ip.


../|ug


--- WinPoint Beta 5 (359.1)
* Origin: Reluctantly Revisiting Fidonet (2:221/1.58)

Hello August!

On 31.03.19 at 18:53, August Abolins wrote to Martin Foster:

//Resending.. I think I played around with the 5D "Uplinks" part too
much.//

Ah, could that explain why all your posts of the 30th were in
triplicate :-)

Could be.

OkiDoki.

But I'm *not* going to mess around with Uplinks anymore.

Very wise.

[big snip]

Sorry about the panic.

No bother :)

Regards,
Martin

--- OpenXP 5.0.36
* Origin: Bitz-Box - Bradford - UK (2:310/31.3)

On 2019 Mar 31 23:02:42, you wrote to me:

This Bink-stuff is quite new to me.

it isn't a bink thing... all FTN mailers do this ;)

The last time I did any of this was dial-up, and it was just one feed. Never used tcp/ip.

it is still the same, though... the only thing is that instead of using a dedicated copper pipe from one end to the other, we now use a packet switched TCP/IP pipe... everything else is still the same ;)

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... We could have made it bigger. But why?
---
* Origin: (1:3634/12.73)

Re: Winpoint: BinkP errors
By: mark lewis to August Abolins on Mon Apr 01 2019 11:55 am

it is still the same, though... the only thing is that instead of using a dedicated copper pipe from one end to the other, we now use a packet switched TCP/IP pipe... everything else is still the same ;)

Did I ever tell you about the time I worked in a network where we ran ARCnet between floors by tapping into 2 water pipes?
--- SBBSecho 3.06-Win32
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)

On 2019 Apr 01 11:59:52, you wrote to me:

it is still the same, though... the only thing is that instead of using
a dedicated copper pipe from one end to the other, we now use a packet
switched TCP/IP pipe... everything else is still the same ;)

Did I ever tell you about the time I worked in a network where we ran ARCnet between floors by tapping into 2 water pipes?

i don't think i've heard about that one but i do know that POTS used a positive ground and you could stick on lead of a buttset into the ground and one on a tip terminal in a pedestal, get dialtone, and make a call... it might be a ring terminal, though... i forget which one was ground...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... A Kosher president would eliminate government pork barrelling.
---
* Origin: (1:3634/12.73)

mark lewis wrote to Kurt Weiske <=-

i don't think i've heard about that one but i do know that POTS used a positive ground and you could stick on lead of a buttset into the
ground and one on a tip terminal in a pedestal, get dialtone, and make
a call... it might be a ring terminal, though... i forget which one was ground...

If memory serves, ring was ground. Most payphones were ground start
lines, to keep people from plugging in a home telephone into a pay
phone jack and get dial tone. That made for a good story.

Red's Java House is a coffee shop/restaurant along the piers in San
Francisco - they started selling burgers to longshoremen back in the
1930s. When I was doing telecom in the late 80s, there was a story
about the pay phone outside of Red's, that kept getting trouble
tickets. When the y looked at the phone, it worked fine. More tickets
came in. It wasn't until someone noticed that the tech who installed
the phone ran a copper wire down the piling into the San Francisco bay
that the isolated the problem.

When the tide came in, the bay water provided the ground. At low tide,
the wire was hanging in the air, and no ground.

They took a more civilized approach to grounding (using a water pipe)
and all was well.



... Do you ever see inconsistencies in your world?
--- MultiMail/XT v0.51
* Origin: http://realitycheckbbs.org | tomorrow's retro tech (1:218/700)