I'm looking for a tcpdump binary that runs on openwrt. The website only shows source code that must be built. Anybody point me to a location that contains a prebuild binary? Thanks.
I suggest to set up a working repository, i.e.:
https://downloads.openwrt.org/chaos_calmer/15.05-rc2/x86/generic/packages/base/
You can put the url on your OpenWRT system under /etc/opkg.conf.
Using opkg you do not have to deal with all the dependencies.
opkg update
opkg install tcpdump
If there is no internet connection on the Openwrt system, and there is no local repository deployed, the solution above works as well, but it is more painful and consumes more time.
You find binaries at
http://downloads.openwrt.org/snapshots/trunk/
but you have to use the right one for your hardware plattform
e.g for x86
http://downloads.openwrt.org/snapshots/trunk/x86/packages/tcpdump_4.2.1-1_x86.ipk
The prefered method is to use opkg to install the package
Related
I'm using NixOS as the distro on WSL (via the excellent setup provided by Trundle: https://github.com/Trundle/NixOS-WSL) and I'd like to install the racket package. If I run nix-shell -p racket, it dutifully downloads (or uses the previously downloaded) the pre-built binary and I can use it just fine. But if I add racket to the environment.systemPackages list in configuration.nix and try to nixos-rebuild test, it starts trying to build things from source. It fails when it gets to gtk (presumably because WSL2 doesn't yet support graphical applications).
Why the difference in behavior? Is there a way I can convince NixOS to use the pre-built racket when filling out the systemPackages? Happy to post my configuration.nix if it would help the diagnosis, though it's really not much of a departure from Trundle's.
When I configure like shown below and then compile, then the resulting qemu-arm performs many (about 20 to 40) times worse than the qemu-arm-static that came with Ubuntu 18.04.3 (AMD64).
I used the same branch (stable-2.11) as the version that came with Ubuntu.
How could I configure to get more performance?
./configure --static --target-list=arm-softmmu,arm-linux-user --extra-cflags=-O3 --extra-cxxflags=-O3 --extra-ldflags=-O3
I'm not sure if -O3 is a good idea -- you could check whether the Ubuntu package build uses that; I suspect it uses the default -O2 instead. In fact a good first step would be to build the Ubuntu package without any changes (ie get the package source with 'apt source qemu' and build it as an Ubuntu package) and check that it has the same performance you're seeing with the shipped binary version.
If the package you build doesn't have the same performance as the Ubuntu-built binary: then something weird is going on, which you'd need to investigate.
If the package you build does have the same performance as the Ubuntu-built binary (ie better than whatever you're building now): then the difference is somewhere in either how the Ubuntu packaging is configuring QEMU, or in the build environment it is using, or in some set of patches it's using that aren't in the branch you're currently building. You could try to narrow down what the difference is.
Other than that, a general note is that 2.11 is now a pretty old version of QEMU, and there have been performance improvements upstream since 2.11. But they're not 20-40x, so you should definitely try to identify why you're not getting the same performance as the Ubuntu package binary first.
I'm learning how to build a basic OS kernel with https://intermezzos.github.io
I've create my .iso file and I'm at the point where I am runnning qemu-system-x86_64 -cdrom os.iso
When I press enter, QEMU runs a window with the following output:
Booting from Floppy...
Boot failed: could not read the boot disk
Booting from DVD/CD...
Boot failed: Could not read from CDROM (code 0004)
Booting from ROM...
iPXE (PCI 00:03.0) starting execution...ok
iPXE initializing devices...ok
iPXE 1.0.0+git-20131111.c3d1e78-2ubuntu1.1 -- Open Source Network Boot Firmware
-- http://ipxe.org
Features: HTTP HTTPS iSCSI DNS TFTP AoE bzImage ELF MBOOT PXE Menu
net0: 52:54:00:12:34:56 using 82549em on PCI00:03.0 (open)
[Link:up, TX:0 TXE:0 RX:0 RXE:01]
Configuring (net0 52:54:00:12:34:56)...ok
net0: 10.0.2.15/255.255.255.0 gw 10.0.2.2
Nothing to boot: No such file for directory (http://ipxe.org/2d03e13b)
No more network devices
No bootable device.
I went to the website listed in the output (http://ipxe.org/2d03e13b) and one of the tips is that I might Use the iPXE command line to perform DHCP manually, however when I press CTRL + B to access cli, I'm not able to do so.
Where do I look next to troubleshoot this problem of not being able to boot my .iso?
How do I make QEMU have access to keyboard input?
UPDATE
I don't know how, but I'm am now able to use CTRL + B to access iPXE command line.
This seems like a good place to start diagnosing my problem of not being able to boot my .iso.
What am I looking for?
UPDATE 2
Thanks to Peter Maydell's suggestion below, I've tested a known-good iso image (https://alpinelinux.org/), running qemu-system-x86_64 -cdrom alpine-3.4.3-x86_64.iso and it booted perfectly just as I expected.
I've rewritten my files from https://intermezzos.github.io to create a new iso image, this time copy and pasting the code from the repository, just in case I was previously inputting typos.
Still not booting. On to the next clue...
The first thing to do is to check whether this command line and ISO image work on a normal Linux host system. That will tell you whether the problem is (a) the Windows Subsystem for Linux not correctly implementing something QEMU relies on or (b) your ISO image actually not being a bootable CDROM.
You might also try booting a known-good ISO image such as one for a Linux distribution.
(The general principle here is to try to do diagnostic tests to split the space of "what might be the problem" into smaller sections and determine which side your problem is.)
Simple solution to the problem. Has to do with systems that use EFI to boot.
source
I needed to apt-get install grub-pc-bin and then rebuild image.
I am trying to use libvmi tool on KVM virtual machine running on Eucalyptus cloud. It is a cloud-in-a-box 3.4.2 version. To use libvmi on KVM, it requires me to change the qemu-kvm that Eucalyptus by default uses. So I did a patch to the qemu-kvm-1.2.0 source code, compiled it and "make && make install" as this web page said: https://github.com/bdpayne/libvmi/tree/master/tools/qemu-kvm-patch.
Now I need to make sure my system will use this newly installed version of qemu-kvm when running KVM virtual machines. Could anyone tell me how to setup so that Eucalyptus would use my newly-installed qemu-kvm when launching new instances?
I tried "yum erase qemu-kvm", hoping to erase the original version of qemu-kvm so that maybe Eucalyptus would have to use the qemu I just compiled and installed. However when I used "yum erase qemu-kvm", it said "eucalyptus-nc" would also need to be erased for depedency reason, so I didn't continue.
Any help would be appreciated. Thank you very much.
I guess you have a couple options:
Tell configure to install into location used by the packaged installation (perhaps something like ./configure --prefix=/).
Find the qemu-kvm binary on the system and overwrite it with the binary produced in the source tree during compilation.
A backup may help, but then you can always reinstall from packages.
How to build OpenSSL for WP8?
AFAIK, we must replace winsock.h by winsock2.h because WP8 only supports winsock2.h. And maybe we must replaces code to target WinRT architecture on WP8 (ThreadPool, ...)
The caveat is that we must build OpenSSL as WP8 static library, so that the output lib can be wrapped by WP8 runtime component, right ?
You can use the Microsoft openssl fork on github with support for windows phone 8.1/8.0 and Windows Store 8.1, that address the entropy on each platform using windows random generators, instructions are located at INSTALL.WINAPP, there is a script located at
ms\do_vsprojects.bat
you should be able to just execute that script withing the root location and open vsout\openssl.sln to build the openssl libraries for different windows platforms.
The fork is located at
https://github.com/microsoft/openssl
At this momment these changes are being in process to be integrated with the main OpenSSL source code base.
here is what you have to do, go to this link and download the VSbuild, now put that into the source files downloaded from the OpenSSL website, the folder structure should look like this:
apps
bugs
certs
.....
vsbuild
once that is done, open the solution, it should upgrade it to VS12, change the settings to a Windows Phone RT build, to generate DLL's there is no need to build *_lib*, so change the other projects, most changes you need to do are to libeay32, do not compile openssl project, just ignore that, start by building libeay32, and start making changes to the code, as there are some functions we don't have in WinRT, you can either #ifdef them out, or create your own functions,
NOTE for rand_win.c change the functions to use rand_s and #ifdef most of the code there is, this might muck up the security, you will have to test it out yourself
Good Luck !
This is so that if anyone wants to build the new version of OpenSSL "1.0.1g" that fixes the Heartbleed problem you can follow the previous steps whit the following changes:
I renamed the folder include to --include and create a new folder named include, the VS project will take care of copying the information, --include if you like you can remove this, when i build the project without this change there where compilation issues.
Note: the include folder that i changed is the one found in the root not the one found under VSbuild
Enjoy
Here is a download of pre-compiled OpenSSL libraries for Windows Phone 8.1 among other platforms:
https://www.teskalabs.com/blog/openssl-binary-distribution-for-developers-static-library
Disclaimer: I run that site.