I want to deploy an application on mobile devices participating in a WiFi ad hoc network that improves information robustness. The primary task is pretty simple: Send data (may be of bigger size) from a node S (source) to node D (destination). Here is my sample topology:
--- N1 ---
/ | \
/ | \
S ----- N2 ----- N4 ----- D
\ | /
\ | /
--- N3 ---
By simply using TCP, I can set up a reliable communication channel from S over N2 and N4 to D. That's ok.
My problem now is: I want that N1 and N3 can also get (overhear) the messages sent by S, N2 and N4, but they don't need to get it reliably. You can think of it as a flow of packets. For example, S wants to send a packet to D. But this packet may be useful for N[1-4], too - and should therefore be stored.
This is of course possible by using the promiscuous WiFi mode on all nodes, but that would be an overkill - because it would mean that every node would have to parse all packets to see if they can store them.
A simple solution would be to send UDP packets:
S sends UDP broadcast packet with a time-to-live of 1 to N2 with additional information.
N1, N2 and N3 can receive and store the packet, but only N2 resends the information to N4.
This behaviour repeats itself until D gets the package.
But then I have to somehow reimplement TCP in terms of packet ordering, congestion control and reliable communication - which is bad.
So my question is: Do you know about a protocol which supports this behaviour?
I have done what you are saying, and there are a couple of ways to do it. Using linux is the easiest, and the only platform where I have actually implemented this.
On linux there are two ways you can do this.
1., use iptables and NQUEUE and pass received packets to an application process that do whatever you want with them. Use iptables rules to only pass up packets you are interested in, such as those with IP dst N2, N4 etc.
2. use libpcap, and link you program with this library and configure a capture filter to capture the packets you are interested in.
Related
I'm debugging an IOT protocol between two essentially black boxes on my local network talking over a telnet connection. On either end, I can specify the IP address and port. I'd like to observe / record the data exchanged between the client and server.
I'm thinking a proxy running on my Mac laptop might work. I've done some research and experimentation with nc (BSD netcat). I can only figure out a working one-way pipe, and thus the protocol exchange does not happen between A and B.
Telnet TCP server (A) <===============> TCP Client (B)
Telnet TCP server (A) <===\ /==> TCP Client (B)
\ /
\ /
Proxy/Intercept (C) *
Using a feature in the server device (A), I can have two telnet connections active. Using this, I've been able to see the server's (A) responses to whatever Client (B) is commanding, but I cannot see the Client (B) commands. ~80% of the responses are a code meaning invalid command received, but a few are reasonable responses for what this thing should be doing. I can also note that that data rate is only about 4 Bytes / second, so I'd be happy to just watch this exchange live in a terminal.
To clarify: I can power-cycle the client (B), and it will re-establish a socket connection to the IP address and port of my choosing, so I'm not really thinking about a sniffing / Wireshark type solution.
I guess I'm hoping for a relatively straightforward solution run in the shell using existing standard tools. I suppose a small program could be written in Python or something to do this, but I hope that's overkill.
Sorry, this is a basic question, but I was wondering what will happen in this case? Firstly, is the case below valid example?
Lets say I have 100 servers configured to be in same subnet. I want each of these servers to be able to communicate with one other. Let's say these servers are connected to some network switches. As an example --
---- Switch 4 --- Server 3
/ /
/ -------------/
--- Switch 3 /
/ /
/ /
Server1 -- Switch 1 -- Switch 2 -- Server 2.
Based on what I read online, if the servers are within the same subnet, then there is no routing involved. The packets from server 1 are sent over the ethernet interface which says it belongs to this subnet and at the ethernet transport layer, and the frames are sent with the destination Mac set.
So, for the above diagram, if Server 1 wants to send a packet to Server 3, then it will determine that the packet needs to be sent down the interface that is associated with Switch 1. When Switch 1 tries to decide where to forward the packet, it realizes that frames with this particular MAC address should be forwarded to Switch 3 (not switch 2). Switch 3 then forwards to Switch 4 and Switch 4 then delivers it to Server 3.
Furthermore, my understanding is that, at the layer 2, no sophisticated routing algorithm is used by Switch 1 to decide whether it should send to Switch 2 or Switch 3. It is based on a dumb MAC table that tells it whether it has ever seen this MAC or Switch 2 or 3 and forwards accordingly.
Is my understanding above correct? If so, then what I fail to understand is this --
How is the above MAC based routing within same subnet, any better than using a layer 3 routing protocol like OSPF or LSP that seems to be a lot more smarter about routing efficiently.
If no routing algorithms are used, how will it realize that it is better to go via Switch 2 to reach Server 3 than use Switch 3?
If no routing is present the path to the switch will be determine by its mac address. Server 3 must have 2 network cards (2 MACs' 2 IPS), one connected to switch4 and switch2. When you send a package you use the IP address, then an ARP broadcast will be made to get the MAC address of the device, once you have it then you create the packet with the appropriate headers (layer 2 Mac, layer3 IP).
If you have a routing protocol and instead of switches you have routers, different methods of cost can be taken into consideration to determine the fastest route. For example hoops and speed. You can even force the route via one path no mater what is the best one.
BONUS: If your switches have STP (spanning tree protocol) and have multiple connections between them, then they will determine the fastest route of connection between switches and have redundancy in case of one link fails. In this example the route may change on the diagram that you posted. But remember switches are connected between them with more than one connection 2 or more for each one of them.
Traceroute is an application to trace the path from A to B. (A is your location and B is the server you want to trace).
The basic algorithm is as follows:
send UDP with TTL = 1
Server A1 received, and return ICMP packet to A because TTL is expired.
--> know first machine between. For example A1.
send UDP with TTL = 2
Server A1 received, and send this UDP to server A2.
Server A2 received, and return ICMP packet to A because TTL is expired
--> know second machine between. In this example is A2.
Do it until to B. we can track down: A -> A1 -> A2 -> ... ->B
I have a doubt that makes me skeptical as to whether this algorithm works correctly.
Since routing tables are updated frequently, during a traceroute, say for TTL=3, the probe packet follows the path A1->A2->A3->A4.
Now, when we send a probe packet with TTL=4, is it guaranteed to pass through A1, A2, A3, and A4 and then onto A5?
If not? Does the final output represent a valid path?
Hope someone can shed some light on this issue. Thanks a lot in advance!
Now, when we send a probe packet with TTL=4, is it guaranteed to pass
through A1, A2, A3, and A4 and then onto A5?
No, it's not guaranteed, but it is likely in most real-world cases. In cases in which the TTL=4 packet doesn't travel along the same path as the previous packets, you'd end up with a result that doesn't accurately reflect the actual network topology:
You can reduce the chance of this happening by using Paris Traceroute, which is a traceroute implementation that fiddles with various IP & ICMP header fields (article) to increase the chances for all packets to travel along the same path.
One of the major factors that affect TCP performance in 802.11 ad hoc networks is the unfairness in the MAC. Could someone please illustrate for me what this "unfairness" means?
In ad hoc networks, you usually are trying to do multihop routing. 802.11 CSMA/CA can manifest the "exposed terminal problem" in these situations. Consider a linear topology
... A <---> T <---> B ...
A and B are not in CSMA range. Suppose T is already transmitting a data stream to A. Now suppose a TCP stream starts getting routed through B. Because B CSMAs with A, it will essentially be locked out of the channel. The TCP connection being routed through B will eventually timeout.
Another possibility is the "hidden terminal problem". Consider the topology
A ---> X <--- B
A and B cannot CSMA. Suppose A and B each try to send a TCP stream to X. Because they cannot CSMA with each other, both win their respective channel contention rounds and transmit, only to have their frames collide at X. This can be solved to some extent with RTS/CTS. But in general, the reason for poor TCP performance in wireless environments has to do with the fact that TCP uses a dropped packet as a congestion signal, i.e., a TCP source will cut its window and there by drop its throughput. In wireless networks, dropped packets can be due to any number of transient things (e.g., collision, interference). A TCP source misinterprets these packet drops as a congestion signal and will throttle its send rate and underutilize the channel.
Another problem that can arise is due to the "capture effect". Again, consider
A ----> X <-------------B
Both A and B are in range of X, but B is farther away and thus has a lower received signal strength at X. Again, A and B cannot CSMA. In this case, X may "capture" the stronger transmitter A, i.e., its radio will decode A's frames but consider B's as noise (even though in the absence of A, X would go right ahead and decode B's frames). This sets up an unfair advantage for A if both are trying to route a TCP stream through X.
802.11's DCF also favors the last winner of the channel contention round. As a result, this gives a slight advantage to long-lived, bulk TCP transfers.
Note that all these problems affect all transport protocols, not just TCP. It's just that the way TCP is designed makes it react particularly poorly to these scenarios.
I want wireless data transmission between microcontrollers. Of the three microcontrollers A,B and C , i need one to many connection in such a way that A have bidirectional communication with B and C but B and C need not communicate with each other. Will RF transcievers be helpful??
Yes, RF transceivers will be helpful implementing a wireless communications link. (I suppose you could use IR transceivers if your devices will have line of sight to each other.)
Are you asking how to direct the messages to the proper destination? If your data can be packetized then the answer is the same as for any other multi-drop network media. You add a header to the packet and put a destination address in the header. Nodes B and C may receive each other's transmissions but they will check the destination address, see that the message is addressed to A, and they will ignore those messages. Another possibility is that B and C could use different radio frequencies. Then they won't receive each other's transmissions. But in this case A will have to receive on two frequencies. Perhaps A could retune in order to communicate to the other node.
Update: If two of your devices transmit at the same time the transmissions may interfere and the receiver may not be able to receive either transmission. This issue is addressed with a channel access strategy. Here again, techniques used on wired networks also apply to wireless networks. One way to avoid collisions is for the transceiver to listen for a carrier signal or existing transmission before transmitting itself. This technique is called Carrier Sense Multiple Access (CSMA). If there is no signal then it is OK to transmit. But if their is an existing signal on the channel then the transceiver will hold off on its own transmission until the channel is clear. I'm familiar with the CC1101 transceiver and this functionality is built into the transceiver (although it may need to be enabled via configuration). Another way you could avoid collisions is with a master/slave or client/server communication strategy. For example, if B and C only transmit in response to requests from A then A can manage when each node transmits and ensure that two nodes don't transmit simultaneously. Other ways to avoid collisions include Time Division Multiple Access (TDMA) or Frequency Division Multiple Access (FDMA).