We Keep Coding

filter in scapy function sniff() says libpcap is not available

I was playing around with the Scapy sniff function and I wanted to add a filter into the parameters. So I added this filter:
pkt = sniff(count=1, filter='arp')
and the output i recieve is:
WARNING: Cannot set filter: libpcap is not available. Cannot compile filter !
I still get a packet that was sniffed, but for some reason the filter is not working.
I am running Mac OS Big Sur. I have libpcap installed using Homebrew and I have tcpdump installed using Homebrew.
I also saw online that you could manually initialize pcap on Scapy using
conf.use_pcap = True
However when I type this in I get:
WARNING: No libpcap provider available ! pcap won't be used
I'm sure it is just a small fix but I can't seem to figure out what I am doing wrong. If anyone can help that would be amazing!

Older versions of Python 3 assume that, on macOS, all shared libraries are in files located in one of a number of directories.
That is not the case in Big Sur; instead, a cache file is generated for system shared libraries, and at least some of the libraries from which the cache file is generated are not shipped with the OS.
This is one of the issues in CPython issue 41100, "Support macOS 11 and Apple Silicon Macs"; the fix is to look in the shared library cache as well as in the file system.
That issue says
Thank you to everyone who contributed to this major undertaking! A particular thank you to Lawrence for doing much of the initial work and paving the way. Now that 3.8 also supports Big Sur and Apple Silicon Macs as of the imminent 3.8.10 release, it's time to close this issue. If new concerns arise, pleasa open or use other issues.
So a sufficiently recent version of Python should fix this issue.

tldr:
$ brew install libpcap
$ ln -s /usr/local/opt/libpcap/lib/libpcap.a /usr/local/lib/libpcap.a
$ ln -s /usr/local/opt/libpcap/lib/libpcap.dylib /usr/local/lib/libpcap.dylib
Explanation (applicable for Python 3.9.1, Scapy 2.4.5 # Big Sur and libpcap installed by brew):
When you debug the Scapy sniff function, after a while you get to scapy.libs.winpcapy, line 36:
_lib_name = find_library("pcap")
find_library is located in ctypes.util, for POSIX it starts on line 72. On line 73 you can see that the library is expected as one of these filenames ['libpcap.dylib', 'pcap.dylib', 'pcap.framework/pcap'], being fed to dyld_find.
dyld_find is located in ctypes.macholib.dyld on line 121. If you iter through the chain on line 125 yourself, you find out that dyld_find is trying to succeed with one of these paths:
/usr/local/lib/
/Users/<user>/lib/
/usr/local/lib/
/lib/
/usr/lib/
In my case none of them contained the libpcap lib, which is installed in different location by brew.
The library sits in /usr/local/opt/libpcap/lib/.
And here you go, you just need to get the file libpcap.dylib (nothing wrong with libpcap.a too) into one of those paths searched by dyld_find. The two soft links above are one of a few more possible solutions.

Error initializing ctypes in pybuilder

A couple of days ago I cloned a git repository and tried to make a build out of that code with PyBuilder; however, I have not been able to do so.
Every time I run pyb -X -E jenkins-zipfile-release in Bash I get the following error: BUILD FAILED - Error initializing ctypes. The thing is, none of my colleagues have this problem, we don't know why.
The traceback tells me the problem is here: .../pyenv/versions/2.7.14/lib/python2.7/site-packages/oscrypto/_openssl/_libcrypto_ctypes.py
We thought the problem that my python was not correctly compiled with SSL. We even had a different SSL version. I replaced LibreSSL with OpenSSL, but the problem persists.
Another person told me that maybe the oscrypto libraries are conflicting (one from the environment and the other one from the project's lib directory) How can I check that?
I would deeply appreciate if someone could point me in the right direction, I've been trying for two days now.

There was an issue with regards to running oscrypto in a High Sierra. The issue was fixed and it will be a part of the next release.
More info: https://github.com/wbond/oscrypto/issues/22

Python node2vec (Gensim Word2Vec) "Process finished with exit code 134 (interrupted by signal 6: SIGABRT)"

I am working on node2vec in Python, which uses Gensim's Word2Vec internally.
When I am using a small dataset, the code works well. But as soon as I try to run the same code on a large dataset, the code crashes:
Error: Process finished with exit code 134 (interrupted by signal 6: SIGABRT).
The line which is giving the error is
model = Word2Vec(walks, size=args.dimensions,
window=args.window_size, min_count=0, sg=1,
workers=args.workers, iter=args.iter)
I am using PyCharm and Python 3.5.
What is happening? I could not find any post which could solve my problem.

You are almost certainly running out of memory – which causes the OS to abort your memory-using process with the SIGABRT.
In general, solving this means looking at how your code is using memory, leading up to and at the moment of failure. (The actual 'leak' of excessive bulk memory usage might, however, be arbitrarily earlier - with only the last small/proper increment triggering the error.)
Specifically with the usage of Python, and the node2vec tool which makes use of the Gensim Word2Vec class, some things to try include:
Watch a readout of the Python process size during your attempts.
Enable Python logging to at least the INFO level to see more about what's happening leading-up to the crash.
Further, be sure to:
Optimize your walks iterable to not compose a large in-memory list. (Gensim's Word2Vec can work on a corpus of any length, iuncluding those far larger than RAM, as long as (a) the corpus is streamed from disk via a re-iterable Python sequence; and (b) the model's number of unique word/node tokens can be modeled within RAM.)
Ensure the number of unique words (tokens/nodes) in your model doesn't require a model larger than RAM allows. Logging output, once enabled, will show the raw sizes involved just before the main model-allocation (which is likely failing) happens. (If it fails, either: (a) use a system with more RAM to accomdate your full set of nodes; or (b) or use a higher min_count value to discard more less-important nodes.)
If your Process finished with exit code 134 (interrupted by signal 6: SIGABRT) error does not involve Python, Gensim, & Word2Vec, you should instead:
Search for occurrences of that error combined with more specific details of your triggering situations - the tools/libraries and lines-of-code that create your error.
Look into general memory-profiling tools for your situation, to identify where (even long before the final error) your code might be consuming almost-all of the available RAM.

If you're running macOS v10.15 (Catalina), this might help you.
For me, I started seeing this error right after the upgrade to Catalina.
Execute the following commands one by one in Terminal, and you should be good:
brew update && brew upgrade && brew install openssl
cd /usr/local/Cellar/openssl/1.0.2t/lib
sudo cp libssl.1.0.0.dylib libcrypto.1.0.0.dylib /usr/local/lib/
cd /usr/local/lib
mv libssl.dylib libssl_bak.dylib
mv libcrypto.dylib libcrypto_bak.dylib
sudo ln -s libssl.1.0.0.dylib libssl.dylib
sudo ln -s libcrypto.1.0.0.dylib libcrypto.dylib
I found this in one of the Apple forums (but I can't seem to recollect exactly where).
Also, some blessed soul has also written a batch for this.
It can be found in this gist.

I had the same issue, and finally, I figured it out. The reason for me was my Keras version 2.2.0 was too high.
After I changed the version to 2.0.1, it worked.

For me the problem was with the Snowflake connector Python library running on macOS v10.15 (Catalina).
I found the solution from user VikR in a blog post given in answer 59538581 that has been deleted from this page: Python Abort trap: 6 fix after Catalina update by Danny Bryant. It explains that the SSL libraries need to be placed back into your Mac's operating system path and gives the steps to do it. It also lists the steps to upgrade your libraries using brew and pip3.
Here are the steps that I followed to get my Python script running again.
brew update
brew upgrade
cd /usr/local/lib
ln -s /usr/local/Cellar/openssl\#1.1/1.1.1j/lib/libssl.1.1.dylib libssl.dylib
ln -s /usr/local/Cellar/openssl\#1.1/1.1.1j/lib/libcrypto.1.1.dylib libcrypto.dylib
pip3 install --upgrade snowflake-connector-python
For me I did not have to install OpenSSL as I had already installed it. Please read Bryant's page for more detail.
Note that
My version of OpenSSL is of course later than Bryant's instructions. Your version will most likely be later, too, compared to what I used here.
The Homebrew /Cellar/ directory structure was slightly different for me versus when Bryant wrote his instructions. It may have changed again when you read this.
I chose to link the libraries directly rather than linking to copies of the libraries, as Bryant did.
My Homebrew /Cellar/ and /usr/local/lib folders actually needed a fair amount of user ownership changes. Since that wasn't related to the original question, I omitted those steps.

Use:
import os
os.environ['KMP_DUPLICATE_LIB_OK'] = 'True'

Building Blender for breakpoints/Debug in Xcode

TL;RD Following http://wiki.blender.org/index.php/Dev:Doc/Building_Blender/Mac for Xcode what are the steps that let you add breakpoints/watches and correctly debug the executable on OS X?
My spec
Xcode Version 6.4 (6E35b)
OSX 10.10.4 (14E46)
CMake 3.3.0 GUI build with QT 4.8.6
The long description
I did follow the instructions so I set the scheme as suggested as for Xcode 5 (did let debug as default) but
First time cmake fails because there is no numpy there is no numpy (release or debug) inside https://svn.blender.org/svnroot/bf-blender/trunk/lib/darwin-9.x.universal/python/lib/python3.4/ also from the console output munpy is searched on something like /Users/tyoc213/blender-build/blender/../lib/darwin-9.x.universal/python/lib/python3.4/python3.4/site-packages/numpy also you can see that it search on python3.4/python3.4 which is weird.
On the second run it says that it will skip numpy on install(ation). you can see the cmake output here https://gist.github.com/tyoc213/aea0fb541383dc06981a
So we now can generate Xcode project, we open the generated blender project with Xcode configure the scheme as on the dev-wiki and wait it fails at blinker step.
The only plausible fix for debug scheme is no fix at all, use release scheme
There is only one "fix" for compile&run for this and it is to change the scheme to Release, but even having checked Debug application and that Xcode attach on start to the process, breakpoints don't work.
The debug scheme
So the problem in Debug scheme is this: How to build a blender build in Xcode 5? basically there are references from libbf_intern_cycles.a that are not found: _Controller_actuators_length, _CurveMapping_curves_length, _MeshColorLayer_data_length, _MeshLoopColorLayer_data_length, _MeshPaintMaskLayer_data_length, _MeshPolygonFloatPropertyLayer_data_length, _MeshPolygonIntPropertyLayer_data_length, _MeshPolygonStringPropertyLayer_data_length, _MeshSkinVertexLayer_data_length, _MeshTextureFaceLayer_data_length, _MeshTexturePolyLayer_data_length, _MeshUVLoopLayer_data_length, _MeshVertexFloatPropertyLayer_data_length, _MeshVertexIntPropertyLayer_data_length, _MeshVertexStringPropertyLayer_data_length, _Sensor_controllers_length, _Spline_points_length this are ld: symbol(s) not found for architecture x86_64
Any suggestions in the correct setup for debug and put break points then do steps, threads with Xcode and watch variables and so on?.

The only way for the moment that I have found to be able to put breakpoints in Xcode and do step by step, see locals and so on, is to disable cycles in CMake.
Maybe I should post this as an error in the build process at less for CMake, I don't know if I can build scons inside Xcode and debug it inside Xcode.

Pylibftdi library not working (serial mode, UM232H)

First of all I am quite new with both python and Linux.
That said I am trying to communicate to an FTDI UM232H chip using the pylibftdi library.
I am running my scripts on Linux Ubuntu 12.04.
I installed the library that I got here:
http://pylibftdi.readthedocs.org/en/latest/
and apparently everything worked fine.
I was also able to run some of the examples successfully.
I then tried to write some code to communicate with the device: I wired it in a bus powered configuration (in order to get power from the USB), then I short-circuited TX and RX pins so that what I am sending on TX will be read back on RX.
I do not get any error, but I am not able to read back anything on RX.
Here is my very simple code:
import pylibftdi as p
import time
test = p.Driver()
print test.list_devices()
#This is not working
#print test.libftdi_version()
dev1 = p.Device(device_id='FTUBL36A', mode='t')#, chunk_size = 0)
dev1.flush()
dev1.baudrate = 9600
len = dev1.write('Hello World')
time.sleep(1)
res = dev1.read(len)
print 'res: ', res
Also I am not able to get the libftdi_verion information, even though I installed it.
Does anybody have an idea of what I am doing wrong? Has anyone else ever experienced such a problem?
Thanks in advance!

I'm afraid I don't have a full answer, but some observations (I would make this more concise and put as a comment, but I don't have sufficient rep).
Disclaimer: I'm the author of pylibftdi
libftdi version / installation
The Ubuntu libftdi package (even latest 13.10) is 0.20. This is particularly confusing / annoying since the Ubuntu package name is 'libftdi1'. Prior to (real) libftdi 1.0, there isn't a ftdi_get_library_version() function, so libftdi_version() won't work with the Ubuntu default package. The next version of pylibftdi recognises this and gives an appropriate response.
To install 1.0, follow the instructions at http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00014.html (e.g. the following worked for me - note I'd previously had the Ubuntu libftdi1 package installed, and other dependencies may be required):
$ sudo apt-get install cmake libusb-1.0
$ git clone git://developer.intra2net.com/libftdi
$ cd libftdi
$ git checkout tags/v1.0
$ mkdir build; cd build
$ cmake ..
$ make
$ sudo make install
$ sudo ldconfig # ensure the new library is recognised
Following this, getting the library version should work:
$ python -c 'from pylibftdi import Driver; print Driver().libftdi_version()'
(1, 0, 0, '1.0', 'v1.0')
Data reading errors with UM232H
Note that the latest libftdi (repeat things above but use git checkout master) seems to work slightly better for me, and your program above works perfectly for me with a UM232H (I obviously omitted the device=... parameter, but otherwise left it unchanged). If I replace 'Hello World' with 'Hello World' * 10, writing and reading a longer string, then I get a truncated value returned, typically only 29 bytes. I'm not sure why it's this value; with earlier libftdi versions it seemed to return 17 bytes consistently. Very odd.
With other devices (UB232R, UM232R), this all works perfectly as expected, so in the (admittedly unlikely) event you have a choice of device, you could consider switching... Note the FT232H chip is relatively new and support in libftdi may not be as solid as for the older devices - but equally possible is that I'm incorrectly assuming it should work in a similar way to the older devices in pylibftdi.
Other thoughts
I've tried blacklisting ftdi_sio (add blacklist ftdi_sio to the end of /etc/modprobe.d/blacklist.conf), which stops the Linux kernel doing who-knows-what with the device on plugging it in (the Rx/Tx LED flashes several times when plugging in without this and the ftdi_sio module is loaded. I'm not sure this is necessary or makes a difference though.
Note that there's no guarantee that a read() will return anything previously written to the device (assuming an external Tx->Rx loopback), due to internal buffering in the device, and various driver layers (including USB). These are just streams, and framing should be done in the application layer. Having said that, it 'just works' on a UB232R, and even taking this into account seems the UM232H seems to have issues with pylibftdi for serial mode.
Bitbang mode seems to work fine for UM232H / pylibftdi.
I'll continue investigating and update this answer if I find out anything more.