TCPSER Raspberry Pi Amiga 500

[3583Bytes]

I have been playing around with tcpser (Modem Emulator).  I basically connect my Amiga 500 to a PC (serial to usb null modem cable) with tcpser running and I am able to use telnet via JR-COMM or NComm to visit BBSs and even telnet to a Linux VM to use Lynx and Alpine for email.  (easy internet for the A500)

So I decided to take it one step further and get a Rasberry Pi.  I setup tcpser and connect it to the Amiga via a null serial cable.  It works except that I can only visit telnet BBSs.  

The command I am using is:

 sudo tcpser -d /dev/ttyUSB0 -p23 -s 19200 -l5

If I try to telnet to the Pi itself or another Linux machine it seems to get stuck at:

2014-03-28 05:49:16:-1243241360:INFO:Parsing nvt command
2014-03-28 05:49:16:-1243241360:INFO:Parsing nvt command
2014-03-28 05:49:16:-1243241360:INFO:Parsing nvt command
2014-03-28 05:49:16:-1243241360:INFO:Parsing nvt command

Since it works on Windows I am guessing my Amiga Term settings are OK.  I think the issue is on the Raspberry Pi itself, maybe the telnet settings.  But I am not a Linux expert and I can't figure it out.

If someone managed to get this working I would really appreciate some help.

Thanks

[desiv]

Haven't used tcpser yet (or a Pi), so this won't be very helpful I'm afraid, but..

sudo tcpser -d /dev/ttyUSB0 -p23 -s 19200 -l5

Let's check the options:
sudo tcpser - running it as root.
-d /dev/ttyUSB0 - So, running it on the USB port ( Is the Pi's serial port USB0?)
-p23 - listening on port 23 (this is only for devices wanting to talk TO your Amiga "modem" I think).  I wouldn't think this would conflict with your Pi listening on 23 for it's telnet (assuming it is running telnetd and listening on 23).  Maybe, for testing, comment that out and leave it at the default 6400?
-l5 - logging level 5.   Maybe pop it up to max (l7 I think?) to see what happens?

If I try to telnet to the Pi itself or another Linux machine it seems to get stuck at:
2014-03-28 05:49:16:-1243241360:INFO:Parsing nvt command

I think that's just an informational message, so TCPSER doesn't seem to be complaining..

Since it works on Windows I am guessing my Amiga Term settings are OK.  I think the issue is on the Raspberry Pi itself, maybe the telnet settings.  But I am not a Linux expert and I can't figure it out.

One thing I'd do is test telnet on the Pi first.
SSH into the Pi from your windows machine (putty).  Then from your session, type "telnet 127.0.0.1" which should try to connect form the Pi to the Pi on port 23 using telnet.
If that works, your Pi is at least listening on 23.

If not, you're telnet daemon isn't happy.

desiv

[3583Bytes]

Haven't used tcpser yet (or a Pi), so this won't be very helpful I'm afraid, but..

Let's check the options:

Thanks for your reply,

I tried removing the port argument for tcpser before and now again and still the same behavior.  Also I can telnet to 127.0.0.1 and I can telnet to another ubuntu vm I have setup, but I can't do it via the Amiga,  JR Comm states:

Connected to: PiTest
19200

But nothing happens after, when I type in the Amiga, I am getting messages in the tcpser but nothing comes back to the terminal.

Remember this is all works using windows so either the version of tcpser is different on the pi or the linux config is different.

UPDATE:

I just installed ubuntu on an old laptop and repeated the test and I got the same result.  So this is not a Rasberry Pi issue, this is a Linux issue.

[desiv]

Can you install telnet on Windows (I know, it's a bad thing security wise, but just for a test) and try telnetting to a Windows box.
(Depending on your OS, there are different ways to enable telnet on Windows - http://technet.microsoft.com/en-us/library/cc770501(v=ws.10).aspx )

Wonder if we might be having a terminal type issue.
Can you set NComm of JRComm for VT100 or something else, just to see?

Also, for more involved testing, on the Ubuntu or Pi machine, while it's happening, can you run a tcpdump?

Something quick, like "sudo tcpdump port 23" should show your connection attempts from your tcpser session to your machine ..  We'd be looking for, are packets going out?  And, are packets being acknowledged and going back...

desiv
p.s.  Try setting your Amiga terminal program to a 2 color screen, just to make sure it's not a display/font/color issue..

[3583Bytes]

Can you install telnet on Windows (I know, it's a bad thing security wise, but just for a test) and try telnetting to a Windows box.
(Depending on your OS, there are different ways to enable telnet on Windows - http://technet.microsoft.com/en-us/library/cc770501(v=ws.10).aspx )

Wonder if we might be having a terminal type issue.
Can you set NComm of JRComm for VT100 or something else, just to see?

Also, for more involved testing, on the Ubuntu or Pi machine, while it's happening, can you run a tcpdump?

Something quick, like "sudo tcpdump port 23" should show your connection attempts from your tcpser session to your machine ..  We'd be looking for, are packets going out?  And, are packets being acknowledged and going back...

desiv
p.s.  Try setting your Amiga terminal program to a 2 color screen, just to make sure it's not a display/font/color issue..

Tried above with no luck, I am not sure how to switch JRComm or NComm into VT100 mode, I don't see that option.

I did the tcpdump and it looks like tcpser is hitting the linux machine but it is sending or expecting something that the Amiga or tpcser is not giving back.  You see tcp activity on port 23 and then it stops, here is the log:

17:26:14.029577 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags , seq 1493988946, win 29200, options [mss 1460,sackOK,TS val 764625 ecr 0,nop,wscale 7], length 0
17:26:14.029659 IP 192.168.0.108.telnet > 192.168.0.110.43427: Flags [S.], seq 271779469, ack 1493988947, win 28960, options [mss 1460,sackOK,TS val 1532695 ecr 764625,nop,wscale 5], length 0
17:26:14.036379 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags [.], ack 1, win 229, options [nop,nop,TS val 764626 ecr 1532695], length 0
17:26:14.054325 IP 192.168.0.108.telnet > 192.168.0.110.43427: Flags [P.], seq 1:13, ack 1, win 905, options [nop,nop,TS val 1532701 ecr 764626], length 12
17:26:14.058131 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags [.], ack 13, win 229, options [nop,nop,TS val 764633 ecr 1532701], length 0
17:26:14.058169 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags [P.], seq 1:4, ack 13, win 229, options [nop,nop,TS val 764633 ecr 1532701], length 3
17:26:14.058484 IP 192.168.0.108.telnet > 192.168.0.110.43427: Flags [.], ack 4, win 905, options [nop,nop,TS val 1532702 ecr 764633], length 0
17:26:14.062271 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags [P.], seq 4:13, ack 13, win 229, options [nop,nop,TS val 764634 ecr 1532702], length 9
17:26:14.062581 IP 192.168.0.108.telnet > 192.168.0.110.43427: Flags [.], ack 13, win 905, options [nop,nop,TS val 1532703 ecr 764634], length 0
17:26:14.062867 IP 192.168.0.108.telnet > 192.168.0.110.43427: Flags [P.], seq 13:37, ack 13, win 905, options [nop,nop,TS val 1532703 ecr 764634], length 24
17:26:14.108433 IP 192.168.0.110.43427 > 192.168.0.108.telnet: Flags [.], ack 37, win 229, options [nop,nop,TS val 764645 ecr 1532703], length 0

[desiv]

Hmmm..
They are talking to each other.
Now its just, what are they saying.. ;-)

Can you set you flow control to XON/XOFF and see what happens?

Also, in tcpser, there was an option for carrier detect (-I???), maybe try that.
(Doesn't look like it's thinking the carrier isn't there, just figure it's worth a shot..  ;-)

If the telnet BBS stuff works, but the telnet to Linux doesn't, it feels like it doesn't like the terminal type / negotiation..
(Actually, I still wonder if the linux host has a security setting stopping it?)
It's weird because, from a network perspective, there's really no difference between a telnet BBS and telnet to a linux box.  So it feels app..  Something on the Linux telnet daemon..

Can you telnet from your Windows box to the Ubuntu or Pi?
(If you have Windows 7 (and maybe 8?  not sure), i think telnet needs to be added:
http://social.technet.microsoft.com/wiki/contents/articles/910.windows-7-enabling-telnet-client.aspx )

I wonder if it's a security setting on Linux for telnetd..
(i haven't used telnetd in ages..  Only sshd)

desiv

[3583Bytes]

Hmmm..
They are talking to each other.
Now its just, what are they saying.. ;-)

Can you set you flow control to XON/XOFF and see what happens?

Also, in tcpser, there was an option for carrier detect (-I???), maybe try that.
(Doesn't look like it's thinking the carrier isn't there, just figure it's worth a shot..  ;-)

If the telnet BBS stuff works, but the telnet to Linux doesn't, it feels like it doesn't like the terminal type / negotiation..
(Actually, I still wonder if the linux host has a security setting stopping it?)
It's weird because, from a network perspective, there's really no difference between a telnet BBS and telnet to a linux box.  So it feels app..  Something on the Linux telnet daemon..

Can you telnet from your Windows box to the Ubuntu or Pi?
(If you have Windows 7 (and maybe 8?  not sure), i think telnet needs to be added:
http://social.technet.microsoft.com/wiki/contents/articles/910.windows-7-enabling-telnet-client.aspx )

I wonder if it's a security setting on Linux for telnetd..
(i haven't used telnetd in ages..  Only sshd)

desiv

I can telnet from Windows to the Pi and Ubuntu, and I can go through Ubuntu to Pi, I can also go from Amiga through tcpser running on Windows to the Pi or Ubuntu.

It's very weird.

Has no one actually done this for their Amiga, as far as I can tell this is the only realistic method for getting your 1.3 Amiga on the net?  I thought more people would have tried this.

Thanks for any help.

[desiv]

Has no one actually done this for their Amiga, as far as I can tell this is the only realistic method for getting your 1.3 Amiga on the net? I thought more people would have tried this.

I use an external Lantronix box for that, although I didn't try connecting from my Amiga to a Linux box.  Only Telnet BBSes...

If you can transfer some programs to your Amiga, I'd try a better VT100 emulator next..
Maybe something like this:
http://aminet.net/package/comm/term/Vt100
(Note: I'm not sure that app is 1.3 happy.  It supports ARexx, so maybe not.  That was just a quick google search.)

I'll to set mine up if I get a chance this weekend.  I kind of have my A1000 totally open for a floppy emulator project I'm working on.. ;-)

desiv

[3583Bytes]

I use an external Lantronix box for that, although I didn't try connecting from my Amiga to a Linux box.  Only Telnet BBSes...

If you can transfer some programs to your Amiga, I'd try a better VT100 emulator next..
Maybe something like this:
http://aminet.net/package/comm/term/Vt100
(Note: I'm not sure that app is 1.3 happy.  It supports ARexx, so maybe not.  That was just a quick google search.)

I'll to set mine up if I get a chance this weekend.  I kind of have my A1000 totally open for a floppy emulator project I'm working on.. ;-)

desiv

I have vt100 installed (there is a version for 1.3), but it does not have a modem interface, it may work by directly interfacing with the Rastberry Pi TTL serial interfaces.  but I have not managed to get that going yet.  If someone has a tutorial please feel free to share.

Any help would be appreciate it.  For now I am interfacing with my Pi via windows but that is kind of insulting to both devices I think

[desiv]

Modem interface?

I wonder if the Windows tcpser is doing something different then..

For a telnet BBS, you use the  modem interface, or you type something like:
ATDT w.x.y.z
(where w.x.y.z is the IP or DNS name of the remote BBS)
TCPSER should send a RING to the telnet BBS program.  The telnet BBS, when it sees that, should send a CONNECT (and possibly a BAUD RATE) back to your program.
Your program sees the CONNECT and knows it's ONLINE.

TELNETd on a Linux box isn't going to know anything about RING or CONNECT..

Yep, been googling (as I was typing) and it looks like it might be related to IAC negotiation in telnet:
http://www.lemon64.com/forum/viewtopic.php?t=39987&sid=2011a548ba2b0338f3710203f90f7acd

Not sure why it works thru Windows tcpser tho...  It must be doing something different..

If the VT100 program you have lets you connect to a serial port, try that, and then use the ATDT w.x.y.x method to connect..
Not sure if it will recognize it at that stage tho, but maybe..

desiv

[3583Bytes]

Modem interface?

I wonder if the Windows tcpser is doing something different then..

For a telnet BBS, you use the  modem interface, or you type something like:
ATDT w.x.y.z
(where w.x.y.z is the IP or DNS name of the remote BBS)
TCPSER should send a RING to the telnet BBS program.  The telnet BBS, when it sees that, should send a CONNECT (and possibly a BAUD RATE) back to your program.
Your program sees the CONNECT and knows it's ONLINE.

TELNETd on a Linux box isn't going to know anything about RING or CONNECT..

Yep, been googling (as I was typing) and it looks like it might be related to IAC negotiation in telnet:
http://www.lemon64.com/forum/viewtopic.php?t=
39987&sid=2011a548ba2b0338f3710203f90f7acd
Not sure why it works thru Windows tcpser tho...  It must be doing something different..

If the VT100 program you have lets you connect to a serial port, try that, and then use the ATDT w.x.y.x method to connect..
Not sure if it will recognize it at that stage tho, but maybe..

desiv

tcpser does not pass the modem commands on, it just uses the telnet protocol because they are telnet BBSs.  

That lemon64 post may have a lead.  However I have no idea how to configure telnetd to bypass IAC negotiation.  Google is unhelful in this case,

Any Linux telnet experts know how to try this?

[3583Bytes]

One difference I noticed between the two is the usb device name,

Linux (pi):

 sudo tcpser -d /dev/ttyUSB0 -s 19200 -l5

Windows

tcpser.exe  -d /dev/ttyS2  -s 19200 -l5

I don't know if that makes a difference but perhaps not going through the tty device does not allow me to start a telnet session.  I am not a Linux expert so I am not sure.