I am trying to use a expect script to stop the loading of the flash on a Cisco Autonomous AP so that I can get into the rommon.
Loading "flash:/ap3g1-k9w7-mx.124-25d.JA/ap3g1-k9w7-mx.124-25d.JA"...###
If you are sitting a keyboard pressing the escape key at this point will stop the process and give you the option to abort and put you to a rommon prompt.
With the expect script I have tried:
Sending an escape
send "\x1B"
this is sending the hex value for Esc. This is ignored and the process continues. However this works on a WLC device so I know the value is valid.
Sending a break
send "\x1D"
expect "telnet>"
send "send Break\r"
this is sending the hex value for Ctrl+] which is the escape character for but it puts it to telnet> prompt. Sending the break comes back from the telnet and continues loading the flash. On another device that stops the load and puts the device in rommon.
I have also tried the hex for the F1 key and for an arrow key because those work from the keyboard also.
The send "\x1B" will work on an AP as long as the device is set up to allow password recovery.
Related
I'm trying to pipe logs to fzf so that I'll be able to filter them live, as my program spits a lot of logs out.
However, I've noticed the long lines get truncated and I have no way to show the whole lines, except to press ENTER, at which point the line will be displayed in it's entirety but the logs will be deleted from the screen and the program will crash with the error failed printing to stdout: Broken pipe (os error 32)'
It seems fzf supports this feature, as it has a --no-hscroll: Disable horizontal scroll flag, implying horizontal scroll is available by default, but arrow keys don't work, at least not alone or with the usual modifiers.
I've also tried using less -S for this, but doesn't work on live logs as it doesn't resume following after the first interrupt and F command.
As an alternative, I've noticed fzf supports a preview window feature, it would be neat to have the whole line display there so that the logs are still visible and scrolling while following the lines.
I could append logs to a file and try working from there, but is that necessary? Or can these tools also work properly on live stdout logs?
I am using a BBC Micro:bit version 2 and have a program set up on an editor called Micro:blocks. The code is supposed to take input from the first micro:bit's microphone and play it out of the other one's speaker. But when I try it, all I get is an annoying buzzing noise coming out the other end.
I can play it correctly out of the first micro:bit only (not using radio) and it sounds fine. I can't figure out why the second micro:bit makes a buzzing noise.
With the program without radio, I messed around with how long before it played the noise, and none of the tests resulted in a buzzing noise, so I know it's probably not a timing or delay issue.
Anyways, here is my code.
Transmitting code:
when [button a] pressed
set radio group to (7)
set radio channel to (7)
set radio transmit power to (7)
digital pin write (on) to (28)
forever
analog pin write (microphone + 500) to (0)
radio transmit number (microphone + 500)
when [button b] pressed
stop other processes
radio transmit number (0)
analog pin write (0) to (0)
receiving code:
when program started
forever
if (new radio message)
analog pin write (0) to (radio last received number)
This is an interesting project!
Your program looks correct but the radio system may not be fast enough to send each sound sample as a separate message. As a result, you are just hearing a series of clicks, resulting in the buzzing noise.
You could check that the sound data is being sent and received by sending a second or two of sound and graphing the incoming samples on the receiving side. It will be slow, but you should see something that looks like a smooth audio waveform.
Assuming speed is the issue, you could try sending several samples in each packet by encoding them into a string. But even that may not be fast enough to create a smooth audio stream, especially since the encode/decode process will take time.
A different approach would be for the receiver to collect a second or two of sound samples in a list, then play them back in a burst. That would not provide continuous audio but might allow transmitting a sentence at a time.
Here is a record/playback project you might use as a starting point for experimentation.
Note that you can download this image and drop the .png file into the MicroBlocks IDE. MicroBlocks will read the project back from the image itself :)
Using XTERM control sequences (specifically CSI ?1000h), I can get notified on stdin any time the user clicks on the terminal window. Unfortunately this also means I get notified if the scroll wheel is spun, instead of normal terminal scrolling taking place. Is there any way to, preferably easily and simply, just get notified about clicks and nothing else?
Alternatively, is there a way to send an escape sequence that the terminal emulator will interpret as "oh, you want me to scroll normally"? I'd be (reluctantly) okay with having to parse all the mouse commands, and then if I notice a scroll-up signal (button 96 or 64 depending on mode), echo it back saying "here, terminal, you handle this one". In theory these should be the scroll-forw and scroll-back actions, but I haven't found a way to use these directly.
If it makes any difference, I'm using xfce4-terminal, but am willing to try other terminal emulators if it would help with debugging this.
The X10 protocol sends only clicks (no wheel mouse). That's documented. But that's for xterm.
VTE (checking just now with XFCE Terminal) differs from xterm by sending wheel-mouse events. VTE has no documentation worth mentioning, aside from its source-code (ymmv).
The scroll-forw and scroll-back actions are xterm features, for which there are no counterparts in VTE.
I'm dealing with a barcode scanner that acts as a keyboard emulation.
I print my barcode labels with a custom heading character (pipe) .
In my main form, I listen to the keypress event and as soon as I see the custom header character, I start receiving the scan and than do my stuffs.
This method works pretty well if my application is focused but can't do nothing if the application is minimized or unfocused.
I tried to setup a keyboard hotkey. It partialli works: my application get focused on the first character but is not fast enought to capture the subsequent characters spitted very fast from the scanner.
Any idea on how to capture this keystrokes with the application unfocused?
Obviously if the heading char id detected the subsequent characters must be suppressed until the sequence is completed with a vbcr or a timeout is reached.
Note that the scanner spits a sequence of 15 characters in less than a tenth of a second
This is how Windows works, only the active application will handle keyboard input. Thus, when your application is minimized, it will not receive or handle any keyboard input.
As Bradley Uffner commented, you need a global keyboard handler, I've used this in the past and it works quite well. Basically a system wide listener that will handle keyboard input even while minimized.
I need to get a char with ncurses, but when I get the char, I don't want it printed to the screen. Is there a way to do this?
Assuming you're using C, you can use noecho();.
The following is a relevant excerpt from the manual pages.
The echo and noecho routines control whether characters typed by the user are echoed by getch as they are typed. Echoing by the tty driver is always disabled, but initially getch is in echo mode, so characters typed are echoed. Authors of most interactive programs prefer to do their own echoing in a controlled area of the screen, or not to echo at all, so they disable echoing by calling noecho.