I developed a web app that communicate with an external API in REST.
Most of the time I have no problem, but a few times (1 or 2 times a day) I have my request which is timed out although the message I send is correct.
By analyzing with Wireshark, here is the error I get when a request is timed out : [TCP Retransmission][TCP Port numbers reused]
There's an error to upload an image, so you'll find the screenshot of Wireshark here : https://imgur.com/yj2TZ4l
The problem occurs on several of my client workstations with different public IP addresses. The API itself has the same IP address.
Can you help me please ?
Related
I have a client Server configuration with one connection, the server cannot process the requests received in parallel, it processes them in series, to overcome this problem, we developed a proxy server (installed between client and server) to receive request open connection with the server ==> send request server ==> send response to the client ==> close connection.
The problem we have is this, the response is sent divided on 2 part, we did a TCPDUMP on the port, we see that the request is sent devised on two part one with a length 1 and the second with à length 33
We don't know if it's a configuration on the server or on the network
Can some one help us ?
i am having an application running inside a gateway,
this application is a coap-server coded using the libcoap library
the server is running perfectly fine, the ip:port is tested using different commands such as nmap , telnet and others, each time it shows that the port is open and the connection is a success.
My problem is that there's no response from the server, wireshark is showing that the requests are being re-transmitted until timeout.
After some research, i thought that the gateway doesn't support NAT loopback, so i tried sending requests from another connection (i used my phones 4G). I even disabled firewall on the gateway too, But no success either.
UPDATE:
after some digging, i managed to receive a response from the server, but only when using TCP connection, the UDP still sends requests until timeout,
from a logical point of view, what may be the problem here ?
note: UDP is a must in this application so i cant just ignore it.
I am using Camel Netty for full duplex communication over TCP socket.
My application is using the following parameters in the route.
<inOut uri="netty:tcp://{{IP-Port}}?
textline=true&sync=true&decoderMaxLineLength=1000000&autoAppendDelimiter=false&disconnect=false&producerPoolMaxActive=-1&producerPoolMinEvictableIdle=120000&keepAlive=false&noReplyLogLevel=INFO&serverExceptionCaughtLogLevel=INFO&requestTimeout=2500" />
The netty component above receives requests from a preceding wiretap in the flow.
During the day after about 8-10 hours, some of the connections show as ESTABLISHED state but will not be serving any requests. Even at the server end, these connections show as ESTABLISHED but there is no activity for hours.
When we looked at one connection closely, found that the last request attempted (not been received by server) was writing body to endpoint and got an exception org.apache.camel.processor.DefaultErrorHandler - Failed delivery for (MessageId: xxxxx on ExchangeId: ID-xxxx). On delivery attempt: 0
Since netty is being called from wiretap, after this last request, succeeding requests are not even entertained and they are blocked in wiretap itself..
I am collecting tcpdump later tonight for more details though.
Questions:
1. Why is producerPoolMinEvictable NOT kicking in to clear such stale connections?
2. How do we clear these stale connections automatically without having to
bounce the application?
3. Is there a problem using wiretap?
Appreciate suggestions to resolve this issue. Please ask for any more details needed to answer and I shall be happy to share.
Note:
camel-netty
2.11.2-
I got a bounce message today from a client. In the bounce notice it shows:
The error that the other server returned was:
554-Service unavailable; Client host [mail-io0-f178.google.com] blocked using
554-Barracuda Reputation;
554 http://www.barracudanetworks.com/reputation/?r=1&ip=38.116.199.194
And further down where it shows the original message it says
Received: from Macbook-Pro-Retina.local ([38.116.199.194])
The above is a blocked Russian IP Address. Normally the source of my messages shows:
Received: from Macbook-Pro-Retina.local
(CPE0016cbc430da-CMf0f249004a80.cpe.net.cable.rogers.com. [174.119.**.**])
The 174.119 is my normal external IP address and shows in the source of any message I send. Also I use Google apps for all my mail so its going through their server.
So the question is, is the bounce message a result of an issue on my local machine or does it have to do with the client's server?
38.116.199.194 IP address is part of a 38.0.0.0 - 38.255.255.255 range allocated to Cogent (ARIN WHOIS). A part of this range, 38.116.198.0/23 subnet is operated by MaRS Discovery District.
It appears that your computer was connected to the MaRS Discovery District's network when you sent the email. Maybe you were using their Wifi at the time or maybe some (malicious) software on your machine was routing traffic via that network unbeknownst to you.
I have configured Windows Live Mail for my Gmail account. It uses IMAP for incoming and SMTP for outgoing mail. I collected packets recvd/sent by the application over a period of 4 hours using Netmon. I observed that the server every now or then sends a TLS packet of TCP payload length 39. I decrypted the packet and it contains:
* 554 EXISTS
Can anyone tell me what is going on?
I found the answer: The server is basically saying it has 554 messages. Each message is assigned a unique identifier. I have told Live Mail to check for new mail every 5 minutes and I indeed see see this packet every 5 minutes.