How to simulate TCP sync attack in ns2? Please provide some guidelines that how to simulate this DOS Attack in ns2 ?
Tcp sync attack can be generated by using AQM & DOS simulation plateform.
Related
I have the following problem with "Mikrotik RB3011UIAS-RM!
I downloaded the application form "Mikrotik"website BTest and run some test with it. The test with tcp protocol was successful but when I try to do a test with udp I get the message "disconnected" and this one shows only when i am sending info to it!
Here is is the picture and the result that
Btest
reruns
If the only thing you're changing between the TCP bandwidth test and the UDP bandwidth test is the protocol, verify that there are no firewall rules blocking UDP from port 2000 and up.
You could try adding a rule explicitly allowing UDP 2000 to 3000, which should be good for a bunch of tests since RouterOS allocates UDP ports as needed.
Please note that port UDP/2000 is the default and may be configured differently on your system.
You could also try to decrease the Local Tx Size in case the packets are unable to be delivered due to excessive size for your network.
-Rich Alloway (RogueWave)
I have recently developed a GPRS communication software using Arduino (embedded application) and GSM modem to communicate to/fro from web server. However I found that there is enough delay and request getting dropped (response timeout) while receiving a response from server at client side.
The techniques I have tried are - TCP / UDP / HTTPS / HTTP.
In my case our requirement is for a Reliable, Fast, Guarantee Communication between client and server.
Please let me know which communication stack would establish the same or rather be best to be used?
Thanks in advance
GPRS gives you direct IP access to the Internet. If you're losing packets or suffering large delays when sending packets to your server then this sounds like a problem with the mobile ISP.
As Ken mentioned GPRS will provide you IP connectivity to the internet (or some private network if applicable).
On top of IP you can choose to use a number of higher layer protocols, the two most common of which are probably UDP and TCP.
UDP is 'connectionless' and provides very little in the way of error detection/correction etc.
TCP is connection orientated (which means that some signalling happens back and forth to establish a virtual 'connection' first). It also includes mechanisms to provide error detection, error correction and correct packet delivery order. TCP also includes flow control, to avoid the sender overloading the receiver, and congestion control to avoid network overload.
There is a perception that UDP is faster than TCP, but I think it depends on the situation - take a look at this discussion for some further discussion on speed, reliability etc between UDP and TCP (go down through all the high scored answers):
UDP vs TCP, how much faster is it?
For your requirements, I would think a solution based on TCP/IP is probably what you want.
Whether you want to use HTTP or some other protocol on top of that is going to be dependent on your solution, and to some extent on personal preference.
I have gone through various udp based P2P Technology like Stun . I have implemented UDP/TCP hole punching recently for implementing p2p.
I found there are other technology as for like ICE,UPnP and teredo
Can any body tell me what is the difference between these technology.
Which one is the latest technology/protocol used for P2P in recent year.
It will good If any can provide comparative analysis on various UDP based P2P protocols.
Any link or suggestion will appreciated.
ICE stands for Interactive Connectivity Establishment. It is a protocol for NAT traversal (i.e., punching holes) supported by the IETF. There has been several reviews and evolutions of the RFC. Some may find the specifications overkill in general or unclear when it comes to performing TCP NAT traversal.
UPnP is a technology helping local devices finding each other and start communicating automatically. It implements IGD for NAT traversal, which allows remote configuration of the NAT/Router (when possible) to redirect WAN traffic to the device. Unfortunately, this method is a huge threat to security, since any application could hijack NATs/routers to let any undesirable traffic come in.
Teredo is not really related to P2P or NAT traveral. If you have an IPv6 device A on a ipv4 LAN (for example), it won't be able to connect using ipv6 to a remote ipv6 enabled device B located on the WAN. Teredo allows A to communicate with B with ipv6 by transporting ipv6 over ipv4. Teredo is massaging the frictions between ipv4 and ipv6, so to speak.
None of these technologies is 'dominating' P2P for now. It is still a boiling environment.
I am a newbie in network related aspects. I have few basic questions related to tcp/ip protocol and network
If a network switch (in a LAN network) between two PC's running Client and server (that are communicating through async. sockets) is powered down. Can the client and server will be notified that the socket connection is no longer active. Client and server are running on Win XP OS and are coded using C#.
Does network topology play a role in case of half open connection between socket client and socket server. For e.g. Will a disconnect status of either one or both be notified to other end and does it depend on network topology.
Thanks in advance.
A network element such as a router/hub/switch does not activly cause anything anything to happen on the TCP layer if it goes down. The operating system might notice that the physical layer is down and error out all sockets bound on that network card if it's a network element directly connected to the PCs that breaks - this will vary among operating systems/network cards and other things. Other than that, in order to detect that the connection has been severed, you'll have to send something and rely on the TCP timeout mechanisms to error out. This can be done implicittly by enabling TCP Keepalives on the connection.
A disconnect on one side will only be noticed if those messages reach the other side, if the network topology changes or sometinhg breaks in the middle of the connection in such a way that messages no longer reach the other end, a disconnect won't be noticed. (NAT gateways are a big source of problems such as this, they might time out a TCP connection they're tracking and you'll never know the connection is no longer valid unless you try to write something (or enable TCP keepalives) to the connection). Note that most networking APIs require that you Read from the connection to discovver that a the other end has closed the connection - assuming those "close" messages actually reach your side.
In Rails what would be the best way of integrating a UDP listening process that updated certain elements of the model (specifically its going to be adding rows to one of the tables).
The simple answer seems to be start a thread with the UDP socket object within the same process, but its not clear quite where I should even do that which fits with the rails way. Is there a neat way to start listening to UDP? Specifically I'd love to be able to write a UDPController and have a particular method called on each Datagram message. Ideally I would want to avoid using HTTP over UDP (as it would waste some of what in this case is very precious space) but I am fully in control of the message format so I can provide Rails with any information it would need.
Rails is a web application framework, not a server daemon framework. Unless you know of a web server that passes UDP packets, I imagine you would have to write and run a separate process and either have it talk to your Rails app via HTTP or just manipulate the database directly.
Let me make a pitch for TCP. UDP is a "throw the packet to the wind" protocol which provides no reliability. It finds uses in, for example, voice over IP where the odd dropped packet is acceptable. By using a TCP socket, you can still avoiding using HTTP, plus TCP stack will handle retries & etc. for you.
A TCP server which is launched by inetd is the simplest thing in the world: you write a program that reads from stdin and writes to stdout, then tell inetd to run that program whenever requests come in on a certain port. You won't have to write any network code.
Here's a simple inetd tcp server:
#!/usr/bin/ruby1.8
input = gets
puts "You said: #{input}"
Here's how to tell inetd to run it:
1024 stream tcp nowait wconrad /tmp/tcpserver.rb
This means to listen for tcp connections on port 1024. When they occur, launch /tmp/tcpserver.rb as user wconrad. man inetd.conf for more information.
You can test it with telnet:
$ telnet localhost 1024
Trying 127.0.0.1...
Connected to ceres.
Escape character is '^]'.
Howdy!
You said: Howdy!
Connection closed by foreign host.
$
Or you can use a simple client:
$ cat /tmp/tcpclient.rb
#!/usr/bin/ruby1.8
require 'socket'
t = TCPSocket.new('localhost', 1024)
t.puts "Hello"
t.close_write
puts t.read
t.close
$ /tmp/tcpclient.rb
You said: Hello
and just to show that tcp servers in Ruby are easy:
!/usr/bin/ruby1.8
require 'socket'
def handle_session(socket)
s = socket.gets
socket.puts "You said: #{s}"
socket.close
end
server = TCPServer.new('localhost', 1024)
while (session = server.accept)
Thread.new do
handle_session(session)
end
end
With TCP being so easy, you need a compelling reason to bother with UDP.