AAL0 problem

[Alfonso Gonzalez <96132587@brookes.ac.uk>]

Hi Uwe

Thank you for the answer. Hope you had nice holidays.

I have been trying to fix the bug these days. The problem is that I
don't know which functions are calling each other. I would appreciate if
you could send me any detailed documentation.

I have tested the same things:

1. Normal operation.

pca200e_activatevcin is called with aal = 13 and the driver returns
stat_error, making the program return the error: bind: device or
resource busy 


2. Change atm.h definitions (ATM_AAL0 = 0 and ATM_NOAAL = 10)

The application works, and the atm_connect function (in
linux/net/atm/common.c) displays AAL0 in the console. However, in some
place the AAL0 is converted to AAL5, and this is the AAL used for the
actual transmission.


3. Hack the driver and change the value of aal in the
pca200e_activatevcin function from 5 to 0. (For this I use an if
statement that changes the value when the vci corresponds to my
application)

The transmitting application seems to work, but the receiving
application blocks and the aal0 statistics remain full of zeros.

I printed the aal being used when the pca200e_inttx function was called,
and again the aal5 was being used there.


4. So I decided to hack that function too. I change the value of the aal
from 5 to 0, when the vci match the one used in my application. 

The transmitting program seems to work, buy in a couple of seconds a lot
of error messages start comming up. Also, the pcadump tool displays
corrupted values in its statistics.

I hope this information will be of any help for you. I have to hand my
dissertation in two weeks, and I am getting a little bit nervous. It
would be great if you could fix the bug before that, or just give me
some  information to solve it myself.


Thank you and bye...



-- 

--------------- 
Alfonso Gonzalez 
Msc. High Speed Networks & Distributed Systems
Oxford Brookes University

Uwe Dannowski wrote:
> 
> Hi Alfonso
> 
> sorry for the delay - now I'm back from my holidays.
> 
> > After sending the mail this morning I tried to find out what AAL my
> > application was using. I send 10000 cells and run pcadump, which showed
> > an 10000 increment in the AAL5 sar tx statistics. Conclusion, even if I
> > open the socket with a 0 in the AAL field, the application still uses
> > AAL5.
> ATM_NO_AAL is an hidden alias for AAL5 as this is the default for data
> transfers. Look in
>         <whereyourlinuxsourcetreelives>/net/atm/common.c near line 253.
> 
> > I have been tracing the error EBUSI and the farest I get is that the
> > driver calls the function pca200e_activatevcin (see pca200e.c), then
> > this writes the commands to the card and then reads the operation
> > status. This status is logical or between error and complete (stat_error
> > | stat_complete) and causes the function to return 0, which in turns
> > makes open to return EBUSY.
> stat_complete is expected.
> stat_error shows a problem in opening the given VCI/AAL combination.
> That can be caused by trying to open the same VCI twice, too.
> You have to close that VCI before.
> If I remember right you can't open the same VCI with two different AALs.
> 
> From: "[Solved] Re: setsockopt(SO_ATMQOS):Invalid argument" - 02.09.97 02:11
> > Unfortunately now I get a nastier one. When I try to bind the socket,
> > always the same unmerciful message appear:
> >
> > atm_connect (TX:cl 1, bw 0-0, sdu 52; RX: cl 1, bw 0-0, sdu 52, AAL13)
> > bind: device or resource busy
> This call must go wrong - AAL13 is not known to the PCA-200E.
> That comes from the assumption that the vcc->aal member carries the AAL number.
> But vcc->aal carries the values defined in atm.h:
> 
>         #define ATM_AAL0        13              /* "raw" ATM cells */
>         #define ATM_AAL1        1               /* AAL1 (CBR) */
>         #define ATM_AAL2        2               /* AAL2 (VBR) */
>         #define ATM_AAL34       3               /* AAL3/4 (data) */
>         #define ATM_AAL5        5               /* AAL5 (data) */
> 
> I expected to get 5 for AAL5, 4 for AAL4 and 0 for AAL0.
> Thank you for pointing out this bug.
> A dirty fix could be to redefine the values for ATM_AALx ... but this won't
> work if some other code uses numbers instead of the defines. Try it :)
> I'll fix that as soon as possible.
> 
> Uwe
> 
> -------------------------------------------------------------------------------
> Uwe Dannowski, student, Dresden University of Technology, Dept. of CS, OS group
> email: Uwe_Dannowski@inf.tu-dresden.de  WWW: http://www.inf.tu-dresden.de/~ud3/
> tel: +49-351-2848091/+49-172-3736772 addr: Gamigstr. 20, 01239 Dresden, Germany

-- 

--------------- 
Alfonso Gonzalez 
Msc. High Speed Networks & Distributed Systems
Oxford Brookes University