[QNX2] ftp/ftpd, inetd.conf, Can I ftp INTO one of these systems?

QNX USERS QNX2 and QNX4
1

My predecessor started a couple threads about QNX2 network related stuff in the past, but I’ve since dug deeper and figured out more about these systems than those before me, so I’m here with my own questions… (my post got larger than I intended, so I am sticking to one subject and will eventually ask some of my other questions in a separate thread)

Let me preface this by saying

  • I am not certain who made the networking stack/software/whatev but there is a file snmpconf that reads SpiderTCP TCP/IP (release 5.1) for QNX version 2.15, 1.3.6.1.4.1.24.4.1.1.4 Note, our systems are QNX 2.21
  • It seems fairly robust, and appears to have parallels to unix/linux style network components and configuration files (unless QNX actually came like this by default, of which I am unaware), but sadly I am not intuitively familiar with other *nix environments
  • NIC is just a LinkSys Ether16 base 10 ISA card
  • I do not suspect hardware failure anywhere along the network nor do I believe there is any filtering or blocked ports/services within the scope of what I am trying to do

Primarily, I am trying to determine if I might be able to ftp INTO one of these machines.
These systems have had the capacity to connect to OTHER systems via ftp for ages; we have a server on our network to which we routinely push data through the main software that we use, as well as a command line (or shell, i suppose?) text-based ftp program for general file transfer.

I’ve spent a decent amount of time online reading about how to configure the different files to enable/configure different components, but all of the stuff I have seen has been for QNX 4 or straight up Unix and Linux, so I don’t know quite how much of that is mirrored on these systems.

Here is a list of files in /etc/ and /etc/cmds/

etc
etc661×484 22.5 KB

etc_cmds
etc_cmds661×484 37.1 KB

According to @Tim in this post, ftpd should be loaded when there’s an incoming ftp request/attempt, and so should telnetd if someone has telnetted into a system.
I am certainly able to telnet into the system, and telnetd is definitely running when I check the tsk command.

If I open inetd.conf, this is its contents:

#
#   INETD.CONF :: Inetd configuration file
#
#
ftp     stream  tcp nowait  autonet /etc/cmds/ftpd  ftpd
echo    stream  tcp nowait  autonet internal    internal
discard stream  tcp nowait  autonet internal    internal
daytime stream  tcp nowait  autonet internal    internal
chargen stream  tcp nowait  autonet internal    internal
time    stream  tcp nowait  autonet internal    internal
smtp    stream  tcp nowait  autonet /usr/lib/sendmail   sendmail -bc
rshd    stream  tcp nowait  autonet /etc/cmds/rshd  rshd -bc
finger  stream  tcp nowait  autonet /etc/cmds/fingerd   fingerd -b

As I understand it, this file dictates how incoming network requests are handled… my untrained eye would say it looks as though it might expect to receive incoming ftp requests

But for whatever reason, if I try to ftp INTO one of these systems, it either just doesn’t connect, or QNX supposedly refuses the connection. (the refusal comes on port 20 where as the completely failed connection is on port 21)

One of the pages I found online outlines this file, but in a GNU system

But more importantly, this page from c. 2005 outlines the BSD version and talks about password and user files and a lot of extra components that I haven’t yet seen on one of these QNX machines;
https://web.archive.org/web/20200809112713/https://netbsd.gw.com/cgi-bin/man-cgi?ftpd++NetBSD-4.0
now, again, I understand that these things will most certainly not be one-to-one with the QNX systems I’m dealing with, but it makes me wonder if this could actually work if I were to make those extra configuration files.

I mean, it looks like these systems at least have the foundation for incoming ftp access…

I’ve just sorta hit a wall and I’m not sure where to go from here, and I don’t know whether this is a pointless effort in the first place.

does anyone have any insight or perhaps a direction to point me in?

2

I’ll start with the 2.15 vs 2.21 stuff. 2.15 was the last version of QNX 2. Well, it should have been, but for a Y2K kind of issue. Originally QNX 2 used a unique date format, which start from 1980. I believe that the year used 4 bits, so it would run out in 1996. As the date grew closer, this was remedied by version 2.20, which needed some fix in 2.21.

The inetd program and /etc/inetd.conf file are a pretty standard part of TCP/IP. To connect to a TCP/IP computer you need it’s IP address and a port, which corresponds to which service you want. Without inetd running, you would need a daemon running for each service. Examples would be ftpd, and telnetd. So one thing to check is whether you’ve started inetd or ftpd. The ‘tsk’ command will let you know. You might be able to run ftpd, but that might require a parameter to keep it alive. Instead of this, the inetd program runs and receives requests for all ports. It then sees a port is listed in the inetd.conf file it will start the listed daemon. An important thing that you need to know about the inetd.conf file is that the tokens in the first column refer to port numbers. They are defined in another file, I believe /etc/protocols. So check that file to make sure that ftp cooresponds to the port number you think it should.

3

Yes those are there. inetd is loaded at startup, the other network related components are already configured and working.

i’ve used ftp at home to connect TO servers for years, and we ftp into our lab’s server here with these QNX machines all the time, I just haven’t had to configure ftp server capabilities in this kind of OS environment so I don’t know what I don’t know.

And I’m not sure whether that capability even exists with what is provided on these systems.

Like I said above, it seems like it has all the components, but there are no specific resources on the internet for making this happen in QNX 2, and all the information online for adjacent stuff (like unix, linux, and later versions of qnx) talk about extra files for users and passwords and stuff…

I think it is actually the services file, as the protocols file just has entries to outline ip, icmp, tcp, and udp; The services file calls out a dozen and a half different services and their corresponding ports, and ftp is in there.

In this GNU page, it reads:

This is what I mean, these systems do not have these files in the /etc/ directory… it goes further to talk about ftpchroot (“chroot” isn’t even a command on these systems), ftpwelcome, message of the day, etc etc.

I feel like these components need to be added to possibly satisfy whatever else the system and/or ftpd might expect to see in order to fully start the ftp server process.

Also, I don’t know if /etc/passwd is solely for ftp/remote login, or if it is supposed to be for universal system login… these systems have a different user and password file located at /config/pass and this is what specifies name, password, user id, group id, starting directory, and any script to be executed upon logging on… i believe this is managed by a program in /das/sys/ed_user as I see that running when I type tsk after going into the software to modify a user.

There’s a directory called /passadmin/ with what I assume are password related utilities, but we have never interacted with that, I think it goes unused

4

Without having the ftpd source code it’s impossible to know for sure.

But what you see on the GNU page is what I’ve always needed to make ftpd work on QNX (4/6/7 etc). So I suspect you’ll need to create those directories and add those files that ftpd is looking for in order to be able to ftp into your QNX 2 machine. It should be pretty straightforward to add them and test if it works.

Note that /etc/passwd is the universal system login on Unix type machines (QNX4 and later). So your /etc/passwd file should follow the standard format that ftpd expects (and not the QNX 2 standard if it’s different).

Tim

5

You are right about the /etc/services file. You mentioned something about passwords that you might want to check. With QNX 2 there is a startup state where passwords are not needed. The password file is ignored. You login with the the name of some directory under /usr. You turn on passwords with a shell command, I think passon. ftp might have a problem if passwords are turned off.

Even if they are turned on, as I recall, ftp doesn’t like to login to root. So you would need a non-super user account for connecting.

I don’t know how it worked, but I know what chroot does. You can set things up so a user, probably anonymous, can use ftp to get into the system, but it does not see the whole file system. Instead you choose a location in the file system, and that becomes the root for the user while logged in. As I recall this needs some finess as under the chroot you need a cmds directory so you can run ‘ls’ from ftp. At least that’s approximately what happens.

6

So we need to use a password to log in with SOME accounts, and not with others… and the user/password file is just a plain text document, with five lines per entry;

username
     password
     group#.user#
     /starting/directory
     /script/to/run/upon_login

The script and password fields can both be blank; meaning no pw required for userx, and just drop them in the shell at their starting directory.

But since I don’t actually know qnx/bsd/linux OS environments very well, I don’t know if this is non-standard. Tim said /etc/passwd is the traditional system login on unix and qnx4+, so I made that file and added an entry based on one format guide I found… but it talks about encrypted passwords and stuff that I don’t think these old qnx systems have.

I tried putting just a random string for a password in the second field with no luck, but I also don’t know what else may be missing/expected.

(also, there are /user/ and /usr/ directories; usr has /lib/ and /spool/, user has just /qnx/ and /operator/ but both are empty. i don’t think any part of these systems utilize those user directories…)

a user account is specified in inetd.conf and allegedly that is the account that ftpd is run as, though I don’t know if that needs to be the account that is also trying to ftp into one of these machines.

Yeah, it’s a way to keep users in kind of a walled-garden when they log in, but these systems don’t even have the chroot command, so I’m thinking I don’t have to worry about this aspect for now…

I was hoping it would be relatively straightforward but like I said above in this message, the info I found for that /etc/passwd file talks about encrypted passwords, and I don’t think that is A Thing on these systems, plus I don’t know if putting /cmds/sh works for the “shell” field.

I’ve added the rest of the files (ftpchroot, ftpusers, ftpwelcome, etc etc) and typed just a “placeholder” string commented out with a # sign at the start of the line for the ones like ftpchroot and ftpusers since I don’t want to or can’t configure them.

I think it doesn’t help that I don’t know what other general permissions QNX2 expects from people using the system, I don’t have a good understanding of the whole permissions and attributes thing for files and processes, so it makes certain aspects of navigating these kinds of things just a bit more obtuse.

The takeaway for now is that I haven’t gotten it to work yet or offer any change in behavior. I’m still scouring around online for other info, I really wish I could find documentation for unix/bsd iterations from like the early 90s…

7

If you have Wireshark on your windows machine (and you should even if it’s hard to get your IT to approve stuff) it’s probably worth while getting a capture of the messages when you attempt to ftp into the QNX machine. We can glean some useful info from that on whether you are getting a flat refusal (ie QNX thinks FTP not enabled) vs a user/password issue. We may be trying to debug the wrong issue.

Regarding the user/password stuff. The /etc/password file is a ‘human readable’ file that utilities like FTP can use to determine what users exist on a system and whether they have a password. The format (which you can easily find online and one I copied) looks like:

fred:x:290:120:Fred L. Jones:/home/fred:/bin/sh

In this case the username is fred and the ‘x’ indicates this account has a password and the login directory is /home/fred and the default shell is /bin/sh

This is what you need to replicate. Only fred will be replaced with a user on your QNX 2 system that has a password.

What should then happen is ftp should read that etc/password file and allow a user called fred to log in. Note that it doesn’t know the password. What happens is the ftpd deamon will pass on the password that you enter to the actual password verification program in QNX to validate the password and allow the login to take place. So you just have to make sure the user you put in the /etc/password file is one on your QNX2 machine that has a password. I would also make sure that the login directory is correct (the /home/fred above) for the user.

But first, I think we need the wireshark capture to know what the issue is (not enabled vs user/password). Hopefully you know how to do things like filter the wireshark traffic by port so that you only see the stuff going to port 20 and 21 (eg udp.port == 20)

Tim

8

I can put in a software approval request but I don’t have high hopes for it to be approved considering the nature of what we do and don’t technically do here in the lab (ie: it may be considered too esoteric or too much of a risk, I’m not sure I could justify its purpose enough to be given clearance)

I did try this; with both a provided password in the second field as well as “x” in the second field.
No success.
(note: the earliest information I found online for adjacent systems named the file passwd instead of password, I have tried both)

I understand this but part of me wonders if the QNX2 environment is so old or incongruent with later qnx and also BSD/Unix environments that this port of ftpd maybe just can’t find all the other components it needs to start the service successfully. Was ftpd even originally included with QNX2 in the first place?

So like I said, it might be a struggle to convince The Powers That Be to approve the software… BUT I have also recently been having difficulty telnetting into my test machine here at my desk with my company-provided desktop; dropped connection, able to ping the test machine from my desktop but not my desktop from my test machine, etc etc… Telnet connections to any other QNX machine in the facility don’t drop out.

I’ve opened a ticket for the IT department to help diagnose/investigate things, so I might be able to have them actually test/check ports 20 and 21 as well.

9

ftp/ftpd definitely was not originally included with QNX2. All networking was originally Arcnet based with either custom QNX networking or Fleet protocol. TCP/IP support came very late in QNX2s timeline (after QNX4 was already released) and I don’t ever recall using it on QNX2 (we used the Arcnet networking).

But the fact that they included ftpd says that they intended to allow ftp access into a QNX2 machine because that’s the whole reason for ftpd to exist (to accept connections). The problem is we just don’t know what’s required on the QNX2 side of things to make it work.

I guess we have to wait until your IT department decides (or get lucky and find some actual documentation on ftp on QNX2). Maybe they can run wireshark for you from their PCs and give you the capture.

Note this document on ftpd mentions you need an /etc/services file. Do you have one of those? Hopefully QNX2 expects those to be in that path location (just thought of something, if you run a strings command on ftpd do you see anything that looks like paths / filenames?).

Tim

10

Services file:

#
# Network services, Internet styel
#
ftpdata		20/tcp
ftp			21/tcp		ftpd
telnet		23/tcp		telnetd -d
smtp		25/tcp
bootps		67/udp		bootpd
bootpc		68/udp		bootp
tftp		69/udp		tftpd
snmp		161/udp		snmpd
route		520/udp		router routed
echo		7/tcp
echo		7/udp
discard		9/tcp		sink null
discard		9/udp		sink null
daytime		13/tcp
daytime		13/udp
chargen		19/tcp		ttytst source
chargen		19/udp		ttytst source
time		37/tcp		timserver
time		37/udp		timserver
finger		79/tcp
ntalk		518/udp
exec		512/tcp
domain		53/tcp		nameserver	# name-domain server
domain		53/udp		nameserver
nb_nmsrv	137/udp		netbios nameserver
nb_sssrv	139/tcp		netbios session server
nb_dgsrv	138/udp		netbios datagram server
			1000/tcp	qnxserver
anet		4242/tcp	anetd
#
# UNIX specific services
#
login		513/tcp		rlogin rlogind
shell		514/tcp		rsh rshd cmd
who			513/udp		rwho rwhod whod

(no idea why “style” is misspelled lol).

Also, not sure what you mean by “strings command” but I’m able to search for text strings in a hex dump of the file… etc/ftpusers, hosts, host, services, resolv.conf are called out in different places.

[edit:] also, I’ve already been through that link you posted beforehand; it’s from the neutrino version of qnx, so I don’t know if it really applies much if at all :/

11

I don’t know if this is useful, but since we are talking about QNX 2 and passwords:

1: I’m pretty sure that QNX 2 did not have a shadow file. Passwords were in the /etc/passwd file in plain text. That was the default.

  1. The startup state of QNX 2 was that the password file was not used at all during login. Instead you could either enter a directory, e.g. ‘/’ in which case you would be placed in the root directory, or if your login id did not start with / a directory /usr/name was looked for. So if yo entered qnx you would be put in /usr/qnx.

3.Passwords were turned on and the /etc/paaswd file was used after you entered the shell command ‘passon’. This was often run in the /config/sys.init file.

  1. At some point, someone, maybe QNX, came up with something called the password administrator. This proveded a better level of security.

I don’t know how any particular ftp intereacted with the three possible situations, passwords off, passwords on, or using the password administrator.

I do recall that generic ftp does not like to let you connect as root.

1 Like
12

Oh it’s useful insofar as it offers a little more insight into the stuff that’s working in the background.

In my particular case, though, these systems have never been in a state where passwords were not enabled. The pack of installation disks for the DAS software installs QNX preconfigured to suit the program… coincidentally, I just checked the sys.init file and passon is indeed called out rather early in the file. The QNX manual says that once passwords have been enabled, they cannot be turned off; I don’t see passon in the /cmds/ directory, so maybe the command deletes itself after it has been enabled.

The password file is located at /config/pass, not /etc/passwd or /etc/password though.

Like Tim mentioned, the ftpd program may still be looking for a user/pwd file in /etc/ so I likely need to populate one there, but I haven’t found any information online about how that file is used/configured if passwords are NOT encrypted/shadowed.

What password administrator might you mean? There IS a /passadmin/ directory, with

authorize
login
pass_util.doc
passadmin
pswd

pswd3
pswd3661×484 28.3 KB

and that .doc file is a lengthy explanation of how to use anything in that folder, but to my knowledge, none of that is ever employed.

The only utility that a typical user would interact with for sake of user/password configuration is something that must have been written by the company who created the DAS software;

pswd2
pswd2661×484 27.6 KB

pswd1
pswd1661×484 30.2 KB

If that passadmin is what you were talking about, maybe I should try setting that up and seeing if it has any positive effect on ftpd; maybe if there’s some kind of administrator running to handle password-related calls, the system will give ftpd what it might be looking for…

13

I forgot ‘strings’ wasn’t a QNX2 command, it came later on QNX4. It’s just a command that searches an executable for ‘string’ data. Essentially what you did with hex dump.

The reason I was asking about this is because ftp, inetd etc does not appear in the QNX2 manuals anywhere it’s possible it was a 3rd party add on that came much later (ie with Ethernet network drivers). That makes it much more likely that it was just a direct port of the existing ftpd code from Unix rather than a specific QNX2 rewrite. In other words a direct port would be looking for files (and executables) in the ‘Unix’ directories rather than the QNX2 directories where the equivalent files reside.

From what you list, it looks like it’s a direct port from Unix. That’s why I think the neutrino docs are still useful because they are going to call out files/executables/directories along with settings inside those that you are going to have to replicate on QNX2 for it to succeed.

Tim

P.S. Any luck with having your IT department come down and run wireshark to get some data.

14

Fair, and yes that is basically what I was assuming as well.

I understand that, but I wondered if the Neutrino documentation might be a little too “new.” This software was released in the early/mid 90s, and the network package was finalized in 98/99. If it were ported from any other platform, I am inclined to think I would need to reference the config/setup of the contemporary platforms… the dates on the files in /etc/ and /etc/cmds/ are mostyly dated in 1992 and 1993, a couple are a few years later;

inetd.conf Dec-03-98
services Aug-09-96
the ethernet card driver is dated Dec-15-95

ftpd and inetd are both dated Dec-31-11, which is entirely wrong… I believe that is the default date when something has been put on a dos file system, as any time I had trafficked files via dos floppy to a windows machine here, all of them had that same date stamp. So there’s no way to actually know when the two programs were actually finalized, but I imagine it must have been around 1998… the installer package files are all dated january 15 1999.

Not yet; coincidentally I recently started having intermittent issues telnetting into the machine from my desktop and I’ve got an open ticket for someone to come up and witness the situation today (hopefully). I don’t know the scope of what they can or will do, but I can also ask them to do some tests for ports 20 and 21.

15

Here’s the link to the QNX 4.25 docs.
https://www.qnx.com/developers/docs/qnx_4.25_docs/qnx4/bookset.html

You’ll note how they still call it the DARPA file transfer protocol. Haven’t read that in decades. LOL. You can see if there is anything different between Neutrino and 4.25. The section on User Authorization might be helpful.

One thing to note. I have the QNX 4.0 books (came out in 91) and an updated 4.2 utilities supplement book (95) and neither of those mention ftp/inetd etc. Basically I don’t think Ethernet support was in QNX 4 at that time either (95 or earlier).

That makes a lot of sense to me. Not sure how old you are but I remember running Win 3.11 and to connect to the internet in 1994 I had to have a 3rd party program called Trumpet Winsock that I had to run first before ‘dialing in to my ISP over modem’ or I would not get an IP address so I would not be able to access the internet. So even Windows didn’t have native support until Win 95 was launched with Ethernet/TCP/IP support built in.

Since we can’t find any docs for this and I’ve been unable to find anyone posting anything online about ftp in QNX2 its possible that ftpd doesn’t even work (might never have been fully tested) so we could be chasing something impossible.

Other than looking at the QNX 4 docs on ftp/ftpd there really isn’t much you can do until your IT department decides to take a look and uses Wireshark to see what happens when you attempt to ftp into your QNX2 machine.

Intermittent issues could be anything unfortunately (cable, flaky card in QNX2 machine, running at 10 Mbit speed, issues with hostnames if you aren’t using direct IP addresses). Probably zero utilities to help on the QNX2 side either which is unfortunate (starting in QNX4.25 there were network utilities added for diagnosing issues).

Tim

16

Also, I realized that passon is not something that exists within the /cmds/ directory, but it’s still a function within the OS itself.

it is absolutely called in the sys.init file at startup; if I comment it out, I can login with / very much the way @maschoen has instructed to people in other threads in the past. If I make a folder in /user/, I am then able to login with the same name as whatever folder I created.

with passon ignored, I decided to toy around with the things in the /passadmin/ folder, this is the authorize program;

authorize1
authorize1661×484 37.8 KB

I wondered if loading passadmin at startup would be something that ftpd defers to for user login, but I think there’s a problem because when I create a new user, i get an error when it tries to create that “.login” file;

/config/.login: Unable to open
Error - Unable to copy default .login fil (sic)

The documentation for the authorize program says this about the .login file during user creation

Once the new entry has been created, the authorize utility will 
prompt if it should create the new user's directory unless the 
directory already exists.  If 'Yes' is selected, the add function 
will attempt to add the new directory and set ownership for the 
directory to be that of the new user.  As well, if the default 
command that is executed at login time is left as the supplied 
default, it will ask if the default .login file is to be copied to 
the new user's home directory, and ownership set correctly. By 
default this file should be located in the /config directory and 
should be called .login although the file to be used may be 
specified through the l=login_file command line option.

I also swapped the default login file in the /cmds/ folder with the one in the /passadmin/ folder and discovered that there is a 5kb difference in file size, it also displays a different login message

QNX Version 3.21   Node 0  $tty0  Local Time: 11-Mar-125 xx:xx:xx am
Copyright (c) Quantum Software Systems Ltd. 1983,1989

vs the text shown by the default login file that shipped with the system

AOS Version 2.21  Protected
Node 0  $tty0  Local Time: 11-Mar-125 xx:xx:xx am

I wondered if the company that made our DAS software had perhaps removed some features that the QNX login file might have.

17

Didn’t think to look into user authorization, good point. Can’t say I’m super familiar with anything DARPA related, but there IS mention of some “arpanet” settings in some of the config files…

So what you’re saying is that it’s technically a small miracle that these machines seem to play just fine with ip4 tcp/ip networking? lol

I’ll be 41 this year, my earliest hands-on computer foolery was probably circa 96/97 (12-13yo) with an obsolete 486 running Win 3.11. I only vaguely recall the words “trumpet winsock” and our ISP at the time had an installer package that included whatever was necessary for basic dialup connection. I eventually fiddled with stuff like IRQ settings when doing small things to update that machine (got a free video card, better modem, etc) but I was using beige Macs more at the time and eventually got a mac modem and almost didn’t touch the pc after that.

Yeah I’m nearly ready to throw in the towel, but I feel like there are still some breadcrumbs worth following. Not specifically holding my breath, but I’ve always been stubborn about Making Thing Do Thing, so I’m still gonna fumble with it a bit more.

It’s definitely not a flaky card or cable, nor speed issue, nor hostname vs ip as I can do outgoing ftp stuff on all our QNX machines consistently without fail (tends to average around 500 kbytes per sec upload/download). For some reason hostnames don’t resolve through the network, unless the DNS server doesn’t work that way (been a while, I haven’t had to think how that all resolves) but I loaded up the hosts file with entries for all the different ips that I need to interact with and that works fine.

I dunno, I guess I’ll see what happens whenever one of the network guys makes their way up to my desk. Lunch now, day’s half over…

18

passon was a shell command, like cd, only it had a persistant effect. You won’t find it anywhere on disk as a command. While I don’t know the details, I know that there was a hack that allowed one to turn off passwords. It was not official.

While the passadmin provided better security that the default, I don’t think it was distribute as part of the OS. It was an add on. I don’t think it cost anything. The stuff you found in /passadmin may be this feature, but having only seen it and never used it, I can’t be sure. If one wanted to turn passwords off, a sure fire way would be to edit the sysinit file and comment out ‘passon’. I don’t think the passon command had any effect on the passadmin utililty.

Yes, sorry about the mixup in the file name. QNX 2 used /config instead of /etc and the filename was passwd.

19

Thus far, the only real mention of “passadmin” I’ve found is coincidentally another post here on the forums;

written by Martin Zimmer, it was apparently on QUICS, presumably all other traces lost to the ether -_-

I realized passadmin is actually called out in the /config/sys.opt.tcp file, but I can’t perceive/discern what effect it has on anything, or where/when, as far as these systems’ normal operation.

Not sure if the order of operations makes a big difference, but the sys.init file loads any sys.opt.* files after passon is executed, so QNX’s own password feature is triggered before this other password utility.

I did try removing passon from sys.init and putting passadmin in its place, but I couldn’t seem to get it to honor the passwords for the test accounts I made; you could log in without using a password for any user that had a corresponding folder in the /user/ directory, but it seemed indifferent to passwords.

Thinking back a couple weeks ago, I don’t think I had realized passadmin was also called out in sys.opt.tcp, so I may go back and toy with it now that I have some time again…

@Tim
had the network guys try to figure out why my telnet connection kept dropping, and it turns out the static IP I had been given for my QNX test machine was also being used by a machine elsewhere in the facility. Not sure how they didn’t have a list of active IPs but after getting reassigned, my connection doesn’t drop out.

They did not explicitly test on port 21 but they said they don’t see any filtering, and if I’m able to successfully ftp in one direction, it should work the other direction as well. Still digging for a little more confirmation, but i’m going to tentatively assume that I either still haven’t gotten something configured quite right, or perhaps this ftpd and the stuff in the /etc/ folder is potentially just vestiges of whatever else they ported the tcp function from.

20

We didn’t need the IT guys to tell us that. It’s obvious if you can ftp in one direction you can ftp the other way.

What we needed was Wireshark packet sniffing to tell us why it’s not working in the other direction (to the QNX2 machine). We still can’t be sure whether the ftpd deamon is indeed listening for incoming connections or whether it’s accepting connections but failing the password authentication or whether it’s something else. The network traffic would have given us a better idea.

Tim

P.S. One last thought. Have you tried to ftp into your QNX2 machine since the IT guys reassigned the IP address? Maybe the ftp command was being routed to the other machine and not the QNX2 machine.