ndisproto sample not reading any traffic - driver

i was trying to get familiar with ndisproto samples in wdk. As per the doc, the -r -n 10 option should read 10 packets off the interface, but nothing in result even if I ping to the interface! The only time it reads traffic is when we use write option.
The sample is same, without any modification other than altering to #define NPROTO_PACKET_FILTER (NDIS_PACKET_TYPE_ALL_LOCAL|NDIS_PACKET_TYPE_PROMISCUOUS).
Is the driver really wired to read traffic originating from other sources?
What am I missing? Any idea how to read/sniff the traffic using ndisproto?
C:\Users\Administrator\Desktop\ndisprot>prottest.exe -r -n 10 \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Option: NumberOfPackets = 10
Trying to access NDIS Device: \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Opened device \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8} successfully!
Trying to get src mac address
GetSrcMac: IoControl success, BytesReturned = 14
Got local MAC: 00:0c:29:23:b1:09
DoReadProc
C:\Users\Administrator\Desktop\ndisprot>prottest.exe -w -n 1 \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Option: NumberOfPackets = 1
Trying to access NDIS Device: \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8}
Opened device \DEVICE\{17152850-6288-471A-9708-2889E7F55EE8} successfully!
Trying to get src mac address
GetSrcMac: IoControl success, BytesReturned = 14
Got local MAC: 00:0c:29:23:b1:09
DoWriteProc
DoWriteProc: sent 100 bytes
DoWriteProc: finished sending 1 packets of 100 bytes each
DoReadProc
DoReadProc: read pkt # 1, 100 bytes
DoReadProc finished: read 1 packets

Got the answer at last. The reason is, the driver sample is specifically designed to send/receive EAP over LAN frames, not all. There are a couple of break statements in NdisprotReceiveNetBufferLists that prevents any other packets other than frames of ethertype 0x888E from reaching the client app.
Same is the case for send.

Related

SPI on Beagleboard Black

I've been trying to make the serial communication work on my BBB for days now and I am running out of ideas.
When I use just the BBB and connect MISO/MOSI I get the signal transfer on MOSI, SCLK and CS (MISO is mainly at high level). However, when I connect the lines to my slave part it does not work. I checked the signals on the oscilloscope and they seem fine and the part which I am using as the slave is working well when I set it in parallel mode, so I believe some programming or configuration must be wrong.
This is basically what I do:
config-pin P9.17 spi_cs
config-pin P9.18 spi
config-pin P9.21 spi
config-pin P9.22 spi_sclk
python
from Adafruit_BBIO.SPI import SPI
spi = SPI(1,0) #I would expect SPI(0,0) here, but I get the signal on the above configured ports
Then I set the configurations (already tried in many ways):
spi.mode = 0
spi.cshigh = False
spi.msh = 10500000
spi.bpw = 16
spi.lsbfirst = False
After that I open it and try to send data:
spi.open(1,0)
spi.xfer2([1,254])
If anyone is interested, I am trying to program the LMH6517 as slave and I already tried to ask about this at the TI forum here:
https://e2e.ti.com/support/amplifiers/f/14/t/751415
Oscilloscope images:
CS and SCLK
MOSI and SCLK
MISO and SCLK
Thank you,
JPL

UART data error when using uart.alt(1)

I am trying to acquire rs232 data from a device connected to the ESP8266 (data will then be sent our via http/wifi).
I am using max3232 IC to provide the necessary 3.3v TTL to the ESP8266.
I have have connected the max3232 (pin 12) to GPIO pin 13 (rx) on the ESP8266 (I am only receiving data not sending data, so only the rx pin is connected).
The code i am using:
--
--file: test2.lua
--
tst2 = require "tst2"
tst2.start()
--tst2.lua (testing script)
local module = {}
function module.start()
print("in tst2.start")
uart.alt(1) --use alt GPIO pin 13 (Rx)
uart.setup(0, 9600,8, uart.PARITY_NONE, uart.STOPBITS_1,0)
uart.on("data",10,
function(data)
file.open("data.tmp", "w+")
file.writeline("starting")
for i=1,10 do
file.writeline(string.byte(string.sub(data,i,i)) )
end
file.writeline("from uart: ", data)
file.writeline("finished")
file.close()
end, 0)
uart.alt(0) --switch back to standard Rx/Tx pins
end
return module
The rs232 device connected to the ESP8266 is putting out a single alphabetic character every 3 seconds, however the data written to file (data.tmp) is as follows
starting
10
13
10
13
10
13
10
13
10
13
from uart:
finished
file.close()
Problems:
1- The rs232 device is not issuing any newln or cr characters, but these are appearing in the data file.
2- the string "file.close()" is being written to the data file, and looks like it is the actual lua command that follows the final file.writeline command.
3- the alphabetic data is not appearing in the data file.
4- switching back to the standard uart pins via uart.alt(0) does not work (the ESP8266 must be rebooted - this is not a major issue as the standard uart pins are only used during debugging).
I am writing the rs232 data to a file instead of simply printing it out on the screen (I am using ESPlorer v0.2.0) because the uart.alt(1) command redirects the serial port to the alternative ESP8266 gpio pins.
I think I am doing something fundamentally wrong with the uart set up, but i can't tell what it is.
SOLVED:
It appears that you can't connect the ESP8266 to both the serial port for debugging (e.g. the serial port on a pc running ESPlorer) and also have the alternate serial pins (ESP8266 GPIO 13 and 15) connected (to an external serial device) at the same time.
The nodemcu uart.alt() function does not appear to "turn off" the standard serial i/o pins.
Disconnecting the pc from the standard serial i/o pins solved the problem (debugging becomes an issue, but there are work-arounds to resolve this).
(updated) one workaround is to use a simple telnet server to interact with the lua interpreter. you can either connect the ESP8266 to your wifi router or, even better, set it up as an access point (AP) so that all you have to do is to connect your computer to it and then simply telnet in (to the gateway's IP). so, in addition to the telnet code, you'll need set up the AP in your init.lua. full code for the telnet server and the AP setup is below. A nice benefit is that I can program and monitor the ESP8266 from my phone using an off-the-shelf telnet app!
jj = [[
sock = 22 -- just a placeholder, so it stays global. may not be needed.
-- use sock:send("hello") to insert your own custom output to the client.
telnet_srv = net.createServer(net.TCP, 180)
telnet_srv:listen(2323, function(socket)
local fifo = {}
local fifo_drained = true
local function sender(c)
if #fifo > 0 then
c:send(table.remove(fifo, 1))
else
fifo_drained = true
end
end
local function s_output(str)
table.insert(fifo, str)
if socket ~= nil and fifo_drained then
fifo_drained = false
sender(socket)
end
end
sock = socket -- make the socket globally available.
node.output(s_output, 0) -- re-direct output to function s_ouput.
socket:on("receive", function(c, l)
node.input(l) -- works like pcall(loadstring(l)) but support multiple separate line
end)
socket:on("disconnection", function(c)
node.output(nil) -- un-regist the redirect output function, output goes to serial
end)
socket:on("sent", sender)
print("Welcome to NodeMCU world.")
end)
]]
file.open("telnet.lua", "w")
file.write(jj)
file.close()
jj = [[
wifi.setmode(wifi.STATIONAP);
wifi.ap.config({ssid="ESPtest",pwd=""});
print("Server IP Address:",wifi.ap.getip())
dofile("telnet.lua")
]]
file.open("init.lua","w")
file.write(jj)
file.close()
node.restart()
output:
Server IP Address: 192.168.4.1 255.255.255.0 192.168.4.1
>

RadioTap headers in scapy

I'm trying to send and receive packets with scapy and read the RadioTap Header. The wireless adapter (and driver) is able to handle those headers, but I can't seem to get them.
Whenever I send a normal packet in scapy, is does not contain such a header (thus, sniffing packets and checking one with pkt.haslayer(RadioTap) returns 0, and I am not able to display the header like with pkt[RadioTap].show() ).
If I explicitly construct my packets with a RadioTap header (like in a
pkt = RadioTap() and view it, I can get a RadioTap header, but it is empty. After sending it and receiving it, I can get still nothing.
I read posts like this one. But I don't have the problem that the RadioTap header doesn't get decoded, it's simply not filled with anything.
I'm using scapy 2.3.1, if this makes any difference. Any ideas?
Please make sure that your wireless interface and the driver support monitor mode.
$ iw list
...
Supported interface modes:
* IBSS
* managed
* AP
* AP/VLAN
* monitor <-- here
* P2P-client
* P2P-GO
* P2P-device
And your interface is configured to monitor mode with a specific channel (e.g. ch=6).
$ sudo ip link set wlan0 down
$ sudo iw dev wlan0 set type monitor
$ sudo ip link set wlan0 up
$ sudo iw dev wlan0 set channel 6
It is also good idea to try with tools like wireshark first to see if RadioTap is visible.

ESP8266 with NodeMCU firmware: receiving empty messages with secured MQTT subscription

I'm trying to securely connect ESP8266 to MQTT Azure Protocol Gateway broker on cloud or local computer (tried both) like this (not important - connection works correctly):
m = mqtt.Client("{deviceId}", "3600", "{iotHub}/{deviceId}", "{SASToken}")
...
m:on("message", function(conn, top, data)
print(data) -- EMPTY string here!
end)
...
m:connect({IP}, 8883, 1, function(conn)
m:subscribe("devices/{deviceId}/messages/devicebound/#", 1, function(conn)
...
end)
end)
ESP connects to server and handshake is completed successfully. When I publish some data, I can read it on server properly, it is OK. I subscribe to topic without problems. When I send data in cloud-to-device message from server to ESP to subscribed topic, 'on message' event is called but data attribute passed to the function is EMPTY string.
I'm using latest NodeMCU master build based on 1.4.0 SDK (tried both integer and float version). I can't turn on debugging, because i don't have NodeMCU developer yet.
I tried following:
dev version - not help
free memory up to 32kB - not help
captured packets with WireShark: packets contain encrypted data with some lenght, so it is not empty and packet size is less than 2kB buffer size
Can someone please advise me where could be a problem or how to debug it for more info? I would approciate any ideas. Thank you.
EDIT:
I've tried debug mode, and there is nothing interesting on output:
enter mqtt_socket_received.
MQTT_DATA: type: 3, qos: 0, msg_id: 0, pending_id: 0
enter deliver_publish.
string
userdata: 3fff3e88
devices/ESP/messages/devicebound
<- here should be printed data
On
leave deliver_publish.
receive, queue size: 0
leave mqtt_socket_received.
enter mqtt_socket_timer.
timer, queue size: 0
keep_alive_tick: 71
leave mqtt_socket_timer.
enter mqtt_socket_received.
MQTT_DATA: type: 7, qos: 1, msg_id: 8813, pending_id: 0
receive, queue size: 0
leave mqtt_socket_received.
This may be stupid but sometimes lua expects specific names in some functions.
Change this
function(conn, top, data)
for this
function(conn, topic, data)
I have worked previously with mqtt in lua with password protection, and i had to drop it beacuse i wasnt recieving the message content either, however i think mine was due to the amount of messages i was recieving/delivering. I also changed broker from mosquitto to mosca.
I hope you find a fix soon and please share it we might be able to use it to :)

Identifying file causing hang from strace

I have a GTK program running on Ubuntu 10.04 that hangs in interruptible state, and I'd like to understand the output of strace. In particular, I have this line:
read(5, 0x2ba9ac4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
I suspect 5 is the file descriptor, 0x2ba9ac4 the address in this file to be read, and 4096 the amount of data to read. Can you confirm? More importantly, how can one determine which file the program is trying to read? This file descriptor does not exist in /proc/pid/fd (which is probably why the program hangs).
You can find which file uses this file descriptor by calling strace -o log -eopen,read yourprogram. Then search in the log file the call to read of interest. From this line (and not from the first line of the file), search upwards the first occurrence of this file descriptor (returned by a call to open).
For example here, the file descriptor returned by open is 3:
open("/etc/ld.so.cache", O_RDONLY) = 3
The second argument to read() is simply the destination pointer, it's asking for a read from file descriptor 5, and max 4096 bytes. See the manual page for read().
Adding to #liberforce answer, if the process is already running you can get the file name using lsof
form strace
[pid 7529] read(102, 0x7fedc64c2fd0, 16) = -1 EAGAIN (Resource temporarily unavailable)
Now, with lsof
lsof -p 7529 | grep 102
java 7529 luis 102u 0000 0,9 0 9178 anon_inode

Resources