shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

> 1761
>

well that's the magic packet

> Broadcast paquets are only sent to the same VLAN as the server
>

yes, that's why you need routers to support directed subnet
broadcasting, to forward the packet on - ZENworks cannot do this.

--

Shaun Pond


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: WOL not working

We have 3Com switchs and it worked in ZCM version 10.0.3.2.
We didn't make any changes in our switch.
Where should I look for at this time ?


"Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
groupe de discussion : VA.0000c1ac.153b7af8@no-mx.forums.novell.com...
> Normand,
>
>> 1761
>>

> well that's the magic packet
>
>> Broadcast paquets are only sent to the same VLAN as the server
>>

> yes, that's why you need routers to support directed subnet
> broadcasting, to forward the packet on - ZENworks cannot do this.
>
> --
>
> Shaun Pond
>
>

0 Likes
shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

go and check the switch configuration - see exactly what it's set for
with directed subnet broadcasts...

--

Shaun Pond


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: WOL not working

Does IGMP Snooping having something to do with multicast WOL packet ?


"Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
groupe de discussion : VA.0000c1b9.18fc5c43@no-mx.forums.novell.com...
> Normand,
>
> go and check the switch configuration - see exactly what it's set for
> with directed subnet broadcasts...
>
> --
>
> Shaun Pond
>
>

0 Likes
shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

WOL isn't multicast, it's a broadcast...

--

Shaun Pond


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: WOL not working

Oups... 😞


"Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
groupe de discussion : VA.0000c1d5.060f98cd@no-mx.forums.novell.com...
> Normand,
>
> WOL isn't multicast, it's a broadcast...
>
> --
>
> Shaun Pond
>
>

0 Likes
shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

🙂

--

Shaun Pond


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: WOL not working

Just a little confusion between terms but still not working 😞


"Shaun Pond" <spond@no-mx.forums.novell.com> a écrit dans le message de
groupe de discussion : VA.0000c1d9.069a38d6@no-mx.forums.novell.com...
> Normand,
>
> 🙂
>
> --
>
> Shaun Pond
>
>

0 Likes
shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

can we see one of the packets?

--

Shaun Pond


0 Likes
Anonymous_User 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
shaunpond Absent Member.
Absent Member.

Re: WOL not working

Normand,

interesting...

--

Shaun Pond


0 Likes
Anonymous_User 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
Anonymous_User 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
Anonymous_User 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
Anonymous_User 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
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.