IrDa print server - howto?

16 views
Skip to first unread message

Automatix

unread,
Jun 20, 2005, 1:31:10 PM6/20/05
to
Hi all,

i'd like to implement an IrDa print server,
receiving printing requests from mobile phones or
notebooks via IR and redirecting them to a local
port or file on the PC / PDA, with Winsock-API
(WIN32 and/or WinCE).
My problem is that i cannot find a way to set the
device info (resp. printer hint bit) via setsockopt(),
so that IR-connected devices will accept my server as a
printer device.
Is there e.g. an undocumented OptionName for
WSHSetSocketInformation() to set the hint bits for the
local device? Or is it a general limitation of
current irda.sys / wshirda.dll that device hint bits
are always hard coded, so the only way is a complete
replacement of the irda protocol stack?

Thanks for replies,
Gilbert

Rhett Gong [MSFT]

unread,
Jun 21, 2005, 3:14:06 AM6/21/05
to
Hello Gilbert,
Based on my understanding of your problem, your scenario is similiar as
following:
Mobile phones/Notebooks <------- irDA ---> PC/PDA ----------->Print Device
You want to implement a printer server in PC/PDA and make PC/PDA viewed as
a print device from Mobile phones/Notebooks.

From GDI view, socket is just responsible for transportation, and there
should not have such optname existed to set a print hint and make the
PC/PDA viewed as a printer device. But if you have implemented printer
driver/application in Mobile phones/Notebooks side, you can set custom
print hint and resolve them by yourself when received.

IMO, If you don't use windows printer service, then you need to define a
simple transport protocol, implement both client and server application,
resolve information you defined and make client app/driver present PC/PDA
as a print device. In this way, you can use the existing irda dlls instead
of replacing them completely .

If you have more ideas, please feel free to discuss with me.

Thanks,
Rhett Gong [MSFT]
Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties and confers no rights.

Automatix

unread,
Jun 21, 2005, 3:57:10 AM6/21/05
to
Hi Rhett,

i'm sorry, but that's not exactly what i asked for.
It wouldn't help me to implement a proprietary client/
server pair with it's own protocol. The print server
should by aware of printing requests from existing
3rd party devices (mobile phones, notebooks, PDA's)
usually via IrLPT (3wire raw) or whatever the device
requests.
My problem is, that printer client apps usually
request the IrDA device list and look for the device
hint bit "LM_HB1_Printer" set, I guess.
If I write a server app that is listening to an
IrDA socket, a device that requests for printing
doesn't connect to while the hint bit isn't set;
no matter what IrCOMM service type or LSapSel is set
in the IAS entry (3wire raw, 3wire, 9wire, Centronics).
On the other hand, the same device will print via IrDA
e.g. with a HP Laserjet 2200 whithout any problem.
Do You think You can help me in this case?

Thanks,
Gilbert

Rhett Gong [MSFT] schrieb:

Alan J. McFarlane

unread,
Jun 21, 2005, 1:48:07 PM6/21/05
to
I suggest we restrict any follow-ups to
microsoft.public.win32.programmer.networks, where this is most on-topic.

In article news:uaLYa3bd...@TK2MSFTNGP15.phx.gbl, Automatix wrote:
[...]


> My problem is that i cannot find a way to set the
> device info (resp. printer hint bit) via setsockopt(),
> so that IR-connected devices will accept my server as a
> printer device.
>

I know of no way to set hint bits on Windows, it's been discussed here
before and no other answer appeared. :-( See
http://groups.google.co.uk/group/microsoft.public.win32.programmer.networks/browse_frm/thread/d195bf0ca910c1a1/6648f32db961ac09?q=irlpt.server&rnum=1&hl=en#6648f32db961ac09
and also Section 4.10.3 of
http://www.alanjmcf.me.uk/comms/infrared/Microsoft%20Windows%20IrDA%20programming.html

I'd love to hear otherwise of course.


> Is there e.g. an undocumented OptionName for
> WSHSetSocketInformation() to set the hint bits for the
> local device? Or is it a general limitation of
> current irda.sys / wshirda.dll that device hint bits
> are always hard coded, so the only way is a complete

It does appear to be hard-coded. I suppose one could try and alter the
binary, perhaps it's stored as a constant somewhere. How that plays
with system file protection etc though...

> replacement of the irda protocol stack?
>

It appears that the port of the Linux stack to Windows has indeed been
used for this purpose, see the last sentence of page 14 in this
presentation, http://www.ukuug.org/events/linux2003/papers/Kiska.pdf
--
Alan J. McFarlane
http://www.alanjmcf.me.uk/
Please follow-up in the newsgroup for the benefit of all.

Rhett Gong [MSFT]

unread,
Jun 22, 2005, 3:49:01 AM6/22/05
to
Thanks for your reply and I must say sorry that I misunderstood your
question before.

Based on your posts, you would like to find a way to set
_IRDA_DEVICE_INFO.irdaDeviceHints1 to LM_HB1_Printer so that the PC/PDA can
be recognized as a IrDA print device, right?

Currently I am still investigating on this problem, and if there is
anything out, I will update you here at the first time.

Thanks for your patience,

Automatix

unread,
Jun 22, 2005, 4:47:36 AM6/22/05
to
Hello Rhett,

thank You for your reply! I will wait for Your
further suggestions in this problem.

Kind regards,
Gilbert

Rhett Gong [MSFT] schrieb:

Rhett Gong [MSFT]

unread,
Jun 27, 2005, 4:38:36 AM6/27/05
to
Hi Gilbert,
This problem is a bit complex, I post to let you know I am still working on
it. Thanks very much for your patience,

Best regards,

Yan-Hong Huang[MSFT]

unread,
Jun 27, 2005, 10:58:16 PM6/27/05
to
Hi Gilbert,

Thanks very much for your patience. This issue is complicated. Currently we
are pinging our network support team to check for their idea on it. We will
return here as soon as possible. If you have any concern on it, please feel
free to post here.

Thanks again and have a good day.

Best regards,
Yanhong Huang
Microsoft Community Support

Get Secure! ¨C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
-http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.as
p&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Arkady Frenkel

unread,
Jun 28, 2005, 2:40:52 AM6/28/05
to
JFYI AFAIK there's no socket connection in IrDa in PC opposite to WinCE
Arkady

"Automatix" <auto...@newsgroup.nospam> wrote in message
news:%23x7vBlv...@TK2MSFTNGP10.phx.gbl...
> Hello Rhett,
>
> I'm still waiting with confidence.
>
> Greetings,


> Gilbert
>
> Rhett Gong [MSFT] schrieb:

Poonawala [MSFT]@discussions.microsoft.com Mazahir Poonawala [MSFT]

unread,
Jun 29, 2005, 2:48:05 PM6/29/05
to
Problem Description:
===============
I'd like to implement an IRDA print server, receiving printing requests from
mobile phones or notebooks via IRDA and redirecting them to a localport or
file on the PC / PDA, with Winsock-API (WIN32 and/or WinCE).
My problem is that I cannot find a way to set the device info (esp. printer
hint bit) via setsockopt, so that IR-connected devices will accept my server
as aprinter device.

Is there e.g. an undocumented OptionName for WSHSetSocketInformation() to
set the hint bits for the local device? Or is it a general limitation of
current irda.sys / wshirda.dll that device hint bits are always hard coded,

so the only way is a complete replacement of the IRDA protocol stack?

Answers:
=======
If the OS is some flavor of Win CE then the following answer will not apply.

If you are using Win 2000 and later OS then here is the answer:

Windows Desktop OS does not have an API to change the hint bits. Hints bits
are just that, hints, and don't really tell you if a service is available so
our recommended procedure is to query the IAS database for the service.

We do have an undocumented and unsupported way of setting the hint bits via
the registry.

HKLM\System\CurrentControlSet\Services\irda\pamameters\HINTCHARSET=x

where x is a DWORD with the low order byte equal to character set (0x00),
next byte is last hint byte.

This is the default:

#define IRLAP_DEFAULT_HINTCHARSET 0x842500 // computer, IrCOMM, Obex,
and telephony

So you will want to add HINTCHARSET=0x8C2500 for the printer.


Byte 1 Byte 2

Bit Function Bit Function

0 PnP Compatible 8 Telephony

1 PDA/Palmtop 9 File Server

2 Computer 10 rsvd

3 Printer 11 rsvd

4 Modem 12 rsvd

5 Fax 13 rsvd

6 LAN Access 14 rsvd

7 Extension 15 Extension


Please keep in mind that this registry key and the values are not supported
and may change from one OS to another or from one service pack to another.


thanks,
Mazahir Poonawala
Microsoft Developers Support

Automatix

unread,
Jul 1, 2005, 11:49:40 AM7/1/05
to
Hello Mazahir Poonawala,

thank you very much for your help! This hack seems to
work fine on win2000/XP, so I can go on with my work.
Since it doesn't work with winCE, I'm testing to use a
device with XP embedded instead.
I'll post in this thread if further problems would appear.

bye,
Gilbert

Mazahir Poonawala [MSFT] schrieb:

Mazahir Poonawala [MSFT]

unread,
Jul 1, 2005, 1:20:03 PM7/1/05
to
Hi Gilbert,
I am an IRDA and Winsock expert on Windows desktop OS. I do not know much
about Win CE. But I am sure there might be a similar workaround for Win CE
too. Do you know what version of Win CE you are using?

thanks,
Mazahir

Automatix

unread,
Jul 2, 2005, 11:32:43 AM7/2/05
to
Hi Mazahir,

after several hours of further testing im not really
satisfied, yet. I couldn't find a way to run my IrDA
server so that IrLPT clients will connect to.

I can connect with an mobile phone or my sample IrLPT
client program to a printer (HP Laserjet 2200) and
print out some text, but not to my server program.

When I query for devices with my sample client program,
I will get the printer device hint bit set. When I query
the IAS database, I will get IrLPT - LsapSel, but when I
connect, only error 10061 is returned. It's the same
on WinXP or Win2000.

If I switch server and client program to IrDA:IrCOMM,
everything works fine (connect, send , recv) - but that
won't help me because existing legacy client devices
(or even the Windows IR printer port) just use IrLPT...

My work looks something like this:

ServerSock = socket (AF_IRDA, SOCK_STREAM, 0);

...

// I tried this, neccessary or not - who knows?
// By the way, when I query the IAS database of the
// HP printer there is no entry - nor IrLPT nor IrDA:IrCOMM
// It does'n look like existing clients (like e.g. mobile phones)
// will matter about IAS database entries, they only look for
// the device hint bits I think...
memcpy(pIASSet->irdaClassName, "IrLPT", 6);
memcpy(pIASSet->irdaAttribName, "IrDA:IrLMP:LsapSel", 19);
pIASSet->irdaAttribType = IAS_ATTRIB_INT;
pIASSet->irdaAttribute.irdaAttribInt = 2;
// or better any number between 0x01 and 0x6f ??
if (setsockopt(ServerSock, SOL_IRLMP, IRLMP_IAS_SET, (const char *)
pIASSet, IASSetLen) == SOCKET_ERROR) {
// bad luck...
}

...

// I tried this, neccessary or not - who knows?
// Or is IRLMP_IRLPT_MODE only relevant for the client side
// and are there further "hidden" switches to activate
// IrLPT server mode???
int bSetIRLPT = 1;
if (setsockopt (ServerSock, SOL_IRLMP, IRLMP_IRLPT_MODE,
(LPCSTR)&bSetIRLPT, sizeof(bSetIRLPT) == SOCKET_ERROR) {
// bad luck...
}

...

// must be the right service name or not ?!
SOCKADDR_IRDA address = {AF_IRDA, 0, 0, 0, 0, "IrLPT"};
if (bind (ServerSock, (struct sockaddr *)&address, sizeof (address)) ==
SOCKET_ERROR) {
// bad luck...
}
everything else like IrCOMM or other network communication...

if (listen (ServerSock, SOMAXCONN) == SOCKET_ERROR) {
// bad luck...
}
...
do {
struct timeval timeout = {1, 0};
FD_ZERO(&ReadSet);
FD_SET(ServerSock, &ReadSet);
if ( WaitForSingleObject(EventHandleList[1],0) != WAIT_TIMEOUT) {
// user aborted by other thread...
break;
}
ret=select(0, &ReadSet, NULL, NULL, &timeout);
} while(ret==0);
if (ret != 1) {
// bad luck...
}
...
if ((ClientSock = accept (ServerSock, 0, 0)) == INVALID_SOCKET) {
// bad luck...
}
...
do {
dwBytesToRead = min(BlockSize, Size - Offset);
dwBytesRead = recv (ServerSock, lpBuffer, dwBytesToRead, 0);
...and so on...


// finally
closesocket(ServerSock);


But at least, how is the way to initialize the socket
interface of the server program to handle incoming
IrLPT requests?
Do you think you can help me in this problem to realize
an IrLPT print server for Win2000/XP(embedded).
Finally, if this really would work, a solution for
WinCE would be the freestyle challenge...

bye and thanks in advance,

Alan J. McFarlane

unread,
Jul 6, 2005, 12:53:46 PM7/6/05
to
In article news:eKx%23LtxfF...@TK2MSFTNGP12.phx.gbl, Automatix
wrote:

> Hi Mazahir,
>
> after several hours of further testing im not really
> satisfied, yet. I couldn't find a way to run my IrDA
> server so that IrLPT clients will connect to.
>
Gilbert

I've been looking at this over the weekend, and it seems that you have
found a bug... :-(

Initially when I looked at your code I thought that the manually setting
of the IAS entry was the problem--unfortunately many people creating
(client-side) programs feel the need to do manual IAS entry creation,
and generally badly! But on looking again and re-reading the text I
realised that this was probably not the problem.

So I initially created an IrLPT server of my own, and also an IrLPT
client (well I used my example at
<http://www.alanjmcf.me.uk/comms/infrared/irdaWinsockCliIrLpt.c.html>).
And the two wouldn't connect... So I guessed that there was something
wrong with the IAS entry, and thus then created a program to read
individual IAS entries. Using this I found *no*
IrLPT/IrDA:IrLMP:LsapSel entry, *but* did find a
IrLPT/IrDA:TinyTP:LsapSel entry, oops! So for this part at least, the
IRLMP_IRLPT_MODE setting is being ignored on the server side, and thus
TinyTP is being used.

Then I used the output of that program to manually connect to the
numerical LSAP Selector, using the form described in Section 4.6 of my
programming reference
<http://www.alanjmcf.me.uk/comms/infrared/Microsoft%20Windows%20IrDA%20programming.html>.
And the two then connected.

But was the server side program using TinyTP mode for the connection?
So, I had the client side some test data, it sent eleven bytes
"abcdefghij\n", and the server received ten bytes, "bcdefghij\n". So it
is clear that the server-side operation is using TinyTP; using the first
byte of every PDU as the TinyTP Credit byte. So it seems that the
IRLMP_IRLPT_MODE mode is being ignored on the server-side.

So there is a bug (if we were being very polite, we might call it a
missing feature) that needs to be fixed. I can't immediately see a
workaround either. If the problem was only the incorrect IAS entry,
then a workaround something /like/ you tried would have been possible.
But because the PDU format is TinyTP too, then you'd have to accept
losing one byte in each PDU... :-( I wonder whether a dummy connect()
can be made, to trick the stack into following IRLMP_IRLPT_MODE
setting...

By the way, I've also another bug to report to MSFT. The stack will use
(and dynamically allocate) LSAP-Sels of any value for 0x01 through to
0x7F! As we know, the LSAP-Sels above 0x6F are reserved. This is very
bad, and explains why after a number of hibernations etc that HotSync
Manager is unresponsive. :-( I have spoke to MSFT's first line support
on this, but they bounced my off to "Professional" support; I haven't
had time to do that yet.

I gues this was not what you wanted to hear here Mazahir. But what do
we do to progress these two issues?

Alan


--
Alan J. McFarlane
http://www.alanjmcf.me.uk/

Have I helped? Consider visiting my Amazon wishlist, see my homepage.

Automatix

unread,
Jul 6, 2005, 4:54:49 PM7/6/05
to
Hi Alan,

the second feature you described would have been
a possible reason for the impossibility of connections
by legacy devices, like mobile phones. But, in fact
the major bug seems to be that the IRLMP_IRLPT_MODE
option only works for the client side.
But at least I didn't lost the hope that there is
a further undocumented option to set the IrLPT mode
for the server side (think of the HINTCHARSET hack...
it's working!)
So please, Mazahir, can You ask the guy who programmed
that for such a backdoor?! I'm in the need of reporting
something about a silver lightning at the horizon...


Greetings to both of you,
Gilbert


Alan J. McFarlane schrieb:

Mazahir Poonawala [MSFT]

unread,
Jul 7, 2005, 2:27:03 PM7/7/05
to
Hi Gilbert,
Can you send me a simple Winsock client and server code that can repro the
problem that you are seeing? I need to investigate this in my lab here.
Please send me a simple repro code at the e-mail address:
maza...@microsoft.com

In the code you can have the client send a "hello world" message and have
the server receive this message.

thanks,
Mazahir

Automatix

unread,
Jul 8, 2005, 12:09:26 PM7/8/05
to
Hi Mazahir and Alan,

I only wanted to notify the community about the situation:
I sent sources for a testing tool to Mazahir.
You can call the test tool in a way that IRLMP_IRLPT_MODE is
set on either client and server side. If you try to connect
to "IrLPT" there is no success. But if you select a
numerical LSAP-SELxy port entry there is a connection, but
in a way that the server side loses the first byte of data
transmitted by the client side - as described by Alan, before!

okay, that's it for the moment,
thanks,
Gilbert

Mazahir Poonawala [MSFT] schrieb:

Mazahir Poonawala [MSFT]

unread,
Jul 26, 2005, 1:33:04 PM7/26/05
to
Hi Gilbert,
How are you doing? Sorry for the delay in the reply but I had to do some
extensive research and testing to get to the bottom of this. Here are my
findings.

You are using Winsock IRDA to do printing. The server has an IRDA Winsock
server listening with the service name IrLPT. The client tries to connect to
this service and fails with error 10061, WSAECONNREFUSED. Why is that
happening?

Answer: "IrLPT" is reserved for IRDA Printer physical device. The client
works well if the peer is IRDA printer device. However we don't support
implementing socket server code as printer device. This is by design and we
do not have any workaround for this.

If you change your service name in the server to LSAP-SEL12 and then the
client tries to connect to LSAP-SEL12, it is able to connect and send data.
In this connection, the first byte of the data sent is not available on the
receiver. Why is this happening? Is this because of the TinyTP protocol used?

Answer: For the server code, whether you use LSAP-SEL12 or service name, it
always use TinyTP. However for the client code, if IRLMP_IRLPT_MODE is set
for socket, it will bypass TinyTP. In a short word, IRLMP_IRLPT_MODE is
implemented as a socket client to connect to physical devices.

The following facts may be useful:

1) If the client doesn't set IRLMP_IRLPT_MODE, the server will receive the
correct data since both sides use TinyTP.

2) If the service name is "IrLPT" on the service code, the client can get
the value for IrDA:TinyTP:LsapSel by IRLMP_IAS_QUERY, then the client can
make a connection successfully to the server by using this LSAP-SELxxx

I hope this answers all your questions.

thanks,
Mazahir Poonawala

Automatix

unread,
Jul 27, 2005, 4:07:00 AM7/27/05
to
Hi Mazahir,

since your IrDA protocol implementation won't support
the print server feature to a virtual "IrLPT" device,
there is no alternative to a complete replacement of
irda.sys / wshirda.dll - as I proposed several weeks
before.
In fact, a reimplementation or a filter layer in the
driver is by far much more work compared to adding
some lines for in your driver codes.
At least, we can be sure that no implementation of
any Windows IrDA print server (compatible to existing
devices, like mobile phones etc.) exists - yet.
So, we know what to do in the next weeks...

Automatix

unread,
Jul 28, 2005, 9:06:00 AM7/28/05
to
Hi Mazahir,

for Windows 2000 an XP the IrCOMM2k - driver patch by
Jan Kiszka does a fine job:

http://www.ircomm2k.de/

An IrLPT server is includeded as source code example.
The complete driver sources are open source under GPL.
But, there is no WinCE port available and there is no
project maintainer for over one year...

Reply all
Reply to author
Forward
0 new messages