I am trying to configure my laptop to be able to Wake On LAN via Magic Packets. I have a magic packet sniffer and it alerts me when a magic packet has been recieved(runs on target machine). The trouble is when I try to use the external ip address instead of the internal address. I have port forwarded port 9 to my internal ip(10.0.0.x, NOTE: x is only one digit). If I use the internal ip address, it tells me that a magic packet has been received. If I try the external ip address and sending from the target machine(to itself) it receives the magic packet. If I send it through a different machine or a website, it does not work. I am connected via ethernet cable(CAT 5). I also have the "Wake on LAN" setting in my BIOS set to "ENABLED". Also, my computer is set to "Allow this device to wake the computer". Am I doing something wrong?
P.S.
The solution to the previous problem was to start the Simple TCP/IP Service in Windows.
To use Wake on LAN across the internet (=> wake on WAN), you must do one of these things :
Edit your router's ARP table so it can forward the magic pack to the target computer with its MAC address
Port forward to LAN broadcast address so the target computer will always receive any magic packet sent to your router until it is plugged to the router
Buy a router with a built-in wake on lan feature (like DD-WRT open source firmware)
Use a magic packet repeater to forward magic packets to the broadcast address. This one should be always powered on
I'm using the fourth option to wake my home computer from my work. I bought an Arduino Uno + Ethernet shield and wrote a little program to do the job (forward magic packet). I set a port forward rule into my router (Netgear DG834G) to forward UDP 9 to the Arduino IP address.
I wrote a tutorial about this on my personal website, it's in French but code is universal ^^ : http://www.finalclap.com/tuto/arduino-wake-on-lan-repeater-80/
I did some more research and it turns out that unless the router itself has a built in management and can be accessed publicly, WoL will not work behind a router. WoL will work however if you have a device already inside the network send the magic packet to the target machine. THat completely destroys the point of WoL!
Related
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
Isn't the router supposed to isolate each client and route only their own data to and from themselves? What actually happens behind the scenes?
Suppose I run Wireshark on my PC, and I'm connected to a router, how can Wireshark know about all the traffic from that router?
If you have a router that's connected to multiple LANs, then Wireshark, running on a machine connected to one of those LANs, can't know about all the traffic from the router unless the router has been configured to, for traffic that would otherwise not be routed to that LAN, send a copy of the packet on that LAN.
If you're talking about a LAN switch, so that everything plugged into the switch is on the same LAN, the situation is similar - the switch would have to be configured to send copies of traffic to the switch port into which the machine running Wireshark is plugged.
The ability to do that is a common feature in higher-end switches; a port can be configured to be a "mirror port". See the Wireshark Wiki page on Ethernet capture setup for details. I don't know whether any routers provide an equivalent of "port mirroring".
The isolation of packets to ports is the functionality of a switch.
A hub sends the packets to all ports.
But your router acts also as a switch. You can place a device in front of the router and sniff from there. This device needs to be a hub, a switch with a monitor port or a splitter.
Or you can use arp spoofing to manipulate the arp tables of the computers in the network. But that is mostly considered as an attack.
Cheers,
Chris
I'm trying to get Age of Empires II (AoE2) to work on my LAN. AoE2 is notorious for it's connectivity problems on modern systems, probably because it used a now deprecated network framework called DirectPlay (in DX9) and the code probably wasn't robust back in the day either.
When I host a LAN game on a computer (win7) for AoE2, Wireshark shows my computer sending a couple packets via SSDP protocol to the multicast address 239.255.255.250. This actually goes to my router (for forwarding I assume) and my router returns a packet using ICMP protocol that says "Destination unreachable (Port unreachable)". Because nothing is forwarded to the other computers on the network, they can't see the game that the host has created.
I think I need to get the application/windows7 to send the packet as something like a broadcast, or I need to get the router to broadcast packets going to that multicast address. Does anyone have thoughts or suggestions on how to do this?
My router/gateway is running DD-WRT firmware v24-sp2.
My first guess is you're using wifi, by default most systems disable multicast on wifi because it can have a detrimental effect on the time slicing that wifi uses. however for just a couple machines it shouldn't be an issue.
here's how to disable multicasting but it should point you in the right direction for enabling it: ddwrt multicast
Secondly make sure they are all in the same VLAN a VLAN is defined as a "broadcast domain" meaning machines on separate VLANs will NEVER get broadcast or multicast from other VLANs without some trickery.
Lastly make sure you've enabled multicasting between LAN ports I believe the option is "multicast forward"
Edit: Just a few things to add to the list in case others have this issue. Broadcasting doesn't exist in ipv6, also a machine running ipv6 MAY NOT see broadcasts from a machine on ipv4 and a machine on ipv4 WILL NOT see multicasts to an ipv6 multi-cast address.
Have you tried LogMeIn Hamachi?
Is not a LAN client itself but it creates a fake Online-LAN and gives you a working IP that will allow you to play with who have it.
Im not too sure why this wont work. My application works fine if the client and server are ran on the same PC hence the 127.0.0.1 but it wont connect to my other laptop using IP 82.41.108.125 which is the IP of that device.
Any reason why this is happening?
Your firewall could quite possibly be blocking the port assuming all of your coding is working fine - try opening up the port number you're running the application on (in the client/server comptuers' firewall options).
Some additional information that should shed some light on things
Networked devices use ARP (Address Resolution Protocol) and RARP (Reverse Address Resolution Protocol) to map IPs to link layer (MAC) addresses and back. Your network interface card (the thing that plugs into your ethernet cable) will have a unique MAC address on both computers. Each PC has an IP configured for it which is used by higher level protocols (those in the Network Layer).
Computer A will know computer B's IP address (and it will be different from computer A's) if your program works correctly. When computer A goes to send to comptuer B, assuming they're directly connected and not going through a router or something in between, computer A's link layer will need to translate that IP for comptuer B into a MAC address it can use. It does this by sending out a broadcast to all network PCs on the same sub network asking "Hey, is this your IP!?" essentially. The one that has an IP matching the broadcasted one yes, "Yes, it's mine - and here's my MAC address so you can talk directly to me."
So, if two computers have the same IP this all goes to hell :) don't do it - give them unique IPs and make sure that comptuer A transmits to the same UDP port and IP that computer B is listening on as well. communications work in {IP, Port} pairs - its like a telephone number and area code.
Also...
As said by EJP - UDP is a connectionless protocol - computer A just sends to computer B and hopes that computer B is listening correctly. If computer B wasn't listening or was but wasn't in the right state to process the data, the data will simply be dropped and lost. Computer A will not know that this happened. If you want reliable communications where it will keep trying and you will have assurance that compuer B received computer A's data then use TCP instead - it does a 3 way handshake to establish a connection and uses acknowledgements to ensure data is retransmitted when it doesn't reach the other end.
It could be that you're listening on localhost (127.0.0.1) and don't accept other traffic. Use a wildcard address.
Check on the server with netstat -npu.
If that's not the case then it's probably firewall issue, verify with tcpdump or wireshark.
Check firewall on your laptop... Most of the time that acts as spoilsport.
I am trying to send data using the AsyncUDPSocket class. And I can send data using the iPhone simulator over the wire to another machine that is running a simple C-coded listening server. I can also receive data over the wire using a client connected to the simulator(server). However, when I tried the same over Wifi, using the simulator, I could only send data but not receive any data.
I read on another post, that unicast data makes this possible. How can I acheive this using AsyncUDPSocket?
Thanks,
Angelo.
Ok, I figured this out. A newbie kind of thing, really.
When I set my Mac network preferences to Ethernet, I get an IP for me to communicate. However, when I turn Airport(Wi-Fi for more newbies) ON, and ethernet cable disconnected, I checked my network preferences, and sure enough my IP address was a different one.
Spoke to a friend (an ace in networking) and the thing clicked immediately: On WiFi networks a DHCP server allocates an IP address. This IP address has to be reserved, at the very least, at the DHCP server. Since my IP was not reserved, I had to change the IP address, in my udp_client.c file, recompile and run the client to connect.
BTW, I can now communicate between my iPhone and my PC using my local WiFi (office) network.
For any who might face the same problem, do not be assured that the IP address of your mchine is the same, when you switch from LAN to Wifi, and use the device mostly for WiFi reated testing. :)
we have little network devices which are shipped with IP address 0.0.0.1 to ensure that they never collide with any other device in their new environment (thus none of the 10.x.x.x, 172.16.x.x or 192.168.x.x ranges) until configuration. DHCP is no solution since there might be no DHCP server in the field.
The devices would listen to UDP broadcasts and answer with broadcasts until they are given their new IP address this way.
This worked fine with Windows XP - but sucks with Windows 7: the config program does not receive the answer packets from the devices which still have 0.0.0.1. Wireshark sees the packets, then they are dumped by the system.
Question: Is there any reason (RFC?) that actually prohibits using this address in a local environment? Or is it just MS that was overcautious? Where can I read why they treat this address "invalid"? Which ranges are really "invalid" now, too?
Any idea of a workaround on the PC side (Win 7)?
I know that it is not recommended to use 0.xxx addresses for work places, but for this very reason - having a not-used address - it works perfectly.
Edit: there is a device out there called "Netburner" which might have faced the similar issue, according to their forum. See: http://forum.embeddedethernet.com/viewtopic.php?f=5&t=612&p=2198 Does - by coincidence - anybody know some background information?
It sounds as if your configuration application is listening for broadcast packets on all network interfaces and expecting to receive packets from foreign subnets.
That should not work - the OS should only pass-on broadcast packets from the subnets each network interface is on, not from all subnets on the same physical (e.g. Ethernet) segment. I am reasonably certain that doing otherwise is broken behaviour WRT the IP protocol.
The are two ways to deal with this:
Make sure that your network interface has an IP address in the target subnet. You can have more than one IP addresses for each network card, so that should not interfere with normal network operations.
Configure or modify you application to use raw sockets, like Wireshark. Keep in mind, however, that this overrides all normal checks and balances and should be avoided, since it can cause behaviour that is almost impossible to diagnose - which is why it is frowned upon by meny network administrators.
Can you you add new routing table entries to Windows machines easily? Windows has to know which interface to use when routing a broadcast packet to the 0.0.0.x network.
The Unix machines I'm familiar with have a routing table that maps network/netmask entries to either gateways or interfaces (if the network is a local network). The local network (192.168.0.0/16 for my home network) gets sent to interface eth0. Everything else 0.0.0.0/0 gets sent to a specific gateway machine 192.168.0.1.
If my machine sent a UDP broadcast message to network 0.0.0.0/24 (in other words, UDP broadcast sent to 0.0.0.255, then my machine would forward the packet to the gateway machine (which it can look up via arp). The switches in the middle wouldn't propagate the packet to other network devices, because the MAC address is set.
If my machine had another routing entry for 0.0.0.0/24 to the local interface, then my machine would send the packet on the wire using an ethernet broadcast group, and the switches would forward the packet to all connections. (Yay! Just like hubs in the 90s! :)
So I figure you need to add a routing entry for 0.0.0.0/24 to your client machines, so that they can properly address the broadcast packet.