On Sun May-15-2016 08:14, Alan Ianson (1:153/757) wrote to Roger Nelson:

On 05/15/16, Roger Nelson said the following...

What happens if you connect to a system that doesn't have a packet password for you and your system is looking for one?

I'm not certain what would happen with mystic. All my links that
use packet passwords are configured so and those that don't are
blank.

Do you receive mail from a D'Bridge system with whom you don't have a packet password?

I'm going to go arrange a test and see what it does with an
unexpected password, and also the lack of a password when it is
expected.

Please let us know.


Regards,

Roger
--- timEd/386 1.10.y2k+ Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna - (1:3828/7)

Hey!

In case some of you were wondering, and judging by the lack of help Joe and I have received, you haven't, we solved the packet password by ourselves.


Regards,

Roger

--- DB 3.99 + Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna (1:3828/7)

Hello Roger,

On 23 May 16 15:41, Roger Nelson wrote to All:

Hey!

In case some of you were wondering, and judging by the lack of help
Joe and I have received, you haven't, we solved the packet password by ourselves.

So what was the outcome?

I offered to help on more than one occasion with no response. That's about all I can do.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

On 23 May 16 15:41, Roger Nelson wrote to All:

Hey!

In case some of you were wondering, and judging by the lack of help NB>RN> Joe and I have received, you haven't, we solved the packet password by NB>RN> ourselves.

So what was the outcome?

I offered to help on more than one occasion with no response. That's
about all I can do.

Sorry. I must have missed your postings. What did you offer, if you don't mind restating again?


Regards,

Roger

--- DB 3.99 + Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna (1:3828/7)

Hello Roger,

On 24 May 16 06:04, Roger Nelson wrote to Nicholas Boel:

So what was the outcome?

I offered to help on more than one occasion with no response.
That's about all I can do.

Sorry. I must have missed your postings. What did you offer, if you don't mind restating again?

I offered up my "othernet" as a testing suite for any DB users that were currently members (including Nick, who is a member) where I would've intercepted any *.bad echomail packets in order to look in them for answers as well as share them here.

That obviously wasn't necessary, so what was the outcome?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hi,

On 24 May 16 06:04, Roger Nelson wrote to Nicholas Boel:

I offered to help on more than one occasion with no response.
That's about all I can do.

Sorry. I must have missed your postings. What did you offer, if you NB>RN> don't mind restating again?

I offered up my "othernet" as a testing suite for any DB users that were currently members (including Nick, who is a member) where I would've intercepted any *.bad echomail packets in order to look in them for
answers as well as share them here.

That was a very nice offer, but it had to be solved one of two places -- here in the echo where everyone including Nick Andre would be aware of the problem or just between Joe Delahaye and I. I think we finally have a solution, but will wait a reasonable amount of time before publishing the findings here because while I was sure last week wherein the problem lay, I'm not so sure today.

That obviously wasn't necessary, so what was the outcome?

See above. I really appreciate the offer Nick, and can't thank you enough.


Regards,

Roger

--- DB 3.99 + Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna (1:3828/7)

Hello Roger,

On 25 May 16 18:10, Roger Nelson wrote to Nicholas Boel:

I offered up my "othernet" as a testing suite for any DB users
that were currently members (including Nick, who is a member)
where I would've intercepted any *.bad echomail packets in order
to look in them for answers as well as share them here.

That was a very nice offer, but it had to be solved one of two places
-- here in the echo where everyone including Nick Andre would be aware
of the problem or just between Joe Delahaye and I. I think we finally have a solution, but will wait a reasonable amount of time before publishing the findings here because while I was sure last week
wherein the problem lay, I'm not so sure today.

The offer was made directly to Nick Andre (and then secondly to anyone else in that network that wanted to test out their setup), since he is a longstanding member of Agoranet (the othernet I host). That test echomail would have went directly from his system to mine (DBridge to Synchronet - where the problem seems to lie along with Mystic). I could have produced the logs as well as the packet with proof there is indeed a packet password included in it. If it wouldn't have been in *his* test.. then it could have been narrowed down to something specific to some (if not all) DB user's configurations, etc. Or if it
indeed was password protected, he would then have absolute proof to look further into the matter.

That obviously wasn't necessary, so what was the outcome?

See above. I really appreciate the offer Nick, and can't thank you enough.

No problem. Keep us (or at the very least, me!) posted with your findings. DB is one of the few (and probably one out of two closed source) softwares I keep my eye on and interest in when it comes to updates and future plans!

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Roger,

On 25 May 16 18:10, Roger Nelson wrote to Nicholas Boel:

Sorry. I must have missed your postings. What did you offer,

if you don't mind restating again?

By the way, I just ran into another DB user that *just now* got the issue, even
though we've been transferring echomail/netmail packets as well as door game packets for quite some time.

While I have limited ways to look at this unless I load DB up in dosemu, I suppose it's easy enough to ask. Is there by chance a "Session password" setting in the echomail section of DB's config as well as a "Session password" setting in the BinkD config section?

Reason I ask, is because when I noticed his mail (and even door game packets) coming in with a packet password just starting yesterday or today, I asked the guy "Did you recently change something?" He only responded with "I noticed your
system was looking for a session password, so I added one". This is all in light of everything working just fine before he added it.

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

While I have limited ways to look at this unless I load DB up in dosemu,
I suppose it's easy enough to ask. Is there by chance a "Session
password" setting in the echomail section of DB's config as well as a "Session password" setting in the BinkD config section?

There is only one location in the DB config for session password. It is located under "Advanced/Misc Security".

There is a separate location for a "Packet Password" that is located under "Packet/Mail Control".

I have verified that I only have "Session Passwords" setup with no "Packet Passwords". The Packet Password field is totally blank - never has been used.

I can also verify that my hub instance is sending echomail with a packet password - using what I have setup under "Session Password".

I'm assuming that packet passwords were previously ignored in both Synchronet and Mystic. That's an assumption, but I have no other explanation as to why we
just recently started noticing this issue.

The solution was simple. I just asked my uplinks to add a Packet Password to match our session password.

- Mark

--- WWIVToss v.1.51
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

Hi,

On 25 May 16 18:10, Roger Nelson wrote to Nicholas Boel:

Sorry. I must have missed your postings. What did you offer, NB>NB>> if you don't mind restating again?

By the way, I just ran into another DB user that *just now* got the
issue, even though we've been transferring echomail/netmail packets as
well as door game packets for quite some time.

While I have limited ways to look at this unless I load DB up in dosemu,
I suppose it's easy enough to ask. Is there by chance a "Session
password" setting in the echomail section of DB's config as well as a "Session password" setting in the BinkD config section?

The packet password setting is in Packet/mail control, while the session password setting is in another section under Security settings. Both areas are
accesible from the main screen via the Esc key for the pull-down menus.

Reason I ask, is because when I noticed his mail (and even door game packets) coming in with a packet password just starting yesterday or
today, I asked the guy "Did you recently change something?" He only responded with "I noticed your system was looking for a session password, so I added one". This is all in light of everything working just fine before he added it.

I wish I knew the answer to that.


Regards,

Roger

--- DB 3.99 + Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna (1:3828/7)

[...]

There is only one location in the DB config for session password. It is located under "Advanced/Misc Security".

There is a separate location for a "Packet Password" that is located
under "Packet/Mail Control".

I have verified that I only have "Session Passwords" setup with no
"Packet Passwords". The Packet Password field is totally blank - never
has been used.

I can also verify that my hub instance is sending echomail with a packet password - using what I have setup under "Session Password".

That is what has been going on for about 3 months now. The ultimate solution to this should be coming in the next few months. unless you just simply cave in
and add a session password to your config.

I'm assuming that packet passwords were previously ignored in both Synchronet and Mystic. That's an assumption, but I have no other explanation as to why we just recently started noticing this issue.

Right.

The solution was simple. I just asked my uplinks to add a Packet
Password to match our session password.

I don't blame you for doing that, but I'd like to know what happened. I want to know if my mailer is doing that, but I don't think it is. Joe and I tested this by removing the session password and so everything began working again. Once a session password in placed, however, the problem begins anew. I have never had a packet password for him and many others, whom, I might add, do not have this problem.


...If you take life too seriously, it ceases to be funny.


Regards,

Roger

--- DB 3.99 + Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna (1:3828/7)

Hello Mark,

On 27 May 16 11:41, Mark Hofmann wrote to Nicholas Boel:

While I have limited ways to look at this unless I load DB up in
dosemu, I suppose it's easy enough to ask. Is there by chance a
"Session password" setting in the echomail section of DB's config
as well as a "Session password" setting in the BinkD config
section?

There is only one location in the DB config for session password. It
is located under "Advanced/Misc Security".

Does the "Advanced/Misc Security" section have any other binkd specific settings? The session password should only be used during binkd's handshake, and not in echomail itself.

There is a separate location for a "Packet Password" that is located
under "Packet/Mail Control".

I have verified that I only have "Session Passwords" setup with no
"Packet Passwords". The Packet Password field is totally blank -
never has been used.

Understood.

I can also verify that my hub instance is sending echomail with a
packet password - using what I have setup under "Session Password".

I'm assuming that packet passwords were previously ignored in both Synchronet and Mystic. That's an assumption, but I have no other explanation as to why we just recently started noticing this issue.

From what Rob tells me, there was a certain configuration with the old sbbsecho
(which I apparantly used) where it ignored packet passwords. This has been fixed in the new version.

The solution was simple. I just asked my uplinks to add a Packet
Password to match our session password.

That's definitely a simple "workaround", but not really a solution if we want to help get the issue found and fixed. :)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Roger,

On 28 May 16 05:50, Roger Nelson wrote to Nicholas Boel:

While I have limited ways to look at this unless I load DB up in
dosemu, I suppose it's easy enough to ask. Is there by chance a
"Session password" setting in the echomail section of DB's config
as well as a "Session password" setting in the BinkD config
section?

The packet password setting is in Packet/mail control, while the
session password setting is in another section under Security
settings. Both areas are accesible from the main screen via the Esc
key for the pull-down menus.

My only question (and I asked Mark the same) is if there is any other binkd specific settings under that Security settings along with the session password?

A session password should only be handled by the mailer. So is there a way in DB to edit specific binkd commands (like the actual "node" line where the session password should be placed) in DB?

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

Hello Roger,

On 28 May 16 06:03, Roger Nelson wrote to Mark Hofmann:

I don't blame you for doing that, but I'd like to know what happened.
I want to know if my mailer is doing that, but I don't think it is.
Joe and I tested this by removing the session password and so
everything began working again. Once a session password in placed, however, the problem begins anew. I have never had a packet password
for him and many others, whom, I might add, do not have this problem.

It wouldn't be your mailer doing that. It would be the editor or tosser stuffing the password into the echomail header. The mailer itself doesn't modify the contents of echomail/netmail.

So I suppose if you want to find a possible real solution, see if there's a way
to edit binkd settings manually. You would have to add the session password there, and not use the one in DB's Security section. If there is any way you can edit the "node" line in binkd that DB creates, the session password goes in
there, for example:

node 1:154/10@fidonet -md bbs.pharcyde.org <SESSIONPW> c /usr/fido/1154100

(my node number) (md5) (my address) (session pw) (crash/hold/direct/immediate/etc) (optional "filebox" - not necessary)

Regards,
Nick

--- GoldED+/LNX 1.1.5-b20160322
* Origin: thePharcyde_ telnet://bbs.pharcyde.org (Wisconsin) (1:154/10)

28 May 16 07:45, you wrote to Roger Nelson:

I don't blame you for doing that, but I'd like to know what happened.
I want to know if my mailer is doing that, but I don't think it is.
Joe and I tested this by removing the session password and so
everything began working again. Once a session password in placed,
however, the problem begins anew. I have never had a packet password
for him and many others, whom, I might add, do not have this problem.

It wouldn't be your mailer doing that. It would be the editor or
tosser stuffing the password into the echomail header. The mailer
itself doesn't modify the contents of echomail/netmail.

it can't be the editor as they do not do anything with PKTs... tossers assemble
and disassemble PKTs while mailers send and receive them ;)


)\/(ark

Always Mount a Scratch Monkey

... The last sound that it made was "Zap" .
---
* Origin: (1:3634/12.73)

On Sat May-28-2016 07:41, Nicholas Boel (1:154/10) wrote to Roger Nelson:

On 28 May 16 05:50, Roger Nelson wrote to Nicholas Boel:

While I have limited ways to look at this unless I load DB up in
dosemu, I suppose it's easy enough to ask. Is there by chance a
"Session password" setting in the echomail section of DB's config
as well as a "Session password" setting in the BinkD config
section?

The packet password setting is in Packet/mail control, while the
session password setting is in another section under Security
settings. Both areas are accesible from the main screen via the Esc
key for the pull-down menus.

My only question (and I asked Mark the same) is if there is any
other binkd specific settings under that Security settings along
with the session password?

I answered that above. Was I not clear? In case you didn't know, Nick made his own version of BinkD and incorporated it into D'Bridge as BINKDWIN. There is also an OS/2 version. Since many of us are running different operating systems and configurations, it's almost impossible to tell what is going on at someone else's system. Then there are the various spftware programs in use and
how they are run. I always have been an advocate of keeping things simple.

A session password should only be handled by the mailer. So is
there a way in DB to edit specific binkd commands (like the actual
"node" line where the session password should be placed) in DB?

Nick will have to answer that one to your satisfaction, I'm afraid. The setup in D'Bridge is relatively simple, even for newbies.


Regards,

Roger
--- timEd/386 1.10.y2k+ Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna - (1:3828/7)

On Sat May-28-2016 10:37, mark lewis (1:3634/12.73) wrote to Nicholas Boel:

28 May 16 07:45, you wrote to Roger Nelson:

I don't blame you for doing that, but I'd like to know what happened.
I want to know if my mailer is doing that, but I don't think it is.
Joe and I tested this by removing the session password and so
everything began working again. Once a session password in placed,
however, the problem begins anew. I have never had a packet password
for him and many others, whom, I might add, do not have this problem.

It wouldn't be your mailer doing that. It would be the editor or
tosser stuffing the password into the echomail header. The mailer
itself doesn't modify the contents of echomail/netmail.

it can't be the editor as they do not do anything with PKTs...
tossers assemble and disassemble PKTs while mailers send and
receive them ;)

On that note, I have yet to encounter an editor that would stuff a packet password into a message and I've been at this since the late 80s before becoming a node in '91. I switched my config to Detailed so I could see if a system was presenting a packet password when connecting here. To date, it has only happened with SBBSecho, and that was within the last 3 months. The node I
have a packet password with is also presented.


Regards,

Roger
--- timEd/386 1.10.y2k+ Windows 10
* Origin: NCS BBS - Houma, LoUiSiAna - (1:3828/7)

Does the "Advanced/Misc Security" section have any other binkd specific settings? The session password should only be used during binkd's handshake, and not in echomail itself.

All BinkD setup is in another location.

From what Rob tells me, there was a certain configuration with the old sbbsecho (which I apparantly used) where it ignored packet passwords.
This has been fixed in the new version.

What is strange is that it seems Ward is seeing this behavior. We would have to compare things to figure out what is different. It sounds like he has some nodes with packet passwords. I have none configured, so that is one difference.

That's definitely a simple "workaround", but not really a solution if we want to help get the issue found and fixed. :)

Is a "packet password" like having a password on an archive (zipped file)? I get the feeling it isn't.

When my BBS tosser (WWIVTOSS) processes messages from my D'Bridge hub, it has not problem with them - packet passwords and all. I also have no packet password setup in WWIVTOSS - but it still works.

It seems like many things just ignore them.

- Mark

--- WWIVToss v.1.51
* Origin: http://www.weather-station.org * Bel Air, MD -USA (1:261/1304.0)

29 May 16 09:49, you wrote to Nicholas Boel:

Is a "packet password" like having a password on an archive (zipped
file)? I get the feeling it isn't.

no... the PKT password is a field in the header of the PKT...

)\/(ark

Always Mount a Scratch Monkey

... Responsibility is the one thing in the world that develops us.
---
* Origin: (1:3634/12.73)