chaps,

I've made a new release of ip65 (at MagerValp's request)

Main new features of this release is the addition of DHCP, DNS and TFTP

The new project homepage (including download links) is at http://ip65.sourceforge.net/

Cheers

Jonno

Wonder what that is then...

_________________
Commodore 128 Programmer
City of Kouvola, Finland

http://mydarkgothvampiricplace.endofthe ... Commodore/

IIRC it's an IP stack modeled after MagerValp's proposition for a standard for TCP/IP configuration on the C64.

actually, it's an ip stack modelled on MagerValp's ip stack for 6502 computers

It doesn't actually use that proposed standard for C64 IP configuration - you either hardcode the IP address,netmask, gateway etc directly into the application, or (as of the the latest release, you can use DHCP - although the MAC address is still hardcoded into the application).

Most of the code is MagerValp's work, I'd made some extensions (DHCP/DNS/TFTP) and since MagerValp didn't have time to integrate them into his codebase, he invited me to take over the project, which I did.

Cool. Have to check it out and see how it differs from uIP.

I'm trying to compile ip65 from ip65-2009-03-21.zip, but get this error:

shadowm@cenbe:/mnt/common/src/ip65 > make
make -C ip65 all
make[1]: Entering directory `/mnt/common/src/ip65/ip65'
ca65 copymem.s
ca65 config.s
ca65 timer.s
ca65 cs8900a.s
ca65 eth.s
ca65 arp.s
ca65 ip.s
ca65 icmp.s
ca65 udp.s
ca65 ip65.s
ca65 printf.s
ca65 debug.s
ca65 dhcp.s
ca65 dns.s
ca65 dottedquad.s
ca65 tftp.s
make[1]: *** No rule to make target `\', needed by
`ip65.lib'. Stop.
make[1]: Leaving directory `/mnt/common/src/ip65/ip65'
make: *** [ip65] Error 2
shadowm@cenbe:/mnt/common/src/ip65 >

Anybody know what I'm doing wrong? I'm using cc65-2.12.0 under the current version of Ubuntu.

_________________
"...and all watched over by machines of loving grace."

not sure exactly what the problem is but guessing from the fact the failure is for "\" and the fact you're compiling on linux, my guess is there is some whitespace or such in the makefile that causes issues on linux but not on windows (which I use).

Can you try grabbing the latest version (which I've only just uploaded today) and see if you still have the problem?

Thanks, got a lot farther:
...
ca65 testtftp.s
ld65 -C ../cfg/a2bin.cfg -o testtftp.pg2 testtftp.o ../ip65/ip65.lib ../drivers/apple2prog.lib
ripxplore.rb --init BeautifulBoot ip65test.dsk -a testdns.pg2 -t AppleBinary
make[1]: ripxplore.rb: Command not found
make[1]: *** [ip65test.dsk] Error 127
rm testtftp.o testdottedquad.o testdns.o
make[1]: Leaving directory `/mnt/common/download/c64/networking/ip65/ip65/test'
make: *** [test] Error 2

_________________
"...and all watched over by machines of loving grace."

what's happening there is the build of "ip65test.dsk" is failing because it uses a ruby tool (calle ripxplore.rb) to make an Apple 2 disk image file containing 4 test programs.

If you do want to be able to test ip65 for the Apple 2, you could install ripxplore by typing "sudo gem install ripxplore" (assuming you have ruby installed on your machine, "gem install" will find and download the package for you).

Alternatively you can just remove that target from the "all:" target - by deleting the line straight after "all:" that says ip65test.dsk \

I had tried that actually, although I know nothing about Ruby, so...


That worked for me. The only issue I still see is that I'm getting an empty file for ref_frames.html in the doc/ directory. I grabbed a copy of that file from the paradroid site, and then I could see the technical reference, which is extremely helpful.

_________________
"...and all watched over by machines of loving grace."

Cool! Have fun and let us know what you come up with (or if you get stuck).

BTW I will probably do another ip65 release in the next week or so to address some gaps in tcp functionality (i.e. I need to allow the c64 end to initiate closing a connection, and also let it listen on a port, so it can act as a server - still only planning on allowing a single connection at a time though).

Cheers

Jonno

That's excellent news! Good thing I didn't get too far with my TFTP client TCP opens up all kinds of new possibilities.

I'm not sure what your definition of a single connection is, but I think support for 1 outgoing and 1 incoming connection (hence 2 connections) simultaneously would be really useful! Some protocols require that, (FTP IIRC. I dont know about IRC...). Allowing for simultaneous connections shouldn't add too much code. Remember, it's still sufficient to process only 1 "socket" at a time. You don't need to cache packet data for multiple connections. But I guess you knew that already

The difference between incoming and outgoing disappears as soon as a connection is established (i.e. in either case you end up with a bi-directional connection). At the moment the stack only allows a single outgoing connection, but I will shortly add the ability to listen for an incoming connection OR make an outbound connection, but not both at the same time.

I agree it's not a whole lot of extra code to allow multiple connections, but it's more than zero and will be a bit more effort to debug (which is the main reason I didn't include it to start - I figured it would take me long enough to shake out all the bugs in getting the packet sequencing and acknowledgement right, I didn't want to confuse things with bugs where I'd e.g. end up mixing in data from the wrong connection). So I will add it if/when I find an app I want to write that actually needs it.

The only client app I can think of is (as you say) ftp, but I'm not that keen in writing an ftp app - now that I have tftp working with some custom extensions to support directory listings, the only thing ftp would give you over that is a) username/password authentication (in clear text hence not much better than nothing at all) and b) a headache if you tried to implement "ascii" mode properly.

I believe an IRC client would need 1 tcp connection for each server, and another for sending files directly to/from another user (DCC SEND or whatever it is) - I think the client side code needed to manage multiple channels let alone multiple servers will be too complex for me to deal with in ASM, so c & contiki are probably better tools for anyone attempting such a feat.

There might be some value in allowing multiple inbound connections for a multi-threaded server (e.g. a web server) but again there would be a lot of complexity on the app side, and there's no real need (or value) to process requests in parallell - you might as well serialize them (e.g. by not responding to SYN requests when 1 connection is already in flight - the browser will resend the SYN a bunch of times and connect once the previous 'in-flight' request is complete).

But the beautiful think about open source is if anyone really wants multiple connections, they are very welcome to add support themselves