I'm trying to send a Wake on Lan in order to wake up my computer. From within my own network, I'm able to wake it up without conditions. However, if I try to wake it up from outside my network, it doesn't work.
It's an odd behavior because if I send the WOL a few seconds after the computer has shut down (less than 30 sec) it wakes up from the internet but if I try it after one minute it doesn't wake up.
I have a Movistar Homestation router if it helps and I'm sending the magic packet through port 9 (which is redirected to my computer private IP)
Thank you
I have issue on entry disappearing from ARP table on the router. This happens quite often on my router but not as fast as your scenario. I'd have to re-add the entry in order to make the router to accept the magic package again.
Hope this helps.
I assume you have mapped your pc's mac to the IP you are sending the WOL.
Have you created an entry in the ARP table of the router? The router could be cleaning the table after a few time and, when the WOL arrives to the computer, it doesn't know which MAC is for that IP.
If it doesn't work anyway, could you do some tests?
Change the port to port 7
Change the IP to the broadcast IP
I've read you could telnet that router and then you could add a permanent ARP entry in case your router's console doesn't let you(I can't test it)
Related
I want to build a DSR load balancer for an application I am writing. I wont go into the application because it is irrelevant for this discussion. My goal is to create a simple load balancer that does direct server response for TCP packets. The idea is to receive all packets at the load balancer, then using something like round robin, select a server from a list of available servers which are defined in some config file. The next step would be to alter the packer received and change the destination ip to be equal to the chosen backend server. Finally, the packet will be sent over to the backend server using normal system calls for sending packets. Theoretically the backend server should receive the packet, and send one back to the original requester, and then the requester can communicate directly with the backend server rather than going through the load balancer.
I am concerned that this design will not work as I expect it to. The main question is, what happens when computer A send a packet to IP Y, but receives a packet back in the same TCP stream from a computer at IP X? Will it continue to send packets to IP Y? Or will it switch over to IP X?
So it turns out this is possible, but only halfway so, and I will explain what I mean by this. I have three processes, one which is netcat, used to initiate an tcp request, a second process, the dsr-lb, which receives packets on a certain port, changes the destination ip to a backend server(passed in via command line arg), and forwards it off using raw sockets, and a third process which is a basic echo server. I got this working on a local setup. The local setup consists of netcat running on my desktop, and dsr-lb and echo servers running on two different linux VMs on the desktop as well. The path of the packets was like this:
nc -> dsr-lb -> echo -> nc
When I said it only half works, what I meant was that outgoing traffic has to always go through the dsr-lb, but returning traffic can go directly to the client. The client does not send further traffic directly to the backend server, but still goes through the dsr-lb. This makes sense since the client opened a socket to the dsr-lb ip, and internally still remembers this ip, regardless of where the packet came from.
The comment saying "if its from a different IP, it's not the same stream. tcp is connection-based" is incorrect. I read through the linux source code, specifically the receive tcp packet portion, and it turns out that linux uses source ip, source port, destination ip, and destination port to calculate a hash which is uses to find the socket that should receive the traffic. However, if no such socket matches the hash, it tries again using only the destination ip and destination port and that is how this "magic" works. I have no idea if this would work on a windows machine though.
One caveat to this answer is that I also spun up two remote VMs and tried the same experiment, and it did not work. I am guessing it worked while all the machines were on the same switch, but there might be a little more work to do to get it to work if it goes through different routers. I am still trying to figure this out, but from using tcpdump to analyze the traffic, for some reason the dsr-lb is forwarding to the wrong port on the echo server. I am not sure if something is corrupted, or if the checksum is wrong after changing the destination ip and some router along the way is dropping it or changing it somehow(I suspect this might be the case) but hopefully I can get it working over an actual network.
The theory should still hold though. The IP layer is basically a packet forwarding layer and routers should not care about the contents of the packets, they should just forward packets based on their routing tables, so changing the destination of the packet while leaving the source the same should result in the source receiving any answer. The fact that the linux kernel ultimately resolves packets to sockets just using destination ip and port means the only real roadblock to this working does not really exist.
Also, if anyone is wondering why bother doing this, it may be useful for a loadbalancer in front of websocket servers. Its not as great as a direct connection from client to websocket server, but it is better than a loadbalancer that handles both requests and responses, which makes it more scalable, and more able to run on less resources.
thanks in advance for you help if you are reading this.
I have a code that i wrote and it's working. At least it does what i need perfectly. But i think it might be doing some side effect to my WIFI network. A script in NODEJS sends udp packets regularly to different devices that are connected thru wifi. The devices are never responding to that packet but on purpose, i just want the "server" script to send updated info to the devices and "forget" about what it sent. I have a packet send scheduled , say per example, every 100milliseconds. But i need to keep stuff as light as possible. My content is 29 Byte long. My device number can vary.
The code goes something like this kinda pseudo code:
const client = dgram.createSocket('udp4');
for (z=1 , z== numberOfDevices, z++){
if (sendFlag === 1) {
client.send(NONE, 21324, myArgs[z], (err) => {});
}
}
even skipped the error catching because it doesn't matter to me. i want it to work "blindly".
and i only create "client" once and never call "client.close();" because if i do that every packet will generate a new output port and i am guessing that it can't be good for the router nor the machine running the node script.
if i dont call client.close(), like now, the output port remains always the same.
But it also will remain the same even if the target IP address changes. like:
port 50100 to IP1
port 50100 to IP2
port 50100 to IP3
and so on...
And i don't know if that can have any impact on the router if i am running the script for a big while, like 10 hours the wifi connection gets really slow. Even after i stop the server. And if the router is rebooted and i run the script everything is wonderfull and fast.
I would like to make possible that something like this happened:
port 50101 to IP1
port 50101 to IP2
port 50103 to IP3
and so on... for all the time that the script ran.
this seems like something that server.bind would help me , like binding a port for each ip but i am not that good at coding and i simply cannot make it work like that anyhow. If someone could help me i would not be able to thank you enough! Nodejs scripts examples are pretty based on client-> server comunication between two devices and this case i need one to many and i can't find some decent resource that i can learn from.
Side question is if can the same source port sending to multiple clients can have impact on networks.
Thanks!
i have a measurement setup where i want to trigger an oscilloscope base on a network package arriving. I have good results for a few seconds but somewhere between 20s and 40s i get a wrong trigger. My research showed that this could come from the arp packages send from the device. I tried to disable the arp sending but then the whole network went down. Now i'm trying to find a solution where i change the rate at which the arp packets are send without success. So i'm asking you if you know a way to either disable or send as few arp request as possible.
For your information i'm working on a Linux machine. Any help would be appreciated.
I allready tried:
#ip link set arp off dev eth0 <--- results in network down
changing the values for:
/proc/sys/net/ipv4/neigh/default/gc_interval
/proc/sys/net/ipv4/neigh/default/gc_stale_time
/proc/sys/net/ipv4/route/gc_interval
/proc/sys/net/ipv4/route/gc_timeout
with no success
Thx draufunddran
TL;DR: Disabling ARP on your machine will eventually cause other nodes on the network to stop sending packets to your machine (that is why your network appears to go down).
If you want to completely disable ARP packets on your network, you will need to manually program ARP tables on other nodes on your LAN (subnet) so that they know how to map your host's IP to a MAC address to send to on the LAN. This is a difficult thing to do if even possible since some nodes on your network may not offer the ability to program their ARP tables manually.
We have a legacy WinCE device that's been working fine for years when it was on a closed ethernet network. But now we're trying to get it to work nicely with other devices and it's failing when there's a DHCP server on the network.
The problem is that in order to speed up the boot the original engineers set "DhcpEnableImmediateAutoIP" in the registry. This effectively turns off the timeout where WinCE waits for a while before deciding that there's no DHCP server and does a zeroconfig. But because it doesn't actually turn off the DHCP request it allocates an IP address using zeroconfig then screws up when it gets a second IP address from the DHCP server a few seconds later.
I can see that "DhcpEnableImmediateAutoIP" is one of several keys controlling the DHCP, so I was wondering what would happen if I just set "EnableDHCP" to 0? Does this turn off the DHCP request so it just does a zeroconfig, or does it turn off the zeroconfig as well so it never gets an IP address?
I eventually found out that EnableDHCP turns off DHCP and then assumes static IP settings (so you need to provide ip address, subnet mask and optionally gateway/dns).
Here are all the options you can set:
http://msdn.microsoft.com/en-us/library/ms884977.aspx
Keeping DhcpEnableImmediateAutoIP, set the highest possible value for the AutoInterval : REG_DWORD registry entry which specifies the time interval, in seconds, used to verify if a DHCP server is available. This value is internally multiplied * 1000 to have it in msec so the max value you can set without wrapping corresponds to ~49 days. If the device is always on you'll end after that period in having everything screwed up anyway though...
A definitive solution may be cloning the DHCP client (D:\WINCE600\PRIVATE\WINCEOS\COMM\DHCP) and modify it in order not to send the discover packet, for example stubbing someway the function which is periodically called when the AutoInterval timer elapses.
Every time I use a different router and different P2P program, I get the same problem - port forwarding. I then usually read random values of ports(TCP, UDP, whatever) and paste it into random places in my router setttings page and repeat this process until the damn thing starts working. As I am a bit tired of doing that i would like to understand the theory behind it a little bit, so that I can put the right things in right places immediately. Could anybody just explain it briefly to me in a few words? Apologies for lengthy description of the problem, but I didn't know how to describe the level of understanding that I am talking about in a more concise way.
Thanks.
Well, the router hides you from the outer world, so you can only make outgoing connections, for which router takes care of sending your requests to the outer world, receiving responses, and sending those back to you. No one can send a packet to you unless you have specifically asked for it—i.e. you can only receive responses.
In case on p2p, the ability to send packets to your machine is important if not vital. So what you do is ask router to forward (here! that's where the word comes from) all incoming packets to port X to your machine, port X.
Originally IP addresses were provided per device, now-a-days we tend to have 1 IP address per household (unless your doing something crazy), also called your external IP. Your external IP is your connection to the world via your router, but each computer within your network has it's own IP (called internal IP). Port forwarding allows the external world to establish communications with a specific computer.
A web server is a simple example, web services typically rely on port 80, what-if in your network you had 4 computers, 1 of which was your web server. How would the outside world know which PC to contact? Port Forwarding allows you to tell your router to direct internet traffic to that server.