When developing a PCIe - Ethernet driver in Wince 7 .
Send packet is working fine but on receive when we dump buffer at miniport layer we are receiving the packet but once sent to NDIS we don't get any flags or acknowledgement from NDIS to Miniport .
Is there any API or OID or function helping on this cause ?
Related
I have two two about BLE technology.
1)How to ensure the packet can be transferred under connected mode (FEC forward error correction??)
understand the impact of packet loss (in both broadcast & connected mode). For connected mode, if packet loss, will the packet error correction / sequence number / CRC will help to correct it and retransmit the packet?? For broadcast mode, any ack after receiving the packet by the Gateway or just keep transmit by the client device with the same packet information for a while??
I expeceted the BLE have the correction mechanism, but i am not sure
I have a VM (installed Linux) and I want to make a raw socket that sends it to the computer, in Wireshark it says that the packet was sent but it didn't arrive. I saw that I should configure a bridge network adapter but I don't know anything about that except it connects between VM to host. When I configure this adapter, my mac, and IP change so what my packet fields would be?
I am using Scapy to create an SSDP protocol discovery packet for all devices (ssdp:all) however suddenly I am not getting any response from the devices when I did get them before. I am using a Ubuntu VM. This is the code I am using to create the packet.
ssdpPacket = IP(dst="239.255.255.250")/UDP(sport=6700,dport=1900)/Raw(load='M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nST:ssdp:all\r\nMAN:"ssdp:discover"\r\nMX: 2\r\n\r\n')
send(ssdpPacket)
In wireshark, I see that it does send the packet but no response. I am kind of frustrated because it worked before and now its just not working. Help!!
I have a problem with UDP messages under Python3 on Windows10.
The UDP messages are a command/response scheme.
Example: CMD_TURN_ON_LIGHT_BULB, Bulb #4
Response: RSP_TURN_ON_LIGHT_BULB, Bulb #4 - OK.
My local Windows PC address is: 10.1.1.10
In all cases, the netmask here is 255.255.255.0
The remote device has 2 network addresses.
There are various routers between the PC and the remote device.
Device Address (A) is 10.2.2.10 (and is the "default route").
Device Address (B) is 10.3.3.10 (it is a backup interface)
Case 1: This works.
PC sends UDP to 10.2.2.10 (it uses "sendto()")
The remote device responds to the source address using sendto()
The PC receives the response, and the application receives the response.
The PC has a pending/waiting "recvfrom()"
Case 2: This does not work.
PC Sends UDP to 10.3.3.10 (the backup interface)
The remote device replies -
However - due to default route rules, the device replies from 10.2.2.10
The PC receives the reply (I see the reply/response in Wireshark)
The PC has the firewall 100% disabled
But - The application does not receive the UDP message from the remote device.
Any suggestions?
Stated differently:
This works: Transmit to UPD address (A), Port X - reply from: A, port Y
This fails: Transmit to UDP address (B), port X - reply from: A, port Y
The second case, the packet seems to be lost inside the bowels of Windows...
I recently got hands on an workout device which has a USB to PC interface and logs workouts on a lousy Windows Application. My intention is to read out the USB and build a custom application for presenting that data.
When connected to a linux machine the device registers in /dev/ttyUSB0, can be seen with lsusb and stty reports the baudrate among other information. I fire up minicom with the stty settings and as soon as the workout is initiated the device sends a series of 41 bytes
I assume that those bytes represent an announcement to the the PC interface.
What I would like to do is to imitate the workout device and send those 41 bytes to the PC interface myself in order to see what the PC side does upon initiation. Is there a way to imitate the device so that the PC software will recognize it?
if the device is /dev/ttyUSB0 it is very likel implementing a virtual COM port, this is USB Communication Device class CDC (ACM).
the operating system knows what driver / kernel module it has to load because when you plug in the device in USB protocol descriptors are exchanged ( the device sends its device descriptor to the host, according to this the host loads the driver / kernel module ), you can see this information with lsusb -v. Specifically the device sends the following descriptors to the host : device descriptor, configuration descriptor, interface descriptor, endpoint descriptor : http://www.beyondlogic.org/usbnutshell/usb1.shtml
for imitating a device you have to write a firmware on a MCU with exaclty these descriptors and additionally with identic VID ( vendor id ) and PID ( product id )
the 41 bytes you receive flow over the virtual COM port and so in RS-232 protocol ( you are able to receive them with minicom ) and so they are above USB level, however they are part of the payload in USB packets. if you have a proprietary driver in windows of your device in windows these 41 bytes are very likely addressed to the driver ( whichs source code you very likely do not have ...). this is very common there are multimeters with RS-232 interface and one has to send a D = 44 (hex) = 01000100 (bin) to receive any data
so you can try to sniff the virtual COM port ( RS-232 protocol ) directly using a RS-232 sniffer, i.e. https://www.eltima.com/rs232-sniffer.html
alternatively you can try is to sniff the underlying USB traffic with wireshark ( or usbmon in linux ) and extract the payload from the USB packets to record the communication between the windows driver and ther device
https://ask.wireshark.org/question/36/how-to-capture-usb-packets-please/
https://www.youtube.com/watch?v=EfkC7kmIMt8 ( USB in Wireshark )
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
( https://www.kernel.org/doc/html/v4.13/driver-api/usb/URB.html )