Tag Info

Hot answers tagged

61

You can find a good summary here: What is the difference between UDP and TCP internet protocols? Both TCP and UDP work at transport layer TCP/IP model, but have very different usage. The most important differences are: Reliability: TCP: connection-oriented UDP: connectionless Ordered: TCP: order of message receipt is guaranteed UDP: order is not ...


38

And the CEO level explanation: UDP is when you throw your paper in the general direction of the bin. TCP is when it misses, you throw exact copies of the same paper again and again until it falls into the bin. There would be paper wastage, even resent TCP packets result in wastage of network or system resources.


21

Web servers work with the HTTP (and HTTPS) protocol which is TCP based. As a general rule, if people neglect to specify whether they mean TCP/UDP/SomethingElse then they probably mean TCP.


19

It uses TCP. It would be difficult to run it on UDP without the guarantee of packets arriving. If the packets don't arrive, the encrypted data will not be decipherable.


19

HTTPS can run over any reliable stream transport protocol. Normally that's TCP, but it could also be SCTP. It is NOT expected to run over UDP, which is an unreliable datagram protocol (in fact, while that's not its official name, that's a good way to remember what it is). The IANA assignment for UDP is historical; at the time, nearly every protocol was ...


19

The diagram on Wikipedia is horrible. Hopefully what I'm about to write is clearer. The maximum payload in 802.3 ethernet is 1500 bytes. This is the data you're trying to send out over the wire (and what the MTU is referring to). [payload] <- 1500 Bytes The payload is encapsulated in an Ethernet Frame (which adds the Source/Destination MAC, VLAN tag, ...


17

Linux auditing can help. It will at least locate users and processes making datagram network connections. UDP packets are datagrams. First, install the auditd framework on your platform and ensure that auditctl -l returns something, even if it says that no rules are defined. Then, add a rule to watch the system call socket() and tag it for easy finding ...


17

You can't be sure that they really physically arrive at once. The Data link layers below TCP/UDP might split your packet up if they want to. Especially if you send data over the internet or any networks outside of your control it's hard to predict that. But no matter if the data arrives in one packet or multiple packets at the receiver. The OS should ...


17

can TCP packets arrive to receiver by pieces? Yes. IP supports fragmentation, though TCP generally tries to determine the path MTU and keep its packets smaller than that for performance reasons. Fragmentation increases the datagram loss rate catastrophically. If a path has a 10% packet loss rate, fragmenting a datagram into two packets makes the ...


15

The type of packet that is sent differs depending on the implementation. By default Windows tracert uses ICMP and both Mac OS X and Linux traceroute use UDP. I don't have BSD or Solaris machines or any other OS on hand to check but the man page for the Mac OS X version mentions its provenance is BSD 4.3. The Mac and Linux versions I have offer the ability ...


15

You can use netcat - just start it, and type something inside, and pres the return key. nc -u <host> <port> And on the other side you can listen with netcat too (you should see the written text), or just start a tcpdump, and see packets coming in.


13

You can use netstat, but you need the right flags, and it only works if the process that is sending the data is still alive. It won't find the traces of something that came briefly to life, sent UDP traffic, then went away. It also requires local root privileges. That said: Here's me starting an ncat on my local host, sending UDP traffic to port 2345 on ...


12

In our instance, our problem was solved by sysctl parameters, one different from Maciej. Please note that I do not speak for the OP (buecking), I came on this post due to the problem being related by the basic detail (no multicast traffic in userland). We have an application that reads data sent to four multicast addresses, and a unique port per multicast ...


12

You are probably looking for RFC 6056 - Recommendations for Transport-Protocol Port Randomization ("Best Current Practice"). Technically there is no requirement that the ephemeral port be >1024 or random (you could build a system that always initiates connections from port 12 because you like the number 12), it's just not "normal" to do so (and an awful ...


12

The startup performance of a TCP connection is dictated by the round trip time, and every phase of the handshake takes one half of that. The more delay, the worse the initial performance of the connection. If TCP could be securely and safely completed in a one-way handshake, it would be, because that would be faster. So, it is 3-way not because there is ...


12

ARP Connection oriented or connectionless? Connectionless - it's just a request and a response (or a broadcast just letting everyone know about something). It uses TCP It doesn't use TCP - TCP is a layer 4 protocol, whereas ARP is glue between layers 2 and 3.


11

You can't rely on UDP to deliver packets in order because the specification doesn't provide those guarantees. Even assuming the most ideal situation, a single piece of ethernet cable between two hosts, there is still the matter of the OS, the network stack, the NIC driver, and the libc implementation that your writing against. At every step in that chain, ...


11

HTTP (1.0 without connection keep alive) is connectionless because once a single HTTP request is serviced, the connection is closed and not reused. HTTP requests are not TCP protocol data units, so that TCP is connection-oriented with respect to TCP protocol data units doesn't stop HTTP from being connectionless with respect to HTTP protocol data units. ...


11

Create a new chain which will accept any TCP and UDP packets, and jump to that chain from the individual IP/port permissive rules: iptables -N ACCEPT_TCP_UDP iptables -A ACCEPT_TCP_UDP -p tcp -j ACCEPT iptables -A ACCEPT_TCP_UDP -p udp -j ACCEPT iptables -A zone_lan_forward -d 1.2.3.0/24 -j ACCEPT_TCP_UDP This adds the overhead of a few extra lines, but ...


10

This can occur if you create a socket, but never connect() or bind() with it. Your best bet may be to strace (-fF) the application, and then cross-reference with the output of lsof to determine which sockets are causing the issue. As a bonus method of debugging: if you wrap your socket calls with debugging information and write them out to /dev/null, it'll ...


10

To quote the nc man page: -l Used to specify that nc should listen for an incoming connection rather than initiate a connection to a remote host. It is an error to use this option in conjunction with the -p, -s, or -z options. Additionally, any timeouts specified with the -w option are ignored. The key here is that -p cannot be combined ...


9

Try iperf An article that explains the different steps: http://taosecurity.blogspot.com/2006/09/generating-multicast-traffic.html


9

I think that you may be looking for Mosh, the Mobile Shell


9

You can use netcat or nc. It supports TCP and UDP. Use the -u for UDP sockets. You can read man nc for more details.


8

You need to use netcat instead, telnet only supports tcp. Something like this will work: $ nc -u localhost 48772 netcat is installed by default on most modern linux machines (assuming that's what you have). Also for completeness sake I want to point out that there's another tool called socat which describes itself as 'netcat++'. Might be a good thing ...


8

How to do what you asked: With CentOS your firewall is controlled by IPTables / netfilter. Although you could add a rule to block UDP port 5353 traffic with (and traditional state rules): iptables -A INPUT -p udp -m udp --dport 5353 -m state --state NEW -j DROP Why you shouldn't do what you asked: However, I believe that PCI compliance requires that your ...


8

This is very simple with iptables: I'll assume your INPUT chain has no default DROP rule at the end, or you'll have to work around that: # Allow DNS (53) from <source IP> iptables -A INPUT -p udp --dport 53 -s <source IP> -j ACCEPT iptables -A INPUT -p tcp --dport 53 -s <source IP> -j ACCEPT # Deny all other DNS requests iptables -A ...


7

By definition, if a UDP packet is dropped, the receiver cannot sent a notice back to the sender because nothing was received. You can layer your own acknowledgement system on top of UDP. Even a simple "if no data has been received in X seconds, send a packet to the sender indicating such". You can embed your own sequence numbers into the UDP packets, so that ...


7

Based on the image of your capture, it looks like a DOS and not a DDOS since the originating ip address is the same. It looks like they're trying to connect to UDP port 17 (QOTD - http://en.wikipedia.org/wiki/QOTD), if I'm reading the capture correctly, which I might not be since I've never used tcpdump. How about starting out by blocking just that ip ...



Only top voted, non community-wiki answers of a minimum length are eligible