SYN-ACK not received
On a standard TCP connection between server and client, I have this issue: the SYN-ACK is not received from the client, while it is sent from the server. I could see this on Wireshark from both server and client.
Using a different TCP client (eg. telnet) from the client PC, the SYN-ACK is received, and the connection works. Also changing router works with the first client.
I'm not sure, but the main difference between the two clients is the SYN request. In the first case, it has a len=0
in Wireshark, while the len is not zero using telnet.
Is there a way I can use any router with the server (java) and first client, written in C# (maybe changing some options)?
Edit: the server and the client are on two different networks, and I could check both. There is no firewall between. That len=0
in the SYN is the only thing I'm worried about. I don't think this could be allowed.
networking router tcp wireshark sockets
add a comment |
On a standard TCP connection between server and client, I have this issue: the SYN-ACK is not received from the client, while it is sent from the server. I could see this on Wireshark from both server and client.
Using a different TCP client (eg. telnet) from the client PC, the SYN-ACK is received, and the connection works. Also changing router works with the first client.
I'm not sure, but the main difference between the two clients is the SYN request. In the first case, it has a len=0
in Wireshark, while the len is not zero using telnet.
Is there a way I can use any router with the server (java) and first client, written in C# (maybe changing some options)?
Edit: the server and the client are on two different networks, and I could check both. There is no firewall between. That len=0
in the SYN is the only thing I'm worried about. I don't think this could be allowed.
networking router tcp wireshark sockets
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about thatlen=0
in the SYN I read on Wireshark (question edited to add this informations).
– Fra H
Dec 18 '13 at 8:29
1
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35
add a comment |
On a standard TCP connection between server and client, I have this issue: the SYN-ACK is not received from the client, while it is sent from the server. I could see this on Wireshark from both server and client.
Using a different TCP client (eg. telnet) from the client PC, the SYN-ACK is received, and the connection works. Also changing router works with the first client.
I'm not sure, but the main difference between the two clients is the SYN request. In the first case, it has a len=0
in Wireshark, while the len is not zero using telnet.
Is there a way I can use any router with the server (java) and first client, written in C# (maybe changing some options)?
Edit: the server and the client are on two different networks, and I could check both. There is no firewall between. That len=0
in the SYN is the only thing I'm worried about. I don't think this could be allowed.
networking router tcp wireshark sockets
On a standard TCP connection between server and client, I have this issue: the SYN-ACK is not received from the client, while it is sent from the server. I could see this on Wireshark from both server and client.
Using a different TCP client (eg. telnet) from the client PC, the SYN-ACK is received, and the connection works. Also changing router works with the first client.
I'm not sure, but the main difference between the two clients is the SYN request. In the first case, it has a len=0
in Wireshark, while the len is not zero using telnet.
Is there a way I can use any router with the server (java) and first client, written in C# (maybe changing some options)?
Edit: the server and the client are on two different networks, and I could check both. There is no firewall between. That len=0
in the SYN is the only thing I'm worried about. I don't think this could be allowed.
networking router tcp wireshark sockets
networking router tcp wireshark sockets
edited Dec 18 '13 at 8:32
Fra H
asked Dec 17 '13 at 14:27
Fra HFra H
11614
11614
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about thatlen=0
in the SYN I read on Wireshark (question edited to add this informations).
– Fra H
Dec 18 '13 at 8:29
1
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35
add a comment |
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about thatlen=0
in the SYN I read on Wireshark (question edited to add this informations).
– Fra H
Dec 18 '13 at 8:29
1
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about that
len=0
in the SYN I read on Wireshark (question edited to add this informations).– Fra H
Dec 18 '13 at 8:29
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about that
len=0
in the SYN I read on Wireshark (question edited to add this informations).– Fra H
Dec 18 '13 at 8:29
1
1
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35
add a comment |
1 Answer
1
active
oldest
votes
It's hard to say what LEN field you're reading without seeing the actual capture. Wireshark may have switched dissectors at some point and you're now reading the length of something other than what you expect.
I wouldn't get too deep in the weeds doing a protocol trace when you're trying to write an application. If you can connect via telnet, the network layers are working and the problem is most likely in your code.
Try creating another app that simplifies the equation to nothing but a socket and see if that can connect. Even if it doesn't send/receive useful content, any connection at all is progress.
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f689611%2fsyn-ack-not-received%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
It's hard to say what LEN field you're reading without seeing the actual capture. Wireshark may have switched dissectors at some point and you're now reading the length of something other than what you expect.
I wouldn't get too deep in the weeds doing a protocol trace when you're trying to write an application. If you can connect via telnet, the network layers are working and the problem is most likely in your code.
Try creating another app that simplifies the equation to nothing but a socket and see if that can connect. Even if it doesn't send/receive useful content, any connection at all is progress.
add a comment |
It's hard to say what LEN field you're reading without seeing the actual capture. Wireshark may have switched dissectors at some point and you're now reading the length of something other than what you expect.
I wouldn't get too deep in the weeds doing a protocol trace when you're trying to write an application. If you can connect via telnet, the network layers are working and the problem is most likely in your code.
Try creating another app that simplifies the equation to nothing but a socket and see if that can connect. Even if it doesn't send/receive useful content, any connection at all is progress.
add a comment |
It's hard to say what LEN field you're reading without seeing the actual capture. Wireshark may have switched dissectors at some point and you're now reading the length of something other than what you expect.
I wouldn't get too deep in the weeds doing a protocol trace when you're trying to write an application. If you can connect via telnet, the network layers are working and the problem is most likely in your code.
Try creating another app that simplifies the equation to nothing but a socket and see if that can connect. Even if it doesn't send/receive useful content, any connection at all is progress.
It's hard to say what LEN field you're reading without seeing the actual capture. Wireshark may have switched dissectors at some point and you're now reading the length of something other than what you expect.
I wouldn't get too deep in the weeds doing a protocol trace when you're trying to write an application. If you can connect via telnet, the network layers are working and the problem is most likely in your code.
Try creating another app that simplifies the equation to nothing but a socket and see if that can connect. Even if it doesn't send/receive useful content, any connection at all is progress.
answered Jan 13 '14 at 18:54
BowlesCRBowlesCR
2,527818
2,527818
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f689611%2fsyn-ack-not-received%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
first off, why do you think your router is involved? is the server on your network and the client elsewhere? your firewall logs are a good place to start then. The .Net sockets library isolates everything related to the underlying connection (tcp implementation details like handshakes) from the coder, so there shouldn't be any options you would need to tweak. .Net is concerned with the network streams, not the packets themselves. if you are concerned about your client, post over at stackoverflow.
– Frank Thomas
Dec 17 '13 at 15:08
Thank you. The server and the client are in two different networks, but I could check both. There is no firewall from both sides. I'm concerned about that
len=0
in the SYN I read on Wireshark (question edited to add this informations).– Fra H
Dec 18 '13 at 8:29
1
I guess part of my point is, instead of going to wireshark to see the bad traffic, just focus on why your app framework is not able to connect correctly. chasing packet traces may ultimately give you SOME understanding of whats going on and may eventually become needed, but for now, I’d focus on the code since you are getting different results from different client runtimes, rather than why you have a 0kb response. the best you can hope for from wireshark (for this issue) is determining where a firewall is getting in the way.
– Frank Thomas
Dec 18 '13 at 13:05
Could you post a screenshot or transcript of the len=0 SYN segment?
– artistoex
Jan 13 '14 at 17:35