Highlighted
Absent Member.
Absent Member.

Re: WOL not working

I don't know why but WOL packet was sent when I changed keyboard to English
but now, no more WOL packet are sent.

I'll try to find why this happen... 😞 and will send you a packet when I
will make this work again.


"Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
groupe de discussion : VA.0000c1db.001d44fb@no-mx.forums.novell.com...
> Normand,
>
> can we see one of the packets?
>
> --
>
> Shaun Pond
>
>

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

Normand,

interesting...

--

Shaun Pond


0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

It so happens I ran across a VERY odd problem the other day............

This was ZDM7 and in this case the Packet was sent by the Client
Workstation.
A Packet was being formed with correct Destination Port of (1761) and
Destination Network of (.255)

However, the Packet itself was malformed.
The "Protocol" type was NOT listed as WOL.
The DATA field which should have had the MAC ADDRESS duplicated 16 times,
was filled with junk.

AND...........

This issue only seemed to happen when you specified a Remote VLAN!!!!

AND............

Here is the kicker............
It was only happening on a French Workstation for a Canadian Customer.

He Changed the Windows Language to English and it worked.
He Changed the Windows Language back to French.........And it STILL
worked!!!!

DON'T ask my How or Why?
But if you are using Wireshark (1.0.5 or newer - The version I currently
have loaded), the Protocol Should say WOL and be decodable so you can see
the MAC ID Repeated.
If you are not seeing this, the Packet is likely being malformed on
creation, which is actually not related to the defect you were referencing.
I can't say if the Cause of the MALFORMED Packet lies in ZCM or the Host OS,
Just relaying a really really really odd case I had the other day.



"Normand" <nhudon@noreply.ca> wrote in message
news:xbUol.180$Ht3.59@kovat.provo.novell.com...
>I did the test again with devices in VLAN 90 (same as the ZCM server) and
>in VLAN 80.
> Devices in VLAN 90 works fine with WOL but nothing happen on devices in
> VLAN 80 (failure status).
> In the paquet trace, I see 2 UDP paquets going to destination .255. In the
> Wireshark info section, source port is 1104 and destination port is 1761.
> Also tried using a device as a proxy without success.
> Thanks for your help.
>
>
> "Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
> groupe de discussion : VA.0000c1a3.13026760@no-mx.forums.novell.com...
>> Normand,
>>
>> that's probably the only place you're going to see it, unless your
>> routers are configured to forward the subnet broadcast...
>>
>> --
>>
>> Shaun Pond
>>
>>



0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

OK. Now I will resume my situation because I think it's kind of bizarre...
ZCM 10.1.3, Wireshark 1.1.2
When I lauch a WOL command on a different VLAN as the server, no WOL paquet
is sent.
When I lauch a WOL command on a different VLAN as the server and on a device
on the same VLAN as the server, WOL paquet is sent but:
- paquet to the same VLAN: is send to a group address
(ff:ff:ff:ff:ff:ff)
- paquet to the different VLAN: is send to an individual address (probably
the switch MAC)
In the WOL section of both paquet, I can see MAC address duplicate 16 times
as you said.
What do you think of that ?



"Craig Wilson" <craig_d_wilson@yahoo.com> a écrit dans le message de groupe
de discussion : _yWol.219$Ht3.199@kovat.provo.novell.com...
> It so happens I ran across a VERY odd problem the other day............
>
> This was ZDM7 and in this case the Packet was sent by the Client
> Workstation.
> A Packet was being formed with correct Destination Port of (1761) and
> Destination Network of (.255)
>
> However, the Packet itself was malformed.
> The "Protocol" type was NOT listed as WOL.
> The DATA field which should have had the MAC ADDRESS duplicated 16 times,
> was filled with junk.
>
> AND...........
>
> This issue only seemed to happen when you specified a Remote VLAN!!!!
>
> AND............
>
> Here is the kicker............
> It was only happening on a French Workstation for a Canadian Customer.
>
> He Changed the Windows Language to English and it worked.
> He Changed the Windows Language back to French.........And it STILL
> worked!!!!
>
> DON'T ask my How or Why?
> But if you are using Wireshark (1.0.5 or newer - The version I currently
> have loaded), the Protocol Should say WOL and be decodable so you can see
> the MAC ID Repeated.
> If you are not seeing this, the Packet is likely being malformed on
> creation, which is actually not related to the defect you were
> referencing.
> I can't say if the Cause of the MALFORMED Packet lies in ZCM or the Host
> OS, Just relaying a really really really odd case I had the other day.
>
>
>
> "Normand" <nhudon@noreply.ca> wrote in message
> news:xbUol.180$Ht3.59@kovat.provo.novell.com...
>>I did the test again with devices in VLAN 90 (same as the ZCM server) and
>>in VLAN 80.
>> Devices in VLAN 90 works fine with WOL but nothing happen on devices in
>> VLAN 80 (failure status).
>> In the paquet trace, I see 2 UDP paquets going to destination .255. In
>> the Wireshark info section, source port is 1104 and destination port is
>> 1761.
>> Also tried using a device as a proxy without success.
>> Thanks for your help.
>>
>>
>> "Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
>> groupe de discussion : VA.0000c1a3.13026760@no-mx.forums.novell.com...
>>> Normand,
>>>
>>> that's probably the only place you're going to see it, unless your
>>> routers are configured to forward the subnet broadcast...
>>>
>>> --
>>>
>>> Shaun Pond
>>>
>>>

>
>

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

Did he changed Windows language under Regional and Language settings ?


"Craig Wilson" <craig_d_wilson@yahoo.com> a écrit dans le message de groupe
de discussion : _yWol.219$Ht3.199@kovat.provo.novell.com...
> It so happens I ran across a VERY odd problem the other day............
>
> This was ZDM7 and in this case the Packet was sent by the Client
> Workstation.
> A Packet was being formed with correct Destination Port of (1761) and
> Destination Network of (.255)
>
> However, the Packet itself was malformed.
> The "Protocol" type was NOT listed as WOL.
> The DATA field which should have had the MAC ADDRESS duplicated 16 times,
> was filled with junk.
>
> AND...........
>
> This issue only seemed to happen when you specified a Remote VLAN!!!!
>
> AND............
>
> Here is the kicker............
> It was only happening on a French Workstation for a Canadian Customer.
>
> He Changed the Windows Language to English and it worked.
> He Changed the Windows Language back to French.........And it STILL
> worked!!!!
>
> DON'T ask my How or Why?
> But if you are using Wireshark (1.0.5 or newer - The version I currently
> have loaded), the Protocol Should say WOL and be decodable so you can see
> the MAC ID Repeated.
> If you are not seeing this, the Packet is likely being malformed on
> creation, which is actually not related to the defect you were
> referencing.
> I can't say if the Cause of the MALFORMED Packet lies in ZCM or the Host
> OS, Just relaying a really really really odd case I had the other day.
>
>
>
> "Normand" <nhudon@noreply.ca> wrote in message
> news:xbUol.180$Ht3.59@kovat.provo.novell.com...
>>I did the test again with devices in VLAN 90 (same as the ZCM server) and
>>in VLAN 80.
>> Devices in VLAN 90 works fine with WOL but nothing happen on devices in
>> VLAN 80 (failure status).
>> In the paquet trace, I see 2 UDP paquets going to destination .255. In
>> the Wireshark info section, source port is 1104 and destination port is
>> 1761.
>> Also tried using a device as a proxy without success.
>> Thanks for your help.
>>
>>
>> "Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
>> groupe de discussion : VA.0000c1a3.13026760@no-mx.forums.novell.com...
>>> Normand,
>>>
>>> that's probably the only place you're going to see it, unless your
>>> routers are configured to forward the subnet broadcast...
>>>
>>> --
>>>
>>> Shaun Pond
>>>
>>>

>
>

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

I changed language under Control Panel - Regional and Language settings and
set it to English - Canada and it don't work.


"Normand" <nhudon@noreply.ca> a écrit dans le message de groupe de
discussion : j7Zol.348$Ht3.249@kovat.provo.novell.com...
> Did he changed Windows language under Regional and Language settings ?
>
>
> "Craig Wilson" <craig_d_wilson@yahoo.com> a écrit dans le message de
> groupe de discussion : _yWol.219$Ht3.199@kovat.provo.novell.com...
>> It so happens I ran across a VERY odd problem the other day............
>>
>> This was ZDM7 and in this case the Packet was sent by the Client
>> Workstation.
>> A Packet was being formed with correct Destination Port of (1761) and
>> Destination Network of (.255)
>>
>> However, the Packet itself was malformed.
>> The "Protocol" type was NOT listed as WOL.
>> The DATA field which should have had the MAC ADDRESS duplicated 16 times,
>> was filled with junk.
>>
>> AND...........
>>
>> This issue only seemed to happen when you specified a Remote VLAN!!!!
>>
>> AND............
>>
>> Here is the kicker............
>> It was only happening on a French Workstation for a Canadian Customer.
>>
>> He Changed the Windows Language to English and it worked.
>> He Changed the Windows Language back to French.........And it STILL
>> worked!!!!
>>
>> DON'T ask my How or Why?
>> But if you are using Wireshark (1.0.5 or newer - The version I currently
>> have loaded), the Protocol Should say WOL and be decodable so you can see
>> the MAC ID Repeated.
>> If you are not seeing this, the Packet is likely being malformed on
>> creation, which is actually not related to the defect you were
>> referencing.
>> I can't say if the Cause of the MALFORMED Packet lies in ZCM or the Host
>> OS, Just relaying a really really really odd case I had the other day.
>>
>>
>>
>> "Normand" <nhudon@noreply.ca> wrote in message
>> news:xbUol.180$Ht3.59@kovat.provo.novell.com...
>>>I did the test again with devices in VLAN 90 (same as the ZCM server) and
>>>in VLAN 80.
>>> Devices in VLAN 90 works fine with WOL but nothing happen on devices in
>>> VLAN 80 (failure status).
>>> In the paquet trace, I see 2 UDP paquets going to destination .255. In
>>> the Wireshark info section, source port is 1104 and destination port is
>>> 1761.
>>> Also tried using a device as a proxy without success.
>>> Thanks for your help.
>>>
>>>
>>> "Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
>>> groupe de discussion : VA.0000c1a3.13026760@no-mx.forums.novell.com...
>>>> Normand,
>>>>
>>>> that's probably the only place you're going to see it, unless your
>>>> routers are configured to forward the subnet broadcast...
>>>>
>>>> --
>>>>
>>>> Shaun Pond
>>>>
>>>>

>>
>>

0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

Well, your stated the Packet does not appear "Malformed" and the "MAC" info
is there.
So apparently your issue is different at 1st glance.
I will have to ponder more and maybe more folks will jump be able to help
based on the additional info.

"Normand" <nhudon@noreply.ca> wrote in message
news:vsZol.359$Ht3.47@kovat.provo.novell.com...
>I changed language under Control Panel - Regional and Language settings and
>set it to English - Canada and it don't work.
>
>
> "Normand" <nhudon@noreply.ca> a écrit dans le message de groupe de
> discussion : j7Zol.348$Ht3.249@kovat.provo.novell.com...
>> Did he changed Windows language under Regional and Language settings ?
>>
>>
>> "Craig Wilson" <craig_d_wilson@yahoo.com> a écrit dans le message de
>> groupe de discussion : _yWol.219$Ht3.199@kovat.provo.novell.com...
>>> It so happens I ran across a VERY odd problem the other day............
>>>
>>> This was ZDM7 and in this case the Packet was sent by the Client
>>> Workstation.
>>> A Packet was being formed with correct Destination Port of (1761) and
>>> Destination Network of (.255)
>>>
>>> However, the Packet itself was malformed.
>>> The "Protocol" type was NOT listed as WOL.
>>> The DATA field which should have had the MAC ADDRESS duplicated 16
>>> times, was filled with junk.
>>>
>>> AND...........
>>>
>>> This issue only seemed to happen when you specified a Remote VLAN!!!!
>>>
>>> AND............
>>>
>>> Here is the kicker............
>>> It was only happening on a French Workstation for a Canadian Customer.
>>>
>>> He Changed the Windows Language to English and it worked.
>>> He Changed the Windows Language back to French.........And it STILL
>>> worked!!!!
>>>
>>> DON'T ask my How or Why?
>>> But if you are using Wireshark (1.0.5 or newer - The version I currently
>>> have loaded), the Protocol Should say WOL and be decodable so you can
>>> see the MAC ID Repeated.
>>> If you are not seeing this, the Packet is likely being malformed on
>>> creation, which is actually not related to the defect you were
>>> referencing.
>>> I can't say if the Cause of the MALFORMED Packet lies in ZCM or the Host
>>> OS, Just relaying a really really really odd case I had the other day.
>>>
>>>
>>>
>>> "Normand" <nhudon@noreply.ca> wrote in message
>>> news:xbUol.180$Ht3.59@kovat.provo.novell.com...
>>>>I did the test again with devices in VLAN 90 (same as the ZCM server)
>>>>and in VLAN 80.
>>>> Devices in VLAN 90 works fine with WOL but nothing happen on devices in
>>>> VLAN 80 (failure status).
>>>> In the paquet trace, I see 2 UDP paquets going to destination .255. In
>>>> the Wireshark info section, source port is 1104 and destination port is
>>>> 1761.
>>>> Also tried using a device as a proxy without success.
>>>> Thanks for your help.
>>>>
>>>>
>>>> "Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
>>>> groupe de discussion : VA.0000c1a3.13026760@no-mx.forums.novell.com...
>>>>> Normand,
>>>>>
>>>>> that's probably the only place you're going to see it, unless your
>>>>> routers are configured to forward the subnet broadcast...
>>>>>
>>>>> --
>>>>>
>>>>> Shaun Pond
>>>>>
>>>>>
>>>
>>>



0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

I think I have a different problem. I don't get a magic packet for either local or remote workstations. I do get an error in loader-messages.log:

[DEBUG] [3/4/09 10:34:11 AM] [] [Loader.QueueRunner] [Handler failed to process action ID : 193, Type: WOL_QUICK_ACTION_TYPE, ] [Handler failed to process action ID : 193, Type: WOL_QUICK_ACTION_TYPE, ] [] []
[DEBUG] [3/4/09 10:34:11 AM] [] [Loader.QueueRunner] [java.lang.NullPointerException
at com.novell.zenworks.loader.modules.NetworkInterface.convertIPStringToBytes(NetworkInterface.java:92)
at com.novell.zenworks.loader.modules.NetworkInterface.getSubnetAddress(NetworkInterface.java:68)
at com.novell.zenworks.loader.modules.WOLUtil.groupDevice(WOLUtil.java:140)
at com.novell.zenworks.loader.modules.WOLUtil.groupDevicesIntoSubnet(WOLUtil.java:97)
at com.novell.zenworks.loader.modules.WakeOnLANHandler.processAction(WakeOnLANHandler.java:304)
at com.novell.zenworks.loader.modules.queue.runner.QueueThreadWorker.processAction(QueueThreadWorker.java:193)
at com.novell.zenworks.loader.modules.queue.runner.QueueThreadWorker.run(QueueThreadWorker.java:139)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
] [java.lang.NullPointerException
at com.novell.zenworks.loader.modules.NetworkInterface.convertIPStringToBytes(NetworkInterface.java:92)
at com.novell.zenworks.loader.modules.NetworkInterface.getSubnetAddress(NetworkInterface.java:68)
at com.novell.zenworks.loader.modules.WOLUtil.groupDevice(WOLUtil.java:140)
at com.novell.zenworks.loader.modules.WOLUtil.groupDevicesIntoSubnet(WOLUtil.java:97)
at com.novell.zenworks.loader.modules.WakeOnLANHandler.processAction(WakeOnLANHandler.java:304)
at com.novell.zenworks.loader.modules.queue.runner.QueueThreadWorker.processAction(QueueThreadWorker.java:193)
at com.novell.zenworks.loader.modules.queue.runner.QueueThreadWorker.run(QueueThreadWorker.java:139)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)

ZCM 10.1.3 on Windows 2003 R2
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: WOL not working

Tweiland,

in that case I think it's better that you post this as a new root
message: you'll get better answers, as they won't be confused with the
other issue in the thread 🙂

Shaun Pond


0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.