V0.13 had been uploaded and approved; same place as before

hey sonic,
many thanks for v0.13 ... Yam and SSL works now!
i wish you all the best for the new DHCP implementation.

Quote:
Have You had a look at lwIP? It looks portable (have only had a little look at the code long time ago), and includes an DHCP client...

[Edit]and it would even give MorphOS IPv6

[ Edited by hnl_dk on 2005/11/10 4:34 ]

Quote:

Yes, of course i looked it. It's worse solution than stack based on AmiTCP since lwIP is a thing-in-itself. It's hard to upgrade, it has no AmigaOS API, it has no SANA-II support, etc. It would require much more work.
As to IPv6, much better approach would be to re-merge recent FreeBSD code into ezTCP. This would give not only IPv6, but also PPP, PPPoE, ATM, BPF, PCap, etc.
In fact DHCP problem is not so large, i already reconsidered it back. ISC DHCP is good and up-to-date, it just requires more changes in the code. In the worst case re-merging newer versions out-of-the-box will be impossible due to large amount of changes, but that's all.

Today i thought a bit more and cleaned up ISC DHCP code. It will be used. It is possible to bypass all limitations in a portability-friendly manner. Script part will be either rewritten in native AmigaOS shell language or replaced with additional C code. The add-on will be made in a such manner that it will be able to be integrated into ISC distribution.

how can inetd be enabled? Copying inetd and inetd.conf to ezTCP directory and start it via shell? This doesn#t work for me.

- Copy inetd to somewhere.
- Copy inetd.conf to ezTCP:db
- Assign AmiTCP: ezTCP - this is necessary since inetd looks for this location.
If still doesn't work, please tell me what inetd says or Snoopium says.
I'll verify it on my machine.

Huh...
Congratulate me, on saturday it succesfully compiled for the first time.
Binaries don't work yet since some tweaking is still needed (replacing close() with CloseSocket() etc). But it's on the way.

@ Sonic

Yes indeed these are good news, congratulations!!!

I'm looking forward for the finished version.

Regards

Christoph

Sonic, great! Keep going!

I made another small donation to the bounty.

This should be a big step for MorphOS, no more need to use old Amiga stacks.

2 analogkid:

inetd can fail also because there's no user/group information availible and inetd relies on it. Try the following (in addition to previous recommendations):
1. Copy netinfo.device from m68k AmiTCP to DEVS:
2. Copy "passwd" and "group" files to ezTCP/db.
Hmm... This starts to be problematic enough to consider porting inetd and removing these issues. Well, i'll look at it...

@Sonic

Btw have you planned to build M68k version? I mean, some users have
asked it because there is no TCP/IP stack for 68k Amigas.

And is it possible to differentiate ezTCP from original AmiTCP? Scout
identifies (via identify.library) the TCP/IP stack. ezTCP would show
up as an AmiTCP (I believe) ?

Quote:

ezTCP is designed to portable by nature, it can be compiled on any AmigaOS-derived platform. In fact not all code is currently portable since i don't have time. m68k version requires additional maintenance. If there are any interested developers i would like to speak to them.
It is possible to open source code right now for porting, i would just need some additional agreement then which would prevent me from task takeover (some bad guy grabs the code, quickly finishes it since he's a student and has much more free time than i have, and claims for the reward).

Quote:
Hmmm. Don't know. It depends on how exactly identify.library finds out the stack type. There are a lot of ways to do it, and not every way is correct. I didn't check it myself.

Hi Sonic,

I would like to second this thought about separating ezTCP and AmiTCP. I for myself like to have several different software installed, and then also when it comes to TCP software.

However, haven't looked into how it works out with ezTCP/AmiTCP for now.

Gunne

@sonic

Sorry for being away, thus unable to answer emails. however, you shouldn't be concerned about anyone else grabbing the "bounty." The MorphZone Bounties aren't a free-for-all, just in case of the problem you have just mentioned. Anytime there is a conflict of programmers wanting to work on the same kind of project it has to be decided within some time frame of the initial agreement between the "bounties staff" and the programmer(s).

If we were to allow an open competition for some project or another, it would most likely be be stated as such before any programmer came aboard for a project.

The way I see it personally, if someone else came along and wanted to add valuable code to your project -- they should speak to you first to determine if you would be willing to share for the help. In other words, I leave anything of that nature in the programmer's (in this case, Sonic's) hands.

I'll get to your email shortly Sonic, and again I am sorry that I've been unavailable for so long.

Targh.

Quote:
Well well...
1. miami.library is not a problem. It will just detect that another stack is running and refuse to open.
2. usergroup.library - can cause problems with Genesis. Everything depends on what is loaded first. If AmiTCP is started at boot time before any ixemul apps then AmiTCP will load its own usergroup.library from AmiTCP:Libs. In fact plain AmiTCP has no strict dependencies, only Genesis has them (the GUI won't work with alien usergroup.library).

Yesterday i compiled DHCP client and it even starts! It even didn't crash! Wonderful...
http://sourceforge.net/project/screenshots.php?group_id=133480&ssid=21524

There's a small problem in the kernel so we see an error message. I already know how to fix it.

Sonic, this is great news! Keep up the great work. You are doing an awesome job!

Great Work... Keep it up!!!

Compiled next changes yesterday. Packets are sent to the network correctly. Nothing is received, but i guess the problem source is simple.
There will be no support script, everything will be written in C code.

I am glad to tell that i am at last moved away from the deadstop. It was tricky but i at last dealed with interface configuration and routing. Now dhclient sends out packets to the network but they are broken since there are currently no means to obtain hadrware address of an interface. This is being implemented now. I hope soon i'll get everything working.
I am sorry again for long delays. The kernel is really horribly outdated, a plenty of time is needed in order to bring it up.

I've at last finished writing, in the evening i'll try to compile the whole thing :)
The kernel is heavily fixed and updated. It supports a number of new IOCTLs and also i implemented an interface to statistics structures. "ifconfig" utility will be also upgraded to accomodate all changes. Probably i'll even build new normal "netstat" utility since everything is ready for it.
DHCP should start working at last after these changes. AF_LINK is fully supported now.
Changelog grows at a frightening speed...

how can you be sorry ? you're going so fast and did such an amazing job ! congrats !

I can only second that what Soundsquare is writing!
It's amazing to read and see the progress you make with the Port.

As I've said before, WELL DONE! I cant wait to see the results! Keep it up, your just fantastic!