I am developing an Ethernet connected embedded system. The embedded system's network stack is limited, I do not want to use TCP/IP.
The IP address of the embedded system can be configured by the user and there is scope for that IP address to be forgotten by the user. I'm looking for a simple method for discovering that IP address. The embedded system does not have a display.
I can guarantee that the embedded system and PC performing the discovery are on the same local network. There may be a ethernet switch between the two devices, but no router. However, it is possible that the embedded system will have been configured with an IP address from a completely different subnet.
My plan is to send a UDP broadcast to the network. The embedded system receives this and will respond with its serial number and currently configured IP address. I have successfully got the UDP broadcast to the embedded system, but I am struggling with the source IP address for the response sent by the embedded system.
Even if the destination IP address, destination MAC address and source MAC address are correct (non-broadcast), if the source IP address is from a different subnet, the UDP packet isn't received by the PC (It isn't shown in Wireshark on Windows 10). An illustration of what I'm trying to do is below:
Is it possible to use something else for the source address (possibly the network address)?
I'm wondering if there are any other approaches to this problem?
I'm looking for a solution that does not require any special user permissions on the PC and ideally can be programmed in C#.
Related
I want to develop an Android app that connects with a Windows desktop application via TCP/IP.
However I have very little knowledge of networking and so please forgive me if this is a very basic doubt.
My Windows based laptop as well as Android phone are connected to the internet via the same WiFi router.
Now I checked the IP address for my laptop as well as phone using a website.
Both are same!
If both have the same IP address, then to achieve networking between these devices I will choose different set of port numbers.
Will this connection work?
Is the connection happening via the internet or just locally on my
router?
EDIT: After reading the answer from #Doon, I have broadened my question.
Let's say the local address of laptop is 192.168.1.10 and that of phone is 192.168.1.20.
If I code my application to use these IP addresses, it should work as it is a local network.
But what if I want my laptop to connect with another phone which is not connected to the WiFi router, rather by 3G network.
Then which IP address should be used for the laptop and the other phone?
Since I am not allowed to use any other server, I am going to use port forwarding i.e. the user will type in the IP address displayed on the other device. The connection could be initiated on either one of the devices.
If you could also show how to do this programmatically, it would be very helpful.
My Windows application is developed in C++ using Qt.
All of your devices are sharing 1 external or WAN IP address using NAPT (network address port translation). Internally on your LAN each device has its own address. So yes it will work but you are going to need to use internal addrss and the devices actual IP address not its perceived address via an external service.
As for the connection locally or via router that all depends on where you are connecting to. If both end points are on your lan or on the same Subnet then the router will not be involved. So in the average home network between your phone and desktop both connected to the same network say via wifi then they are most likely layer 2 adjacent (see the OSI 7 layer model for more info on layer 2 vs layer 3). But once they are not on the same network then routing will be involved and your router will be used. If the phone is connected to 3G or the cell data network and you want it to talk to your desktop on your home network you are going to need to deal with port forwarding on your router and other such fun things.
In regards to updates. Once you leave the local network it gets more complicated especially with IPv4 as address are running out so there is more and more use of nat or IPv6 with 6 to 4 gateways. Do you want the laptop to initiate connect to the phone or phone to the laptop? But normally you will need to iterate your address on your interfaces. Then connect with an external service to get your external IP address and compare and see if they are the same. if both endpoints are dynamically assigned you will need some sort of location mechanism could be dynamic DNS could be locator service etc.
I recently found that packets are encapsulated within ethernet frames. Packets use IP addresses, frames use MAC addresses.
Why aren't IP addresses used in ethernet frames for routing? I understand that when trying to access a basic website, the computer goes to a DNS to find the IP address relevant to the user-entered domain name. How do computers find the correct MAC address?
Really, how are MAC addresses used in routing internet traffic?
Thanks
IP packets aren't always encapsulated in Ethernet frames. There are other physical media such as ISDN, etc. When packets are routed, IP addresses are used to determine the next hop and the physical address is used to physically identify the interface serving as the next hop. Only the former (determining next-hop) is usually called routing.
To answer your second part, MAC addresses are discovered through ARP (Address Resolution Protocol) in IPv4 & ND6 (Neighbor Discovery) in IPv6.
Update:
The destination IP address in the IP header is the final destination. In the process of routing (at each hop), you get the next hop's IP address to (eventually) reach the final destination from the routing table (this could be a default gateway's IP address). To send the packet to the next hop, you need its MAC address. While hopping through intermediate links, the IP address in the IP header don't change - only the MAC addresses change.
Bit late but still here is my answer :) ...
To send data you need two address, the MAC address and the IP address.
Basically the sending host will ARP for a MAC address, this occurs when the local host doesn't know the MAC address of the host it has an IP address for or it will ARP for the default gateway MAC address (if it doesn't already know it) if the IP address in on a different subnet/ network. Once it obtains a MAC address the IP packet is encapsulated in a L2 frame and sent across the media. If the IP packet is meant for a host on a different subnet/ network, it will be sent to the default gateway, this router will de-encapsulate the L2 frame (remove and discard it) check the IP address and will forward it. For the router to do this it needs a MAC address to send it over the media, It will look up the next hop in it's routing table, encapsulate the IP packet with the same source and destination IP address that was sent from the original host into a new L2 frame. This time the MAC address for the source address will be that of the forwarding interface of the router, and the receiving interface of the next hop will be the destination MAC address. This will continue from hop to hop until it reaches the final host, each time the MAC addresses will change, but the original IP address will remain the same.
Here's the key point -- there can be more types of packets than INTERNET traffic. You could be using IPX, which is non-routable. How do clients identify each other? By the MAC address.
Routing != Addressing, which is really where the MAC comes into play.
In order to be routed, the OSI model adds a layer to allow for path discovery to the next gateway. This layer is responsible for routing, but knows nothing about the MAC address.
As a side note, at the hardware level, MAC addresses ARE used by switches, but not for routing. From How Stuff Works:
The switch gets the first packet of data from Node A. It reads the MAC
address and saves it to the lookup table for Segment A. The switch now
knows where to find Node A anytime a packet is addressed to it. This
process is called learning.
In this way, a switch can make sure that traffic is only outputted to the correct port. This isn't accomplishing routing so much as reducing network congestion. Only broadcasts and traffic destined specifically for that MAC address should be sent out the port.
Recently I have been thinking about the same and came upon this question. Here is my answer to this question. Actually MAC address is needed for correctly sending the packet to right destination. This is specially true when packet is needed to sent over a VLAN. There can be multiple switches/routes connected on that VLAN over multiple physical interfaces. However IP Routing is unaware of these physical interface. It only knows about the logical connectivity. For example, route 10.10.10.0/24 is reachable via VE/VIF0.10(logical VLAN interface) and/or nexthop neighbor is 20.20.20.1. There could be multiple interfaces under VLAN 10. Then to which interface packet is sent out? This is where ARP comes in the picture. ARP helps to discover the MAC address associated with the next-hop IP address. When switch/router learns the nexthop MAC. along with that it learns the physical interface also via which that MAC is reachable. Hence while routing packet, firstly MAC corresponding to the destination IP is searched and then the physical interface associated with that MAC is searched. Finally packet is sent out via that physical interface. The MAC corresponding to that destination IP is used as destination MAC. In absence of this, routed packets will always be flooded in the outgoing VLAN.
Hope this helps.
Thanks.
Answer: MAC addresses are not used in the process of routing of a packet.
segment -> transport layer (TCP ports)
packets -> network layer (IP addresses)
frame -> data link layer (MAC addresses)
bits -> physical layer (electric/optical signals)
Create your own packet/segment visit http://wirefloss.com/wireit/
There are 2 models (TCP/IP and ISO/OSI)
In detail:
Your app has some data. This is encapsulated by mentioned layers. Encapsulation means that a header with fields is added at each layer. If your data never leave the local network the MAC address will be the same. Once your data needs to be delivered outside your network the frame header is stripped by router and is replaced by router fields.
UPDATE 2021: Some people seems never heard of ISO OSI model and put this answer as incorrect.
I have a network, consisting 4 PCs. All PCs are connected to a hub.
One of these PCs has two network interfaces which one of them is connected to the hub. and the other one in connected to the internet.
How can i configure this PC to sniff in the internal hub network, and capture all pockets and send them to the specific destination on internet? (I do not what this PC to change the source address of packets just destination address to the remote machine on the internet! so that when the packet arrived at the remote machine, it contains the address of one of other 3 PCs as the source)
IS it possible at all?
I'm not sure to understand exactly what you want, but if you want to access an external network from your 3 pc, you should set the pc with two cards as the default gateway. On the pc with two cards you should also setup some kind of masquerading. However, at the destination point you'll never have the exact source address, but the addres of the pc doing the nat/pat translation.
Do I understand correctly you want to "spy" the other computer? If you're on the same network, you can try to use Wireshark to capture all traffic going over a router.
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.