For those using the super cool BLAM BBSlist script, and node list addition (latest combo version available that I can find,) I have a question ... not necessarily had all change the port. I'm curious for those using the node list telnet feature of this script, if the nodelist looks for a port or not? Is it necessary for an admin to change it? I had one state that their network doesn't really look at that, yet said admin also has the mod installed and I can't connect -- defaults to port 23.
Ahh, I have an idea.
If you edit your nodelist and change the INA:<hostname> to an INA:<hostname>:<port> does it fix your problem?
I dont think that should updset the IBN (binkp details), or any of the other flags (ITN,IFC)....
Ahh, I have an idea.This is where the nodelist, I THINK (not sure,) can come into play. I THINK, not sure, the network lead dude has to change my port within the nodelist or when others look me up, they'll be dialing into the wrong port. Well .. telnetting into the wrong port. In addition, the
If you edit your nodelist and change the INA:<hostname> to an
INA:<hostname>:<port> does it fix your problem?
It's not as much a nodelist issue as it is the specific script manya re using on their BBS's for their BBSlist. The script does not appear to be recognizing <hostname>:<port> and defaulting to port 23. While I could likely fix it on my BBS, I can't do so on others who have my BBS listed. This is where the nodelist, I THINK (not sure,) can come into play. I THINK, not sure, the network lead dude has to change my port within the
For my part just reading the exchange between yourself and Deon I agree with Deon that the INA may be the best place to put the telnet port
info. I'm not honestly sure and will need to try and read up on this. I have been (and I think incorrectly) been using the ITN flag to note this but I think that flag is really only for use to signal a Telnet based mailer on the port stated.
I'm not honestly sure and will need to try and read up on this. I have been (and I think incorrectly) been using the ITN flag to note this but I think that flag is really only for use to signal a Telnet based mailer on the port stated.
(I'm thinking it might be useful to use the nodelist as a "database" of how to telnet to anybody's BBS - which then things like Spectre's
By using ITN right? and only for non standard ports i.e. other than port 23
Would somebody have a telnet mailer and BBS on different ports? Most telnet mailers (that I am aware of anyway), use a "press ESC to go to
the BBS" type function (and said BBS probably cant handle direct telnet anyway). And anybody who didnt have a mailer, would connect that port to the telnetable BBS anyway.
I'm not aware of any. However, if you HOST a network (forgive my niativity) and someone changes their BinkP port, how does a network admin change it on their end? Is it a flag, or something else? Being ignorant to running a network, I'm unfamiliar with how that side functions from an admin prospective. But the simplicity would seem you go into a menu, or
So the nodelist is for "mailers" to connect to each other. Not for
people to connect to BBSes... It tells one mailer, how to connect to another mailer to transfer mail and files.
When you change your binkp on your side, you need to tell the nodelist admin to update the nodelist, so another mailer knows how to connect to you - if it has mail to send to you "directly". (IE: Not routed through
a hub).
You probably also need to tell you mail hub (where you collect mail
from) - technically the nodelist should be sufficient, but mailer
software sometimes cannot read it properly and mail hubs configure a specific address/port to connect to you, using their mailer config.
(The nodelist was created for mailers using telephones and modems - not for BBSes using IP. Some software doesnt know how to read the nodelist
for IP information - some does though...)
...δεσ∩
Thank you. That makes sense. However it appears many coders have begun using the nodelist to script it into a BBSlist, that allow users to browse all BBS's connected to a specific and or ALL networks, and then select and telnet out to one while online.
However, if the nodelist does not contain
the telnet port, would the telnet script not then have to auto default to 23 regarless of sript?
could be wrong. At that point, then using the nodelist for the Webring would not be beneficial to any BBS who have abandoned port 23.
Wouldn't it be better for a BBS list mod to use a BBS list as a source
of data rather than a nodelist?
I mean a nodelist might have entries for mailing nodes that aren't
bbses.
Just gonna jump in here, because I've had too many beers.
Just gonna jump in here, because I've had too many beers.
Mmmm... beer... Sounds like a grand idea and it's beer o'clock...
Lastly, this is not an FSXnet only issue, mystic issue, script issue. Even the National BBS list doesn't seem to like ports that exceed 4 digits. I'm stuck in a waiting room for the owner of the site to
approve a white list to allow traffic to telnet to me via that site. So lesson learned, keep the port at 4 digits or less, not 5. However that
is not the problem here, as there are a few BBS's with 5 digit ports,
that work via BBS script Telnet features. However, I can only attest to my BBS as I'm making my rounds editing the port on other BBS listings, that indeed it's possible for a BBS to telnet into mine using the same script as others; however most that are not using port 23, appear to
fail to connect, on most BBS's.
read up on this. I have been (and I think incorrectly) been using
the ITN flag to note this but I think that flag is really only for
use to signal a Telnet based mailer on the port stated.
ITN means a mailer connection that is via Telnet, EMSI over telnet.
It's not a user access port.
We must be very careful when deciding upon a port and understand the difference between well-known, registered, dynamic, private and
ephemeral ports. The reasons we use non-standard ports with 5 digits is to stay well away from ports that are used by other applications. It would not be best practice to use 4-digit ports. What problem is addressed by doing so?
Im not particularly good at). The ideas discussed here regarding the inclusion of telnet ports in nodelists will do no good unless the
software used to connect to the bbs knows about them and uses them. Otherwise, its just another way to advertise. Something that I
personally welcome but do not see happening anytime soon.
ITN means a mailer connection that is via Telnet, EMSI over telnet.
It's not a user access port.
1. When I call other BBS's and "Edit" my BBS listing, there isn't a specific selection for "port" just for "telnet address." So obviously I select www.theunderground.us:10023 ..
I really should scrub those from the nodelist but keep them in systems.txt
(I'm thinking it might be useful to use the nodelist as a "database" of how to telnet to anybody's BBS - which then things like Spectre's
webring could use it in addition to what TG is trying to do... :)
Just gonna jump in here, because I've had too many beers.
Wouldn't it be better for a BBS list mod to use a BBS list as a source
of data rather than a nodelist?
I mean a nodelist might have entries for mailing nodes that aren't
bbses.
You may be correct here. Today I wrote a script to convert the fsxnet nodelist into a web-usable format (JSON) and I had to do a lot of
fiddling to hide ZONE, HOST, PVT, DOWN, etc. read the flags and
translate them, but I *was* able to do it.
http://167.172.194.72:1234/fsxnet
ITN means a mailer connection that is via Telnet, EMSI over
telnet. It's not a user access port.
Thanks for confirming, this is what I thought / realised some time ago
and after I had started to use it for BBS wanting to showcase
non-standard telnet ports for users :(
I really should scrub those from the nodelist but keep them in
systems.txt
Vorlon, that might affect you right? Since MBSE is also a telnet
mailer. Would it choose binkp over telnet if there was an IBN flag as well?
I really should scrub those from the nodelist but keep them in system
But is there any harm in using it for a record of telnet addresses for people to connect to?
The only challenge I've seen with any script that pulls from the
nodelist to a BBSlist is that the telnet ports are not usually listed within a nodelist. So ... this takes, what, 50% of the BBS's and makes them not able to be connected to via the displayed list if only the URl
is listed to the user. With my limited knowledge, I can't imagine an
easy way to do this for the Net Admin, or the person writing the script. Wouldn't either the admin have to go in and add flags and port numbers
to each node and/or wouldn't the script have to search a range of ports for the listed URL to discover the correct one, and then populate said telnet port into the BBS list? I may be wrong but from a "fresh set of newbie eyes," to me a nodelist used as a BBS list to display to users is currently useless to 50% of the BBS's who have abandoned port 23 and/or
a lot of work for the network admin (unless a script can acheive this
goal automatically with simply a URL or IP address...)
AAAAAND as I sit here writing this, I realize that this probably already exists in principle in other places: web-based Telnet Guides, BBS List mods, etc. LOL
On 27 May 2020 at 10:17p, vorlon pondered and said...
ITN means a mailer connection that is via Telnet, EMSI over
telnet. It's not a user access port.
Thanks for confirming, this is what I thought / realised some time
ago and after I had started to use it for BBS wanting to showcase non-standard telnet ports for users :(
I really should scrub those from the nodelist but keep them in
systems.txt
I really should scrub those from the nodelist but keep them in systems.txt
Yes, and the talk about adding extra junk to the nodelist that is built for mailers is just going to put more junk into the nodelist.
User access information should be done via another mediam.
On 05-30-20 18:36, vorlon wrote to Avon <=-
Yes, and the talk about adding extra junk to the nodelist that is built for mailers is just going to put more junk into the nodelist.
User access information should be done via another mediam.
Yes, and the talk about adding extra junk to the nodelist that is built for mailers is just going to put more junk into the nodelist.
User access information should be done via another mediam.
I've been lurking and I'm inclined to agree. Leave the nodelist for mailers.
User access information should be done via another mediam.
User access information should be done via another mediam.
Why?
On 05-30-20 08:11, stizzed wrote to Vk3jed <=-
I've been lurking and I'm inclined to agree. Leave the nodelist for mailers.
Then come on over to FSX_NET and help us build a new one...
On 30 May 2020 at 06:36p, vorlon pondered and said...
I really should scrub those from the nodelist but keepthem in Av> systems.txt
Yes, and the talk about adding extra junk to the nodelist that
is built for mailers is just going to put more junk into the
nodelist.
User access information should be done via another mediam.
I confess I flip and flop between using the nodelist and setting
the course your suggesting. We've moved the thread over to FSX_NET
if you want to chip in your thoughts. You'd be most welcome to.
On 05-30-20 18:36, vorlon wrote to Avon <=-
Yes, and the talk about adding extra junk to the nodelist that
is built for mailers is just going to put more junk into the
nodelist.
User access information should be done via another mediam.
I've been lurking and I'm inclined to agree. Leave the nodelist
for mailers.
Yes, and the talk about adding extra junk to the nodelist that
is built for mailers is just going to put more junk into the
nodelist.
Ooooh, it would be so nice if we could get rid of the junk in the nodelist.
User access information should be done via another mediam.
If much of it were not already there I would agree. Im 50/50
between using whats there and starting over. There are a few
attempts at lists out there already, the ibbslist comes to mind.
We could hi-jack one of these existing lists or create our own. In
any case, much of the information already contained in the already implemented nodelists is already there. (that sentence made my head
hurt) ;)
Re: Re: Blam BBS List question
By: vorlon to Avon on Sat May 30 2020 06:36 pm
User access information should be done via another mediam.
Why?
The hammer has been thrown your way, make sure it doesn't hit you in the face. $->)
On 01 Jun 2020 at 12:39p, vorlon pondered and said...
The hammer has been thrown your way, make sure it doesn't hit
you in the face. $->)
:) It's all good in the hood.
Sysop: | Eric Oulashin |
---|---|
Location: | Beaverton, Oregon, USA |
Users: | 97 |
Nodes: | 16 (0 / 16) |
Uptime: | 01:56:08 |
Calls: | 4,614 |
Calls today: | 8 |
Files: | 8,491 |
Messages: | 349,822 |
Posted today: | 4 |