Work on ezTCP has slowed down a bit lately, but for a reason. I've just bought a flat the last Thursday, and now I'm in a process of moving there. But well, it isn't that I do nothing. I've implemented IP header chesksum routine and I'm going to speed it up with asm macro (as it uses some things like wrapped carry bit, it is very hard to make C compiler using some nice PowerPC instructions). Too bad I currently do not have detailed PPC instruction list, and downloading some User Manual via GPRS is very bad idea... I also have started work on IP defragmenting routine. I've also learned how to make Windows to throw a lot of heavily fragmented packets at ezTCP, so serious tests can be performed. I hope I will have a cable connection to the Internet at my new home so downloading heavy PDF-s will be no more a problem . So to sum it up: ezTCP is now able to open network device, set up a queue of requests, fetch packets, verify them (checksum, checking lengths etc.) and it will be able to defragment packets soon (with handling of defragmentation timeouts as recommended in RFC 791 and 1122). Then packets will be moved to a routing module.

Great to Hear... even with the slow down You are progressing faster
then I had imagined!! Keep up the good work!!

Excelent,

The work is going on !
We need a good TCP/IP stack.
Thank for it.
YEH

Congradulations on the new flat krashan, and thanks for the update about ezTCP. My apologies for being so quiet lately, but as I'm sure everyone can tell--I've had my hands full with MZ's newest little bug... (grr!)

I would also like to take a moment to send off a "Wow!" to the users-->WOW!!! I never expected to collect this much in donations! I don't know if you've all heard it often enough, but this community is absolutely amazing!

Hey cool stuff! :)

Just one question- will it have a Firewall/Packet Filtering, or a system in which a Firewall can be added by a third party?

- Ants

That was answered already. If I remember properly:
The initial bounty is for the stack, not for the extra features like packet capture / filtering / NAT BUT the stack is designed with modularity to allow the development of these extra features.

ezTCP has been imported to a CVS repository today. It means safe backup of sources and change log. Worked a bit on ARP packet verification and started DHCP client (it is a must for my new Internet connection).

Keep up the good work Krashan.

Is there any screenshot to see, or did you have any site running yet? or is it early...? :D

Quote:

Great news!

Oh, and DHCP is not only a must for *your* Internet connection, it's a must for *ALL* Internet connections!

takemehome

err what about static addressing??

magnetic


@krashan

great work

Magnetic: I'm sure Americans get as many static IPs as they
want - since you own 85% of the world's IPv4 ranges.

The rest of us has to share the last 15% (about 650 million)
adresses for 5.8 billion people..

Static IPs from your ISP is very rare in Europe.

ezTCP may be in the future extended to support IPv6 if it can help.

@ Krashan

Every time I see on the front page that you have posted something in ezTCP threads, I'm drawn to it like a magnet!

I cant wait to see a working beta. It looks like the money is rolling in! We went WAY over what the AROS guys went to on this one. I want to see it go over $1000 still.

@ Acill

Well I do not expect to have fully functional beta before end of september. I plan to release some alpha thing however. It won't be able to work as a TCP/IP stack yet, but will be released for users to test and detect problems with DHCP protocol. The protocol seem to have some 'flavors' and deviations from specification (to make things worse, it is documented in parts in at least 4 different RFC documents). As I can't test DHCP on many networks, alpha release will be used to gather possible problems. To release it I should finish DHCP module (the work is advanced) and basic routing module with UDP demultiplexer (just started today).

That would be a good approach IMHO. There are lots and lots of different ISP's, and I bet many of them provide their own various "flavours" of it, and the net connect procedure in large. Some kind of logger that writes all DHCP communications and individual user settings etc to a log file would perhaps be a good idea? That log file could then be sent in to you for "analysis" ...

@ takemehomegrandma

It is obvious. ezTCP makes real use of syslog() functionality and redirects all syslog() messages (generated both by ezTCP itself or by applications) to a nice graphical frontend (shot). This frontend also allows for saving the log to a file. Additionally all DHCP packets will be dumped to ramdebug, and can be captured for example by LogTool application.

> The initial bounty is for the stack, not for the extra features like packet capture / filtering / NAT BUT the stack is designed with modularity to allow the development of these extra features.

Nice! :)

- Ants

Today ezTCP has got a router process. It will be responsible for IP packets routing and also TCP and UDP multiplexing/demultiplexing for localhost. The router is just a process skeleton at the moment, but will be able to accept and send packet messages soon. The router process communicates with interface process(es), it accepts messages containing incoming packets and sends messages containing outgoing packets. In 'bounty' version of ezTCP it only sends packets generated by localhost applications (via bsdsocket.library API) and receives packets destined to the localhost. I will start from UDP demultiplexer, as it is easier (stateless) and needed for basic services like DHCP and resolver. Then TCP demultiplexer will be done.

Routing module is in the work. It is already prepared to handle multiple network interfaces and allows ezTCP to act as a gateway. It should be noted however, that no dynamic routing protocols will be implemented (may be added later however), so only static routes are possible. Routes are defined very easily. There will be one routing table for every network interface. Routing decision will be taken depending of destination IP address (I'm not sure if routing should depend on source IP too). Defined IP ranges can be sent to another interface, accepted by the localhost or dropped. Any number of ranges (including single IP ones) can be defined, they will be browsed top-down and first matching one will be used. If no range matches, packet is dropped.

@ Krashan

This is great news (as always)! I am getting more and more confident that not only will you complete the project, but that it also will be perhaps the best (and best performing) PPC TCP/IP kernel ever made for a single user (or *any*, who knows? ) platform!

Very interesting to see your progress reports! Keep them coming!

Quote:

I think that in order to collect working DHCP communication and "dialects" and other kinds of net connect procedure info, and/or custom settings for individual networks assigned to as many as possible of the European/World ISP's (in order to make it as compatible as possible by default), I think that the "logger" will have to be extremely easy to use, even for a "noob". If you release an "alpha version" of the stack, it could perhaps be more of a test app, with a focus to collect data from various networks in a *a push at a button* manner, preferably without any great need of networking/logging skills or experience. What I am talking about is perhaps a "connection wizard" with capturing and logging abilities, but in an extremely easy way? I don't know, perhaps this goes out of the scope of the bounty, but such a thing would perhaps result in a databank that could perhaps be valuable for the future evolution of the stack anyway, so ...?

Again, thanks for your reports!

UDP checksum verification works now. Then I plan to write an UDP demuxer, a routine which for every incoming packet checks the list of sockets waiting in recv() for a socket waiting on the same port as the destination port of packet. Then data may be delivered. The next step is send(), so a procedure assembling packets is needed. When I have a complete, bi-directional UDP communication I can finish DHCP module and also implement resolver module. After having working DHCP and resolver ezTCP may be considered standalone, so I need not run the second stack to test ezTCP, as it will be able to configure itself.

Thanks for the updates Krashan! I think your updates are really helpful for everyone, and I'm sure I speak for everyone when I say "thank you!"

completly according with targan.
It's very interesting to know what way ezTCP is going on.

Why all developers dont do the same ? unfortunatly.

Thks

Working DHCP module is closer step by step. Why it is not ready yet? Note that I have to setup almost complete socket API for DHCP. It can be done at lower level by hand-assembling IP packets, but socket API has to be done anyway, so it can be done now as well. The only thing not needed for DHCP (and resolver, which will follow DHCP module) is TCP implementation, as both DHCP and resolver rely on UDP protocol. I have some basic bsdsocket functions implemented like socket(), CloseSocket(), bind() and connect(), so almost all needed for DHCP, of course except of recv() and send(), but those are not difficult for UDP (and raw sockets).

In the meantime I realized, that, mainly because of select(), free socket sharing between processes is unimplementable. I've decided to drop this feature (as it is unportable to other stacks anyway), but increased descriptor table size to 512 sockets per process (should be enough even for P2P servers...). Of course AmiTCP-like socket sharing with ObtainSocket()/ReleaseSocket() will work.

As I plan to release ezTCP with sources, I'm also documenting the source code (with help of robodoc program), all internal functions will have autodocs. It helps me in developing and also will help anyone who want to improve, fix or enchance ezTCP.

The last thing for today is GUI question. I know that as a programmer I have a twisted look at GUI problems. So a discussion is welcome, how it should look like.