Menu
▾
▴
linux-atm-general
|
From: mahendra v. <mah...@gm...> - 2010-08-05 09:08:30
|
Hi In the ATM driver during reception, I have a doubt in finding the length of the received bytes. 1. If the user send me 40 bytes of data, below is the dump of the buffer with trailer size: 56 getrsmbuffer = cf888000 ------------------------------------------------------------------------------------------------------------- 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length indicator. 2. If the user send me 80 bytes of data, below is the dump of the LAST buffer with trailer size: 56 getrsmbuffer = cf878048 --------------------------------------------------------------------------------------------------------------------------- 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data 0x69 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length indicator But, In realtime I do not know how many bytes the user will send to me. The padding bytes and the trailer area in the last buffer differs depending on the number of received bytes. I need to get the length indicator field through some logic irrespective of the number of received bytes. Can you please help me on the above ? Mahendra |
|
From: MIke W. <we...@cs...> - 2010-08-05 14:40:15
|
I'm not 100% sure what you are asking here. Some NICs (that do SAR) have registers that the driver can read to determine application payload length. At minimum you MUST be able (somehow) to know how many cell's comprise the AAL5 PDU. But once you can do that the rest is trivial.. The CS trailer is always "right" justified in the LAST cell of the PDU. In your second example, 80 byte payload requires two cells. Two cells have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, CPI at 89 and len at offset 90. Stated another way the 2 byte length field will always be located 6 bytes before the end of the last 48 byte cell. mahendra varman wrote: > Hi > In the ATM driver during reception, I have a doubt in finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the dump of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length indicator. > > > 2. If the user send me 80 bytes of data, below is the dump of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length indicator > > But, In realtime I do not know how many bytes the user will send to me. > The padding bytes and the trailer area in the last buffer differs > depending on the number of received bytes. I need to get the length > indicator field through some logic irrespective of the number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > |
|
From: Ashish <wri...@gm...> - 2010-08-05 14:36:20
|
And if that kind of register is not there then system should have max possible length of buffer (perhaps mtu sized) and then as we get cells we put there and when we received last cell of all5 (based on PTI field) we remove the padding and send only user data to upper layer. --Ashish On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...> wrote: > I'm not 100% sure what you are asking here. Some NICs (that do SAR) > have registers that the driver can read to determine application payload > length. At minimum you MUST be able (somehow) to know how many > cell's comprise the AAL5 PDU. But once you can do that the rest is > trivial.. The CS trailer is always "right" justified in the LAST cell of > the > PDU. > In your second example, 80 byte payload requires two cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > >> Hi >> In the ATM driver during reception, I have a doubt in finding the >> length of the received bytes. >> >> 1. If the user send me 40 bytes of data, below is the dump of the >> buffer with trailer >> >> size: 56 getrsmbuffer = cf888000 >> >> ------------------------------------------------------------------------------------------------------------- >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >> 0x21 >> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >> >> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >> indicator. >> >> >> 2. If the user send me 80 bytes of data, below is the dump of the LAST >> buffer with trailer >> >> size: 56 getrsmbuffer = cf878048 >> >> --------------------------------------------------------------------------------------------------------------------------- >> >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >> 0x69 >> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >> >> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after data >> 0x69 >> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >> indicator >> >> But, In realtime I do not know how many bytes the user will send to me. >> The padding bytes and the trailer area in the last buffer differs >> depending on the number of received bytes. I need to get the length >> indicator field through some logic irrespective of the number of >> received bytes. >> >> Can you please help me on the above ? >> >> Mahendra >> >> >> ------------------------------------------------------------------------------ >> The Palm PDK Hot Apps Program offers developers who use the >> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >> of $1 Million in cash or HP Products. Visit us here for more details: >> http://p.sf.net/sfu/dev2dev-palm >> _______________________________________________ >> Linux-atm-general mailing list >> Lin...@li... >> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >> >> >> >> > |
|
From: mahendra v. <mah...@gm...> - 2010-08-05 14:44:13
|
I could able to receive all the cells upto last cell. I do not have a register in the ATM controller indicating the length count of the received bytes ( the datasheet claims the length count is done internally and updated in the last cell) I need to remove padding and send only user data to upper layer. I have only the last cell buffer address and entire content of the last cell including padding and trailer. My doubt is Since I do not have the length indicator through some register how to find the trailer in the entire content of the last cell ? On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...> wrote: > And if that kind of register is not there then system should have max > possible length of buffer (perhaps mtu sized) and then as we get cells we > put there and when we received last cell of all5 (based on PTI field) we > remove the padding and send only user data to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: > >> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >> have registers that the driver can read to determine application payload >> length. At minimum you MUST be able (somehow) to know how many >> cell's comprise the AAL5 PDU. But once you can do that the rest is >> trivial.. The CS trailer is always "right" justified in the LAST cell of >> the >> PDU. >> In your second example, 80 byte payload requires two cells. Two cells >> have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, >> CPI at 89 and len at offset 90. >> Stated another way the 2 byte length field will always be located 6 bytes >> before the end of the last 48 byte cell. >> mahendra varman wrote: >> >>> Hi >>> In the ATM driver during reception, I have a doubt in finding the >>> length of the received bytes. >>> >>> 1. If the user send me 40 bytes of data, below is the dump of the >>> buffer with trailer >>> >>> size: 56 getrsmbuffer = cf888000 >>> >>> ------------------------------------------------------------------------------------------------------------- >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>> 0x21 >>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>> >>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>> indicator. >>> >>> >>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>> buffer with trailer >>> >>> size: 56 getrsmbuffer = cf878048 >>> >>> --------------------------------------------------------------------------------------------------------------------------- >>> >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>> 0x69 0x69 >>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>> >>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>> data 0x69 >>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>> indicator >>> >>> But, In realtime I do not know how many bytes the user will send to me. >>> The padding bytes and the trailer area in the last buffer differs >>> depending on the number of received bytes. I need to get the length >>> indicator field through some logic irrespective of the number of >>> received bytes. >>> >>> Can you please help me on the above ? >>> >>> Mahendra >>> >>> >>> ------------------------------------------------------------------------------ >>> The Palm PDK Hot Apps Program offers developers who use the >>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>> of $1 Million in cash or HP Products. Visit us here for more details: >>> http://p.sf.net/sfu/dev2dev-palm >>> _______________________________________________ >>> Linux-atm-general mailing list >>> Lin...@li... >>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>> >>> >>> >>> >> > |
|
From: Ashish <wri...@gm...> - 2010-08-05 18:05:44
|
Mahendra, westall, has given very good example to track length field in aal5 trailer. "In your second example, 80 byte payload requires two cells. Two cells have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, CPI at 89 and len at offset 90. " you can check structure of aal5 trailer on net. other thing is trailer would be last 8 bytes in last cell. so last cell contains = remaining user bytes + padding + 8B aal5 trailer. --Ashish On Thu, Aug 5, 2010 at 8:14 PM, mahendra varman <mah...@gm...>wrote: > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length count > of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the last > cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some register > how to find the trailer in the entire content of the last cell ? > > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...>wrote: > >> And if that kind of register is not there then system should have max >> possible length of buffer (perhaps mtu sized) and then as we get cells we >> put there and when we received last cell of all5 (based on PTI field) we >> remove the padding and send only user data to upper layer. >> >> --Ashish >> >> >> On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: >> >>> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >>> have registers that the driver can read to determine application payload >>> length. At minimum you MUST be able (somehow) to know how many >>> cell's comprise the AAL5 PDU. But once you can do that the rest is >>> trivial.. The CS trailer is always "right" justified in the LAST cell of >>> the >>> PDU. >>> In your second example, 80 byte payload requires two cells. Two cells >>> have payload capacity 96. Thus CRC is at offset 92 with UU at offset >>> 88, >>> CPI at 89 and len at offset 90. >>> Stated another way the 2 byte length field will always be located 6 bytes >>> before the end of the last 48 byte cell. >>> mahendra varman wrote: >>> >>>> Hi >>>> In the ATM driver during reception, I have a doubt in finding the >>>> length of the received bytes. >>>> >>>> 1. If the user send me 40 bytes of data, below is the dump of the >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf888000 >>>> >>>> ------------------------------------------------------------------------------------------------------------- >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>>> 0x21 >>>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>>> >>>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>>> indicator. >>>> >>>> >>>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf878048 >>>> >>>> --------------------------------------------------------------------------------------------------------------------------- >>>> >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>>> >>>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>>> data 0x69 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>>> indicator >>>> >>>> But, In realtime I do not know how many bytes the user will send to me. >>>> The padding bytes and the trailer area in the last buffer differs >>>> depending on the number of received bytes. I need to get the length >>>> indicator field through some logic irrespective of the number of >>>> received bytes. >>>> >>>> Can you please help me on the above ? >>>> >>>> Mahendra >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Palm PDK Hot Apps Program offers developers who use the >>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>>> of $1 Million in cash or HP Products. Visit us here for more details: >>>> http://p.sf.net/sfu/dev2dev-palm >>>> _______________________________________________ >>>> Linux-atm-general mailing list >>>> Lin...@li... >>>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>>> >>>> >>>> >>>> >>> >> > |
|
From: MIke W. <we...@cs...> - 2010-08-05 21:45:13
|
Mahendra, While what Ashish and I have said is generally true. There are some special cases that must be accounted for. If a user wants to transmit 92 byte APDU the APDU will fit in two cells but the CS trailer will not. In that case a third cell will be required and the CS trailer will be (as usual) at offset 88 in the third cell and there will be 4 bytes pad in the second cell and 88 bytes pad in the third cell. IN THESE CASES THERE WILL BE NO USER DATA AT ALL IN THE LAST CELL and there may or may not (APDU is multiple of 48 in length) be padding in next to last cell. It takes a only little bit of special case code to handle this situation correctly, but you need to not overlook it. Mike Ashish wrote: > Mahendra, > westall, has given very good example to track length field in aal5 > trailer. > > "In your second example, 80 byte payload requires two cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU at offset 88, > CPI at 89 and len at offset 90. " > > you can check structure of aal5 trailer on net. > other thing is trailer would be last 8 bytes in last cell. so last > cell contains = remaining user bytes + padding + 8B aal5 trailer. > > --Ashish > > On Thu, Aug 5, 2010 at 8:14 PM, mahendra varman > <mah...@gm... <mailto:mah...@gm...>> wrote: > > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the > length count of the received > bytes ( the datasheet claims the length count is done internally > and updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the > last cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some > register how to find the trailer in the entire content of the last > cell ? > > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish > <wri...@gm... > <mailto:wri...@gm...>> wrote: > > And if that kind of register is not there then system should > have max possible length of buffer (perhaps mtu sized) and > then as we get cells we put there and when we received last > cell of all5 (based on PTI field) we remove the padding and > send only user data to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall > <we...@cs... <mailto:we...@cs...>> wrote: > > I'm not 100% sure what you are asking here. Some NICs > (that do SAR) > have registers that the driver can read to determine > application payload > length. At minimum you MUST be able (somehow) to know > how many > cell's comprise the AAL5 PDU. But once you can do that > the rest is > trivial.. The CS trailer is always "right" justified in > the LAST cell of the > PDU. > In your second example, 80 byte payload requires two > cells. Two cells > have payload capacity 96. Thus CRC is at offset 92 with > UU at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be > located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > > Hi > In the ATM driver during reception, I have a doubt in > finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the > dump of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 > 0x28 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with > 0x28 as length indicator. > > > 2. If the user send me 80 bytes of data, below is the > dump of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 > 0x1e 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding > data(8 bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with > 0x50 as length indicator > > But, In realtime I do not know how many bytes the user > will send to me. > The padding bytes and the trailer area in the last > buffer differs > depending on the number of received bytes. I need to > get the length > indicator field through some logic irrespective of the > number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who > use the > Plug-In Development Kit to bring their C/C++ apps to > Palm for a share > of $1 Million in cash or HP Products. Visit us here > for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > > > > > |
|
From: MIke W. <we...@cs...> - 2010-08-05 15:03:34
|
The full 8 byte trailer is ALWAYS located at offset +40 from start of last cell. Hence length is always located at offset +42 from start of last cell (as it was in your examples). Mike mahendra varman wrote: > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length > count of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the > last cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some > register how to find the trailer in the entire content of the last cell ? > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm... > <mailto:wri...@gm...>> wrote: > > And if that kind of register is not there then system should have > max possible length of buffer (perhaps mtu sized) and then as we > get cells we put there and when we received last cell of all5 > (based on PTI field) we remove the padding and send only user data > to upper layer. > > --Ashish > > > On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall > <we...@cs... <mailto:we...@cs...>> wrote: > > I'm not 100% sure what you are asking here. Some NICs (that > do SAR) > have registers that the driver can read to determine > application payload > length. At minimum you MUST be able (somehow) to know how many > cell's comprise the AAL5 PDU. But once you can do that the > rest is > trivial.. The CS trailer is always "right" justified in the > LAST cell of the > PDU. > In your second example, 80 byte payload requires two cells. > Two cells > have payload capacity 96. Thus CRC is at offset 92 with UU > at offset 88, > CPI at 89 and len at offset 90. > Stated another way the 2 byte length field will always be > located 6 bytes > before the end of the last 48 byte cell. > mahendra varman wrote: > > Hi > In the ATM driver during reception, I have a doubt in > finding the > length of the received bytes. > > 1. If the user send me 40 bytes of data, below is the dump > of the > buffer with trailer > > size: 56 getrsmbuffer = cf888000 > ------------------------------------------------------------------------------------------------------------- > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 > 0xdf 0xe9 0x8c 0x21 > 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f > > 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 > as length indicator. > > > 2. If the user send me 80 bytes of data, below is the dump > of the LAST > buffer with trailer > > size: 56 getrsmbuffer = cf878048 > --------------------------------------------------------------------------------------------------------------------------- > > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 > 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e > 0xd8 0xd2 0xeb > 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 > > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 > bytes) after data 0x69 > 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 > as length indicator > > But, In realtime I do not know how many bytes the user > will send to me. > The padding bytes and the trailer area in the last buffer > differs > depending on the number of received bytes. I need to get > the length > indicator field through some logic irrespective of the > number of > received bytes. > > Can you please help me on the above ? > > Mahendra > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm > for a share > of $1 Million in cash or HP Products. Visit us here for > more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > <mailto:Lin...@li...> > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > ------------------------------------------------------------------------ > > _______________________________________________ > Linux-atm-general mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-atm-general > |
|
From: mahendra v. <mah...@gm...> - 2010-08-05 15:13:57
|
Hi Mlke Thanks for your Information. My doubt is cleared and I understood the concept Thanks a Lot Mahendra On Thu, Aug 5, 2010 at 8:33 PM, MIke Westall <we...@cs...> wrote: > The full 8 byte trailer is ALWAYS located at offset +40 from start of last > cell. Hence > length is always located at offset +42 from start of last cell (as it was > in your examples). > Mike > > > mahendra varman wrote: > > > I could able to receive all the cells upto last cell. > I do not have a register in the ATM controller indicating the length count > of the received > bytes ( the datasheet claims the length count is done internally and > updated in the last cell) > > I need to remove padding and send only user data to upper layer. > > I have only the last cell buffer address and entire content of the last > cell including padding > and trailer. > > My doubt is Since I do not have the length indicator through some register > how to find the trailer in the entire content of the last cell ? > > > > > > On Thu, Aug 5, 2010 at 8:06 PM, Ashish <wri...@gm...>wrote: > >> And if that kind of register is not there then system should have max >> possible length of buffer (perhaps mtu sized) and then as we get cells we >> put there and when we received last cell of all5 (based on PTI field) we >> remove the padding and send only user data to upper layer. >> >> --Ashish >> >> >> On Thu, Aug 5, 2010 at 7:51 PM, MIke Westall <we...@cs...>wrote: >> >>> I'm not 100% sure what you are asking here. Some NICs (that do SAR) >>> have registers that the driver can read to determine application payload >>> length. At minimum you MUST be able (somehow) to know how many >>> cell's comprise the AAL5 PDU. But once you can do that the rest is >>> trivial.. The CS trailer is always "right" justified in the LAST cell of >>> the >>> PDU. >>> In your second example, 80 byte payload requires two cells. Two cells >>> have payload capacity 96. Thus CRC is at offset 92 with UU at offset >>> 88, >>> CPI at 89 and len at offset 90. >>> Stated another way the 2 byte length field will always be located 6 bytes >>> before the end of the last 48 byte cell. >>> mahendra varman wrote: >>> >>>> Hi >>>> In the ATM driver during reception, I have a doubt in finding the >>>> length of the received bytes. >>>> >>>> 1. If the user send me 40 bytes of data, below is the dump of the >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf888000 >>>> >>>> ------------------------------------------------------------------------------------------------------------- >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c >>>> 0x21 >>>> 0xae 0x7b 0x62 0x16 0xce 0xf5 0xf1 0x2f >>>> >>>> 0x0 0x0 0x0 0x28 0xdf 0xe9 0x8c 0x21 = trailer with 0x28 as length >>>> indicator. >>>> >>>> >>>> 2. If the user send me 80 bytes of data, below is the dump of the LAST >>>> buffer with trailer >>>> >>>> size: 56 getrsmbuffer = cf878048 >>>> >>>> --------------------------------------------------------------------------------------------------------------------------- >>>> >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 >>>> 0x69 0x69 >>>> 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x69 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 0x0 0x0 0x0 0x0 0x1e 0xd8 0xd2 0xeb >>>> 0xff 0xff 0xff 0xff 0x0 0x0 0x0 0x0 >>>> >>>> 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 = padding data(8 bytes) after >>>> data 0x69 >>>> 0x0 0x0 0x0 0x50 0xdc 0x9e 0xca 0xa4 = trailer with 0x50 as length >>>> indicator >>>> >>>> But, In realtime I do not know how many bytes the user will send to me. >>>> The padding bytes and the trailer area in the last buffer differs >>>> depending on the number of received bytes. I need to get the length >>>> indicator field through some logic irrespective of the number of >>>> received bytes. >>>> >>>> Can you please help me on the above ? >>>> >>>> Mahendra >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> The Palm PDK Hot Apps Program offers developers who use the >>>> Plug-In Development Kit to bring their C/C++ apps to Palm for a share >>>> of $1 Million in cash or HP Products. Visit us here for more details: >>>> http://p.sf.net/sfu/dev2dev-palm >>>> _______________________________________________ >>>> Linux-atm-general mailing list >>>> Lin...@li... >>>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general >>>> >>>> >>>> >>>> >>> >> > ------------------------------ > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details:http://p.sf.net/sfu/dev2dev-palm > > ------------------------------ > > _______________________________________________ > Linux-atm-general mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/linux-atm-general > > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X