I have the following problem: I have a Wintec WBT-202 GPS device which has the ability to transmit the location data live as NMEA data over USB. Inside this USB it is just a USB to serial bridge which is run under Windows using the standard usbser.sys driver.
My problem is to get it working under Mac OS X.
The hardware the USB GPS mouse uses an Atmel AT91SAM7S256 chip which also is responsible for the USB interface.
The problem under Mac OS X there is nothing happening. There is no new character device created under /dev to make this device accessible.
Under Windows the standard driver usbser.sys is used. There is just an .inf file pointing the vendorID and productID to this driver.
From using Snoopy Pro on Windows (a USB sniffing software) I know that once the device is properly initialized it sends the data as ASCII NMEA strings, which is all I want.
Question 1 Is there an usbser.sys equivalent for Mac OS X? If yes, could a codeless kext be used to make sure driver matching occurs properly?
If this would not work, I would use IOKit from user space to send and receive messages to the device. I still have questions of how this would work in detail, because I do not fully understand apple's documentation. If a USB device is connected, driver matching occurs. what happens if no driver is found.
Question 2 Could it be that then some generic USB driver is loaded to which I am able to "talk to" in the kernel from user space? How do I know that the right driver is loaded?
Question 3 I saw that there was a "getting started with I/O Kit" session in WWDC08 is there a way to get access to this session video?
I have appended some logs of USBProbe and the I/O registry excerpt.
Any comments about how I could start which documentation provides a decent tutorial would be greatly appreciated.
I have looked into Mac OS X Internals - A System Internals by Amit Singh, Apple's documentation "Getting started with I/O Kit", "I/O Kit Fundamentals Guide" and the USB private data sample.
APPENDIX
USB Probe
Full Speed device # 8 (0xFD360000): ............................................. Communication device: "WINTEC WBT202 CDC"
Port Information: 0x0019
Captive
External Device
Connected
Enabled
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 2 (Communication)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 8
Device VendorID/ProductID: 0x03EB/0x6119 (Atmel Corporation)
Device Version Number: 0x0100
Number of Configurations: 1
Manufacturer String: 0 (none)
Product String: 1 "WINTEC WBT202 CDC"
Serial Number String: 0 (none)
Configuration Descriptor
Length (and contents): 67
Raw Descriptor (hex) 0000: 09 02 43 00 02 01 00 C0 32 09 04 00 00 01 02 02
Raw Descriptor (hex) 0010: 00 00 05 24 00 10 01 05 24 01 01 00 04 24 02 02
Raw Descriptor (hex) 0020: 05 24 06 00 01 07 05 83 03 40 00 0A 09 04 01 00
Raw Descriptor (hex) 0030: 02 0A 00 00 00 07 05 01 02 40 00 00 07 05 82 02
Raw Descriptor (hex) 0040: 40 00 00
Number of Interfaces: 2
Configuration Value: 1
Attributes: 0xC0 (self-powered)
MaxPower: 100 ma
Interface #0 - Communications-Control
Alternate Setting 0
Number of Endpoints 1
Interface Class: 2 (Communications-Control)
Interface Subclass; 2
Interface Protocol: 0
Comm Class Header Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 00 10 01
Comm Class Call Management Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 01 01 00
Comm Class Abstract Control Management Functional Descriptor
Raw Descriptor (hex) 0000: 04 24 02 02
Comm Class Union Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 06 00 01
Endpoint 0x83 - Interrupt Input
Address: 0x83 (IN)
Attributes: 0x03 (Interrupt no synchronization data endpoint)
Max Packet Size: 64
Polling Interval: 10 ms
Interface #1 - Communications-Data/Unknown Comm Class Model
Alternate Setting 0
Number of Endpoints 2
Interface Class: 10 (Communications-Data)
Interface Subclass; 0 (Unknown Comm Class Model)
Interface Protocol: 0
Endpoint 0x01 - Bulk Output
Address: 0x01 (OUT)
Attributes: 0x02 (Bulk no synchronization data endpoint)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x82 - Bulk Input
Address: 0x82 (IN)
Attributes: 0x02 (Bulk no synchronization data endpoint)
Max Packet Size: 64
Polling Interval: 0 ms
IO Registry
8: WINTEC WBT202 CDC#fd360000 <class IOUSBDevice>
AppleUSBCDC <class AppleUSBCDC>
IOUSBInterface#0 <class IOUSBInterface>
AppleUSBCDCACMControl <class AppleUSBCDCACMControl>
IOUSBInterface#1 <class IOUSBInterface>
bcdDevice 256 (0x100)
bDeviceClass 2 (0x2)
bDeviceProtocol 0 (0x0)
bDeviceSubClass 0 (0x0)
bMaxPacketSize0 8 (0x8)
bNumConfigurations 1 (0x1)
Bus Power Available 250 (0xfa)
Device Speed 1 (0x1)
idProduct 24857 (0x6119)
idVendor 1003 (0x3eb)
iManufacturer 0 (0x0)
IOCFPlugInTypes
9dc7b780-9ec0-11d4-a54f-000a27052861 IOUSBFamily.kext/Contents/PlugIns/IOUSBLib.bundle
IOGeneralInterest IOCommand is not serializable
IOUserClientClass IOUSBDeviceUserClientV2
iProduct 1 (0x1)
iSerialNumber 0 (0x0)
locationID -46792704 (0xfd360000)
Low Power Displayed No
non-removable yes
PortNum 6 (0x6)
Requested Power 50 (0x32)
sessionID 1167822359 (0x459b8e17459b8e17)
USB Address 5 (0x5)
USB Product Name WINTEC WBT202 CDC
USB probe log on device attach
12.719 [5] AppleUSBHub[0x6805a00]::ProcessStatusChanged found (0x 40) in statusChangedBitmap
12.719 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(+) now (1)
12.719 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: port 6 obtained runLock
12.719 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: calling GetPortStatus for port 6
12.719 [5] AppleUSBHub[0x6805a00]::powerChangeDone - spawning _checkForActivePortsThread
12.719 [5] AppleUSBEHCI[0x65ea000]::FindControlBulkEndpoint (inactive) - linking to active list: 65997c0
12.719 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - Hub 0xfd300000 port 6 - Initial status(0x0101)/change(0x0001)
12.719 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - change 4 clearing feature 0x10.
12.719 [5] AppleUSBHub[0x6805a00]::ClearPortFeature port/feature (60010) - clearing
12.719 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - status(0x0101) - change(0x0000) - before call to (4) handler function
12.719 [5] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler - handling port 6 changes (101,0).
12.719 [5] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler port (6) - waiting 100 ms before asserting reset
12.819 [5] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler - port 6 - no existing device found on port
12.820 [4] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler port 6 status(0101)/change(0000) - no error from GetPortStatus
12.820 [5] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler - port 6 - device detected, calling AddDevice
12.820 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(+) now (2)
12.820 [5] AppleUSBHubPort[0x6807200]::DefaultConnectionChangeHandler - port 6 done, ending.
12.820 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - err (0) on return from call to (4) handler function
12.820 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: calling GetPortStatus for port 6
12.820 [5] ***** AppleUSBHubPort[0x6807200]::AddDevice - port 6 on hub at 0xfd300000 - start
12.820 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - Hub 0xfd300000 port 6 - Initial status(0x0101)/change(0x0000)
12.820 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - err = 0 - done, releasing _runLock
12.820 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(-) now (1)
12.820 [3] AppleUSBHub[0x6805a00]::DecrementOutstandingIO(269), outstandingIO(0), _interruptReadPending(false) - rearming read
12.820 [5] AppleUSBHub[0x6805a00]::DecrementOutstandingIO(269) - spawning _checkForActivePortsThread
12.820 [5] ***** AppleUSBHubPort[0x6807200]::AddDevice - port 6 on hub at 0xfd300000 - bus 0x65ea000 - acquiring dev zero lock
12.820 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - about to obtain device zero lock
12.820 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - not already locked - obtaining
12.820 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - setting _devZeroLock to true
12.820 [5] AppleUSBEHCI[0x65ea000]: Acquired Device Zero
12.820 [5] ***** AppleUSBHubPort[0x6807200]::AddDevice - port 6 on hub at 0xfd300000 - resetting port
12.820 [5] AppleUSBHub[0x6805a00]::SetPortFeature port/feature (60004) - setting
12.821 [5] ***** AppleUSBHubPort[0x6807200]::AddDevice - port 6 on hub at 0xfd300000 - (err = 0) done - returning .
12.821 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(-) now (0)
12.879 [5] AppleUSBHub[0x6805a00]::ProcessStatusChanged found (0x 40) in statusChangedBitmap
12.879 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(+) now (1)
12.879 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: port 6 obtained runLock
12.879 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: delaying 100ms before first GetPortStatus after a reset of port 6
12.879 [5] AppleUSBHub[0x6805a00]::powerChangeDone - spawning _checkForActivePortsThread
12.979 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler: calling GetPortStatus for port 6
12.979 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - Hub 0xfd300000 port 6 - Initial status(0x0103)/change(0x0010)
12.979 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - change 1 clearing feature 0x14.
12.979 [5] AppleUSBHub[0x6805a00]::ClearPortFeature port/feature (60014) - clearing
12.979 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - status(0x0103) - change(0x0000) - before call to (1) handler function
12.979 [5] ***** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6 on hub at 0xfd300000 - start - status(0x0103) change (0x0000)
12.979 [5] **1** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6 on hub at 0xfd300000 - delaying 10 ms
12.989 [5] **2** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6 on hub at 0xfd300000 - found full speed device
12.989 [5] **2** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6 on hub at 0xfd300000 - configuring dev zero
12.989 [5] AppleUSBEHCI[0x65ea000]::ConfigureDeviceZero, new method called with hub:3, port:6
12.989 [5] AppleUSBEHCI[0x65ea000]::CreateDevice, high speed ancestor hub:3, port:6
12.989 [5] AppleUSBEHCI[0x65ea000]::DoCreateEP, high speed ancestor hub:3, port:6
12.989 [3] AppleUSBEHCI[0x65ea000]::UIMCreateControlEndpoint(0, 0, 8, 1 #(3, 6))
12.989 [5] **3** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6 on hub at 0xfd300000 - getting dev zero desc
12.990 [5] **3** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6, using 8 for maxPacketSize
12.992 [5] **5** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6, Releasing DeviceZero after successful SetAddress to 5
12.992 [5] AppleUSBEHCI[0x65ea000]::UIMDeleteEndpoint: unlinking async endpoint
12.993 [5] AppleUSBEHCI[0x65ea000]::UIMDeleteEndpoint: Deallocating 0x68bd700
12.993 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - about to release device zero lock
12.993 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - releasing lock
12.993 [5] AppleUSBEHCI[0x65ea000]::ProtectedDevZeroLock - wakeup done
12.993 [5] AppleUSBEHCI[0x65ea000]:: Released Device Zero
12.993 [5] AppleUSBEHCI[0x65ea000]::CreateDevice, new method called with hub:3, port:6
12.993 [5] AppleUSBEHCI[0x65ea000]::CreateDevice, high speed ancestor hub:3, port:6
12.993 [5] AppleUSBEHCI[0x65ea000]::CreateDevice: addr=5, speed=full, power=500
12.993 [5] IOUSBDevice # 5 (500mA available, full speed)
12.993 [5] AppleUSBEHCI[0x65ea000]::DoCreateEP, high speed ancestor hub:3, port:6
12.993 [3] AppleUSBEHCI[0x65ea000]::UIMCreateControlEndpoint(5, 0, 8, 1 #(3, 6))
12.993 [5] IOUSBDevice[0xd335c00]::GetDeviceDescriptor (size 18)
12.994 [5] IOUSBDevice[0xd335c00]::GetStringDescriptor Got string descriptor 1, length 36, got 36
12.994 [5] **10** AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6, at addr: 5, Successful
12.994 [5] AppleUSBHub[0x6805a00]::GetPortInformation for port[6]
12.995 [5] WINTEC WBT202 CDC[0xd335c00]::GetDeviceInformation Hub device name is HubDevice at USB address 3
12.995 [5] AppleUSBHub[0x6656800]::GetPortInformation for port[3]
12.995 [5] AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - Port 6 of Hub at 0xfd300000 (USB Address: 5), calling registerService for device WINTEC WBT202 CDC
12.995 [5] AppleUSBHubPort[0x6807200]::AddDeviceResetChangeHandler - port 6, err = 0, ALL DONE
12.995 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - err (0) on return from call to (1) handler function
12.995 [5] AppleUSBHubPort[0x6807200]::PortStatusChangedHandler - port 6 - err = 0 - done, releasing _runLock
12.995 [3] AppleUSBHub[0x6805a00]::ChangeRaisedPowerState(-) now (0)
12.995 [3] AppleUSBHub[0x6805a00]::DecrementOutstandingIO(274), outstandingIO(0), _interruptReadPending(false) - rearming read
12.995 [5] AppleUSBHub[0x6805a00]::DecrementOutstandingIO(274) - spawning _checkForActivePortsThread
12.999 [5] Finding device driver for WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDC, score: 69000, wildCard = 0
12.999 [5] Finding device driver for WINTEC WBT202 CDC, matching personality using com.apple.iokit.IOUSBUserClient, score: 106999, wildCard = 3
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::handleOpen - [0xdd78880] is not an IOUSBInterface
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::TakeGetConfigLock - calling through to ChangeGetConfigLock
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::ChangeGetConfigLock - setting _GETCONFIGLOCK to true
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::GetFullConfigurationDescriptor - Index (0) - getting first 4 bytes of config descriptor
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::GetConfigDescriptor (length: 4)
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::GetFullConfigurationDescriptor - Index (0) - getting full 67 bytes of config descriptor
13.002 [5] WINTEC WBT202 CDC[0xd335c00]::GetConfigDescriptor (length: 67)
13.003 [5] WINTEC WBT202 CDC[0xd335c00]::ReleaseGetConfigLock - calling through to ChangeGetConfigLock
13.003 [5] WINTEC WBT202 CDC[0xd335c00]::ChangeGetConfigLock - setting _GETCONFIGLOCK to false and calling commandWakeup
13.503 [5] WINTEC WBT202 CDC[0xd335c00]::TerminateInterfaces interfaceList 0 terminate: 1
13.503 [5] WINTEC WBT202 CDC[0xd335c00]::SetConfiguration to 1
13.504 [5] WINTEC WBT202 CDC[0xd335c00]::SetConfiguration Found InterfaceDescription[0] = 0x68bc889
13.504 [5] WINTEC WBT202 CDC[0xd335c00]::SetConfiguration Found InterfaceDescription[1] = 0x68bc8ac
13.504 [5] WINTEC WBT202 CDC[0xd335c00]::RegisterInterfaces interfaceArray 0x6de9b00
13.504 [5] WINTEC WBT202 CDC[0xd335c00]::RegisterInterfaces matching to interface = 0x8261700
13.553 [5] Finding driver for interface #0 of WINTEC WBT202 CDC, matching personality using com.apple.iokit.IOUSBUserClient, score: 104999, wildCard = 5
13.567 [5] Finding driver for interface #0 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCACMControl, score: 50000, wildCard = 0
13.570 [5] AppleUSBEHCI[0x65ea000]::DoCreateEP, high speed ancestor hub:3, port:6
13.570 [5] AppleUSBEHCI[0x65ea000]: UIMCreateInterruptEndpoint endpoint does NOT exist (this is normal)
13.570 [5] AppleUSBEHCI[0x65ea000]::AllocateInterruptBandwidth - pED[0x68bd780] _speed(1)
13.570 [3] AppleUSBEHCITTInfo[0x682b400]::AllocatePeriodicBandwidth: pSPE[0x6f8ae40]
13.570 [5] AppleUSBEHCISplitPeriodicEndpoint[0x6f8ae40]::FindStartFrameAndStartTime - _FSBytesUsed (78)
13.570 [5] AppleUSBEHCISplitPeriodicEndpoint[0x6f8ae40]::FindStartFrameAndStartTime - using Start Time entry found - _startFrame(1) _startTime(36)
13.570 [5] AppleUSBEHCI[0x65ea000]::AllocateInterruptBandwidth - returning 0x0(success)
13.571 [5] AppleUSBHub[0x6805a00]::powerChangeDone - spawning _checkForActivePortsThread
13.573 [5] WINTEC WBT202 CDC[0xd335c00]::RegisterInterfaces matching to interface = 0xd337700
13.621 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.iokit.IOUSBUserClient, score: 104999, wildCard = 5
13.636 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCACMData, score: 50000, wildCard = 0
14.024 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCACMData, score: 50000, wildCard = 0
14.075 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.iokit.IOUSBUserClient, score: 104999, wildCard = 5
14.089 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCACMData, score: 50000, wildCard = 0
14.090 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCECMData, score: 50000, wildCard = 0
14.266 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCECMData, score: 50000, wildCard = 0
14.315 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.iokit.IOUSBUserClient, score: 104999, wildCard = 5
14.330 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCACMData, score: 50000, wildCard = 0
14.330 [5] Finding driver for interface #1 of WINTEC WBT202 CDC, matching personality using com.apple.driver.AppleUSBCDCECMData, score: 50000, wildCard = 0
14.334 [5] WINTEC WBT202 CDC[0xd335c00]::SetConfiguration returning success
EDIT: appended the log file excerpt from console.app after device attach
16.02.11 09:05:55 kernel 0 0 AppleUSBCDCACMControl: getFunctionalDescriptors - Descriptors are incorrect, checking...
16.02.11 09:05:55 kernel 0 1 AppleUSBCDCACMData: start - Find CDC driver for data interface failed
The answer I got from posting to Apple's USB mailing list is that the Apple AppleUSBCDCACMData driver has a bug in it preventing from doing its work. I filed a bug on Apple's radar and hope they will fix it soon.
It looks like the system's CDC driver is matching correctly, which should create /dev/ttyusbmodem* IIRC, I'd check the system logs for error messages in case this isn't working.
If u are a USB Driver programmer, u should download the source code for AppleUSBCDCDriver project, which contains AppleUSBCDCDriver.kext, AppleUSBCDCACMControl.kext, AppleUSBCDCACMData.kext, AppleUSBCDCECMControl.kext, AppleUSBCDCECMData.kext.
What i can promise is that, u definitly could solve this issue by fix the code and build your own driver.(Remember to change the driver's class name.)
What i can confirm is that, the AppleUSBCDCDriver is mainly designed according to the Standard Communication Device Class Specification, and including the consideration by Apple Developement Team, and this issue should not be a bug.
On Mac OS, driver matching is mainly according to the info.plist of the driver, just like .inf file on Windows.
There is a workaround for the bug mentioned in AppleUSBCDCACMData. You need to assign an interface to the call management descriptor. You have it set to 00.
You show:
Comm Class Call Management Functional Descriptor
Raw Descriptor (hex) 0000: 05 24 01 01 00
That lacks and assignment. Using the ATMEL USB libraries, it would look like this:
// Class-specific call management functional descriptor`
{ sizeof(CDCCallManagementDescriptor),
CDCGenericDescriptor_INTERFACE,
CDCGenericDescriptor_CALLMANAGEMENT,
CDCCallManagementDescriptor_SELFCALLMANAGEMENT,
1 // <--needed for MacOS
}
Related
I tried to do some write/read operations on filesystems that I have enumerated for. The problem is when I want to write to other volumes rather than my self (fs0), it will return WRITE PROTECTED Error.
... Enumerated and opened all available volumes successfuly
efiStatus = root->Open(root, &token, L"xxx", EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE | EFI_FILE_MODE_CREATE, 0);
if (efiStatus == EFI_SUCCESS)
{
char* myStr = "Sample Content";
UINTN myStrSize = strlenEx(myStr);
efiStatus = token->Write(token, &myStrSize, myStr);
if (efiStatus != EFI_SUCCESS)
{
Print(L"[X] ! Error [%r]!\n", efiStatus);
}
Print(L"Found Some\n", efiStatus);
}
I Also tried ShellCreateDirectory, ShellWriteFile. Do I really can access write hard disk (pci) from EFI Application?
EDIT:
drivers command output:
T D
D Y C I
R P F A
V VERSION E G G #D #C DRIVER NAME IMAGE NAME
== ======== = = = == == =================================== ==========
43 00000014 D - - 1 - AMI USB Driver Uhcd
45 00000014 B - - 1 4 USB bus Uhcd
46 00000002 D - - 3 - USB Hid driver Uhcd
47 00000001 D - - 1 - USB Mass Storage driver Uhcd
85 00010000 ? - - - - AMI ExFat Driver EXFAT
86 00010000 D - - 5 - AMI NTFS Driver NTFS
89 00000001 D - - 2 - <null string> MouseDriver
8B 00000001 B - - 1 3 AMI AHCI BUS Driver Ahci
8F 00000001 ? - - - - AMI NVMe BUS Driver Nvme
123 00000010 D - - 1 - Serial ATA Controller Initializatio SataController
12E 00000010 B - - 1 1 AMI Console Splitter Text Out Drive ConSplitter
12F 00000010 B - - 1 1 AMI Console Splitter Text In Driver ConSplitter
130 00000010 B - - 1 1 AMI Console Splitter Pointer Driver ConSplitter
133 00000010 D - - 1 - AMI Graphic Console Driver GraphicsConsole
134 0000000A D - - 15 - Generic Disk I/O Driver DiskIoDxe
135 0000000B B - - 3 11 Partition Driver(MBR/GPT/El Torito) PartitionDxe
137 00000000 ? - - - - Integrated Touch Driver IntegratedTouch
13A 00000010 B - - 1 5 AMI Generic LPC Super I/O Driver GenericSio
13C 00A50110 B - - 1 15 AMI PCI Bus Driver PciBus
13E 00000010 ? - - - - AMI PS/2 Driver Ps2Main
13F 00000000 ? - - - - DNS Network Service Driver DnsDxe
140 00000000 ? - - - - DNS Network Service Driver DnsDxe
145 0000000A D - - 2 - FAT File System Driver Fat
147 00010001 ? - - - - AMI ISO9660 File System Driver FsIso9660
149 00000001 ? - - - - <null string> PcieSataController
14A 00000001 ? - - - - <null string> PcieSataController
14B 0000001B B - - 1 3 Intel(R) RST 16.0.2.3402 RAID Drive RaidDriver
159 09000432 B - - 1 1 Intel(R) GOP Driver [9.0.1074] MemoryMapped(0x3,0x845F3018,0x846040D8)
My educated guess is that you trying to access NTFS volume (since you talked about Windows partitions) and NTFS is not supported by UEFI (by default). At least, I haven't seen any firmware that does. UEFI supports FAT32 file systems only.
If you drop into UEFI shell on your platform you should see the "Mapping table" (see the sample picture below), if there is a device labeled "FS0". This indicates that the firmware detected the disk, discovered the partition, and was able to mount the file system. The rest of the volumes labeled as BLK, which means UEFI can give the access using BlockIO Protocol only. No FS Protocol support.
I've created a LXC container in Ubuntu 18.04. Physically, there is an USB to Ethernet adapter connected on the host machine. After starting the LXC container, how to access the USB ethernet adapter? Are there configurations for LXC to do?
The info on the Host machine:
rui#rui-desktop:~$ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet6 fe80::f763:92fe:8145:163 prefixlen 64 scopeid 0x20<link>
ether 00:0e:c6:c9:1a:18 txqueuelen 1000 (Ethernet)
RX packets 1 bytes 46 (46.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 158 bytes 29470 (29.4 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1430
inet 173.39.202.159 netmask 255.255.255.128 broadcast 173.39.202.255
inet6 fe80::2e0:4cff:fe68:12c prefixlen 64 scopeid 0x20<link>
ether 00:e0:4c:68:01:2c txqueuelen 1000 (Ethernet)
RX packets 1911906 bytes 851840909 (851.8 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 350546 bytes 25613552 (25.6 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
device interrupt 149 base 0xd000
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1 (Local Loopback)
RX packets 35420 bytes 2918763 (2.9 MB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 35420 bytes 2918763 (2.9 MB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lxcbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 10.0.3.1 netmask 255.255.255.0 broadcast 0.0.0.0
inet6 fe80::216:3eff:fe00:0 prefixlen 64 scopeid 0x20<link>
ether 00:16:3e:00:00:00 txqueuelen 1000 (Ethernet)
RX packets 859 bytes 86124 (86.1 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 831 bytes 88890 (88.8 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether be:86:e5:ee:9a:ed txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether be:86:e5:ee:9a:ef txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eth0 is the interface that I want to access, and the output from lsusb is
rui#rui-desktop:~$ lsusb
Bus 002 Device 002: ID 0bda:0411 Realtek Semiconductor Corp.
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
**Bus 001 Device 015: ID 0b95:7720 ASIX Electronics Corp. AX88772**
Bus 001 Device 002: ID 0bda:5411 Realtek Semiconductor Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
LXC container info:
Last login: Sat Feb 24 17:40:28 UTC 2018 on pts/0
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.9.140-tegra aarch64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
cisco#ul:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
40: eth0#if41: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:16:3e:d6:9b:38 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 10.0.3.194/24 brd 10.0.3.255 scope global dynamic eth0
valid_lft 3586sec preferred_lft 3586sec
inet6 fe80::216:3eff:fed6:9b38/64 scope link
valid_lft forever preferred_lft forever
Adding these setting in /var/lib/lxc/ul/config make it working.
lxc.net.1.type = phys
lxc.net.1.link = eth0
lxc.net.1.flags = up
lxc.net.1.hwaddr = 00:0e:c6:c9:1a:18
I am attempting to write a linux driver for a printer. I have run USBSnoop on windows XP and obtained the log. In this log it sets wMaxPacketSize to 1026. After i set the interface i get the response of 75 bytes. If i set it to 64 (in the lsusb output) i obviously only get 64 bytes back.
My issue is on a bulk transfer to/from the device i get timeouts. I think i have the same problem as here: http://libusb.6.n5.nabble.com/libusb-bulk-transfer-return-timeout-error-and-transferred-set-to-0-td5712761.html
I performed the libusb_clear_halt() and i get a similar result to the linked post above. Down the bottom of it says "split buffer into 64 bytes manually" to solve it. My question is how to split the packets? This is my first time using LibUSB.
Here is the output of lsusb -v
Bus 002 Device 009: ID 07ce:c000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 7 Printer
bDeviceSubClass 1 Printer
bDeviceProtocol 2 Bidirectional
bMaxPacketSize0 64
idVendor 0x07ce
idProduct 0xc000
bcdDevice 1.00
iManufacturer 1 COPAL
iProduct 2 COPAL USB Printer
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 200mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 7 Printer
bInterfaceSubClass 1 Printer
bInterfaceProtocol 2 Bidirectional
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 0.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 0
bNumConfigurations 0
Device Status: 0x0001
Self Powered
Edit: this was in the dmesg
usb 2-1.1: new high-speed USB device number 9 using ehci_hcd
usb 2-1.1: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
usb 2-1.1: config 1 interface 0 altsetting 0 bulk endpoint 0x82 has invalid maxpacket 64
Edit: I think it may be that linux is getting in the way. On wireshark and i can see the packets come back correctly but not calling my callback function. I already removed the usblp driver. Any ideas?
Got a similar problem. Haven't figured out why I get the timeout errors, yet. Though it seems like they occur much more often for larger package sizes. If you want to split your package, just write yourself a function that splits your large buffer[1024] into packages of 64 bytes, then do a loop that always takes the next 64 bytes from the buffer, puts it in a small_buffer[64] and sends them via usb.
I have to IEEE 802.15.4 devices running. The question is about XBee-PRO.
Firmware: XBEE PRO 802.15.4 (Version: 10e6)
Hardware: XBEE (Version: 1744)
Both units are configured to the same channel (15) and same PAN id (0x1234). It's hooked to my machines COM port and can actually transmit data when I connect picocom to it. (It responds to AT commands properly and can be configured fully through moltosenso Network Manager - I'm on a Mac). All other registers are at their defaults, apart from the serial baudrate.
The XBee side source address is at 0x1, destination address is 0x2. Now when I type an ASCII character into picocom, this is what I see received on the other device, running in promiscous mode:
-- Typing "a"
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
E 61 88 7E 34 12 2 0 1 0 2B 0 61 E1
-- Typing "b"
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
E 61 88 7F 34 12 2 0 1 0 2C 0 62 58
--- Typing "a" again
E 61 88 80 34 12 2 0 1 0 2D 0 61 A9
E 61 88 80 34 12 2 0 1 0 2D 0 61 A9
...
ln pc pan da sa ct pl ck
So for every data payload sent, I see four frames sent out (nobody is picking them up of course). I suppose three of these are 802.15.4 retries, and XBee adds another one for kicks (although the RR register is clearly zero...).
What's the packet format here and where is this specified?
I've looked at XBee API packets and this does look vaguely similar, but I don't see 0x7e delimiters or anything like that here.
I guess what I am seeing is:
ln = length
61 = ??
88 = ??
pc = some sort of packet counter
pan = 16 bits of PAN ID
da = 16 bits of destination address
sa = 16 bits of source address
ct = another counter?
0 = ??
pl = my ASCII character payload
ck = probably a checksum
I tried with setting PAN to 0xFFFF and setting the destination address to 0xFF or broadcast, seeing pretty much the same. These 0x61 and 0x88 don't seem to correspond to much anything in the XBee documentation...
It doesn't directly look like 802.15.4 MAC level data frame either - or if it does, what are the missing fields and where are they specified? Pointers?
EDIT:
Actually, hmm. After importing a hex-formatted dump into Wireshark, it told me exactly that it's a 802.15.4 MAC frame and how to read it.
IEEE 802.15.4 Data, Dst: 0x0002, Src: 0x0001, Bad FCS
Frame Control Field: Data (0x8861)
.... .... .... .001 = Frame Type: Data (0x0001)
.... .... .... 0... = Security Enabled: False
.... .... ...0 .... = Frame Pending: False
.... .... ..1. .... = Acknowledge Request: True
.... .... .1.. .... = Intra-PAN: True
.... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x0002)
..00 .... .... .... = Frame Version: 0
10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x0002)
Sequence Number: 126
Destination PAN: 0x1234
Destination: 0x0002
Source: 0x0001
I still don't know where the second 16-bit counter comes from in front of the actual data byte, and why FCS is messed up (I had to strip the beginning len field to get Wireshark to read it - that's probably it.)
I think the second counter ct is a counter for the application layer in Zigbee protocol to notice when it should update its data because it is receiving a new one :)
For more information about Frames Format in Zigbee Stack try to download this :
Newnes.ZigBee.Wireless.Networks.and.Transceivers.Sep.2008.eBook-DDU.pdf
Have a nice day :)
Have you try to read packets with X-CTU software?
I suggest you to read this post entry: http://www.tunnelsup.com/xbee-guide/
The pdf with the "Quick Reference Guide" is really useful and contains some data format indicated.
Also, it's always good to study the real documentation from developer (Digi in this case).
The frame is like:
API Frame
But only if you have configured previously the xbee to work in API mode with command:
ATAP 1
Or with XCTU.
Try monitoring communication between two XBee modules to see what the acknowledgement frame looks like.
Try sending a sequence of bytes.
Try performing a Node Discovery (ATND) to see what those frames look like.
Try sending a remote AT command from X-CTU to see what those frames and responses look like.
When reverse engineering a protocol, it's useful to see both sides of the conversation. You can test various theories by emulating each side of the protocol, and trying out variations on what you see. For example, "What if I change this byte, does the remote end still respond?".
My guess is that you're correct about the ct byte being a counter. The following zero byte could be flags, or it could identify the type of packet sent (serial data, remote AT command/response, node discovery/response, etc.).
As you build up an understanding of the structure, you can write a program to parse and dump the contents of the frames. Dump an interpreted version of what you know, and leave the unknown bytes as a sequence of hex bytes. Continue to experiment until you can narrow down the meaning of the remaining bytes.
The extra 2 bytes in payload (0x2D 0x0) is MaxStream header (MM in XCTU). If you disable the MaxStream headers by setting the MM command to without MaxStream headers, then these two bytes will become a part of a 802.15.4 payload, so your full payload would become 2B 0 61 instead of just 61
How do I ping 192.168.1.1 10 times with a break of 3 centiseconds after each ping! In command prompt. The ping command is really confusing.
You should propably get fping and use that:
fping -c 10 -p 30ms 192.168.1.1
This will send 10 packets to 192.168.1.1, interval between each packet is 30ms
fping because it allows flooding if required, 30ms interval between sends without waiting reply is propably considered flooding anyway...
With -t msecs you can add timeout for individual packets, this timeout is non blocking so interval between packets is always same, in this case -p 30 it is 30ms.
Packet loss with fping
Because of this, fping -p 30ms -t 10000 -s example.com may first show some packet loss but after waiting before summary is printed it should have enough time (10sec) to receive all packets that is not received in 30ms frame and final summmary shows that there is no real loss at all.
Example of packet exceeding interval but arriving within timeout:
Cmd:
fping -c 10 -p 30ms -s -t 10000 -e somehost.com
Output:
somehost.com : [0], 84 bytes, 299 ms (299 avg, 90% loss)
somehost.com : [1], 84 bytes, 269 ms (284 avg, 80% loss)
somehost.com : [2], 84 bytes, 239 ms (269 avg, 70% loss)
somehost.com : [3], 84 bytes, 209 ms (254 avg, 60% loss)
somehost.com : [4], 84 bytes, 179 ms (239 avg, 50% loss)
somehost.com : [5], 84 bytes, 158 ms (225 avg, 40% loss)
somehost.com : [6], 84 bytes, 128 ms (212 avg, 30% loss)
somehost.com : [7], 84 bytes, 137 ms (202 avg, 20% loss)
somehost.com : [8], 84 bytes, 137 ms (195 avg, 10% loss)
somehost.com : [9], 84 bytes, 127 ms (188 avg, 0% loss)
somehost.com : xmt/rcv/%loss = 10/10/0%, min/avg/max = 127/188/299
1 targets
1 alive
0 unreachable
0 unknown addresses
0 timeouts (waiting for response)
10 ICMP Echos sent
10 ICMP Echo Replies received
0 other ICMP received
127 ms (min round trip time)
188 ms (avg round trip time)
299 ms (max round trip time)
0.410 sec (elapsed real time)
As you can see, finally there is no loss at all 0 timeouts and 10 ICMP Echo Replies received out of 10 ICMP Echos sent.
Here you can find fping for linux.
And here fping for windows.
Assuming you are in a Windows Command Line:
ping 192.168.1.1 -n 10 -w 10
Here is a help page: link
It's ping 192.168.1.1 /n 10 /w 30