Putty

Als putty vanzelf stopt, dan heeft de server waar je verbinding mee probeert te leggen, de verbinding verbroken. Mogelijk staan de instellingen van de verbinding niet goed.

Het is misschien handig om te weten met wat voor server je verbinding probeert te leggen en met welk protocol.

[Bericht gewijzigd door maartenbakker op zondag 14 juni 2020 14:45:03 (25%)

Putty voert helemaal geen commando's uit, en wacht ook niet op antwoorden van een server. Met Putty kun je wel een ssh connectie maken met een server, waarbij je ascii tekst kunt sturen, en ook kunt ontvangen. Gewoon dom doorsturen dus. Verder wat maarten zegt.

Een beetje extra info is handig.

Welk teken naar wat voor module over wat voor een verbidning (SSH, telnet, ... )

Verder wat bovenstaande heren zeggen, putty verbreekt niets, tenzij de andere kant de verbinding dropt.

Het gaat over het ESP bordje uit z'n andere topic. M.i. kan het daar best bij, maar ok.

Het is al lang geen ESP bordje meer maar een WifiBee V1r1. Ik kan het bedienen met de app op de smartphone, maar niet met Putty.
Ik vul in: IP en poort en als Connection type 'Raw'. Dat heeft altijd gewerkt.

Je zult eerst moeten uitzoeken welk protocol er wordt gebruikt. Zodra het bordje een welcome message verstuurd, "Hello" in dit geval, verwacht het een bericht terug. Klopt die respons niet met de verwachting, of treedt er een timeout op, dan wordt de verbinding weer verbroken.
Heb je de code die in die module zit? Daar zou je het protocol uit kunnen afleiden.

Je weet in ieder geval dat de verbinding goed is. Anders kon je die tekst "Hello" niet ontvangen. De eerste test is dus al geslaagd

Op deze site staat e.e.a. uitgelegd:
https://wiki.dfrobot.com/WiFi_Bee_V1.0__SKU_TEL0067_

Sniffing op het netwerk is altijd een mogelijkheid, bv. met tcpdump.
Ik wil er altijd wel eens naar komen kijken, overigens, misschien kan ik dan zelfs nog iets meenemen ook
Overigens is de eerste opmerking helemaal correct en terzake: putty voert helemaal niks uit. Het klinkt ernaar dat de module iets binnenkrijgt waar ze geen weg mee kan en dus de connectie verbreekt. Zonder verder inzicht in de "module" valt er niet veel te zeggen.

[Bericht gewijzigd door big_fat_mama op zondag 14 juni 2020 17:37:10 (43%)

Op 14 juni 2020 16:32:30 schreef Evarist:
Het is al lang geen ESP bordje meer maar een WifiBee V1r1. Ik kan het bedienen met de app op de smartphone, maar niet met Putty.
Ik vul in: IP en poort en als Connection type 'Raw'. Dat heeft altijd gewerkt.

Blijkbaar moet je met telnet met het ding babbelen:

- Type telnet ip port like: telnet 192.168.0.177 2000

- Type $$$ quickly to enter the command mode

In putty kan men zeer wel instellen dat er een telnet-sessie dient opgezet.

Zodra er 'Hello' wordt getoond moet je snel, voor de timeout, $$$ typen. De module komt dan in command mode.

Op 14 juni 2020 17:47:34 schreef big_fat_mama:
In putty kan men zeer wel instellen dat er een telnet-sessie dient opgezet.

Uiteraard kun je telnetten met putty, maar Evarist gebruikte RAW.

Nu hoeft dat het probleem niet perce te zijn, maar het is in ieder geval anders dan de instructies omschrijven.

Op 14 juni 2020 18:18:08 schreef Sine:
Uiteraard kun je telnetten met putty, maar Evarist gebruikte RAW.

Dat zal in de context van putty toch wel heel erg op telnet lijken? Telnet heeft formeel nog een paar "settings" dingen die doorgegeven kunnen worden. Dat wil je hier niet, dus "raw tcpip" is precies wat je wil.

@Rew. Telnet en Raw geeft geen verschil.

@Hennep. Deze functie doe ik met de WIFIBEE in een USB module. Het is alleen nodig om de module te programmeren.
De link die je aanhaalt gaat over de oude module, de Roving. Ik heb de nieuwe versie.

Ik moest bij het instellen deze functie ingeven: set comm idle 5.
Ik meen me niet te herinneren dat ik dat bij de oude module moest doen. Daarom heb ik de waarde op 0 gezet en nu verbreekt de verbinding niet meer!!
Bij de app op de telefoon moet ik telkens terug inloggen. Vroeger was dat niet, dus dat zal nu ook wel verholpen zijn.

Een probleem dat ik vroeger niet had. Putty wil een CR alvorens hij de commando doorgeeft. Ik vind niet hoe ik dat wijzig. Iemand?

Dat zal ook iets van de bee zijn, putty wacht niet op CR

Bij SmarTTY stelt zich dat probleem niet.

Ik had gisteravond ook een probleem om met putty te verbinden met de raspberry (via SSH over wifi).

Iemand had de raspberry geupdate en daardoor was er nieuwe security nodig.

Dus ook putty (aan de client kant, Win10) moest over naar de laatste versie (0.73) om het weer goed te krijgen.

Ik had trouwens wel een vrij duidelijke foutmelding. Iets over mislukte security negotiations.

Ik heb vorige week ook een rpi geupdate en geen wifi connectie probleem gehad met een Putty die er al jaren op staat.

Dat is een algemene tendens, niet specifiek noch voor de Raspi noch voor Putty. In het kader van de algehele jacht op security worden steeds veeleisender versies van ssh en sshd de wereld ingestuurd. Het is al een paar jaar aan de gang.
De foutmeldingen die er komen zijn soms erg duidelijk, soms ook niet, soms komen er helemaal geen. Op Unix-achtigen is het altijd nuttig om eens rond te kijken in de os-logs, meestal in /var/log, soms in /var/sys.

[Bericht gewijzigd door big_fat_mama op dinsdag 16 juni 2020 16:02:22 (31%)

D'r zijn deze week een paar updates mbt encryptie. Vluchtig gelezen: er zijn encryptie/hash methodes die niet meer gebruikt zouden moeten worden: niet meer veilig.

Veel langer is al het advies om DSA niet meer te gebruiken. Zelfde reden. En eens in de zoveel tijd zeggen ze dan: je hebt nu genoeg tijd gehad om een veiligere methode te kiezen en dan "MOET" je ineens om.

Allemaal niet zo relevant als je over je eigen LAN (wifi of niet) naar je pi zit te verbinden. Maar dezelfde putty en SSH worden gebruikt door de bank-systeembeheerder die effe over het internet wat moet regelen. En als dan de boel ongemerkt onveilig is geworden kunnen ineens veel centjes aan de wandel gaan...

Helemaal akkoord, @rew. Enkel ter illustratie: dit gebeurt als ik vanuit een redelijk recente Linux ssh opzet naar een "legacy" virtuele SuSE:

root@wiske:~# ssh virt_bbx
Unable to negotiate with 192.168.0.101 port 22: no matching cipher found. Their offer: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc@lysator.liu.se

Zeg ik er dan bij dat een van die antieke "deprecated" ciphers moet gebruikt worden dan connecteert het netjes:

root@wiske:~# ssh -c aes256-cbc virt_bbx
root@virt_bbx's password: 

(en ja, ik werk "gewoon" als root - sudo is voor sissies!! )

Ik gebruik wel gewoon sudo als ik niet lokaal inlog. "sudo bash"

(dat doet hetzelfde als "su -")

[Bericht gewijzigd door maartenbakker op woensdag 17 juni 2020 03:15:43 (21%)