I want to design a system which reduces travel time of packet what is happening, in reality, am I send an SYN bit from the client side, this bit travel through the router then to server and server reply SYN+ACK which also travel through the router to the client.
So I just want something else like what if the client sends SYN to router, router then send this to server and copy this packet modify SYN to SYN+ACK and send back to client before server can send after server send this SYN+ACK to router, router just accept it(see it as the reply is coming) and discard it.
To achieve above goal, I design a setup in which I have one laptop which sends and receive packet from two ethernet interface and other one is desktop which acts as router(packets are coming and it only forward it to its destination) I set up the routing table from both side and enable the IP forwarding on desktop(which act as router).
All are working fine, on a laptop I have server and client program which send the packet and receive it but the problem is that I want to send the packets to from where it was coming (to source itself) so I modify the packet on routing side using Netfilter module, copy the entire skb(using skb_copy) and interchange its ip source and destination(I did this on NF_INET_PREROUTING) and also interchange the port number but the packet always goes to destination.
What other modification do I need to be done to send the packet to its source itself?
Before all, you have to deal here with some details.
First, on SYN-ACK packet, the server sends its sequence. So if in the router you modify the packet and send back to client, what will be your sequence? It's should be the same like the server will send and the server did not send anything yet.
Second, in the handshake there are several agreements like MSS, SACK enabled etc. So you can't to it on behalf of server.
About the question itself, you should do it in PRE_ROUTING, change the IP addresses and ports, and fix the checksum of both IP and TCP.
Related
I am studying X-MAC in multihop sensor network. I am using AODV as a routing protocol. During run time, at the beginning, I can see that the sensor node starts sending preambles before any route discovery. So, until any route is established these preambles are sent for nothing.
I also studied the same network with csma/ca, in which the route is established first and then the node initiate transmission.
As per suggestions given in OmNET++ group, I tried the following, but it did not resolve the issue.
**.useHelloMessages = true
Would anyone please advice how to configure X-MAC so that when the simulation starts, a node will first establish a route and then it will send preambles for data communication?
Thank you.
At the start of the simulation, there are no routes. So when one of the nodes have some data to send (they contain a TCP app that generates a TCP packet, for example), the AODV initiates route discovery to the destination of the data (the TCP packet).
Aodv does this route discovery by sending an Aodv route request message (AodvRreq). The message indicates that the node wants to discover a route to the destination of the data.
Aodv is implemented as an app in INET, and it sends its route request (and other) messages encapsulated in UDP packets.
The packets (aodv or data) go down the protocol stack to the XMAC for transmission.
So, from the point of view of the XMAC, the Aodv route request message (which is triggered by the node wanting to send TCP data) is itself treated as data (since it uses UDP). In order to send data, the XMAC first sends preambles.
(Answer edited for more details)
I'm building a distributed system and I would like asynchronous send and recv from both sides with blocking after high water mark.
PUSH/PULL sockets works great, but I wasn't able to bind a PUSH socket. Meaning I can't have a client-PUSH to server-PULL and a server-PUSH to client-PULL, if the client is behind a firewall, since the server can't connect to the client.
In the book, the following is written, but I can't find an example of it.
"REQ to DEALER: you could in theory do this, but it would break if you added a second REQ because DEALER has no way of sending a reply to the original peer. Thus the REQ socket would get confused, and/or return messages meant for another client." http://zguide.zeromq.org/php:chapter3
I only need a one-to-one connection, so this would in theory work for me.
My question is, what is the best practice to obtain asynchronous send and recv with ZeroMQ without dropping packets?
Most ZeroMQ sockets can both bind (listen on a specific port, acting as a server) and connect (acting as a client). It is usually not related to the data flow. See the guide for more info.
Try to bind on your servers PUSH socket and connect from your clients PULL socket.
As my knowledge, in normal behavior, client will make random port to connect the SNMP service port, now the client use SNMP trap port (162) to communicate with server.
My questions:
As the client setting, I do not have configure any SNMP setting for the client, why WireShark able to capture SNMP traffic came from the client?
Why the client use SNMP trap port (162) to communicate with server, rather than using random port?
SNMP is usually transmitted over UDP, so there is actually no "connection", and speaking technically the source port doesn't matter. You can just send out datagrams (e.g. traps) without binding to a port.
However, even when run over UDP, SNMP does involve some two-way communication. If you are expecting a response (which a client does if it's sending an SNMP Get or Set request), the only place the other end knows to send it is back where the request came from, i.e. the original IP/port combination. There's no information in a SNMP packet that provides any alternative "return address" information.
So, in order to get a response on a predictable port, you'll send the request datagram from a bound socket. Typically the client will run its own listening "server" on port 162, send requests from there, and then it can receive responses there too. Otherwise you wouldn't see the responses. This also allows us to set up simple firewall rules (though you can often get away without firewall rules for the return path, due to hole punching*).
This is also true for the server, which emits traps and informs on a known, standard, predictable port not only so that you can configure your trap receiver and firewalls in a reliable way, but so that inform responses can be sent back to a known, standard, predictable port that you're listening on.
tl;dr: You can send your requests from an arbitrary port if you like, but it's not very useful.
* My SNMP implementation seemed buggy when the client/receiver only saw traps emitted during the ~15 minutes after it had last poked out some kind of request packet. Subsequent traps seemed to be completely missing. After much debugging on the server end, it turned out that we'd forgotten to open the correct port on the inbound firewall for the client, and were accidentally relying on hole punching, which has a time limit. :D
As for why Wireshark is seeing traffic from an unconfigured SNMP client, well, either your SNMP client actually is configured to send requests, or you're misinterpreting the results. Wireshark doesn't invent traffic. Without a more complete picture of your network setup, software setup, and those packets you're seeing, we could only speculate as to the exact cause of your confusion.
I write a HTTP small server under Windows. Access to the server is secured with the usual HTTP auth mechanisms (I use Windows HTTP API). But I want to have no auth for localhost, i.e. local users should be able to access the server without password.
The question is: is that save? More precisely, is it safe to trust the remote address of a TCP connection without further auth?
Assume for a moment that an adversary (Charly) is trying to send a single malicious HTTP GET to my server. Furthermore, assume that all Windows/router firewalls ingress checks for localhost addresses let source addresses of 127.0.0.1 and [::1] pass.
So the remote address could be spoofed, but for a TCP connection we need a full three-way handshake. Thus, a SYN-ACK is sent by Windows upon reception of the SYN. This SYN-ACK goes nowhere, but Charly might just send an ACK shortly afterwards. This ACK would be accepted if the ack'ed SEQ of the SYN-ACK was correct. Afterwards, Charly can send the malicious payload since he knows the correct TCP SEQ and ACK numbers.
So all security hinges on the unpredicability of Windows' TCP outgoing initial sequence number (ISN). I'm not sure how secure that is, how hard it is to predict next session's ISN.
Any insight is appreciated.
In the scenario you are describing an attacker wouldn't get any packets from your web server. If you can use something like digest auth (where a server sends to a client a short random nonce string first and then clients uses that nonce to create an authentication hash) you'd be fine.
If installing a firewall on a system is an option, you could use a simple rule like "don't accept packets with source ip 127.0.0.1 from any interface other then loopback".
I developed a chat server using websocket in cowboy, but I want to know if the message sent by server to client success.How can I know?
Websocket is a rather thin abstraction layer on top of a conventional TCP socket. After the initial handshake the difference is minimal. So, the question is: how do I know if a data chunk was received by the remote peer? The short answer: only if the peer acknowledges it explicitly by the means of application-level protocol. Remote client will send TCP ACK packets for every data packet you will send it, but this fact is well hidden from the application for good reasons. Receiving ACK packet only means that remote TCP stack has dealt with it, but says nothing about how (and if) the client application has processed it.
Add a special "acknowledge receive" message type to your chat protocol. Include a monotonically increasing sequence number in all of your outgoing messages, and include the SN of the received message in the ACK message to know exactly how much data the client has already processed.