I'm writing a small TFTP client and server for class, and I have to send TFTP ERROR packets when things go wrong. Here is the TFTP RFC for reference.
So, error code 4 is "Illegal TFTP operation", in which cases would you send that ERROR packet?
For example, if the Server is listening on port 69 for RRQ/WRQ packets, but it instead receives a random DATA packet, should it send an ERROR (error code 4) packet in response?
Anything that does not follow the flow and semantics of the spec is "illegal". A packet with an unknown opcode, a packet with a malformed payload, or a packet that is out of sequence with the normal flow of commands/responses would all be considered "illegal". So an unexpected DATA packet for a non-existent transfer could be considered "illegal" and use error code 4, though error code 5 (Unknown Transfer ID) would be more appropriate.
Related
I am trying to understand the differences between NetScaler Monitor types HTTP-ECV and TCP-ECV and used case scenarios? I want to understand the rationale behind using these monitors since they both use the send string and expects a response from the server. When do one need to use TCP-ECV or HTTP-ECV?
Maybe you should begin by indentifying your needs before chosing monitor types. The description of these monitors is pretty self-descriptive.
tcp-ecv:
Specific parameters: send [””] - is the data that is sent to the service. The maximum permissible length of the string is 512 K bytes.
recv [””] - expected response from the service. The maximum
permissible length of the string is 128 K bytes.
Process: The Citrix
ADC appliance establishes a 3-way handshake with the monitor
destination. When the connection is established, the appliance uses
the send parameter to send specific data to the service and expects a
specific response through the receive parameter. Different servers
send different sizes of segments. However, the pattern must be within
16 TCP segments.
http-ecv:
Specific parameters: send [””] - HTTP data that is sent to the service; recv [””] - the
expected HTTP response data from the service
Process: The Citrix ADC appliance
establishes a 3-way handshake with the monitor destination. When the
connection is established, the appliance uses the send parameter to
send the HTTP data to the service and expects the HTTP response that
the receive parameter specifies. (HTTP body part without including
HTTP headers). Empty response data matches any response. Expected data
may be anywhere in the first 24K bytes of the HTTP body of the
response.
As for web service monitoring (is that's what you need?), if you try to ensure some HTTP headers is present in a response, then use tcp-ecv. For HTML body checks use http-ecv.
TCP-ECV - Layer 4 check - If you want to determine that a TCP port/socket is open and you are happy with the service being marked as up as a result of the completion of a TCP 3-way handshake and TCP send() data being sent expecting TCP recv() response then use the TCP-ECV. This is simply a TCP layer 4 check. It has no application awareness.
HTTP-ECV - Layer 5 check - If a simple TCP check is not enough and you want to send HTTP protocols message over the TCP connection once it is established then use the HTTP-ECV. This will send an HTTP protocol control message over the TCP connection and will wait for an HTTP response message back. Typically you would configure the response to expect a 200 OK as a success and a 404/503 as a failure.
I need to send SMS via smpp protocol.
I’m sending an MT message from an emse server to an esme client
My question is about the SMPP traffic and this error "vendor specific error" ... if it's due to a malformed packet smpp or I must refer to my SMPP provider? any explanation please ?
I attached a dump traffic on Wireshark for more details.link to pcap file
The packet is well formed and has no issue. Usually in these types of errors i would go and ask the provider for the exact meaning of the error since the error codes differ from a vendor to another.
However i did notice something odd in the trace, the IP: 10.10.32.66 did not send any enquire link through out the whole wireshark session.
I have an embedded jetty server(server1) which sends UDP packets as trigger to receive a message from another server(server2). server1 then waits for a message from server2. This message is then validated and processed further.
From testing the server1, I saw that some times server2 doesnot send messages on receiving a trigger from server1. So I tried analyzing it with Wireshark.
When I gave the capture filter as UDP, it is not showing any packets even though at the server1 I received some packets.
But when I gave the IP address of the server to which request is sent, it is showing some HTTP and TCP packets. What could be the reason?
The jetty server(server1) is using DatagramPacket for sending requests. Won't this be sent by UDP itself?
Is there any settings in Wireshark which is preventing from displaying UDP messages?
I’m writing a simple client-server app which for the time being will be for my own personal use. I’m using Winsock for the net communication. I have not done any networking for the last 10 years, so I am quite rusty. I’d like to use as little external code as possible, so I have written a home-made server discovery mechanism, as follows.
The client broadcasts a message containing the ‘name’ of a client UDP socket bound to an arbitrary port, which I will call the client’s discovery socket. The server recv() the broadcast and then sendto() the client discovery socket the ‘name’ of its listening socket. The client then uses this info to connect to the server (on a different socket). This mechanism should allow the server to bind its listening socket to the first port it can within the dynamic port range (49152-65535) and to the clients to discover where the server is and on which port it is listening.
The server part works fine: the server receives the broadcast messages and successfully sends its response.
On the client side the firewall log shows that the server’s response arrives to the machine and that it is addressed to the correct port (to the client’s discovery socket).
But the message never makes it to the client app. I’ve tried doing a recv() in blocking and non-blocking mode, and there is never any data available. ioctlsocket() always shows no data is available, even though I know the packet got it to the machine.
The server succeeds on doing a recv() on broadcasted data. But the client fails on doing a recv() of the server’s response which is addressed to its discovery socket.
The question is very vague: what gotchas should I watch for in this scenario? Why would recv() fail to get a packet which has actually arrived to the machine? The sockets are UDP, so the fact that they are not connected is irrelevant. Or is it?
Many thanks in advance.
The client broadcasts a message containing the ‘name’ of a client UDP socket bound to an arbitrary port, which I will call the client’s discovery socket.
The message doesn't need to contain anything. Just broadcast an empty message from the 'discovery socket'. recvfrom() will tell the server where it came from, and it can just reply directly.
The server recv() the broadcast and then sendto() the client discovery socket the ‘name’ of its listening socket.
Fair enough, although actually the server could just broadcast its own TCP listening port every 5 seconds or whatever.
On the client side the firewall log shows that the server’s response arrives to the machine and that it is addressed to the correct port (to the client’s discovery socket). But the message never makes it to the client app
If it got to the host it must get to the application. You must have got the ports mixed up somehow. Simplify it as above and retry.
Well, it was one of those stupid situations: Windows Firewall was active, besides the other firewall, and silently dropping packets. Deactivating it solved the problem.
But I still don’t understand how it works, as it was allowing the server to receive packets sent through broadcasting. And when I got at my wits end and set the server to answer back through a broadcast, THOSE packets got dropped.
Two days of frustration. I hope someone profits from my experience.
This morning, there were big problems at work because an SNMP trap didn't "go through" because SNMP is run over UDP. I remember from the networking class in college that UDP isn't guaranteed delivery like TCP/IP. And Wikipedia says that SNMP can be run over TCP/IP, but UDP is more common.
I get that some of the advantages of UDP over TCP/IP are speed, broadcasting, and multicasting. But it seems to me that guaranteed delivery is more important for network monitoring than broadcasting ability. Particularly when there are serious high-security needs. One of my coworkers told me that UDP packets are the first to be dropped when traffic gets heavy. That is yet another reason to prefer TCP/IP over UDP for network monitoring (IMO).
So why does SNMP use UDP? I can't figure it out and can't find a good reason on Google either.
UDP is actually expected to work better than TCP in lossy networks (or congested networks). TCP is far better at transferring large quantities of data, but when the network fails it's more likely that UDP will get through. (in fact, I recently did a study testing this and it found that SNMP over UDP succeeded far better than SNMP over TCP in lossy networks when the UDP timeout was set properly). Generally, TCP starts behaving poorly at about 5% packet loss and becomes completely useless at 33% (ish) and UDP will still succeed (eventually).
So the right thing to do, as always, is pick the right tool for the right job. If you're doing routine monitoring of lots of data, you might consider TCP. But be prepared to fall back to UDP for fixing problems. Most stacks these days can actually use both TCP and UDP.
As for sending TRAPs, yes TRAPs are unreliable because they're not acknowledged. However, SNMP INFORMs are an acknowledged version of a SNMP TRAP. Thus if you want to know that the notification receiver got the message, please use INFORMs. Note that TCP does not solve this problem as it only provides layer 3 level notification that the message was received. There is no assurance that the notification receiver actually got it. SNMP INFORMs do application level acknowledgement and are much more trustworthy than assuming a TCP ack indicates they got it.
If systems sent SNMP traps via TCP they could block waiting for the packets to be ACKed if there was a problem getting the traffic to the receiver. If a lot of traps were generated, it could use up the available sockets on the system and the system would lock up. With UDP that is not an issue because it is stateless. A similar problem took out BitBucket in January although it was syslog protocol rather than SNMP--basically, they were inadvertently using syslog over TCP due to a configuration error, the syslog server went down, and all of the servers locked up waiting for the syslog server to ACK their packets. If SNMP traps were sent over TCP, a similar problem could occur.
http://blog.bitbucket.org/2012/01/12/follow-up-on-our-downtime-last-week/
Check out O'Reilly's writings on SNMP: https://library.oreilly.com/book/9780596008406/essential-snmp/18.xhtml
One advantage of using UDP for SNMP traps is that you can direct UDP to a broadcast address, and then field them with multiple management stations on that subnet.
The use of traps with SNMP is considered unreliable. You really should not be relying on traps.
SNMP was designed to be used as a request/response protocol. The protocol details are simple (hence the name, "simple network management protocol"). And UDP is a very simple transport. Try implementing TCP on your basic agent - it's considerably more complex than a simple agent coded using UDP.
SNMP get/getnext operations have a retry mechanism - if a response is not received within timeout then the same request is sent up to a maximum number of tries.
Usually, when you're doing SNMP, you're on a company network, you're not doing this over the long haul. UDP can be more efficient. Let's look at (a gross oversimplification of) the conversation via TCP, then via UDP...
TCP version:
client sends SYN to server
server sends SYN/ACK to client
client sends ACK to server - socket is now established
client sends DATA to server
server sends ACK to client
server sends RESPONSE to client
client sends ACK to server
client sends FIN to server
server sends FIN/ACK to client
client sends ACK to server - socket is torn down
UDP version:
client sends request to server
server sends response to client
generally, the UDP version succeeds since it's on the same subnet, or not far away (i.e. on the company network).
However, if there is a problem with either the initial request or the response, it's up to the app to decide. A. can we get by with a missed packet? if so, who cares, just move on. B. do we need to make sure the message is sent? simple, just redo the whole thing... client sends request to server, server sends response to client. The application can provide a number just in case the recipient of the message receives both messages, he knows it's really the same message being sent again.
This same technique is why DNS is done over UDP. It's much lighter weight and generally it works the first time because you are supposed to be near your DNS resolver.