FTP: Is there a way to tell who is connected?

Is there a way to tell who is connected to the TCPnet FTP server?

The same there is for any other service --- there's nothing particular to FTP here. Any authentication protocol can be cracked. It's just a question of resources and determination.

I could refuse connection if its not an IP address i'm happy with!

No, checking the IP won't help. People who can sniff other people's IP traffic can also inject their own falsified traffic posing as those other people, using the same IP.

And of course, even without somebody trying to attack your service, the IP has next to no relation at all to with "who it is". IP addresses get re-assigned all over the place, all the time.

But if you're really justifiably worried, your first step should probably be to abandon FTP altogether. There are much more security-oriented file transfer protocols available these days.

Is there a way to tell who is connected to the TCPnet FTP server?

The same there is for any other service --- there's nothing particular to FTP here. Any authentication protocol can be cracked. It's just a question of resources and determination.

I could refuse connection if its not an IP address i'm happy with!

No, checking the IP won't help. People who can sniff other people's IP traffic can also inject their own falsified traffic posing as those other people, using the same IP.

And of course, even without somebody trying to attack your service, the IP has next to no relation at all to with "who it is". IP addresses get re-assigned all over the place, all the time.

But if you're really justifiably worried, your first step should probably be to abandon FTP altogether. There are much more security-oriented file transfer protocols available these days.

Thanks for your reply.
As far as I am aware the Keil TCPnet stack has no security based file transfer protocols? Or have I missed something!?

I as far I know - you are correct.

Anyone can write a TCP server application.

A TCP server application can use cryptographic methods to send out a random number to the client and expect the client to be able to compute a secure has on the random number and return back. This makes it hard for someone to listen in on a session and then later try to replay the login sequence.

A TCP server can use one of a number of cryptographic methods to encrypt all data, making it hard/impossible for a snooper to understand what happens.

Reasonably good hashes, and encryption algorithms exists with limited requirements on code and RAM space.