Networking – Internet Of Weird Things

Resources:

Overview: This week I wanted to make a juke box that someone could interrupt with a particular song (in this case Smash Mouth’s Allstar). I set it up to run locally, and made a basic site out of Flask, with a button, that then changed the values on a API. I re-used some of my code from the Alexa Blender to to grab that changing API value. The issues I ran into were mostly w/ the feather’s music maker wing. It seems to be having issues maintaining its power when you use an interrupt based play back. I”m guessing there was something wrong w/ the interrupt calls as the blocking calls to the music still worked well. After doing a bunch of troubleshooting I couldn’t get the wing to be stable. I tried different iterations, and tutorials based on using Adafruit IO / doing streaming radio, changing pins and resistors, a different SD card, re-solder, etc. But the board would peter out after a bit. I even tried to follow something to re-flash the nodeMCU, thinking it might be a corrupted memory thing, but for some reason couldn’t make a proper connection. At least I found a lot of resources on music boxes / IoT music things.

Components: Feather Huzzah, Music Maker Featherwing, Flask-Restful

Things I Experimented With: Timers, playlists, SD card.

Things I learned: Plug and play doesn’t really mean that.

Future Iterations: I’d probably set this up via a BaSS, and maybe use a different board. I’d like to still figure out what happened. As the user guide for the huzzah is pretty surface, but if you try and trouble shoot the NodeMCU there’s a rabbit hole of forums. I think as well, I need to find more robust ways of using a homebrew API.

Documentation

Resources

Overview: For this week, my goal was to poke around with Wireshark and learn a bit more about networks. I decided I would also try using pyshark, which is a python wrapper around Wireshark’s command-line utility tshark. Originally I had thought I would pipe some data into Processing to do some viz with it, but at the end of the week realized that Processing already had Carnivore as a library, which allowed packet for in-Porocessing packet sniffing. Wish I’d thought of looking to see if that existed earlier. But oh well? Its nice to know it exists, and I will explore it in the future.

What I ended up doing instead was writing some utility functions to comb through captured data and return the most active of whatever items you send through it. Pyshark has some good ways to dig down into packets, but it can also just grabs all the summaries. So if you want to compare traffic, look for protocols, or just poke around, you can toss together some basic functions to do so.

I think in the end I liked doing the utility functions more than the idea of visualizing it. I would get to the point of having a dataset, and instead of moving on, would go back and dig around in the packets a bit more.

https://youtu.be/yheUVI2p7sM

Of Note: One thing to note though is that LiveCapture in pyshark can sometimes be borked in OSX. Wireshark (and other sniffers) require read access to “/dev/bpf*” which is usually owned by root/wheel. When you use Carnivore, you have to change the permissions on this to 777, which is…very permissive. You will have to do this each time. Wireshark creates a user group, and adds the person who installed wireshark to this group. So pyshark should be able to use tshark under your user without this extra step.

If you can’t get it working then either you need different permissions, or like me, you are trying to read a networking interface that doesn’t exist…because you weren’t paying attention. Then ended up in a 1 day rabbit hole…but I learned some things about what’s depreciated in the OSX system.

Other things I rediscovered: using man pages, and using python’s dir() function. Which is really useful when you want to know what kind of methods you can use on something.

Category: Networking

Week12: Allstar Interruption

Week 2: Wireshark and Networks