ol.sc Posted August 18, 2015 Author Share Posted August 18, 2015 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 1 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted August 25, 2015 Author Share Posted August 25, 2015 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.nongnu.org/bugs/?40303#comment2 That issue is fixed with https://github.com/contiki-os/contiki/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 contiki-atari.zip Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 26, 2015 Share Posted August 26, 2015 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? Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 26, 2015 Share Posted August 26, 2015 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. Quote Link to comment Share on other sites More sharing options...
ol.sc Posted August 26, 2015 Author Share Posted August 26, 2015 (edited) 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.io/doc/atari.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 August 26, 2015 by ol.sc Quote Link to comment Share on other sites More sharing options...
ol.sc Posted August 26, 2015 Author Share Posted August 26, 2015 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 Quote Link to comment Share on other sites More sharing options...
phaeron Posted August 27, 2015 Share Posted August 27, 2015 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? Quote Link to comment Share on other sites More sharing options...
ol.sc Posted August 28, 2015 Author Share Posted August 28, 2015 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/forums/topic/242150-stock-ip65-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 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 17, 2015 Share Posted September 17, 2015 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 ... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 18, 2015 Share Posted September 18, 2015 (edited) 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 September 18, 2015 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
ol.sc Posted September 18, 2015 Author Share Posted September 18, 2015 (edited) 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/contiki-os/contiki/blob/master/apps/irc/irc.c https://github.com/contiki-os/contiki/blob/master/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 September 18, 2015 by ol.sc 1 Quote Link to comment Share on other sites More sharing options...
Joey Z Posted September 18, 2015 Share Posted September 18, 2015 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 Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 18, 2015 Share Posted September 18, 2015 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...... Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted September 20, 2015 Share Posted September 20, 2015 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 Quote Link to comment Share on other sites More sharing options...
ol.sc Posted November 15, 2015 Author Share Posted November 15, 2015 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/contiki-os/contiki/commits/a161dc2 Regards, Oliver contiki-atari.zip 3 Quote Link to comment Share on other sites More sharing options...
w1k Posted November 15, 2015 Share Posted November 15, 2015 (edited) oooo, big thanks whats fixed, changelog? Edited November 15, 2015 by w1k Quote Link to comment Share on other sites More sharing options...
puppetmark Posted November 17, 2015 Share Posted November 17, 2015 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/contiki-os/contiki/commits/a161dc2 Regards, Oliver Thanks Oliver! I added this information and the new build to the Project website. http://www.atari8ethernet.com/ Quote Link to comment Share on other sites More sharing options...
w1k Posted November 18, 2015 Share Posted November 18, 2015 wow, this version is pretty fast web brosing.. Quote Link to comment Share on other sites More sharing options...
w1k Posted November 19, 2015 Share Posted November 19, 2015 (edited) hey, how works TELNETD? i trying to connect to localhost:22 (ssh) Edited November 19, 2015 by w1k Quote Link to comment Share on other sites More sharing options...
ol.sc Posted November 19, 2015 Author Share Posted November 19, 2015 whats fixed, changelog? Primarily https://github.com/contiki-os/contiki/commit/1066bb1a0b7aa4ceab004592610d813252f6538f Quote Link to comment Share on other sites More sharing options...
ol.sc Posted November 19, 2015 Author Share Posted November 19, 2015 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. Quote Link to comment Share on other sites More sharing options...
w1k Posted November 19, 2015 Share Posted November 19, 2015 (edited) 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 Edited November 19, 2015 by w1k Quote Link to comment Share on other sites More sharing options...
ol.sc Posted November 19, 2015 Author Share Posted November 19, 2015 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. Quote Link to comment Share on other sites More sharing options...
w1k Posted November 19, 2015 Share Posted November 19, 2015 nice.. connected via PUTTY.. Quote Link to comment Share on other sites More sharing options...
TheMontezuma Posted November 19, 2015 Share Posted November 19, 2015 Would it be a big effort to build a telnet client for the CONTIKI? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.