I took a look over the already asked questions and I didn't find the information I need. In case I miss the questions somehow, please accept my apologize.
I would like to know how can I use a router as switch on GNS3? Since GNS3 (at least in this moment) doesn't accept switches images, how can it be done?
Once this step is made, it is possible to use most the important switch functions? like etherchannel, trunk, multiple vlans etc.
Thank you very much.
Firstly, there is no true way to put switching into hardware, as of yet, that is. The TCAM's functions in L3 switches these days has yet to be perfected in software.
Secondly, there are a couple of ways to do this, but out of the three, two of them will either cost money or take some investigative work.
Drag the switch icon into the simulation. You can do vlan tagging as an access port, or as a trunk port. No etherchannel though. Alternatively, the 3725 Router has some switching capabilities using the 16-ESW card, however functionality is limited and syntax differs.
Buy VIRL from Cisco's website. It is basically an Ubuntu VM with Cisco routers, IOSvL2 (a switch essentially), ASAv, and a couple other virtual network devices. However, if you're not a student, it's a few bucks. In addition, it is subscription based
3.Upload IOU to GNS3. You will need:
-IOU image, found here: http://sourceforge.net/projects/gns-3/files/IOU%20VMs/
-Virtualbox
-License file for IOU
-GNS3 (Obviously)
-L2/L3 IOU images (The L2 images are switches)
You can find the instructions here: http://srijit.com/how-to-configure-iou-in-gns3-for-real-cisco-switching-labs/
Hope this helps.
Related
so basically I've been online trying to research this the whole day and I seem to only be able to come across specific setups that people have for their own specific needs rather than a generic list of hardware needed.
What I want to do firstly using my raspberry pi 2 running raspbian, and secondly a laptop running kali, is to be able to do penetration testing along with some extras.
What I Am looking for is a list of hardware that I need (other than the rpi2 for the first case and laptop for the second) that will enable me to sniff out WiFi signals, and attempt to get onto the network. I believe the general name for this is wardriving.
I know that I need a portable power supply for the rpi2, and a screen or some sort (I want a small screen that I can see the rpi gui desktop from. Not just terminal), so any suggestions of examples of those would be appreciated.
Where I get confused is about the WiFi antenna that I need. From what I understand is that it needs to be one that can monitor as well as connect to a WiFi, but I don't really know of any examples or of what the actual difference is between it and a normal usb WiFi stick.
I'm also not sure what else I need to have beyond that to successfully accomplish my stated goal.
Any further help would be greatly appreciated, and I think beneficial to anyone else who's looking to get started doing the same thing.
Any extra information would be good too what I mean is when I was doing my research I saw some people mentioning radio attachments, gps attachments, etc. But I'm not really sure if they're necessary to start or things that can be added further down the road with experience.
Thanks.
Ok so I seem to have found a good article that answers at least the general part of my question. It can be found here.
http://lewiscomputerhowto.blogspot.ca/2014/06/how-to-hack-wpawpa2-wi-fi-with-kali.html?m=1
It also gives tips on the process of pen testing.
My project is to create an interactive program using the Micro:bit microprocessor I'm building a game which uses a drill motor as a controller of sorts reading the rotation direction and speed as inputs for control
but my mentor also said it would be cool to power the board at the same time as the game is running so now I hit the situation where once I stop turning to change direction or my speed goes below transmitting 3.3 volts to power it then the game restarts and I lose all progress
I had the Idea of using a second micro:bit as a sort of storage place being powered by my computer and the two continuously communicating sending back player position and other objects on the LED's
but i can't figure out how to get the two Micro:bit's to talk to each other
If someone could just point me in the right direction or even set up some sort of communication to nudge me in the right direction as I start moving forward
i'm a high school student who doesn't know as much as I pretend to so I'll probably need a lot of help (i am more advanced then most in my class at this sort of thing so think of me as a tech gifted teenager thrown in with college students losing my undeserved ego day by day LOL) please help me somehow I'm currently completely lost
You won't be able to use Bluetooth for the reasons indicated in the documentation (not enough memory): http://microbit-micropython.readthedocs.io/en/latest/ble.html
However, there is an incoming implementation of the lighter radio module, which would allow you to send simple data: https://github.com/bbcmicrobit/micropython/pull/283
The proposed documentation can be found in: https://github.com/bbcmicrobit/micropython/pull/305
As you can see in GitHub, at the time of writing it has not yet been merged into micropython. So if you'd like to try it you would have to clone the repository, apply the patch and build it from source. Keep in mind there is risk for the API to change, as there are still discussions about it.
Alternatively, as Sean has mentioned, you can use the C++ DAL implementation of the radio module to get something running on the meantime. Or if you prefer, the blocks and touch develop languages also offer radio functionality.
I don't think there is a way to do this in micropython (or at least simply), but the microbit runtime docs describe that, as well as supporting bluetooth, the 2.4 GHz radio:
However, it can also be placed into a much simpler mode of operation based that allows simple, direct micro:bit to micro:bit communication
In order to use this, you might need to write in c++ using the mbed environment (or offline) - but I hope this at least gives you a pointer to start from.
Here's a blog post describing how to do data logging using two microbits in exactly the configuration you describe.
http://www.suppertime.co.uk/blogmywiki/2016/06/microbit-logger
How to get the two micro:bits to talk to each other
As of 2016, you can! First check micropython has the radio module
import radio
If you get the error "No module named 'radio'", use https://codewith.mu/
Then follow the radio tutorial https://microbit-micropython.readthedocs.io/en/latest/tutorials/radio.html
The API is
https://microbit-micropython.readthedocs.io/en/latest/radio.html
BACKSTORY
The other day I found a motorized wheel chair that someone was throwing away. Being a maker who spends a lot of time looking at what other people have made online I decided to snatch it and try to make a robot out of it. I also bought an Arduino mega, a Kinect sensor, and a motor controller to try to control the motors and give it some form of vision.
MY VISION
Honestly I don’t intend for this robot to be much more than a fun, and challenging, project. My current goals are to have it run SLAM algorithms to figure out where it is on a map and for it to navigate to predetermined points on the map. However at this point I would be happy with just being able to do a simple teleop control with the keyboard.
MY PROBLEM
I have spent the past week researching ros and how to get it talking to my Arduino. I have installed diff_drive_controller, Turtlebot, ros_control, ros_serial, ros_arduino_bridge, and several others trying to find something that will tell the motors what to do. By now I feel like I have a good barely below the surface understanding about how ros works. Basically there are a series of nodes each publishing info for the other nodes to see and subscribing to info that they want to read. All I want right now is a node that publishes data about the velocity of the motors based on it trying to navigate or teleop or something like that. I think turtlebot is my best bet considering it is an all in one stack that does everything I want it to do. The only problem is I don’t have an iRobot create. But it seems like it should be simple enough to intercept those commands and have them drive my own robot base. However I’m not sure which topic to listen on and how to run turtle bot in a way that doesn’t try to connect to an iRobot create. I could just listen to the /cmd_vel_mux/input/teleop topic but I think that would limit me to just teleop and it might make it hard to move on to autonomy in the future.
What topic should I listen on? Am I going about this the right way? Are there any packages that would be better suited for my needs? Keep in mind that I am new to ros so tutorials would be appreciated.
I look forward to your responses
Thanks, Logan
Nice sounding project! I second the recommendation to take a look at the tutorials, but I think you spend some more time with the basic ROS tutorials before diving into the world of Arduino + ROS.
For instance, I noticed one misconception I believe you may have. It doesn't really matter which topic your nodes listens to, as its just a name that can be easily remapped through a parameter given when launching the node. The important thing is to ensure you are listening to the right type of messages - they specify the interface by which all the different nodes communicate. There's a bunch of options, and if none of them fit your use case, you can define your own.
I suspect that for low-level things, such as drivers for your motors, you will need to write your own ROS nodes. For advanced functionality, such as SLAM; there's a variety of options. You can find one that's suited to the input data you have available from your sensors.
One last recommendation is to take advantage of the features of ROS that allow you to break a big problem into manageable subtasks. Do one thing at a time - implement a motor contoroller, write a teleoperation method; taking care to specify suitable interfaces at each point. The advantage of this approach is that if you made smart choices in defining individual components with good interfaces, it is very easy to replace them with another one should you so wish.
You can find a list of tutorials how to interface Arduino and ROS here.
I am attempting to write a userspace application that can hook into an OS's network stack, sniff packets flying past and edit ones that its interested in.
After much Googling, it appears to me that the simplest (yet reasonably robust) method of doing so (on any platform) is Linux's libnetfilter_queue project. However, I'm having trouble finding any reasonable documentation for the project, outside of the limited official documentation. Its main features (as stated by the first link are)
receiving queued packets from the kernel nfnetlink_queue subsystem
issuing verdicts and/or reinjecting altered packets to the kernel nfnetlink_queue subsystem
Emphasis is my own. How exactly am I meant go about this? I've tried modifying the sample code provided, but perhaps I am misunderstanding something. The code is operating in NFQNL_COPY_PACKET mode, so I am receiving the whole packet -- but my modifications to it seem to be restricted to my own application -- as one would expect, given the "copy" semantics.
My feeling is that I am meant to make use of NF_QUEUE somehow, but I haven't quite grokked it. Any pointers?
(If there is a simpler mechanism for doing this, which is also cross-platform, I'd love to hear about it!)
I can't believe I missed this previously. As reticent as I am to post questions on SO, I thought I would never work this one out myself. :)
I didn't look at the function prototype properly. It turns out in the "verdict" function (outlined below),
int nfq_set_verdict(struct nfq_q_handle *qh,
u_int32_t id,
u_int32_t verdict,
u_int32_t data_len,
const unsigned char *buf
)
The last two parameters are for the data to be returned to the network stack. Obvious in hindsight, but I missed it completely as the print_pkt function doesn't take the packet data as a parameter, but extracts it from the struct nfq_data.
The key is to NF_ACCEPT the packet and pass the suitably modified packet back to the kernel.
Just a wild guess from digging around the source code: try explicitly adding the mangled payload using nfnl_addattr_l(…, NFQA_PAYLOAD, …)?
All right, let me preface this by saying: I'm not completely confident this is programming-related. I'm trying to use software to solve a problem, but the software I actually trust; I suspect I'm doing something wrong with the hardware. However, I don't know where else to ask this question. Superuser already shot me down, and the Gadgets FAQ makes me think it's not a good fit there, either. If this question really strikes you as too off-topic to permit here, do what you gotta do. But, please. If you could go either way, I beg for your mercy.
I have a Pioneer DVD-V5000 player that I'm trying to control via 9-pin RS-232 port. (As opposed to the 15-pin port that's hard to find cables for.) Trouble is, I can't get the thing to acknowledge any commands. I'm not even getting any error messages back; only silence.
I have the specs for communicating with that port in front of me, and as far as I can tell I'm doing everything right; I'm sending two-character ASCII commands followed by a <CR>. I've gone into the Advanced Setup menu on the player, and have selected the 9-pin port (factory default is the 15-pin). The spec seems to be indicating the 9-pin port is perfectly standard; I don't see any indication I need some kind of custom cable to be using it. And I'm following all the setup protocols from the spec: 8-bit data length, 1-bit stop bit, no parity. Baud rate can be either 9600 or 19200, depending on the Advanced Setup, but neither works.
I'm fairly sure the software handling the COM-port communication isn't the problem. I've used a version of this software to successfully control another device, and I'm getting identical results (no response whatsoever) when I try to manually shove through commands with a serial port terminal.
Is there anybody familiar with Pioneer's serial-controlled electronics who can give me some suggestions about where I'm going wrong, or for other avenues of investigation?
For the sake of anybody else in a similar bind who stumbles across this question, I'll swallow my pride and record the correct solution, rather than just delete this into oblivion and pretend I was never this dumb. (Topicality hawks, I'm now far less worried about you nuking this thing.) The solution is unrelated to the specific hardware. It's all about the RS-232 cables and what NOT to do with them.
Specifically, if the F-F cable you have is too short, do not use a M-F cable as an extender -- or, if you do, use two of them. Regardless, your total number of cables MUST BE odd. What's Pin 2 on one end is supposed to be Pin 3 on the other end -- but if you have an even number of cables, then Pin 2 on one end goes to Pin 2 on the other end. This is wrong, and whatever gadget you're trying to talk to will rightfully ignore you. You will get very frustrated, fruitlessly Google away trying to figure out what you did wrong, and post lengthy questions of dubious topicality on your favorite Q&A site.
And seriously, who needs that?