I'm trying to understand a wireless linux device driver.
So after netdev_open is called...
what happens?
I know packets are being transmitted through an xmit function, but how does the code get there?
The dev->hard_start_xmit() function for the netdev is called out of the networking core - see net/core/dev.c (in particular dev_hard_start_xmit() and dev_queue_xmit()). These functions are in turn called out from the protocol handlers - see for example ip_queue_xmit() in net/ipv4/ip_output.c.
Related
My team has been struggling with a pretty strange issue while using the WinRT/C++ APIs for Windows to connect to both a MIDI port and receive BLE notifications through a proprietary service on the same device.
The WinRT/C++ library itself is really nice and provides easy and modern C++ interfaces to access the managed Windows runtime classes.
I've pushed a sample repo to Github where we've replicated the issue with a minimal example.
The repo's readme goes over the problem in detail, but I'll post the relevant bits here for completeness.
The sample program is performing roughly these steps:
Check for available MIDI devices using a DeviceWatcher.
Check for available Bluetooth LE devices using another instance of a DeviceWatcher.
Match discovered MIDI and BluetoothLE devices on their ContainerId property (see DeviceInfo for details). This is the method JUCE employs in the native WinRT code for their library, and works as expected.
Open the MIDI port and attach a handler to the MessageReceived event (see the code).
This causes the system to create a connection to the Bluetooth LE device. The program detects this state change, creates a BluetoothLEDevice, we perform GATT service discovery and attach a handler to the ValueChanged event for the characteristic we're interested in notifications from (see the code).
The program then counts how many MIDI messages are received on each port and how many BLE notifications are received from the corresponding device.
The behaviour we notice is that data from the most recently connected device streams just fine, while the throughput for the others is severly limited. We are at quite a standstill regarding this issue, and are not sure where the problem may lie.
We are at quite a standstill here. I'd be more willing to accept it if all the devices would exhibit this behaviour, but that's not the case. Is there any reason that creating both a MidiInPort and an BluetoothLEDevice from the same peripheral should cause this issue?
A BLE radio can only receive or send at any given time. And therefore only communicate with one device at any given time. It uses a scheduler to allocate radio time for every device when you have many devices. That way a second connection can "interrupt" a connection event from another device, decreasing the throughput for that device. See https://infocenter.nordicsemi.com/topic/sds_s132/SDS/s1xx/multilink_scheduling/central_connection_timing.html
I am making a CAN simulator for GPS trackers, they only record CAN data and doesn't send ACK. Is it possible to send CAN data with raspberry, using mcp2515/tja1050, without any device on bus that would trigger ACK?
This will usually generate a continuous retransmit.
Some devices have a "one-shot" transmit mode when just sends the CAN frame and does not attempt a retransmission. If you transmitter has this mode you can do what you describe, otherwise you will get a lot of retransmissions.
No it isn't possible, you need at least 2 nodes that are actively participating in the communication. This can however be fixed by just providing another CAN controller on the bus, which doesn't have to do anything intelligent except the ACK part.
For development/debug/test purposes you can however put your own node in "loopback mode", meaning it will speak to itself. Can be handy if you have to proper hardware available yet.
You can try to set the controlmode presume-ack to on.
Assuming you are using the ip command for creating your can sockets that would be something like
ip link set <DEVICE> type can presume-ack on
This will ignore missing ACKs. However I am not sure whether this works with all controllers.
What I mean is that, when I code a project, I need to communicate with the serial port like COM1, COM2... but sometimes there is no device connected and I also can use the function CreateFile to get the COM port handle.
When I use the WriteFile function to send a string to the COM port the software blocks.
After I dig into the problem I find another function GetCommModemStatus which can get status of the COM port but when I use the usb-rs232 transition line, the second parameter always returns 0.
How can I get the COM port status so that I can check if is there some devices connected to the computer?
If I understand correctly, you want to detect if a device is connected to your COM port and ready to accept packets. If that's the case, you need to check control signals (DTR/DSR and CTS/RTS) before sending data, assuming your device is aware of them and sets the appropriate PIN on your DB-9 or DB-25 connector. Some devices rely on software handshaking instead (XON/XOFF) and do not set control signals. Your best bet would be to consult documentation of your device.
I have been using ComPort Library version 4.10 by Dejan Crnila. It does support both hardware and software handshakings, so you can focus on your own code instead of reinventing the wheel.
As several people have already pointed out, it is not a good idea to try to "re-invent the wheel." Except for "quick and dirty" testing, your code will have to handle the com port in a separate thread and the available solutions all make this much easier.
BUT, if you Really want to do it, I'll give you some pointers.
If you are using "WriteFile" then you have probably already figured out the "CreateFile" part of the procedure and how complicated things can get depends upon what kind of IO you specified in that procedure, Overlapped or not. Overlapped IO is more complicated but does let the OS handle some of the burden.
You mentioned that your call to "WriteFile" hangs. You should look up the "SetCommTimeOuts" function. Setting both the WriteTotalTimeoutMultiplier and WriteTotalTimeoutConstant members of TCommTimeouts to zero will tell the OS to return immediately. You may also need to "SetCommMask" if your target uses handshaking.
What happens next really depends on what your target is supposed to do. The GetCommMask function can be used to check the status of the handshake lines.
I'm writing a windows utility that communicates to a a USB Device. The driver is a custom driver, supplied by Analog Devices (the manufacturer of the controller chip used in the device).
I've adapted one of their example Windows apps for communcicating with the device. Communication is done via named pipes, and can be synchronous or asynchronous. The problem I've found during testing is that calls to the WriteFile api function can sometimes fail to return if the device is switched off during a write (the device has a hard power switch). The same thing is observed using async or sync calls - I see no timeout happening when using aysnc.
After this has happened, I need to restart my app, as the thread dealing with USB communications is hung.
Is there a way I can prevent the WriteFile from failing to return in this case?
Thanks
Tom Davies.
You can cancel IO operations using CancelSynchronousIo and CancelIoEx. You could do this if you detect that your comm thread is unexpectedly blocking during writes.
Possible deal breakers:
Available only in Windows Vista and newer
Driver has to support cancellation
I need to modify a kernel module(s) to count number of packets that the machine has sent / received over my wireless adapter for the linux 2.6 kernel. Please let me know which modules should I modify. Any references would also be helpful.
I am not very sure about wireless adapter, but I think it is similar to a wired one. For wired and wireless NIC, you can use ifconfig eth0 command, then in the output, you will see one or two lines telling you the number of packets sent(TX) or received(RX).
To get the same information from the kernel module, one way is to modify the device driver for the network card. One tutorial about rtl8139 (wired one) is here: http://linuxgazette.net/156/jangir.html
Also, I think there are some standard kernel interface that you can use to get the same info. For example, tp->stats.tx_packets mentioned in the above link.
If you're interested in IP packets you should consider creating a kernel module that uses netfilter hooks. It's very simple, here take a look at this:
http://www.netfilter.org/documentation/HOWTO/netfilter-hacking-HOWTO-3.html
Netfilter is primarily intended for firewalling, but it can do what you want and you don't need to mess with other kernel modules. Hope it helps.
cat /proc/net/dev
is probably not what you want, but then explain why.