1

I've been playing around with IPv6 and setup a DigitalOcean droplet. The only difference between now and before is that I told it to setup IPv6. More often than not, when I run ifconfig the SSH session hangs, then disconnects due to unresponsiveness. The ifconfig command doesn't finish when this happens...it only gets past dumping the IPv6 details.

Any place I can check to debug this? My solution right now is just not to run ifconfig.

After reading the comments again, I realized that there is maybe a misinterpretation occurring. My command was only ifconfig to display network details, I'm not configuring anything with it so there are no extra details beyond that.

The tip that ifconfig isn't in use anymore is the most helpful thing so far. There is so much legacy crap on the net still, it is easy to pick up something antiquated.

  • 1
    Well you shouldn't run ifconfig anyway; it's obsolete for ten years and occasionally gives wrong information today. Use the corresponding ip commands instead. – Michael Hampton Jun 8 at 1:08
  • Good tip. I'll look into it – Brian Jun 8 at 1:43
  • 1
    In any strange situation run the tcpdump and write the capture into the file. Please clarify, do you have the local access or you mantain the server remotely? Use the gnu screen or the tmux if you doesn't have local access to keep user's processes running. – Anton Danilov Jun 8 at 5:23
  • This is pure remote with DigitalOcean. about 3 seconds after the session notices it is disconnected, it reconnects and I can open a new terminal. Good call on the screen, I'll look into your suggestions. – Brian Jun 8 at 11:48
2

That sounds like a MTU issue - perhaps the extra IPv6 addresses in the ifconfig output tipped the packet size over the MTU limit and the session hangs.

Does the hangup happen with any other long-listings? Perhaps when running top? Or when copying files to/from the host? Check the link, it explains what a MTU problem is and what you can do about it.

  • Thanks. apt-get upgrade works just fine, and so to other package installs. I'll keep this in mind. – Brian Jun 8 at 11:50
  • 1
    @Brian It would be a MTU between the instance and your laptop, i.e. anything that outputs data to a terminal. Try scp from the server to your laptop (in this direction, not the other way around). The apt-get upgrade takes a different path, that's not relevant. – KeepLearning Jun 9 at 23:17
  • Why would this be a different behavior? apt-get blasts a ton of stuff out to my terminal, same as what I would think ifconfig is doing. I'll try what you suggested though, though I think things have been pretty good. – Brian Jun 10 at 20:55
  • 1
    @Brian apt output is likely line-buffered and each line goes out in a separate (small) packet. OTOH ifconfig is simply buffered to as large blocks as possible and these don't fit in your path MTU. That's the difference. Sure, I can be wrong but unless you verify this theory with scp as suggested I can't really help you much more. – KeepLearning Jun 10 at 21:38
  • That is a fair assertion and something I can work with. Is scp more "raw" than sftp over that same connection? – Brian Jun 11 at 13:53
1

I don't know what exactly happens in your case, but I'll try to describe steps to troubleshoot this issue.

  • Check the logs of the ssh daemon. Increase the level of logging. Maybe it'll help to find the cause.
  • Don't use the ifconfig. It's deprecated. Otherwise extend the question and provide the complete command, that you run.
  • Use the gnu screen or the tmux. It keeps your programs running. Otherwise after disconnection the user session is closed and all programs in this session will be terminated. But they should be run to move forward to the solution.
  • In screen session run the ip monitor command. It shows most of changes and events in the network configuration. In the other screen console run your ifconfig command. What the ip monitor command has shown?
  • If the previous step doesn't help, run the tcpdump also under the screen. You can write the capture into the file with the -w option to open it later in the wireshark. Analyze the traffic capture in the wireshark. It requires some knowledge of the TCP, but it shouldn't be very complicated. Your first task in this step is determine what happens with your SSH connection.

I think the steps above will help you in most cases. Extend the answer and I'll try to help you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.