2

I am having an issue where I cannot view/edit the contents of a file that is larger than a few lines of text/code. When I use nano to open a file the system hangs after displaying: "[Read N lines]" and the only thing I can do is kill/restart the ssh session.

text editor output in cmder

I have tried multiple text editors (nano, vi, vim) and ssh clients (cmnder, putty) with the same result. I have also verified that the files are in unix format.

Is there a workaround to be able to read/edit larger files in the ssh session?

Improve this question
3
  • 2
    There is something funky going on, shouldn't need a "workaround". Would check ssh logs or journalctl and see if you see anything. – Chad G Apr 30 '19 at 15:21
  • 1
    Might be filesystem or memory problems. Does dmesg show any problems? What do you have your memory split set to? – evildemonic Apr 30 '19 at 16:20
  • If the problem is with one file, perhaps it's corrupted. Try creating a new file using that editor from the ssh screen, and see if you still encounter problems. Also, try a different ssh client. – user96931 Apr 30 '19 at 20:27
1

I found that the issue ended up being due to the network connection that I was using to ssh into the pi. Originally I had connected the rapsbperry pi to an Ethernet switch, and connected my laptop to the wireless router that the Ethernet switch was connected to. In this configuration my ssh sessions were hanging whenever I ran a command or opened a file that was more than a few lines of data. It is also worth noting that this wireless router is at my work and I do not have access to the router/firewall settings. However I am confident that there is a packet fragmentation issue that is occurring when sending data between the wired and wireless connections (reference example).

To verify this I connected my laptop directly to the the wired network and the issue was resolved. As an additional check I connected a second wireless router that does not directly use our firewall and had no issues with the ssh session. I have narrowed down the root cause to be one of two potential issues:

  1. mismatch in mtu settings when sending data packets from WAN to LAN interfaces through our firewall.
  2. the network firewall does not allow packet fragmentation when using a WAN to LAN connection.
Improve this answer

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.