External interrupts generated by TCP/IP stacks

[dissident]

Originally Posted by StingRay

FindResident() might be an option.

Thanks for the hint. I know FindResident() from the standart bootblock-routine. I will check this way to detect the bsdsocket.library this way.

[dissident]

Originally Posted by StingRay

FindResident() might be an option.

It doesn't work. I've tested it with Miami running in the background and the bsdsocket.library was not found. But SysInfo said it is there. So this library seems not to be resident.

[dissident]

But using OpenLibrary() worked. The bsdsocket.library was found.

[mark_k]

Originally Posted by dissident

So I guess I only have to try to open this library:
...

That may not be the best method. Is it possible (depending on the TCP/IP software I guess) that opening bsdsocket.library could enable network card interrupts?

Better would be to do something like this (in pseudo-code):

	Forbid()
	FindName(ExecBase->LibList, "bsdsocket.library")
	beq.b	no_bsdsocket

	movea.l	D0,A0
	tst.w	(LIB_OPENCNT,A0)
	beq.b	bsdsocket_idle

	moveq	#yy,D0	;Indicate bsdsocket.library exists and is opened (in use?)
	bra.b	done

bsdsocket_idle
	moveq	#zz,D0	;Indicate bsdsocket.library exists but opencount is 0
	bra.b	done

no_bsdsocket
	moveq	#xx,D0

done	Permit()
	rts

[dissident]

Originally Posted by mark_k

That may not be the best method. Is it possible (depending on the TCP/IP software I guess) that opening bsdsocket.library could enable network card interrupts?

Better would be to do something like this (in pseudo-code):

    Forbid()
    FindName(ExecBase->LibList, "bsdsocket.library")
    beq.b    no_bsdsocket

    movea.l    D0,A0
    tst.w    (LIB_OPENCNT,A0)
    beq.b    bsdsocket_idle

    moveq    #yy,D0    ;Indicate bsdsocket.library exists and is opened (in use?)
    bra.b    done

bsdsocket_idle
    moveq    #zz,D0    ;Indicate bsdsocket.library exists but opencount is 0
    bra.b    done

no_bsdsocket
    moveq    #xx,D0

done    Permit()
    rts

Many thanks for that hint, mark_k. I will check this.

[dissident]

I included mark_k's test-routine in a little AGA-intro. Now I need some testers who can test it in conjunction with different common TCP/IP apps namely:

-AmiTCP
-MiamiDX
-Genesis
-IIRC
-Roadshow

on an AGA machine.

What should you do?

Please start your TCP/IP app before you start my enclosed intro from your WB by its WB-icon.

What should happen?

The intro should detect the existing used bsdsocket.library and open a requester to inform you that a TCP/IP app is running. Now you have the choice. Exit the intro by selecting the gadget "Forget it!" or pressing the gadget "Resume".
If your TCP/IP app is still open, then the requester should appear again. Close your app and try the gadget "Resume" again. Now the intro should start and show a morphing glenz vector with some music playing. The module controls the morphing of the object.
The replay routine uses INT2&6, the main routine runs in user mode and waits for the VBI in a loop. The morphing is triggered by the Module (with a special $800 command) generating a SOFTINT-interrupt which is checked and replied in the main routine.

My test on real hardware (A1200/030 + Miami) was successful.

Thanks for testing and your feedback.

[Toni Wilen]

IMHO it is good idea to have "ignore" option too because for example UAE bsdsocket won't generate any interrupts if there is no open connections. Real hardware bsdsocket (NIC device driver) probably won't benerate any interrupts either if network cable is not connected. At least some drivers.

Preferably via command line.

[daxb]

Tested on A1200 040 with/without MiamiDx running and it works.

[dissident]

Originally Posted by daxb

Tested on A1200 040 with/without MiamiDx running and it works.

Hi daxb. Many thanks for your support.

[dissident]

Originally Posted by Toni Wilen

IMHO it is good idea to have "ignore" option too because for example UAE bsdsocket won't generate any interrupts if there is no open connections. Real hardware bsdsocket (NIC device driver) probably won't benerate any interrupts either if network cable is not connected. At least some drivers.

Preferably via command line.

Okay, that means that my assumtion with this code doesn't guarantee that a bsdsocket.library found in exec's library list and which is opened does not always generate interrupts at last?

  CALLEXEC Forbid            ;Multitasking off
  lea     LibList(a6),a0     ;Pointer to Library-List
  lea     bsdsocket_name(pc),a1 ;Name of Bsdsocket-Library
  CALLEXEC FindName
  tst.l   d0
  beq.s   no_tcp_stack_found ;If Null -> branch
  move.l  d0,a0
  tst.w   LIB_OPENCNT(a0)
  beq.s   no_tcp_stack_found ;If bsdsocket.library not open -> branch
tcp_stack_found
  CALLEXEC Permit            ;Multitasking on

A third button "Ignore" in the requester would be no problem to include. A good idea.

[DrCinicus]

Originally Posted by dissident

Please start your TCP/IP app before you start my enclosed intro from your WB by its WB-icon.

On A 1200 with 3.9 and Genesis works correctly.

Bye
Fabio

[dissident]

Originally Posted by DrCinicus

On A 1200 with 3.9 and Genesis works correctly.

Bye
Fabio

Thanks for testing and your feedback, DrCinicus.

[dissident]

Originally Posted by dissident

Hi,
I've got a problem that perhaps the program MiamiDX causes using a TCP/IP stack and generating spurious interrpts, maybe the PORT-int. See also http://eab.abime.net/showthread.php?p=675900&styleid=4

My demo takes over the machine and uses INT6 & TNT2 generated by the CIA-timers for the tracker-replay-routine. If the CIAs are not the source of the inerrupts, then the INT2/6 is acknowledged and the routine returns by a NOP + a RTE.

I guess the only way to handle this, is to close MiamiDX and starting my demo after that. Otherwise my demo freezes but the music keeps playing.It seems that the CPU doesn't reach a user mode any more to execute my effects.

An extract from here: http://www.whdload.de/docs/en/bugs.html

There is a general problem with all extra hardware connected to the Amiga which generates Interrupts at random or regular times. An example is my network card (Hydra). If I have my TCP/IP stack running, nearly every installed program will freeze after a short time because the card creates PORTS interrupts (the same type as interrupts created by the keyboard) which cannot correctly replied to by the installed program.

Now I found a solution for this problem without aborting the running TCP/IP stack. I can confirm that only the PORTS interrupt (level-2-interrupt) is affected. If you take over the machine, just disable the PORTS interrupt and don't use it. Only use the CIA-B-timers which generate a level-6-interrupt for your tracker-replay-routine. "The Player" routine works this way and there are no problems of frozen routines any more.

The problem remains, if you turn off the OS, use your own keyboard handler and enable the PORTS interrupt for using the CIA-A interrupts SP and TA. Alternatively you could wait for the CIA-A interrupts in a loop directly and query them this way to avoid enabling the PORTS interrupt.

[patrik]

Originally Posted by dissident

I included mark_k's test-routine in a little AGA-intro. Now I need some testers who can test it in conjunction with different common TCP/IP apps namely:

-AmiTCP
-MiamiDX
-Genesis
-IIRC
-Roadshow

on an AGA machine.

What should you do?

Please start your TCP/IP app before you start my enclosed intro from your WB by its WB-icon.

What should happen?

The intro should detect the existing used bsdsocket.library and open a requester to inform you that a TCP/IP app is running. Now you have the choice. Exit the intro by selecting the gadget "Forget it!" or pressing the gadget "Resume".
If your TCP/IP app is still open, then the requester should appear again. Close your app and try the gadget "Resume" again. Now the intro should start and show a morphing glenz vector with some music playing. The module controls the morphing of the object.
The replay routine uses INT2&6, the main routine runs in user mode and waits for the VBI in a loop. The morphing is triggered by the Module (with a special $800 command) generating a SOFTINT-interrupt which is checked and replied in the main routine.

My test on real hardware (A1200/030 + Miami) was successful.

Thanks for testing and your feedback.

Couldn't test this on my A3000, it opens a new window saying:

No AGA-PAL-machine !

Press any key.

[dissident]

Originally Posted by patrik

Couldn't test this on my A3000, it opens a new window saying:

No AGA-PAL-machine !
Press any key.

Hi patrik, that's the way how this test-prg, written for AGA machines, behaves on a non-AGA machine:

I included mark_k's test-routine in a little AGA-intro. Now I need some testers who can test it in conjunction with different common TCP/IP apps namely:

-AmiTCP
-MiamiDX
-Genesis
-IIRC
-Roadshow

on an AGA machine.

So on your A3000 with ECS you'll get the error message you mentioned above.

[patrik]

Originally Posted by dissident

Hi patrik, that's the way how this test-prg, written for AGA machines, behaves on a non-AGA machine:

So on your A3000 with ECS you'll get the error message you mentioned above.

Wouldn't you get more feedback on this TCP/IP-stack detection method without the chipset limitation? Does the chipset affect the detection in any way?

[patrik]

If you find that bsdsocket.library is active, would it be possible to whitelist some UAE bsdsocket.library implementations by querying the name with the SocketBaseTagList() tag SBTC_RELEASESTRPTR?

Did a test program for it (yes, poor name):
http://megaburken.net/~patrik/StackName.lha

#include <exec/exec.h>
#include <dos/dos.h>
#include <dos/dosextens.h>

#include <proto/exec.h>
#include <proto/dos.h>
#include <proto/socket.h>

struct ExecBase *SysBase;
struct DosLibrary *DOSBase = NULL;
struct Library *SocketBase = NULL;

const char *GetReleaseStr(void);

int main(void) {
    SysBase = *(struct ExecBase **) 4;
    DOSBase = (struct DosLibrary *) OpenLibrary("dos.library", 36);
    if(NULL == DOSBase) {
        return RETURN_FAIL;
    }

    int retval = RETURN_ERROR;

    SocketBase = OpenLibrary("bsdsocket.library", 3);
    if(NULL != SocketBase) {
        const char *releaseStr = GetReleaseStr();
        if(NULL != releaseStr) {
            retval = RETURN_OK;
            Printf("%s\n", releaseStr);
        }
        else {
            PutStr("Failed getting bsdsocket.library release string!\n");
        }
    }
    else {
        PutStr("Failed opening bsdsocket.library v3!\n");
    }

    CloseLibrary(SocketBase);
    CloseLibrary((struct Library *) DOSBase);

    return retval;
}

const char *GetReleaseStr() {
    struct TagItem tags[] = {
        { .ti_Tag = SBTM_GETVAL(SBTC_RELEASESTRPTR), .ti_Data = 0 },
        { .ti_Tag = TAG_END }};

    if(0 == SocketBaseTagList(tags)) {
        const char *releaseStr = (const char *) tags[0].ti_Data;
        return releaseStr;
    }
    return NULL;
}

I have no WinUAE to test with right now, but results with the most common TCP/IP-stacks:

Roadshow:

> StackName 
Roadshow 4.332 (29.4.2017)

AmiTCP 4.3:

> StackName 
AmiTCP/IP Pro 68020 4.3 (26.03.96)

AmiTCP 3.0b2 (seems AmiTCP v3 lacks this feature even if the SocketBaseTagList() function is present here):

> StackName 
Failed getting bsdsocket.library release string!

Miami 3.2b:

> StackName 
Miami 3.2b (09.11.98)

[dissident]

Originally Posted by patrik

Wouldn't you get more feedback on this TCP/IP-stack detection method without the chipset limitation? Does the chipset affect the detection in any way?

You may be right, but my target is an AGA machine with a 68020+. All my routines are based on this. That's why I've chosen this example which needs the AGA chipset just to have a test in conjunction with a small intro environment. As far as I know, most common Amigas with a 68030+ CPU are not OCS/ECS machines. The A3000 is of course an exception.

The AGA chipset does not affect the detection in any way and is not necessary for it (see my sourcecode in post 14 October 2017, 20:18)