Jump to content

Photo

Contiki - August 2015


70 replies to this topic

#26 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Tue Aug 18, 2015 4:08 PM

Hi,

 

Thank you for the kind words Oliver.  I am very proud of the work we have done.

 

:-)

 

For me that was/is like standing on the shoulder of giants: On the one hand the Dragon Cart behaving totally identical to the CS8900A-based devices on the C64 and Apple II - and on the other hand the work Chris and others have put into the cc65 C library for the Atari (XL).

 

[...] but it only had a small part in my decision to put the next hardware production oh hold.

 

Good to know !

 

Regards,

Oliver



#27 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Tue Aug 25, 2015 4:37 PM

Hi,

 

Think I may have found a small issue in the DHCP client in ipconfig.com. According to RFC2131 a client is supposed to send a DHCPREQUEST message with the same 'xid' as the corresponding DHCPOFFER message from the server, but ipconfig is using a different xid. I ran into this problem with a custom dhcpd implementation that validated the xid field (which apparently most dhcpds don't). This is what I'm seeing:

client > server: DHCPDISCOVER, xid=1
server > client: DHCPOFFER, xid=1
client > server: DHCPREQUEST, xid=2

Apparently, lwIP had the same issue:

 

http://savannah.nong...?40303#comment2

 

That issue is fixed with https://github.com/c...ntiki/pull/1214

 

Please find attached the updated .zip file.

 

However if the "custom dhcpd implemenation" you mention happens to be Altirra 1.60 then ipconfig.com still doesn't work. As far as I can see from the CS8900AN log the DHCP server's DHCPOFFER doesn't include the DHCP message type (0x35 0x01 0x02).

 

Regards,

Oliver

Attached Files



#28 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Tue Aug 25, 2015 10:20 PM

I remember testing about on this a few years back, but we had the Atari running part of it and then the pc running the other part.. The Atari is doing all of the work now?? how cool! Glad to see it is moving forward and much better in function as well.. Great Job!

 

side question. Is it still going to function via slip... siotopc... or possibly lantronix uds..... or is it going to be dragon only?



#29 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,240 posts
  • Location:USA

Posted Tue Aug 25, 2015 10:53 PM


However if the "custom dhcpd implemenation" you mention happens to be Altirra 1.60 then ipconfig.com still doesn't work. As far as I can see from the CS8900AN log the DHCP server's DHCPOFFER doesn't include the DHCP message type (0x35 0x01 0x02).

 

Thanks, can confirm it's fixed.

 

Altirra 2.60's DHCP server is bugged -- I was actually in the process of fixing it for 2.70 when I ran into this issue. I've already adjusted the internal dhcpd to ignore the xid field, but haven't published a release with the fix yet.



#30 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Wed Aug 26, 2015 7:58 AM

Hi,

 

I remember testing about on this a few years back, but we had the Atari running part of it and then the pc running the other part.. The Atari is doing all of the work now?? how cool! Glad to see it is moving forward and much better in function as well.. Great Job!

 

Thanks :-) Yes, Contiki is about running everything on the Atari. No host / server / proxy whatsoever. Just a straight Ethernet connection.

 

side question. Is it still going to function via slip... siotopc... or possibly lantronix uds..... or is it going to be dragon only?

 

As already mentioned I don't see Contiki with any type of "serial line emulated by TCP connection" device. SLIP is of course different as the TCP/IP stack stays on the Atari...

 

SLIP would be conceptually for sure be possible. It would even be sort of nice as cc65 comes with an abstraction layer for serial ports which could be used here in the same way the Contiki mouse support uses the mouse abstraction layer of cc65.

 

For the Atari there's an implementation of that abstraction layer  for the R: device - see http://cc65.github.i...tari.html#ss6.5

 

However I personally am not interested in SLIP as it isn't a standard network interface nowadays. You'd have to set up a SLIP server for that very purpose. And at that point you can as well start to move functionality to that SLIP server - up to the point of offering a shell login with Lynx etc. and running Dan's Telnet client...

 

Regards,

Oliver


Edited by ol.sc, Wed Aug 26, 2015 8:04 AM.


#31 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Wed Aug 26, 2015 8:13 AM

Hi,

 

 

Thanks, can confirm it's fixed.

 

Thanks for testing and providing feedback :-)

 

 

Altirra 2.60's DHCP server is bugged -- I was actually in the process of fixing it for 2.70 when I ran into this issue. I've already adjusted the internal dhcpd to ignore the xid field, but haven't published a release with the fix yet.

 

Thanks for the explanation. As you can imagine I was wondering how you managed to find an issue in Contiki's DHCPREQUEST message when I didn't manage to get to the point of having Contiki send a DHCPREQUEST message ;-)

 

Does your latest 2.70 pre-release already contain your DHCPD fixes - apart from the xid thingy? If not it would be nice if you would post a short message in this thread when an Altirra is available that's compatible with the IPCONFIG.COM I posted yesterday.

 

BTW: It would of course be great if the Altirra NAT would allow for incoming connections. From the tech demo perspective the Contiki Telnet server is the most interesting program as it can use two TCP connections simultanously: One incoming from the Telnet client and one outgoing for the wget shell command.

 

Regards,

Oliver



#32 phaeron OFFLINE  

phaeron

    River Patroller

  • 2,240 posts
  • Location:USA

Posted Thu Aug 27, 2015 1:07 AM

Does your latest 2.70 pre-release already contain your DHCPD fixes - apart from the xid thingy? If not it would be nice if you would post a short message in this thread when an Altirra is available that's compatible with the IPCONFIG.COM I posted yesterday.

 

BTW: It would of course be great if the Altirra NAT would allow for incoming connections. From the tech demo perspective the Contiki Telnet server is the most interesting program as it can use two TCP connections simultanously: One incoming from the Telnet client and one outgoing for the wget shell command.

 

Yes, 2.70 test-22/23 has the dhcpd fixes and also has support for mapping incoming connections. Specifically, you can specify a forwarding port and address, and the emulator will listen on and reflect connections. For instance, if you specify 192.168.100.100 port 80 as the forwarding address, any TCP connections or UDP data sent to port 80 on the local host will be forwarded to 192.168.100.100:80 on the emulation network. Note that due to socket limitations, TCP connections to the host will succeed even if the emulation network isn't responding -- standard sockets doesn't allow programs to hold the TCP connection half-open (although there may be a Winsock extension to do this).

 

I am having problems getting incoming connections to work reliably, though. With webserv.com, most of the time they are getting stuck like this:

CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49156 > 192.168.0.101:80 tcp S 4067860995:4067860995(0) win 32768
CS8900AN: Sending 58 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49156 tcp S 72:72(0) ack 4067860996 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49156 > 192.168.0.101:80 tcp . 4067860996:4067860996(0) ack 73 win 32768
CS8900AN: Receiving 137 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49156 > 192.168.0.101:80 tcp . 4067860996:4067861091(95) ack 73 win 32768
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49156 tcp . 73:73(0) ack 4067861091 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49156 > 192.168.0.101:80 tcp . 4067861091:4067861091(0) ack 73 win 32768
<pause>
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49156 tcp R 73:73(0) ack 4067861091 win 1460

The HTTP request goes through and is ACKed by the Contiki TCP stack, but no data comes back. Eventually the connection times out and Contiki resets the connection. However, if I connect a Linux VM via VXLAN, it is able to retrieve index.htm fine:

CS8900AN: Receiving 30 byte frame: 42:D1:92:A0:AD:2B > FF:FF:FF:FF:FF:FF | arp where is 192.168.0.101
CS8900AN: Sending 42 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | arp 192.168.0.101 is at 00:0E:3A:11:11:11
CS8900AN: Receiving 62 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp S 2808285807:2808285807(0) win 29200
CS8900AN: Sending 58 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp S 0:0(0) ack 2808285808 win 1460
CS8900AN: Receiving 42 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp . 2808285808:2808285808(0) ack 1 win 29200
CS8900AN: Receiving 153 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp P 2808285808:2808285919(111) ack 1 win 29200
CS8900AN: Sending 138 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp P 1:85(84) ack 2808285919 win 1460
CS8900AN: Receiving 42 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp . 2808285919:2808285919(0) ack 85 win 29200
CS8900AN: Sending 81 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp P 85:112(27) ack 2808285919 win 1460
CS8900AN: Receiving 42 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp . 2808285919:2808285919(0) ack 112 win 29200
CS8900AN: Sending 619 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp P 112:677(565) ack 2808285919 win 1460
CS8900AN: Receiving 42 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp . 2808285919:2808285919(0) ack 677 win 29945
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp F 677:677(0) ack 2808285919 win 1460
CS8900AN: Receiving 42 byte frame: 42:D1:92:A0:AD:2B > 00:0E:3A:11:11:11 | ipv4 192.168.0.200:58944 > 192.168.0.101:80 tcp F 2808285919:2808285919(0) ack 678 win 29945
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 42:D1:92:A0:AD:2B | ipv4 192.168.0.101:80 > 192.168.0.200:58944 tcp . 678:678(0) ack 2808285920 win 1460

Now here's the really weird part. If I retry the emulator's forwarded connection after the Linux box connects, it sometimes mysteriously works, even though the initial packets for the 3-way handshake and header transmit are pretty much the same:

CS8900AN: Receiving 30 byte frame: 02:00:00:00:00:01 > FF:FF:FF:FF:FF:FF | arp where is 192.168.0.101
CS8900AN: Sending 42 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | arp 192.168.0.101 is at 00:0E:3A:11:11:11
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp S 34212681:34212681(0) win 32768
CS8900AN: Sending 58 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp S 121:121(0) ack 34212682 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212682:34212682(0) ack 122 win 32768
CS8900AN: Receiving 137 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212682:34212777(95) ack 122 win 32768
CS8900AN: Sending 138 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp P 122:206(84) ack 34212777 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212777:34212777(0) ack 206 win 32768
CS8900AN: Sending 81 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp P 206:233(27) ack 34212777 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212777:34212777(0) ack 233 win 32768
CS8900AN: Sending 619 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp P 233:798(565) ack 34212777 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212777:34212777(0) ack 798 win 32768
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp F 798:798(0) ack 34212777 win 1460
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp . 34212777:34212777(0) ack 799 win 32768
CS8900AN: Receiving 42 byte frame: 02:00:00:00:00:01 > 00:0E:3A:11:11:11 | ipv4 192.168.0.1:49153 > 192.168.0.101:80 tcp F 34212777:34212777(0) win 32768
CS8900AN: Sending 54 byte frame: 00:0E:3A:11:11:11 > 02:00:00:00:00:01 | ipv4 192.168.0.101:80 > 192.168.0.1:49153 tcp . 799:799(0) ack 34212778 win 1460

Wireshark didn't help much -- it flagged a duplicate ACK coming out of the emulator's TCP stack, but fixing that didn't solve the timeout problem. Telnetd.com has the same issue. Any clue on your end?

 

 



#33 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Fri Aug 28, 2015 8:26 AM

Hi,

 

 

Yes, 2.70 test-22/23 has the dhcpd fixes and also has support for mapping incoming connections. Specifically, you can specify a forwarding port and address, and the emulator will listen on and reflect connections. For instance, if you specify 192.168.100.100 port 80 as the forwarding address, any TCP connections or UDP data sent to port 80 on the local host will be forwarded to 192.168.100.100:80 on the emulation network. Note that due to socket limitations, TCP connections to the host will succeed even if the emulation network isn't responding -- standard sockets doesn't allow programs to hold the TCP connection half-open (although there may be a Winsock extension to do this).

 

Wow, that's pretty cool :-) 

 

 

I am having problems getting incoming connections to work reliably, though.

 

[...]

 

Any clue on your end?

 

In fortunately not :-( After all I didn't write the core Contiki code...

 

However I felt that it might be helpful for you to have alternative ATARI network software listening on incoming TCP connections. Therefore I went ahead and "quickly" ported the stock IP65 library to the ATARI - see http://atariage.com/...-for-the-atari/

 

The HTTPD.COM in the disk image attached to that message works pretty nicely on the C64 and the Apple II. In fact it was used for endurance testing the Contiki/IP65 W5100 driver (using Siege)...

 

Regards,
Oliver


#34 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Thu Sep 17, 2015 3:45 PM

in the irc.com file,

a couple of simple issues to address, irc.com cuts off at 80 characters on screen output so it's nick:output to 40 wrap line then output to 40 cut...

since a standard nick is 9 characters plus a dividing character.... total of 10 characters... the irc.com client should be modified to wrap twice and cut at 90.... that will make it follow the standard..

 

the divider is colon which is good..... when receiving a private message irc may send an asterisk or other flag... the divider should alter when receiving a private message.

those two changes increase usability quite nicely...

 

I am pretty sure you've already started working more deeply in the client ...



#35 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Thu Sep 17, 2015 8:32 PM

cut after 90 ie 120 cut since a whole line would be wasted and some servers will prepend commands in front of a line

40 characters wrap

40 characters wrap

40 characters cut

most it could spit out is 120 or three lines before moving on...

this help greatly if using any irc functions and commands


Edited by _The Doctor__, Thu Sep 17, 2015 8:35 PM.


#36 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Fri Sep 18, 2015 1:55 AM

Hi,

 

First of all thanks for checking out the IRC client.

 

I am pretty sure you've already started working more deeply in the client ...

 

Actually the very opposite is true. I've basically never looked at the IRC client code.

 

I've personally never used IRC neither in the past nor now. I must admit that I'm personally not interested IRC. Maybe I just don't know what I'm missing but I'm not into any type of text chat / messaging.

 

Given the above I'd appreciate if you - or someone reading (and in contrast to me understanding) your post - would look at the souce and modify it to your needs. I'd commit to make sure that I'll have it merged into the Contiki upstream repo and create new disk images. See:

https://github.com/c.../apps/irc/irc.c

https://github.com/c...apps/irc/ircc.c

 

If that's impossible you'd need to provide me a step-by-step guide on how to reproduce the issue you describe, what part of the screen output differs from your expectation and how that part should rather look like.

 

Regards,

Oliver


Edited by ol.sc, Fri Sep 18, 2015 1:57 AM.

  • w1k likes this

#37 Joey Z OFFLINE  

Joey Z

    Dragonstomper

  • 874 posts
  • Location:Hoffman Estates, IL

Posted Fri Sep 18, 2015 7:09 AM

cut after 90 ie 120 cut since a whole line would be wasted and some servers will prepend commands in front of a line

40 characters wrap

40 characters wrap

40 characters cut

most it could spit out is 120 or three lines before moving on...

this help greatly if using any irc functions and commands

messages on every network I've ever used can be as long as 256 characters, IIRC, so that should probably be taken into account deciding the limit before a message is cut off



#38 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Fri Sep 18, 2015 7:16 AM

I see some irc extends the nick up to 16 + 1 for a total of 17 char.. but it has to be done on the entire network, I haven't seen 256 as a continuous stream but rather sent as two 128 pieces.... going to have to dig further I guess......



#39 _The Doctor__ OFFLINE  

_The Doctor__

    River Patroller

  • 2,354 posts
  • Location:10-0-11-00:02

Posted Sat Sep 19, 2015 10:15 PM

looks like it depends on the network and who accesses what and how....unlike using telnet to access irc.... I shouldn't make any assumptions... Time to go back and read what supposed to be at the core of it all instead of what I perceive by observation... Just sent a larger line via web interface... as opposed to thru the cart and it's a different ball game.....  did not realize it was limiting what I sent.... now I know



#40 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Sun Nov 15, 2015 10:08 AM

Hi,

 

I fixed several issues and created new Contiki disk images.

 

I'm not in control over Contiki versioning - and even if I were I'd likely not bump the version for every code drop. So in order to allow you to understand what Contiki code base was used to create the disk images the ZIP files from now on contain a ZIP comment. It's a link to the Contiki GitHub page showing the last commits (incl. their date) that are part of the code base. For the ZIP file attached that link is https://github.com/c...commits/a161dc2

 

Regards,

Oliver

Attached Files



#41 w1k OFFLINE  

w1k

    Stargunner

  • 1,646 posts
  • Location:martin, slovakia

Posted Sun Nov 15, 2015 10:09 AM

oooo, big thanks :)

 

whats fixed, changelog?


Edited by w1k, Sun Nov 15, 2015 10:11 AM.


#42 puppetmark OFFLINE  

puppetmark

    Dragonstomper

  • 710 posts

Posted Tue Nov 17, 2015 9:03 AM

Hi,

 

I fixed several issues and created new Contiki disk images.

 

I'm not in control over Contiki versioning - and even if I were I'd likely not bump the version for every code drop. So in order to allow you to understand what Contiki code base was used to create the disk images the ZIP files from now on contain a ZIP comment. It's a link to the Contiki GitHub page showing the last commits (incl. their date) that are part of the code base. For the ZIP file attached that link is https://github.com/c...commits/a161dc2

 

Regards,

Oliver

 

 

Thanks Oliver!

 

I added this information and the new build to the Project website.  http://www.atari8ethernet.com/



#43 w1k OFFLINE  

w1k

    Stargunner

  • 1,646 posts
  • Location:martin, slovakia

Posted Wed Nov 18, 2015 6:08 AM

wow, this version is pretty fast :) web brosing.. :)



#44 w1k OFFLINE  

w1k

    Stargunner

  • 1,646 posts
  • Location:martin, slovakia

Posted Thu Nov 19, 2015 4:35 AM

hey, how works TELNETD?

 

i trying to connect to localhost:22 (ssh)


Edited by w1k, Thu Nov 19, 2015 4:35 AM.


#45 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Thu Nov 19, 2015 4:49 AM

whats fixed, changelog?

 

Primarily https://github.com/c...10d813252f6538f



#46 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Thu Nov 19, 2015 4:54 AM

i trying to connect to localhost:22 (ssh)

 

SSH isn't Telnet ;-)

 

Use a Telnet client (on default Telnet port 23). I.e. PuTTY allows to switch to Telnet.



#47 w1k OFFLINE  

w1k

    Stargunner

  • 1,646 posts
  • Location:martin, slovakia

Posted Thu Nov 19, 2015 5:13 AM

so, with TELNETD.COM i can open only 23 port?

 

something like putty doesnt exist on atari?

 

here is TELNETD.COM:

this is ok?

how i can open something like PD.DARKTECH.ORG ?

 

edit:

AMIGA mouse doesnt work.. port 1, 2

Attached Thumbnails

  • IMG_3170.jpg

Edited by w1k, Thu Nov 19, 2015 5:17 AM.


#48 ol.sc OFFLINE  

ol.sc

    Space Invader

  • Topic Starter
  • 44 posts

Posted Thu Nov 19, 2015 5:30 AM

TELNETD.COM isn't a Telnet client, it's a Telnet server (aka Telnet Daemon). Use it like the web server: Start it and connect to it with a suitable client from another computer.



#49 w1k OFFLINE  

w1k

    Stargunner

  • 1,646 posts
  • Location:martin, slovakia

Posted Thu Nov 19, 2015 5:37 AM

nice.. connected via PUTTY..



#50 TheMontezuma OFFLINE  

TheMontezuma

    Dragonstomper

  • 530 posts
  • Location:Hildesheim, D / Kraków, PL

Posted Thu Nov 19, 2015 6:05 AM

Would it be a big effort to build a telnet client for the CONTIKI?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users