I'm working on an iMX23 cpu with linux-2.6.35.3 and wondering if this is even possible to implement.
I can build g_serial and g_multi and use the serial port function, which uses /dev/ttyGS0.
Do I just have to change [console=ttyS0] to [console=ttyGS0] on the kernel command line?
Thanks
Yes, it should be that simple. Just change your kernel command line to "console=ttyGS0,115200" or similar. You'll find it even works with usb ports ie "console=ttyUSB0" for example.
It seems you can easily add another console port just by adding another setting in [/etc/inittab]
::respawn:/sbin/getty -L ttyAM0 115200 vt100
::respawn:/sbin/getty -L ttyGS0 115200 vt100
Adding another line as above will enable you to use USB serial as console too(/dev/ttyGS0).
Related
I am trying to run a series of commands to configure a vlan on a Dell EMC OS10 server using Paramiko. However I am running into a rather frustrating problem.
I want to run the following
# configure terminal
(config)# interface vlan 3
(conf-if-vl-3)# description VLAN-TEST
(conf-if-vl-3)# end
However, I can't seem to figure out how to achieve this with paramiko.SSHClient().
When I try to use sshclient.exec_command("show vlan") it works great, it runs this command and exits. However, I don't know how to run more than one command with a single exec_command.
If I run sshclient.exec_command("configure") to access the configuration shell, the command completes and I believe the channel is closed, since my next command sshclient.exec_command("interface vlan ...") is not successful since the switch is no longer in configure mode.
If there is a way to establish a persistent channel with exec_command that would be ideal.
Instead I have resorted to a function as follows
chan = sshClient.invoke_shell()
chan.send("configure\n")
chan.send("interface vlan 3\n")
chan.send("description VLAN_TEST\n")
chan.send("end\n")
Oddly, this works when I run it from a Python terminal one command at a time.
However, when I call this function from my Python main, it fails. Perhaps the channel is closed too soon when it goes out of scope from the function call?
Please advise if there is a more reasonable way to do this
Regarding sending commands to the configure mode started with SSHClient.exec_commmand, see:
Execute (sub)commands in secondary shell/command on SSH server in Python Paramiko
Though it's quite common that "devices" do not support the "exec" channel at all:
Executing command using Paramiko exec_command on device is not working
Regarding your problem with invoke_shell, it's quite possible that the server needs some time to get ready for the next command.
Quick-and-dirty solution is to "sleep" shortly between the individual send calls.
Better solution to is to wait for command prompt before sending the next command.
I know there are a bunch of blogs explaining how to set up the wifi headless on the raspberry pi. I have followed them and they worked, once. But I had to format the sd card, and re-do it and it doesn't connect to the WiFi anymore.
I use the RPI Imager to write the OS. (Note I've also tried with the advanced option pressing Ctrl + Shift + 10, and set up the wifi, ssh over like this. After writing it, the verification returned an error that couldn't create a FAT32 partition).
Then I created a blank ssh file inside the sd card (boot) to allow the ssh connection.
Then I created the wpa_supplicant.conf file containing this:
country=CZ
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
network={
ssid="NETWORK-NAME"
psk="NETWORK-PASSWORD"
}
Then I eject the sd card, insert it in the raspberry pi and it doesn't connect to the wifi.
I know that the Raspberry pi, and the wifi connector work well. So it must be something that I'm misssing.
I'm honestly desperate at this point since I have spent more than 10 hours just trying to connect to the WiFi. I have formated and re-installed the Raspberri-OS a bunch of times already, and tried as many tutorials as I could find.
There's not really a single universal answer to your question, so at the risk of telling you a bunch of things you already tried, here's my exhaustive list of stuff to try/consider:
If you're using Ubuntu you probably have to use netplan - see here for some instructions https://askubuntu.com/questions/1143287/how-to-setup-of-raspberry-pi-3-onboard-wifi-for-ubuntu-server-with-netplan
Don't forget your key_mgmt field (use the value relevant to your wifi):
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=CA
network={
ssid="NETWORK_SSID"
psk="PSWD"
key_mgmt=WPA-PSK
}
If you can ssh into with a wired connection, and are using Raspian, you may find using raspi-config easier (sudo raspi-config, then System Options > S1 Wireless LAN).
Now we get into the "I already checked that five times" part of the list:
a)if you're using Ubuntu/netplan, ensure you're using the correct interface id by doing ifconfig - should be wlan0, but you never know
b)ensure you have your SSID correct - you can do sudo iw wlan0 scan to find all the networks in reach and double check the SSID. Watch out for weird quotation marks (e.g. 'smart' quotes), elongated dashes and stray spaces - in particular if you have pasted the SSID and password from elsewhere
c) ensure your SSID, password and key setting is correct by checking a different device
d) ensure you are looking for the right IP address on your LAN - you can do a sudo nmap -sn 192.168.1.0/24 and your Pi devices should show up looking like:
Nmap scan report for 192.168.1.68
Host is up (0.00044s latency).
MAC Address: B8:27:EB:8B:73:AD (Raspberry Pi Foundation)
Remember that if using DHCP, your Wifi and Wired connections will get different IP addresses - if using static for Wired, you'll also likely get a DHCP address for your wireless interface.
If you keep failing using the same Raspian image, try something different, just to isolate the problem - e.g. try Ubuntu if you keep failing with Buster (or vice versa)
Finally, some more general advice about what to do when you're just so frustrated with a problem that you've spent way too much time on - write out a 'proof' of why what you're trying to do is impossible, explaining line by line how you've done exactly the steps that are supposed to work. This is my method of last resort, and currently has a 100% success rate - when I try to explain why the thing is impossible, I realize what I didn't do, overlooked, or did wrong.
Actually, I solved this by following this blog https://weworkweplay.com/play/automatically-connect-a-raspberry-pi-to-a-wifi-network/?fbclid=IwAR2QckXB5XMPLCttnyBDUWv-MgxFsk0utfih4FHpF1za4OzH-9h-SKgR0GM and adding some stuff to the /etc/network/interfaces/
I'm running multiple SUMO simulations in parallel using TraCI.
Every so often one will fail with the message
Error: tcpip::Socket::accept() Unable to create listening socket: Address already in use
Quitting (on error).
I haven't found anyway to set the address to use on the configuration list at http://sumo.dlr.de/wiki/SUMO
I figure if I can set each instances address manually I should be able to avoid this.
The answer is right on the page you mention. The option --remote-port specifies the port number, so something like
sumo --remote-port 54323 -c my.sumocfg
should do the trick. Of course you need to give the same port when connecting from your traci client.
I have this USB Relay:
http://www.ebay.com/itm/5V-USB-Relay-2-Channel-Programmable-Computer-Control-For-Smart-Home-/141097843081?pt=LH_DefaultDomain_0&hash=item20da163989
Al I need is to send close/open to the device (to turn on & off an LED light)
How can I do that using C# or C++?
Thanks
Boaz
Here's what you need (tested on Linux) :
HIDAPI from http://www.signal11.us/oss/hidapi/
USBRELAY from https://github.com/darrylb123/usbrelay/blob/master/README.md
Use it like :
usbrelay ZG4HU_1=1
usbrelay ZG4HU_1=0
to switch the first relay on and off. ZG4HU_2 addresses the second relay and without arguments you even get the relay status.
-- Hans
The 26484 26483.rar is what I needed for Windows. .exe files for graphic and for command line for testing and .dll for my own development.
Found here: http://files.elektroda.net/794975,26484++26483+usbrelayextlib.html
I'm sending a command to a Mikrotik router using Telnet.
telnet 192.168.100.100 -l admin
Password: pass1234
[admin#ZYMMA] > /interface pppoe-server remove [find user=aspeed13]
[admin#ZYMMA] > quit
It works fine.
Now I want to automate it using expect tcl script:
#!/usr/bin/expect --
spawn telnet 192.168.100.100
expect "Login:"
send "admin\r"
expect "Password:"
send "pass1234\r"
expect "\[admin#ZYMMA\] >"
send "/interface pppoe-server remove \[find user=aspeed13\]\r"
expect "\[admin#ZYMMA\] >"
send "quit\r"
It works, but after authentication (line 6: send "pass1234\r") when the Router CLI is loading it freezes for ~10seconds with the following characters ^[[?6c^[[24;3R
Then the scripts runs ok.
My question is why Telnet loads fast when accessed manually and it takes too much time when accessed via expect script? I read in forums about telnet automation they say telnet is slow, but since manually it's too fast why it takes time to load with expect?
What you're seeing is blow-back from terminal negotiation, which is because you're not running in a real terminal. (Strictly, you are – that's expect's magic – but it's not behaving as a normal terminal does.)
The easiest fix is to set the terminal to something else before spawning the telnet session, e.g.:
#!/usr/bin/expect --
set env(TERM) dumb
spawn telnet 192.168.100.100
# Rest of your script goes here ...
Alternatively, you could try to respond correctly to the request to enter VT102 mode and the report of the cursor location (which feels like a lot of work) or you could rewrite your code so that it does everything inside interact (which connects the other end with the real terminal that you're running inside). But if setting an environment variable fixes it, why go to all that extra hassle?
(NB: I suggest setting the terminal to dumb here, but the key is that you want the stupidest terminal that works. Dumb terminals are ideal, because they're just about totally stupid, making it easy to pretend to be them…)
My answer is possibly too late. This is "Telnet autoconfig command"...I was this problem and found at Mikrotik Wiki this solution:
Add +t after login name. This switch autodetect to off.
Example:
send "admin+t\r"
It is works great and not "wait cca 10 sec" after login by expect.
There is link to Mikrotik WiKi help with more "switches":
http://wiki.mikrotik.com/wiki/Manual:Console_login_process#FAQ
P.S.: Sorry for my English.
Did you try with netcat, with telnet emulation enabled?
A little bit late to answer.
But if you want to speed up your character input with expect.
Try to generate the script with "autoexpect" command, which will save the
interaction in a file named "script.exp" in the same directory from where
you ran the command.
For instance:
cd $HOME
autoexpect telnet 192.168.100.100
# some more telnet commands here
exit
All the above commands will be saved in ~/script.exp
About Tcl, I don't know if ths script can be ran via tcl.