Jump to content
IGNORED

Contiki - August 2015


ol.sc

Recommended Posts

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

  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by ol.sc
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

 

 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

  • 3 weeks later...

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 ...

Link to comment
Share on other sites

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__
Link to comment
Share on other sites

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 by ol.sc
  • Like 1
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 1 month later...

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

  • Like 3
Link to comment
Share on other sites

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/

Link to comment
Share on other sites

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

post-23051-0-22417500-1447931635_thumb.jpg

Edited by w1k
Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...