«

Hello

Sorry this might be a bit offtopic but I don't really know where else
to post this question. If you could point me in the right direction that
is much appreciated.

I'm running into a weird thing on Windows XP.

I'm using Python 2.5 with latest pywin32 from Mark Hammond.

I have this UDP socket server that binds on ('',9090) and is used
to be a broadcast responder. It works fine when I start the server
from the cmd prompt. UDP broadcast packets sent to ('<broadcast>',9090)
arrive in the server.

However now I'm running the same server as a Windows NT Service.
The same code is executed, the UDP server socket is bound to the
same address. But this time, the UDP broadcast packets do NOT arrive.... !?

When sending an UDP packet to the server's IP address directly,
it works. So the socket server is running.
Only thing is it doesn't seem to receive any broadcast packets.

Is this a known 'feature' of a windows NT service?
Doesn't windows allow a service to receive broadcast packets?


Again, sorry that I post this here it is probably more of a windows
question. But I don't know a good place to ask this type of thing.

Thanks for any help,
--Irmen de Jong

En Mon, 09 Apr 2007 08:43:23 -0300, Irmen de Jong <>
escribió:

> I have this UDP socket server that binds on ('',9090) and is used
> to be a broadcast responder. It works fine when I start the server
> from the cmd prompt. UDP broadcast packets sent to ('<broadcast>',9090)
> arrive in the server.
>
> However now I'm running the same server as a Windows NT Service.
> The same code is executed, the UDP server socket is bound to the
> same address. But this time, the UDP broadcast packets do NOT arrive....

Try running the service impersonating another user (not LOCAL_SERVICE, the
default).
You can change that from the service control panel.

--
Gabriel Genellina

Gabriel Genellina wrote:

> Try running the service impersonating another user (not LOCAL_SERVICE,
> the default).
> You can change that from the service control panel.

Alas, that didn't change anything.
I made it run as a user account that has admin privileges even,
and it still doesn't respond to the broadcasts.

--Irmen

En Mon, 09 Apr 2007 13:08:03 -0300, Irmen de Jong <>
escribió:

> Gabriel Genellina wrote:
>
>> Try running the service impersonating another user (not LOCAL_SERVICE,
>> the default).
>> You can change that from the service control panel.
>
> Alas, that didn't change anything.
> I made it run as a user account that has admin privileges even,
> and it still doesn't respond to the broadcasts.

Ouch, no more ideas from me. You'll surely get more answers from a Windows
networking group - this appears not to be related to Python anyway.

--
Gabriel Genellina

Gabriel Genellina wrote:

> Ouch, no more ideas from me. You'll surely get more answers from a
> Windows networking group - this appears not to be related to Python anyway.

Yeah I know that... That's what I mentioned in my original post...
But I'm a noob on that type of thing, no idea where to get reliable
help. So I hoped the good folks in this group could help me out a little.


Thanks for your idea anyway!

-Irmen

"Irmen de Jong" <> wrote:


> Gabriel Genellina wrote:
>
> > Try running the service impersonating another user (not LOCAL_SERVICE,
> > the default).
> > You can change that from the service control panel.
>
> Alas, that didn't change anything.
> I made it run as a user account that has admin privileges even,
> and it still doesn't respond to the broadcasts.
>

I am not sure if this is at all relevant - but I seem to recall seeing
something once that had a list of socket numbers, splitting them
between UDP & TCP - can the socket actually rx UDP?

- Hendrik

Hendrik van Rooyen wrote:
> "Irmen de Jong" <> wrote:
>
>
>> Gabriel Genellina wrote:
>>
>>> Try running the service impersonating another user (not LOCAL_SERVICE,
>>> the default).
>>> You can change that from the service control panel.
>> Alas, that didn't change anything.
>> I made it run as a user account that has admin privileges even,
>> and it still doesn't respond to the broadcasts.
>>
>
> I am not sure if this is at all relevant - but I seem to recall seeing
> something once that had a list of socket numbers, splitting them
> between UDP & TCP - can the socket actually rx UDP?
>
That's probably a red herring, Hendrik. Both UDP and TCP define ports
from 1 through 65535, and so a port number doesn't "belong" to one
protocol or the other.

It's most likely, I suspect without knowing to much about it, that the
service is stalling because of a failure to "pump" Windows messages.
Irmen, are you taking any action in your service to ignore Windows
messages that your service process receives?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
Recent Ramblings http://holdenweb.blogspot.com

> Hendrik van Rooyen wrote:
>> I am not sure if this is at all relevant - but I seem to recall seeing
>> something once that had a list of socket numbers, splitting them
>> between UDP & TCP - can the socket actually rx UDP?

Yeah, as I wrote: when I'm sending UDP packets to the port directly
on the server's IP address, it responds just fine.

It's just the broadcast packets that don't seem to arrive.
(sent to ('<broadcast>',9090) )

Steve Holden wrote:
> It's most likely, I suspect without knowing to much about it, that the
> service is stalling because of a failure to "pump" Windows messages.
> Irmen, are you taking any action in your service to ignore Windows
> messages that your service process receives?

Hm, seeing that it processes TCP and "directed" UDP packets just fine,
there shouldn't be a problem here?

No I'm not knowingly doing stuff that ignores windows messages...


(I could maybe put up the code if someone wants to take a look but
not right now. Need to rip a fair deal out - there's a lot of
other stuff in there that's not relevant to the problem.)

--Irmen

On Apr 10, 3:30 pm, Irmen de Jong <irmen.NOS...@xs4all.nl> wrote:
> > Hendrik van Rooyen wrote:
> >> I am not sure if this is at all relevant - but I seem to recall seeing
> >> something once that had a list of socket numbers, splitting them
> >> between UDP & TCP - can the socket actually rx UDP?
> Yeah, as I wrote: when I'm sending UDP packets to the port directly
>
> on the server's IP address, it responds just fine.
>
> It's just the broadcast packets that don't seem to arrive.
> (sent to ('<broadcast>',9090) )
>
> Steve Holden wrote:
> > It's most likely, I suspect without knowing to much about it, that the
> > service is stalling because of a failure to "pump" Windows messages.
> > Irmen, are you taking any action in your service to ignore Windows
> > messages that your service process receives?
>
> Hm, seeing that it processes TCP and "directed" UDP packets just fine,
> there shouldn't be a problem here?
>
> No I'm not knowingly doing stuff that ignores windows messages...
>
> (I could maybe put up the code if someone wants to take a look but
> not right now. Need to rip a fair deal out - there's a lot of
> other stuff in there that's not relevant to the problem.)
>
> --Irmen

I would investigate Windows security settings as a likely culprit. My
guess is that you are running WinXP SP2 with the default security
policies, which are likely to prohibit such promiscuous behavior.

Here's a URL that may shed some light, it seems surprisingly
instructive for MS support: http://support.microsoft.com/kb/842242 -
Some programs seem to stop working after you install Windows XP
Service Pack 2

-- Paul

Paul McGuire wrote:

> I would investigate Windows security settings as a likely culprit. My
> guess is that you are running WinXP SP2 with the default security
> policies, which are likely to prohibit such promiscuous behavior.
>
> Here's a URL that may shed some light, it seems surprisingly
> instructive for MS support: http://support.microsoft.com/kb/842242 -
> Some programs seem to stop working after you install Windows XP
> Service Pack 2

Paul, that was terrific.
Seems that the windows firewall blocks the broadcast stuff for services.
After I disabled the thing, my service works again as intended!
Have to add this to the notes of my software

Wonderful that my windows specific problem got solved in this Python group.

Thanks again for all the ideas everyone for my silly offtopic problem.

--Irmen