Re: Sending "magic packets" from OBSD router seems to fail

From: clvrmnky (clvrmnky-uunet_at_coldmail.com.invalid)
Date: 01/05/04 

Date: Mon, 05 Jan 2004 11:00:16 -0500

Craig Orsinger wrote:
> On Fri, 19 Dec 2003 12:27:10 -0500, clvrmnky wrote:
>
>
>>I've got a pretty vanilla OBSD 3.1 box acting as a firewall/router for a
>>small internal network of two Macs and a Win2K box. xl0 is the inside
>>device, attached to a switch. xl1 is on the outside attached to a cable
>>modem.
>>
>>I'm using the "wakeonlan" Perl script to wake the Macs from sleep so I
>>can do maintenance, perform updates &etc., but for some reason these
>>packets are not being sent from the OBSD box.
>>
>>I can send the same packets from one of the Macs to another Mac, which
>>works just fine (i.e., both Macs have ethernet cards that support
>>Wake-On-LAN). Of course, in this case, the magic packets are sent
>>through the switch, not the OBSD box.
>>
>>I've done some sniffing with tcpdump, and no traffic related to
>>wakeonlan seems to hit the internal ethernet device (attached to the
>>aforementioned switch). If I specify the IP address arg to wakeonlan,
>>tcpdump reports:
>>
>>12:16:07.048788 arp who-has 10.0.0.10 tell myrouter.domain.org
>>
>>Of course, the ARP table does not have any entry for this IP (yet).
>>
>>Hmm. And I've just found out while testing this as I write, that _some_
>>variation of IP works -- maybe "10.0.0.255"? Perhaps my firewall is
>>blocking 255.255.255.255? I _think_ I tried this w/o any PF rules
>>enabled, but now I'm not so sure.
>>
>>If anyone can spare a clue, that would be great.
>
>
> I'm guessing that Wake-On-LAN only wakes up your Mac if it sees
> its own MAC (ethernet) address. If this is the case, your ARP won't get
> answered by a sleepy Mac, since they are sent as ethernet broadcast
> packets. Try adding your Mac's address to your firewall's ARP table
> by using the arp(8) command (as root, of course):
>
> arp -s <Mac's IP> <Mac's MAC>
>
> Then try to send a wakeup packet. If this works, just
> add that command to an appropriate rc file on your firewall.
>
I tried this with no love. The trick seems to be to send the magic
packet to a broadcast address, but not the default of 255.255.255.255.

Relevant Pages

  • Re: Catalyst 4000 - Ciscos Response
    ... on a variety of factors such as Switch load and traffic patterns. ... Flooding packets ... database on the switch containing switch ports and the MAC addresses sourced ... Sniffer is on a different port than the workstation and servers. ...
    (Bugtraq)
  • Re: how switches work - collision-free / full-duplex
    ... The switch actually has buffers to queue up the packets for a given ... Ethernet just not do any resends and let higher layers worry about it? ...
    (comp.dcom.lans.ethernet)
  • Re: MAC address spoofing - conflict?
    ... Ethernet switches split ethernet networks into different collision ... MAC spoofing should not be applicable to thoses environments as it ... Depending on switch behaviour, you may ... WiFi network, as it is a layer 1 share medium too. ...
    (Pen-Test)
  • RE: mac duplication
    ... MAC addresses are globally unique. ... What a switch does when it sees a duplicated MAC is completely arbitrary... ... And for the interval between updates, the packets get routed only to that ... > duplication in that case so that i can sniff data. ...
    (Vuln-Dev)
  • Re: Sending "magic packets" from OBSD router seems to fail
    ... > through the switch, not the OBSD box. ... > wakeonlan seems to hit the internal ethernet device (attached to the ... the ARP table does not have any entry for this IP. ... its own MAC address. ...
    (comp.unix.bsd.openbsd.misc)