I have set up scapy on linux (raspian on RPI) for sniffing WiFi packets using WiFi adapter (b/g) in monitor mode. I am not sure if scapy by default hops on all the channels of the b/g protocol, or sticks to just one of them.
I'd like to have the capability to sniff different channels by hopping on to them, and to have capability to configure the dwell time on each channel, all using snapy. Can some one help me how to do that? Thanks a lot.
No, Scapy won't do channel hopping for you.
I don't think Scapy has a way to control your interface's channel, but you might have a job (outside your script or fork()-ed from it) that would do something like
import os
import time
chans = [1,6,11]
wait = 1
i = 0
while True:
os.system('iw dev monitor0 set channel %d' % chans[i])
i = (i + 1) % len(chans)
time.sleep(wait)
Or something with subprocess.call() instead of os.system if you prefer.
Related
I would like to read a block of data from my Arduino Mega (and also from an Arduino Micro in another project) with my Raspberry Pi via I2C. The code has to be in Perl because it's sort of a plug-in for my Home-Automation-Server.
I'm using the Device::SMBus interface and the connection works, I'm able to write and read single Bytes. I can even use writeBlockData with register address 0x00. I randomly discovererd that this address works.
But when I want to readBlockData, no register-address seems to work.
Does anyone know the correct register-address, or is that not even the problem that causes errors?
Thanks in advance
First off, which register(s) are you wanting to read? Here's an example using my RPi::I2C software (it should be exceptionally similar with the distribution you're using), along with a sketch that has a bunch of pseudo-registers configured for reading/writing.
First, the Perl code. It reads two bytes (the output of an analogRead() of pin A0 which is set up as register 80), then bit-shifts the two bytes into a 16-bit integer to get the full 0-1023 value of the pin:
use warnings;
use strict;
use RPi::I2C;
my $arduino_addr = 0x04;
my $arduino = RPi::I2C->new($arduino_addr);
my #bytes = $arduino->read_block(2, 80);
my $a0_value = ($bytes[0] << 8) | $bytes[1];
print "$a0_value\n";
Here's a full-blown Arduino sketch you can review that sets up a half dozen or so pseudo-registers, and when each register is specified, the Arduino writes or reads the appropriate data. If no register is specified, it operates on 0x00 register.
The I2C on the Arduino always does an onReceive() call before it does the onRequest() (when using Wire), so I set up a global variable reg to hold the register value, which I populate in the onReceive() interrupt, which is then used in the onRequest() call to send you the data at the pseudo-register you've specified.
The sketch itself doesn't really do anything useful, I just presented it as an example. It's actually part of my automated unit test platform for my RPi::WiringPi distribution.
I'm working on a project where I'd like to be able to send a simple on/off signal back to the PC via one of the modem pins (DSR, DCD, CTS), separate from the standard serial communications.
I'm having trouble accessing these when connecting to the device with the standard VPC serial driver.
Sample Python using pySerial:
import serial
def main(argv):
watchPort(sys.argv[1])
def watchPort(portName):
ser = serial.Serial(portName)
while True:
print("DCD {0}, DSR {1}, CTS {2}".format(ser.cd, ser.dsr, ser.cts))
time.sleep(0.5)
if __name__ == "__main__":
main()
These values are always the same, no matter if the pins are connected HIGH or LOW. I've also tested with a couple terminal programs to verify (CoolTerm, SerialTerm).
I am, however, able to get these values via the D2XX drivers and related APIs, but I'd rather use the simpler serial device method, if possible. Is this not possible?
Why?
I'm setting up a multi-drop RS485 network and planning to use one of these lines as a common signal line that can be used to signal "ready", "error" and to prevent communication collisions.
It turns out that the problem was with the stock FTDI driver that comes with OS X. (see post) Updating to the latest VPC driver fixed it.
I have two xbee's series 1. I have them as endpoint devices working in API mode and talking to each other. The first xbee is attached at a raspberry pi, while the other is on my pc where I see the terminal tab of XCTU program. The baud rate I use is 125000.
From raspberry pi I try to send a jpg image which is 30Kbytes. I send data frames 100 byte long (the biggest as it is said in the xbee documentation). Inside a loop I create and send the packets, I have also a cout statement that prints the loop number. Everything is fine and all bytes are sent. When I comment out the cout statement not all bytes are sent.
From what I have understood the cout statement works as a delay between packets, but I still cannot understand why is this happening as it is supposed that I use the half speed ...
I hope I was clear and look forward for a reply.
UPDATE
Just to summarize, i changed baud rate to 250000 where there is the same behavior as in 125000. I also implemented hardware flow control by checking cts signal. When xbees are in transparent mode I need a delay between sending characters at around 150us. The same goes for api mode too. The difference with 125000 baud rate in api mode was that the delay needed, was enough to be betwween each data packet, but in 250000 the delay is needed between each byte that i send. If i do the above everything goes well.
The next thing i did was to plug both xbees in my pc in transparent mode. I went to terminal tab of xctu software where i chose assemble packet and sent at around 3000 bytes to the other xbee. The result was the same. The second xbee received at about 1500 bytes and then each time that i was sending one byte from the first to the second, the "lost bytes" were being received at packets of 1000. :/
So could anyone know what am I doing wrong?
You should connect the /CTS pin from the XBee module into the Raspberry Pi, and have your routine stop sending data when the XBee de-asserts it.
At higher baud rates, it's possible to stream data into the XBee module faster than it can send to the remote module. The local XBee module uses the /CTS pin to notify the host when its buffers are almost full and the host should stop sending. People refer to this as hardware flow control.
It may be necessary to modify the serial driver on the Raspberry Pi to make use of that signal -- it should pause the transmit buffer when de-asserted, and automatically resume sending when re-asserted.
here's what I'm trying to do:
I have 4 clocks and one PC on the network. I (PC) want to get the time from any of the clocks.
The idea:
Every clock uses UDP Broadcast (broadcast because I don't know the PC's IP). The PC gets a first dataset(time) and from then on only looks at datasets from this clock. (To not get confused by slight timedifferences between the clocks)
Clocks=Clients:
- socket
- bind to port 1234
- sendto(broadcast,'1234')
PC=Server
- socket
- bind to port 1234
- recvfrom(data,client_addr) //extract client_addr from first received data
- connect(client_addr) //to only receive data from this client
- recvfrom()
1: Is this the correct way to do this? Or is there a better option?
2: What can I do, if I want more than one application on the PC to get the time-data? Can I just copy the code and use it? My impression was, that port 1234 is now blocked from the first application that gets the bind.
(I guess SO_REUSEADDR won't work because only ONE application then gets the data AND I don't know which one it is going to be)
Regards
1: Is this the correct way to do this?
Yes.
Or is there a better option?
Can't think of one off-hand.
2: What can I do, if I want more than one application on the PC to get the time-data?
Use SO_REUSEADDR.
Can I just copy the code and use it?
Yes.
My impression was, that port 1234 is now blocked from the first application that gets the bind.
No.
(I guess SO_REUSEADDR won't work because only ONE application then gets the data AND I don't know which one it is going to be)
Wrong guess. Why guess about it at all? Why not try it? Much more reliable than guessing, and quicker than asking questions here too.
I have an Arduino with a WiFly shield, everything works perfectly!
The thing is, when I want to turn on an LED, I open in my
webbrowser:
192.168.1.120/ledon/
(I made a program which handles this URL).
But the thing is; when I make a request, I must wait 1-2 seconds before I can do another one.
So, it is very long, and if I want to control motors, it is just too long.
So, instead of using an HTTP request, I want to use something else which can be faster.
Something "super fast".
I just need to tell the Arduino:
- go direction 1
- go direction 2...
- turn on LED
- turn off LED
- tell me the light level (which return a int)
So it is just about a small amount of data.
Can you show me a way? (Telnet, UDP, OSC?)
For your arduino, have a look at just using sockets or even encoding the data in the URL requested.
You shouldnt get less than about 0.8 Seconds Lag maximum.
How big is your program for handling the Url /ledon/ ?
Using pure packets (usually TCP) from your computer to the arduino is faster sometimes..
But you may need to code a application to handle the packets on the pc.
There is the option of Javascript to parse data back and forth e.g. reading the light level and such.