So I am using XBMC (a media center program) that has an Android app with a feature that allows you to send Wake on LAN "magic packets" to computers you have XBMC installed on. While this would be a great feature for me if I had a dedicated media PC that auto-ran XBMC on startup, I use it instead on my normal desktop PC.
What I would like to do is see if I can write a little listener script that would run on my PC that would listen for those magic packets sent over port 9 and just start the XBMC application.
Some of my friends say that you cannot listen on this port. The Google searches on "port 9", "wake on lan", and "simple TCP/IP" I've performed remain inconclusive as to weather or not this is possible.
With Python and pcap (winpcap and pypcap http://code.google.com/p/pypcap/). Not very nice but works for me.
import os, pcap
pc = pcap.pcap()
pc.setfilter('udp port 9 and (udp[8:4] == 0xFFFFFFFF and udp[12:2] == 0xFFFF)')
for ts, pkt in pc:
os.system(r'"C:\Program Files (x86)\XBMC\xbmc.exe"')
You should be able to do this on a Windows PC. However your program will not run on a *Nix style system without having superuser, or using a privilege escalator program like jsvc.
Related
I have written a program in Python with pyaudio which requires microphone access. The program works perfectly when launched from the terminal but when it is bundled up as an app with py2app it does not request microphone permission when I launch it.
Before I upgraded my mac to Ventura, finder would always ask permission to access he microphone.
Can anyone suggest a hack to fix this problem.
Obviouly I have tried turning on microphone access in Privacy and Security Settings, but since Ventura does not recognise that my app wants microphone access it does not appear in the microphone access settings.
As soon as my code runs it requests audio access.
# Get audio parameters
devices = fn.get_device_list()
p = pyaudio.PyAudio()
audio_format = pyaudio.paInt16
device_channels = devices[device]['maxInputChannels']
# Open the selected audio input device
stream = p.open(
format=audio_format,
channels=device_channels,
rate=sample_rate,
input=True,
output=False,
input_device_index=device,
frames_per_buffer=chunk_size)
i am using qemu-system-arm to execute a bare-metal cortex-m3 binary using a custom machine populated with emulations of memory mapped devices.
To exchange data between host and the m3 binary running in qemu, I start qemu with
-chardev udp, id=ch0, port=x, localport=y -serial chardev:ch0
Then in qemu I bind a device to serial_hds[0]. Writing to the serial device, then results in udp packets sent to the host.
My question is: do I have to make the connection to -serial ? Can I in some way access the created chardevs without using the way via the -serial?
I want to setup qemu to listen on 10 udp ports, but what I understand, the -serial option is limited to max 4 devices.
QEMU's chardev abstraction has "front ends" and "back ends".
The "back end" is whatever you connect to on the host side (which might be a UDP port, stdin/stdout, a UNIX domain socket, etc). The -chardev option is what creates and configures this back end.
The "front end" is the part on the QEMU side of this. The most common use is a UART (serial port), but you can also use chardevs to specify how to talk to the QEMU monitor, or to a guest parallel port.
In this case your problem is "what are the N things that the guest sees", ie what are the front ends? There has to be something here, which means your board needs to actually create multiple UARTs or something. -serial is a limit of 4 (you can probably raise that with a local hack changing MAX_SERIAL_PORTS), but if your device model is written to take a QEMU chardev rather than to look directly at serial_hds[] it should be possible to configure it other than via -serial (either with -device ... or -global ... to set the chardev as the device property).
In the simplest language possible, can someone please explain...
the function of the "telemetry.cfg" file when debugging an application with Adobe Scout?
the function of the ".telemetry.cfg" file when debugging an application with Adobe Scout?
what TelemetryAddress is needed in each file
The only information I've found describing their functionality is very limited and I'm having trouble wrapping my head around these concepts.
Some notes for reference...
Example of "telemetry.cfg" file contents ("172.30.124.81" is the local IP of the machine running Scout):
TelemetryAddress = 172.30.124.81:7934
SamplerEnabled = false
CPUCapture = false
DisplayObjectCapture = false
Stage3DCapture = false
ScriptObjectAllocationTraces = false
And ".telemetry.cfg" could be the same except:
TelemetryAddress = localhost:7934
I've read this to be true:
7934 - Scout's default port
7935 - Flash Builder's default port
Please don't just post a link to the official Adobe documentation; I've read it numerous times.
The .telemetry.cfg and telemetry.cfg file formats are the same.
Either one is only used when enabling Scout options to profile a swf in a remote process (i.e. on a different PC). This configuration file is located on the PC that is running the swf in order to tell the Flash runtime where to send its telemetry data and which data that it should send.
There is an iOS & Android app for configuring AIR on the actual mobile devices and thus the telemetry.cfg/.telemetry.cfg file is not used.
telemetry.cfg is used to config Air (via FlashBuilder) for profiling Blackberry 10s over their USB connection. Same options in the '.telemetry.cfg', just the IP is a link-local IPv4 address (169.254.x.x). Blackberry 10s are at end of life for support for AIR and I personally have not developed for them.
So in the Scout preferences:
You can change the port number that Scout uses, and this port number has to match the one used in the .telemetry.cfg that is located on the remote PC.
The "Make the Flash Runtime on thus computer connect to Scout" option actually creates a temporary ./telemetry.cfg that exists only while Scout run and is picked up by the Flash runtimes/SWFs that you run so profiling is automatic.
TelemetryAddress in the file is the IP (or host name) of the PC that is running Scout and the port address has to match the one assigned in the Scout Preferences (default is 7934)
I have a setup where i need a proxy in front on a server.
LightTpd 1.4.13 is already used on the embedded platform which should act as proxy.
Newer lighttpd's is not easily build due to an old toolchain.
One port (e.g. port 84) of the proxy platform should forward all traffic to port 80 on the server.
Some simple pages are forwarded just fine, but some other fail. The server has as "web_resp.exe", this is returned as a download option of 0 byte.
Wireshark dumping
Dumps with Wireshark show that the needed pages are send the proxy-platform, but 0 bytes are forwarded. (this was performed on a similar setup)
Question
Is my configuration wrong?
Is it impossible on lighttpd 1.4.13? (i have seen forum-post telling the mod_proxy of lighttpd has problem in general)
Reproducibility
I have reproduced the flaw by running Lighttpd on a new mintLinux (same error type)
I get the same error when forwarding to other ip/site (a web-config of a ethernet -> rs232-port unit).
Exactly what triggers the error is do not know, maybee just too large pages.
Configuration
#lighttpd configuration file
server.modules = (
"mod_proxy"
)
## a static document-root, for virtual-hosting take look at the
## server.virtual-* options
server.document-root = "/tmp/"
## where to send error-messages to
server.errorlog = "/tmp/lighttpd.error.log"
## bind to port (default: 80)
server.port = 84
#### proxy module
## read proxy.txt for more info
proxy.debug = 1
proxy.server = ( "" =>
(
( "host" => "10.0.0.175", "port" => 80)
)
)
Debug dumps
functional and non-functional request seem similar.
However the non-functional read larger size of data (it is still to considered small size <100 kB)
other tests
lighttpd 1.4.35 compiled for the target, but it seem to fail in same way.
lighttpd 1.4.35 neither work on the mintLinux.
1.4.35 + rewrite trick...
works worse than directly using a port
lighttpd 1.5 works out of the box (after installing gthread2) on a mintLinux. However will not work for the target hardware.
The issue have been found to be faulty http headers provided by the backend.
The issue was submitted to the Lighttpd-bug site https://redmine.lighttpd.net/issues/2594#change-8877
Lighttpd now have support for webpages only sending \LF as opposed to \CR\LF
You may argue that the bug is in the target web-page. However in by case i was unable to modify the target site.
http://selendroid.io/setup.html
Here is given an example of what I should get when I open localhost at port 4444.
But instead I get:
{"value":{"os":{"name":"Windows 7","arch":"x86","version":"6.1"},"build":
{"browserName":"selendroid","version":"0.10.0"},"supportedDevices":[],"supportedApps":
[{"mainActivity":"io.selendroid.androiddriver.WebViewActivity","appId":"io.selendroid.androiddriver:0.10.0",
"basePackage":"io.selendroid.androiddriver"}]},"status":0}
A device is connected to the PC and it has no screenlock, but it is not detected.
What's wrong?
(I don't have exp with Selenium or Selendroid and trying to start now)
On your device, you need to switch ON the USB debugging which is under developer mode.
then type command on command promt: adb devices
it should display attached devices.