From: Alan J. McFarlane [alanjmcf@yahoo.com]
Sent: 08 July 2005 18:34
To: <mazahirp@...>
Subject: On the other IrDA issue...
Attachments: IrCli_multi example log.txt [fragment below]; IrCli_multi.cpp [IrCli_multi.exe)
Mazahir
As I noted in my newsgroup posting I bet this is exactly what you hope doesn't happen when you post help online: you get bugs reported to you in response. :-,(
Again as I noted there, I have another fault to report, in brief that the IrDA stack in Windows will use illegal LSAP Selectors (like TCP's Port Numbers), this is very bad news because all third-party devices that I have tested refuse to talk to such a port number.
This is likely a very simple issue to solve. When assigning a value, where the code does something like:
if ( curLsapSelToAssign > MAX_LEGAL_LSAP )
Then the value of MAX_LEGAL_LSAP must be 0x6F, instead of 0x7F. There may be two places that does this: one where a dynamically chosen value is being assigned (a Service Name was supplied to bind), and secondly where the program requested a particular numerical value (irdaServiceName is a string on the form "LSAP-SELx" (see section 4.8 and 4.6 in my reference at http://www.alanjmcf.me.uk/comms/infrared/Microsoft%20Windows%20IrDA%20programming.html)).
The IrLMP spec (irLMP11.PDF) says e.g. (Section 1.4, page 10:
“LSAP-SEL An acronym for LSAP selector. A selector that distinguishes between LSAPs within a Station. Legal values for an LSAP-SEL lie in the range 0x00-0x7F. With the exception of the special LSAP-SEL values 0x00 (LM-IAS), 0x70 (Connectionless Data service), 0x71-0x7E (reserved), and 0x7F (reserved for broadcast and currently not implemented), the assignment of LSAP-SEL values is arbitrary.”
Note from that, that 0x70, 0x71-0x7E, and 0x7F are reserved for other purposes, leaving 0x00 through 0x6F for IrLMP usage. From the same document (Section 3.2.2, page 21):
“All other Data LM-PDUs [...] that carry a normal connection address (DLSAP-SEL and SLSAP-SEL values in the range 0x00..0x6F inclusive) are routed [...]”.
It would seem best that when you are looking at the code for Gilbert's issue that you should look at this issue too. One round of testing required etc etc. And this issue is simple, localised, and will bring the code into spec.
I have taken the liberty of attaching my sample code that easily illustrates this issue. It is a simple client-side IrDA Winsock program that carries out a user supplied number of connects, and reports for each what local LSAP-SEL was used (using getsockname()). From its output it is easy to see that the LSAP-SEL wraps at 0x7F.
For an example, see the attached file “IrCli_multi example log.txt”. The initial LSAP-SEL value assigned by the stack was 0x2C (44), and after 63 further connects the value was 0x70 which is illegal, with the values continuing to be illegal until 0x7F was reached, where after low legal values were then assigned.
The code compiles simply with no command-line options required (it includes '#pragma comment ( lib, "ws2_32.lib" )'). All that is required is a Windows 2000/XP/etc PC with IrDA to run it on, and any other IrDA device, I did the example test against my Nokia mobile phone.
You can also see more information in the user-level support case that I previously opened on this, “SRZ050215002716 winxp: IrDA, lmp 0x7F, reserved port”. In particular my submission of “Mon 21/02/2005 13:32”.
Many thanks
Alan
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Tel: +44(cccc)nnnnnn