Quote:

Thanks, i accepted the suggestion and will look at what can be done here. However it will take considerable time to implement this since current kernel has no traffic monitoring capabilities at all, they need to be implemented from scratch.

Tadaa:

https://morph.zone/modules/mydownloads/singlefile.php?lid=334

Already:
1. Implemented MiamiIsOnline() and MiamiOnOffline() - YAM should work again.
2. Frank Mariak disclosed details on AmiTCP fix, i implemented it. AmiSSL should work now too.
3. Some fixes in the SDK.
Expected:
1. Bug fix: crash when exitting ezTCP kernel before syslog viewer.
2. Enhancement: Ability to quit ezTCP using BREAK PORT ezTCP
3. Changing REXX port name to capitalized version (EZTCP) - for simplicity.
4. Further DHCP progress (added mktemp() to netlib).

@sonic

Any idea what causes still the slowness ? i tried again
copying the 27meg mospup.iso from pc to ram:
and ended up with ~33 secs / 0.8K/s

68k miamidx manages ~3100K/s

This is on a 100mbit network and eztcp 0.12

Quote:

Okay, the kernel seems to be stable so it's time to revert back some timer handling code. Old one didn't work due to a bug in other place and i rewrote it. That bug is fixed long time ago and now i can revert back to old code. Probably it'll be faster.

Unfortunately DHCP suite porting task came to a deadend since it requires such functions like fork(), execve(), and, moreover, it depends on UNIX shell. This makes ISC DHCP client inacceptable.
Fortunately, i managed to find another small DHCP client which doesn't have such a weird dependencies. Well, ezTCP will have DHCP support, but the work is actually started from scratch.

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