Quote:

Thanks for doing that! Targhan will update the list when he gets a chance. He does it by hand so it takes some time. This should take us over the $1000 mark!! Well done everyone. This is some serious motivation for Sonic to work non stop now eh? I think $1000 wil go a long way in Moscow.

Hi Motosampy what is the speed you get with ATC?

Unfortunately yesterday i was able to work only 1 hour, i fixed 4 bugs there. I decided to release the result as v0.3 since some people are incomfortable with ping's bsdsocket.library non-closure and some software could crash.
Also i would like to ask everyone to report an information about incompatible applications. I need application's name, version and which bsdsocket.library version it requires. This can be checked via SnoopDOS os Snoopium.
But, i did all the housekeeping work and Big Bug Safari will be opened today. I am going to fix the resolver at last!

Quote:

Remove DOMAIN line from your resolv.conf. This bug is being worked on, have to tell that is't hard to find, but today i'll drop everything other and do my best to destroy it.

Quote:
Can do better? Well, the task was there at least for about a half of the year, noone stopped you...
May be you'll explain here what results you actually got? Could be much more constructive...

Get ezTCP 0.3 while it's still fresh:

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

Wow Stevo does have got a huge finger in the pap..

Gr,
Felix.

I have just discovered why Samba doesn't work with ezTCP. Any ixemul application will not work until i rebuild usergroup.library. Without it ixemul disables any network support.
A possible workaround is to install old socket.library wrapper from Aminet and set "networking type" in ixprefs to as225.
Well, now it's up to you to decide what will be implemented first. It can be DHCP support or ixemul support. Your opinions?
Or course both things will be done, i am just asking about the priority.

My vote goes out to rebuilding the usergroup.library first.

usergroup.library should bo done first

My vote goes out to rebuilding the usergroup.library too.
Tryed 0.3
Jabberwocky still not work. HTTPresume too (it says "AmiTCP or a compatible TCP/IP stack must be started first!")
I still have strange intuiton problems, sometimes pressing "forwrd" button into IBrowse or closeing amirc windows (DCC too) makes my Peg to freeze.

A little suggestion for next release: remember to update version info inside ezTCP executable It still says 0.1
However good work and go ahead Sonic!

DHCP support...

Gr,
Felix.

One vote for DHCP here ...

Real power users use static IPs! DHCP is for pussies..
Just jokeing!

@ThePlayer

I have only 1M/512 adsl and get down average 97kb/s and up 47

DHCP ASAP

usergroup.library please.

I really like the progress of this!

[ Edited by takemehomegrandma on 2005/9/20 9:43 ]

I mean the Lan speed, i got up to 6MB with Genesis and up to 5mb with MiamiDX using ATC!

Nice! very nice. Now it resolvs as was meant to... And now that that works... It was all my fault, because I forgot about deleting that line in the file.

Next thing I wanted to try, was how fast this new stack is, and holly spaghetty monster! it's fast, quite fast... I got 18 megs in about 3 secs, which makes aroun 6Mb/s... But to be true, I couldn't finish downloading the file i was trying, because at around 20 megs, MOS got hung. I tried voyager and ibrowse. Now, i'm goung to try an ftp client, but for this, I need to set up a ftp server in my LAN first :P.

AWeb also got blocked downloading the file, but it did it quite slowly. About 2 Mb/s.

Very good work till now. I'll continue bugtracking.

I have just tried RDesktop (remote desktop client) and it seems to need unsergrouplibrary (I assume ixemul)).

I'll continue with my trial.

[ Edited by amiades on 2005/9/20 0:07 ]

Well, it will be first. I think it won't take long since i examined current code and came to a conclusion that it's totally bad, inserts many unneeded trash into the system (like netinfo.device, credential.resource, etc) and does not do its job since all tasks share common credentials. ixemul.library uses only several functions for accessing groups and passwd files and does not strictly depents on them. So i will write a plain silly stub which returns error on any function call but can be opened (this is enough for ixnet to work).
In theory there can be some applications which rely on usergroup functionality but there are quite a few of them. Full usergroup.library implementation is out of the scope of the task (in fact i wouldn't do it at all, it's ixemul's problem that is stuck to it), this is considered for future in a more normal way than it's done.

i get some funny problems, and i dont understand why..

in S:netdb/interfaces i have :

eth0 DEV=Devs:Networks/rtl_8139pci.device UNIT=0

the other unit(via rhine) is commented out

when executing s:startnet i get :

ifconfig: ioctl (SIOCGIFFLAGS): no such interface

in snoopium i dont even see anything trying to load
the rtl_8139pci.device ? what can be going wrong ?

and just a quick question from the config in archive,
C:ifconfig eth0 192.168.0.1 netmask 255.255.255.0

does this line set the computer ip at 192.168.0.1 ?

that ip is very normal ip for gateway/router

my computer ip is 192.168.0.20 and router ip is 192.168.0.1

so i guess my line is :
C:ifconfig eth0 192.168.0.20 netmask 255.255.255.0

and :
C:route add default 192.168.0.1

i use these ips in miami and work fine, so i guess eztcp
should too.

Quote:
Hmm... You'll be the second who will get version with debug output as soon as i fix DNS resolver (i found the problem at last, on the way to fix, but many places need to be checked).
Well, check the presence of a newline terminator after this line.
Quote:
You're absolutely right. My Pegasos at home has IP=192.168.0.1. It's just my config.
Quote:
Exactly.
By the way, may be it's your problem - the same IPs. Probably your interface fails to setup and you don't see the device loading just because you turned on "Show only fails" flag in Snoopium.

A big thanks to AmigaHarry, who donated $165 on friday! Wow. The bounty is above a grand now!

Yesterday i at last found the worst place in the DNS resolver and now it seems to be working fine. No crashes, no memory trashing. It was extremely badly written WaitSelect() function. Timer handling was horrible there. It lead to that the same timerequest could be posted twice or more. I found this when noticed that stopping DNS lookup via Ctrl-C always trashes memory and when lookup is ended by itself upon timeout everything goes fine. Tracing this lead me into WaitSelect().
Now several small issues are left like dangling timer signal, wrong error codes, etc, i hope today i'll have enough time to cleanup all that.
The second place is totally bad syslog buffer handling, will be rewritten too (v0.3 can freeze if several different tasks post many syslog messages at the same time). v0.4 is expected to be quite stable then.
In order to sort out the DOMAIN line issue i would like to ask someone to try to ping some nonexistent host name and tell me results. I guess it will resolve to some random IP instead of generating an error.

[ Edited by Sonic on 2005/9/22 9:33 ]

[ Edited by Sonic on 2005/9/22 10:28 ]