fischertechnik community forum

Hi Torsten,

Thank you, I'll change it.

On the cfw wireless: I experienced something strange. When I started the controller I got the message "ssh: connect to host 10.0.0.134 port 22: No route to host". Then I checked the WLAN in the menu and found it had received a DHCP address: 10.0.0.202. Pressing on the address menu, it still listed 10.0.0.134 as static, which is correct but it was not connected. So I entered the WLAN password again but still could not login. I could login using the ..202 and found this worked, but I want the 134 address. I decided to cycle power and see: now the 134 address is used and I can login normally.

Is this somehow known behaviour?

hvn

It seems switching dynamically between static and dhcp setups doesn't work properly. Someone needs to have a look at that. But good that it now works for you after a reboot.

I just reviewed the code of the network app and I think we just need to restart the Interface after changing the settings.

Raphael

Another detail I noticed: although the password is set for the ftc user, after trying to login I had 3 occasions (on 2 different computers) where I had to confirm the ssh connection on the controller, despite the host verification being ok. A 2nd attempt on the same computer goes without confirmation being asked.

Thats normal. When you click "OK", the computer is allowed until shutdown.

Raphael

Previously, when I used the older cfw and after setting the password, I didn't have to OK each first time after power-on. So something has changed....

You are mixing up two things:

• netreq: Firewall. Allow / Deny connections from devices to all services (SSH/HTTP/VNC/ROBOPro...)
• PAM: User Athentification. Allow / Deny login if no passoword is set

I think previously you had no password so you needed to click OK each time you login (netreq was introduces for 0.9.3) and now you have a password so you just need to allow the computer after every power on (ntreq is active and PAM is inactive)

Raphael

I know those are 2 different things, and I probably didn't express it entirely correct. When I login, 2 events happen. An ssh connection is set up and a login is performed.
When the ssh connection is set up now, first time after power-on, I have to confirm the connection on the controller. With the older cfw, this confirmation was necessary only once: right after the very first time connecting from that device. I just tested this again: after power-on it asks ssh connection confirmation showing the requester IP address. So as I see it, something has changed in the cfw storing the ssh information.
The login after that works fine, since the password is set.

So this is a pure ssh issue you are facing? Once you run a new cfw version on your txt new ssh keys are generated. It might be that your PC thinks someone is spoofing something and thus refuses to use the new key. Under linux i need to explicitely throw away old keys. Dunno how windows tools handle this.

MasterOfGizmo hat geschrieben:Once you run a new cfw version on your txt new ssh keys are generated.

Only if /etc is deleted. /etc is only deleted if you delete it manually. @Richard When upgrading from 0.9.x to 0.9.3 /etc will be migrated?

Raphael

ski7777 hat geschrieben: @Richard When upgrading from 0.9.x to 0.9.3 /etc will be migrated?

Yes, when upgrading from 0.9.2 simple layout to 0.9.3, /etc (and /home/ftc as well) will be migrated.