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.
Related
Consider the following:
I have a device which sends UDP messages to another device, both on the same switch. The UDP messages are not sent as a broadcast. Now I want to listen to these UDP messages with a third device, also connected to the same switch.
Now I've to choose the right switch and I'm not sure if I missed something:
Is it correct that the UDP messages anyway are sent troughout all ports of the switch since a Layer2 switch doesn't know anything about addresses. Or in other words: Can I use any Layer2 switch, managed or unmanaged, as long as all devices are in the same subnet?
Thanks for your help!
Simon
I think you're misunderstanding how works layer 2 in the TCP/IP model.
If a UDP datagram is sent to a specific machine on the network, it's layer 2 address should be the destination's MAC address and the switch will send it only to this machine as long as he's got the mac address in his CAM table (MAC address <-> physical port association) which should be the case as long as the machine is active on the network.
If you want to intercept packets between two machines, you can either mirror the physical port on the switch to copy informations received by this port, or make a ARP cache poison attack on the local network which will allow you to receive all traffic from one machine to another, also known as MITM attack (man in the middle) which is quite easy to produce on a linux machine.
I'm new to the networking world and I'm using Wireshark to learn stuffs about the network.
I was hanging around in Wireshark while I was using my VPN for circumventing the internet filter (living in a dictatorship country).
While I was using the VPN I see packets that their source or destination IP was neither my IP nor VPN server IP.
I considered two things about my problem:
1- I know my VPN uses its VPN server to send my whole packets to that server then forward them to my deserved destination, then take the response and send it to my client (is that correct?).
2- In Wireshark, I just can see the packets that their either source or destination address is my IP address.
My packets before using VPN:
As you can see, their either source or destination IP is my IP (192.168.1.101).
After using VPN, VPN:
Wireshark:
I tried filtering packets with my IP like this ip.addr == 192.168.1.101 to see only the packets that their either source or destination IP was my private IP, and guess what? nothing was changed. Why did this happen? Wasn't that supposed to filter my packets?
I also checked those packets' MAC and compared them with my MAC, and they were identical.
So my main question is why these kinds of wandering packets were showed by Wireshark? Is my VPN client insecure and trying to sending my data to other places? Or I'm wrong about how my VPN works?
Also, I appreciate it If somebody tells me more explanation about how my VPN or Wireshark works so that I have these types of packets in my Wireshark.
First of all your considerations, point no.1 is right, that's how a typical VPN works and point no.2 is wrong.
Wireshark can capture any packet (any source IP or destination IP) flowing in and out of a network adapter technically known as NIC card. NIC cards are the way through which you can connect to a network (Internet). A quick brief of NIC over here
A typical VPN client software would form a virtual NIC to encrypt and send your traffic through it. A quick brief of VPNs over here
So, to see the required traffic in Wireshark, you must capture traffic from an appropriate interface (NIC card). The answer over here might be helpful.
I'm trying to develop an applicaton for p2p communication between two android devices. In order to punch a hole through my NAT(s), I'd need to know my external ip address and port.
To that end, I've developed a java server on GAE to report my "remote" ip address and port. The problem is that on GAE I can get my ip address, but not my port. Without it, I'm unable to successfully punch the hole.
So, my question is what's the best, free method to find out my external IP address and port?
That's a question that has no answer with TCP.
Here's the problem: your "port" is not a fixed value. You don't have "an" external port. You typically get one dynamically assigned for each outbound connection.
As answers you should see from the test sites posted in another answer clearly indicate, it's a moving target (though it may stay stationary for a short time due to the browser using HTTP/1.1 keepalives and actually reusing the same connection, not just the same port)... but if you hit the site repeatedly, you'll see it either drift around randomly, or increment. Trying it from two different web browsers on the same machine, you'd never see the same port number -- the port corresponds to the specific source connection, not the machine sourcing the connection.
Sometimes, you may find that it's the same port number as the port your machine's stack opened for the outbound connection, but even when it is, it doesn't matter, because no traffic should be able to return to your machine on that port unless it is from the IP address and port of the machine to which you made the outbound connection. Any decent network address translating device would never accept traffic from another source IP address and/or port, other than the one you addressed in the outbound connection.
There is no standard, simple, predictable, reliable, or consistent way to punch a hole in TCP NAT and then exploit that hole for a peer-to-per connection. To the extent that such things are possible in a given NAT implementation, that is an implementation that is shoddy, broken, defective, and insecure.
See also: https://www.rfc-editor.org/rfc/rfc5128
Sounds like your app could use a STUN server to get its external address.
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.
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.