Re: still seeking, is anyone have a shell server I can use for a test?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



As expressed many many many times, our goals never required such debugging.
Further none of the ideas below apply.
thanks all, I believe we have what we needed from this thread.



On Wed, 8 Aug 2018, Linux for blind general discussion wrote:

Thanks, Birdie.

I failed in my attempt to debug with Karen.

Janina

Linux for blind general discussion writes:
Hi,

To me this subject starts sounding more like debugging communications problems than providing simple shell access using ssh.

First of all if something doesn't work it would be good if you draw a picture of the communications path. You need to know what devices there are and which protocols and ports are allowed on the path. Is there address translation used (NAT) on that path? If there is NAT where and how is it used?

Now the thing is that ISPs usually restrict traffic. Quite often they use NAT if they provide the router for you. Specially so if the connection is for household use. The same applies for most connections that I know for SMB use. Even enterprise connections may filter ports and protocols. This could also be done at the ISP end.

If you try making a connection to an arbitrary port it might very well be that it is your ISP banning the traffic. Even well known ports might get blocked. It could also be your firewall or router restricting the permitted ports and protocols. It could be your host routing table. It could be your host firewall. It could be your code which doesn't work as expected. It could be something else which didn't come to my mind.

If you want to be scientific you need to be systematic. Try these steps:
a) Check your host routing table
b) Check your host firewall
c) Use a traffic analyzer on your host (tcpdump would do)
d) Use a traffic analyzer on all the links and devices between the communications endpoints
e) Document all the steps, changes, everything you do.

Please remember to repeat the same code and arguments when checking the next segment. Don't change anything (code, parameters, ports, etc) without documenting first! There must be a sound reason for every change. Don't assume, analyze.

All this could be called systematic fault finding. Don't worry, even professional sysadmins are not always familiar with doing things systematically. This needs to be taught, learned and practised.

My two cents,
Birdie


On August 7, 2018 6:10:31 PM UTC, Linux for blind general discussion <blinux-list@xxxxxxxxxx> wrote:
Just so.  no exchange took place whatsoever.
While I am certain Janina's structure works for others, it is not
suitable
for the small tests  we wish to perform, generating atypical errors
from
the  ones we even expected laughs.
We are moving on making her comments unimportant to our goals.

Karen



On Tue, 7 Aug 2018, Linux for blind general discussion wrote:

Since Karen mentions me by name, let me simply note there's no
evidence
in my logs that she ever reached my machine.

I also provided ssh over a high port that she also never reached.


Best,

Janina

Linux for blind general discussion writes:
Hi folks,
I am still seeking a simple, based on the testing needs  of the
engineers
working with me here  server if possible.
Granted I have already tested a couple of examples, but suppose I
desire
being a touch more scientific.
So, again if anyone has or can suggest a server using alternative
port
settings than 22 for ssh, let  me know off list.
Janina's server times out according to -v information.
Our agency is pressed for time to find a solution, which may end up
being
hostgator for our accounts  in the end.
Thanks,
Karen



_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list

--

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative
(WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list



_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list

_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list

--

Janina Sajka

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa

_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list



_______________________________________________
Blinux-list mailing list
Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list



[Index of Archives]     [Linux Speakup]     [Fedora]     [Linux Kernel]     [Yosemite News]     [Big List of Linux Books]