In DBUS programming terminologies, they use Service name interchangebly with Bus name. Or is there a difference?
A "bus" is a "communication world/space". You can have several buses running simultaneously on the same computer: system & session are the traditionnal ones. There can also be private buses. They are usually identified by their daemon socket: "unix:path=/var/run/dbus/system_bus_socket"
A "bus name" is a connection point, it's kind of an identifier. It can be a process connection to a bus. Typically, you address messages to a "bus name". Sometime, that name is "well-known", meaning it has been registered with a another "friendly" name. http://dbus.freedesktop.org/doc/dbus-specification.html#message-protocol-names-bus
A "service" is normally a program that is started on-demand and provide an expected interface (and a a "well-known" "bus name", such as "org.gnome.keyring")
But people often just call "service" a "well-known bus name that provide an interface" regardless of it is launched on-demand or not.
See also http://www.freedesktop.org/wiki/IntroductionToDBus
Related
We're switching to a system where our shippers need to put barcodes with our article IDs on the products they're sending henceforth. Our management is willing to lend them Brother TD-4100N label printers under the condition that they do not use it for other purposes other than printing our barcodes, and now I'm tasked with programming an interface that allows them to print our barcodes.
Their core competency however lies in shipping management, not IT administration, and so I have to keep things simple and platform-independent - or at least as platform-independent as possible. The idea here is to be able to plug in one of those printers via ethernet without any kind of setup - as simple as possible. No drivers, no nothing, keep it simple, stupid. An ethernet port and sockets is all I wanna use. And with this specific model having an ethernet port and accepting ESC/P codes that shouldn't be so hard, right?
After spending a week with one test machine I've learnt enough about the ESC/P codes and Brother's proprietary extensions (at least they claim them to be) to write a little framework in C. Printing barcodes in the required format (Code128) doesn't pose a problem in and of itself, but the bookkeeping around it does; I'm at my third manual at this point that claims that simply sending the command "\x1B\x69\x53" (ESC i S) should cause the printer to send me a 32-byte record of its current status, but for some reason the printer simply doesn't want to send me how it's doing:
char buffer_send[] = "x1B\x69\x53";
send(sock_jet,buffer_send,sizeof(buffer_send) - 1,0);
char buffer[32];
memset(buffer,0,sizeof(buffer));
recv(sock_jet,buffer,sizeof(buffer),0);
fprintf
(
stderr,
"%02x%02x%02x%02x%02x%02x%02x%02x\n",
buffer[0],buffer[1],buffer[2],buffer[3],buffer[4],buffer[5],buffer[6],buffer[7]
);
fprintf
(
stderr,
"%02x%02x%02x%02x%02x%02x%02x%02x\n",
buffer[8],buffer[9],buffer[10],buffer[11],buffer[12],buffer[13],buffer[14],buffer[15]
);
fprintf
(
stderr,
"%02x%02x%02x%02x%02x%02x%02x%02x\n",
buffer[16],buffer[17],buffer[18],buffer[19],buffer[20],buffer[21],buffer[22],buffer[23]
);
fprintf
(
stderr,
"%02x%02x%02x%02x%02x%02x%02x%02x\n",
buffer[24],buffer[25],buffer[26],buffer[27],buffer[28],buffer[29],buffer[30],buffer[31]
);
This code simply stalls for some time until timeout hits or whatever, and recv doesn't write any data into my buffer:
0000000000000000
0000000000000000
0000000000000000
0000000000000000
And I'm apparently not the only one with such a problem. This Ruby Python package (https://pypi.org/project/brotherprint/#files) claims to be specifically catered for Brother printers, but I never see them receive any data (in brotherprint/brotherprint.py at least). In fact I don't even see them spelling "receive" correctly.
On SO (operating printer with php socket programming) someone tried to do the same in PHP I'm trying to do in C - and they had the exact same problem as I'm having, with the printer refusing to give them status data. The solution seems to involve switching from port 9100 to port 515 and using a different protocol, and while I've seen port 515 to be open on the printer I've never seen any output from that printer, on paper or on the socket. At this point I'd contact the Brother support, but I'm already having another ticket open because another printer of their's does seem to have major problems sending status reports back to CUPS.
I've tried adding a NUL byte at the end of my payload, in case the printer is waiting for a page feed, but that didn't do the trick either. Again: printing barcodes to the damn thing works, so IP, port, and connection work at least to a degree - but receiving a status report doesn't.
The strace from my program:
connect(3, {sa_family=AF_INET, sin_port=htons(9100), sin_addr=inet_addr("192.168.XXX.XXX")}, 16) = 0
sendto(3, "\33iS", 3, 0, NULL, 0) = 3
recvfrom(3, <blocks here for minutes> "", 32, 0, NULL, NULL) = 0
write(2, "0000000000000000\n", 170000000000000000
) = 17
write(2, "0000000000000000\n", 170000000000000000
) = 17
write(2, "0000000000000000\n", 170000000000000000
) = 17
write(2, "0000000000000000\n", 170000000000000000
) = 17
close(3)
And the main manual that I'm using: https://download.brother.com/welcome/docp000579/cv_td4000_eng_escp_120.pdf (search for "ESC i S").
OK, so I actually got a response from the Japanese Brother support. And there is so much wrong with that response that I may come off as rambling a little right now.
Brother insists that
ESC/P is not supposed to be for bi-directional communications.
, which is a load of steaming BS seeing as Brother MADE their implementation bi-directional. That is what the documentation says! Read it for yourself in the ESC/P documentation they provide.
Requests the printer status.
The printer status comprises 32 bytes.
So I've already caught them either lying or being incompetent.
The next lie/being incompetent is:
Namely what you have reported is within our specifications.
I'd have LOVED to actually see those specifications they've quoted here. The only thing I've found so far was section 5 "Additional Functions" in my manual, which has a paragraph called "ESC/P commands" in which they link to the aforementioned ESC/P manual. This manual specifically states:
This information is provided assuming that the user has full understanding of the operating system being used and basic mastery of RS-232C, USB or Ethernet in a developer's environment.
In section 8 "Using Interface Cables" they state that RS-232C (serial) and RJ-45 (ethernet) cables are not standard accessories, and that it's not possible to connect a RS-232C and a USB cable to the same printer at the same time. Then there are some installation instructions on MS Windows computers, and that's about it.
Their FAQ doesn't mention anything (https://www.brother.co.jp/eng/dev/command/faq/index.aspx) except for using SNMP (which doesn't work on this printer because Port 161/162 are not even open), and their network reference is just as mute (https://download.brother.com/welcome/docp000592/cv_td2130n_eng_net.c.pdf - not one mentioning of ESC/P). I'm seriously wondering if I'm too stupid to find this, or if they pulled that one out of their ar**s just to not have to deal with this.
And don't tell me they wouldn't do this. This printer also runs a webserver on port 80 that has a confirmed secvuln (https://threatpost.com/tag/debut-embedded-web-server/).
But then they actually get to the core of the issue here:
Besides, our specification never ruturns when using Netwrokd even if an error does not happen
This little part of Engrish here is probably supposed to mean:
Even if an error occurs our hardware does not send status reports over ethernet.
, which would explain why the printer remains silent. However I don't believe this is part of their specification, which I couldn't even find; I believe they got caught with their pants down yet again and refuse to acknowledge it. It shouldn't make any difference how you connect to the machine - ethernet, serial, or USB - as long as the transport layer works, which obviously is the case since I can send other commands to the printer. However this is supposed to be used on different machines on the same network. Why do they even have an ethernet port if the firmware is unable to send a status report? Who came up with this idea?
I can honestly only discourage people from getting Brother devices. This is the second printer I've seen from this company that simply doesn't work over ethernet, and what good is a printer if you cannot query its status to determine if you're to send a job to it? And they sell those unreliable machines for 600 € apiece.
my problem is I want to manually handle how USB devices are handled when they are plugged in. I don't want the operating system to do anything with the plugged in USB devices other than notify me of their type and their ID when they are plugged in. From there I can then select the appropriate driver to apply to it, or manually do something with it with custom code.
I've read this about how MacOS handles USBs, and it says:
If you want your driver selected above others, all you need to do is add key value pairs for the device your driver is for which cause your driver to get a really high score. Usually it's enough to just put keys in for your vendor id/model. However, I think you can override the matching method (device drivers are written in a restricted set of C++) to give your driver a really high score.
I have also found these 3 libraries for getting notified about things in the USB drive:
https://github.com/tessel/node-usb
https://github.com/MadLittleMods/node-usb-detection
https://github.com/node-hid/node-hid
I just am not sure if these libraries will interrupt all USB device handling by the operating system before anything occurs (before any device driver is selected automatically and applied). I would like for nothing to happen except for me to get access to the device and its type in one of the above libraries, but I'm not sure if they will do that.
I don't have much code yet other than this:
var usb = require('usb')
usb.getDeviceList()
But I imagine this would resolve the plugged in devices after the OS has already selected and applied a default driver to it. I want to do something like this:
usb.blockDefaultOSDeviceHandler()
usb.on('device:plugged_in', function(data){
if (data.type == 'keyboard') {
if (data.modelNumber == '123') {
// allow
usb.applyKeyboardDriver('abc', data.modelNumber)
usb.on('keyboard:event', logKeyboardEvent)
} else {
throw new Error('Unrecognized device')
}
}
})
I would hope that the library would interrupt all default behavior by the operating system so I can handle myself what should be done when a USB device is plugged in. A reason is because maybe the USB device is a keyboard and it automatically starts typing in some keys. I would like to know that it is a keyboard, and require a password and a specific driver I have pre-approved for it. Stuff like that.
I would like to get access to any newly plugged in USB device before the operating system applies its default handling rules. And then have the ability to write the code to manually handle what to do with each plugged in device.
If it's only possible in C, then knowing how to do it there would be good instead of node.js.
https://github.com/Arti3DPlayer/USBDeviceSwift
https://github.com/USBGuard/usbguard
How to block/unlock USB port in mac os x programatically without reboot
https://apple.stackexchange.com/questions/59764/how-to-disable-individual-usb-ports-by-script
https://serverfault.com/questions/566687/blocking-usb-through-gpo-in-2008-r2-excluding-certain-users
https://github.com/google/gousb
https://github.com/IntergatedCircuits/USBDevice
The answer is in the Apple documentation on USB devices. Basically you want to override the probe function in a custom driver, have it return the highest score so as to override all other drivers, and implement the driver like normal. Here is some useful documentation on the driver selection and instantiation process.
Before a device—or any service provider—can be used, a driver for it must be found and loaded into the kernel. The I/O Kit defines a flexible, three-phase matching process that narrows a pool of candidate drivers down to one or more drivers. The final candidate (or, if multiple candidates, the m
ost eligible one) is then loaded and given the first opportunity to manage the device or service provider.
...
Each device driver, considered as a loadable kernel extension (KEXT), must define one or more personalities that specify the kinds of devices it can support.
...
Because a driver can contain multiple matching dictionaries, each one defining a different personality for the driver, the same driver code can be loaded for different devices. For purposes of competition, the I/O Kit treats each personality as if it were a driver. If, in any single personality, all of the properties required by the family match, the driver’s code is loaded and given a chance to run for that device.
...
One common property of personalities is the probe score. A probe score is an integer that reflects how well-suited a driver is to drive a particular device. A driver may have an initial probe-score value in its personality and it may implement a probe function that allows it to modify this default value, based on its suitability to drive a device. As with other matching values, probe scores are specific to each family. That’s because once matching proceeds past the class-matching stage, only personalities from the same family compete. For more information on probe scores and what a driver does in the probe function, see Device Probing.
...
At boot time and at any time devices are added or removed, the process of driver matching occurs for each detected device (or other service provider). The process dynamically locates the most suitable driver in /System/Library/Extensions for the device or service.
...
As described in Driver Matching in the chapter Architectural Overview the matching process is triggered when a bus controller driver scans its bus and detects a new device attached to it. For each detected device the controller driver creates a nub. The I/O Kit then initiates the matching process and obtains the values from the device to use in matching (for example, examining the PCI registers). Once a suitable driver is found for the nub, the driver is registered and loaded. That driver, in turn, may create its own nub (possibly through behavior inherited from its family), which initiates the matching process to find a suitable driver.
...
The matching process proceeds as follows:
In the class matching step, the I/O Kit narrows the list of potential drivers by eliminating any drivers of the wrong class for the provider service (that is, the nub). For example, all driver objects that descend from a SCSI class can be ruled out when the search is for a USB driver.
In the passive matching step, the driver’s personality (specified in a driver’s XML information property list) is examined for properties specific to the provider’s family. For example, the personality might specify a particular vendor name.
In the active matching step, the driver’s probe function is called with reference to the nub it is being matched against. This function allows the driver to communicate with the device and verify that it can in fact drive it. The driver returns a probe score that reflects its ability to drive the device. See Device Probing for more information. During active matching, the I/O Kit loads and probes all candidate drivers, then sorts them in order of highest to lowest probe score.
...
The I/O Kit then chooses the remaining driver with the highest probe score and starts it. If the driver successfully starts, it is added to the I/O Registry and any remaining driver candidates are discarded. If it does not start successfully, the driver with the next highest probe score is started, and so on. If more than one driver is in the pool of possible candidates, the more generic driver typically loses out to the more specific driver if both claim to be able to drive the device.
...
The probe score is a signed 32-bit integer initialized to a value specified in the driver’s personality (or to zero if not explicitly initialized).
...
A driver, in its probe function, returns a driver object (IOService *) if the probe was successful and returns zero otherwise. The returned object is usually the driver itself, but the driver can return another driver that is more suited to the provider. The probe score is an in-out parameter, which probe can modify based on what it discovers about the device.
...
After all drivers have probed the device, the one with the highest probe score is attached and its startfunction, which must be implemented by all drivers, is invoked. The start function initializes the device hardware and prepares it for operation. If the driver succeeds in starting, it returns true; the remaining candidate driver instances are discarded and the driver that started successfully continues operating. If the driver cannot initialize the hardware it must leave the hardware in the state it was in when start was invoked and return false. The failing driver is then detached and discarded, and the candidate driver with the next highest probe score is given a chance to start.
This can't be done with Node.js unless (potentially) a C/C++ extension in node is used.
What do they refer to with GKI here? What does it abbreviate?
It seems to stand for General Kernel Interface, not that it is much useful as itself.
For example:
The libnfc-nci implementation uses a reliable mechanism of queues and message passing named General Kernel Interface (GKI) to easily communicate between layers and modules: Each task is isolated, owning a buffer (or inbox) where messages are queued and processed on arrival. This mechanism is used to send messages from the DH to the NFCC chip, and vice versa.
(Radio Frequency Identification: 11th International Workshop, RFIDsec 2015)
i'm writing a C program to manage certain aspects of a wireless network (Access Point + Client Devices)
One Part of the program runs on the Devices an another runs on the AP. The AP is a simple Linux-Station (a Cubietruck, later on exchanged with a Intel Celeron holding Board; Access Point setup with hostapd and dnsmasq)
Some features are already implemented. I've done a lot with cfg80211/nl80211 and a bit with Wext and some Communication Routines over BSD Sockets are standing.
But now a problem came up. In the C program running on the Access Point i need the Received Signal Strength of the associated Devices.
On the Devices everything works well. With nl80211 i can get nearly every information about the connection. But on the Access Point i don't know how to obtain the RSS. I've tried some nl80211 requests with some attributes but can't get it to work.
Sure, on the Devices it's easy, because they have a single connection. But on the AP i had expected something like a nl80211 answer with a linked list or nested attributes, but nothing. I checked the contained attributes of the answers from certain requests and the messages contain nothing usable.
Does somebody know how to solve this? It shouldn't be a big deal like that to obtain the Received Signal Strength of the associated devices on a WLAN AP.
Would be really nice if it were doable with nl80211 but another solution would also be welcome.
Maybe with some WiFi Package Parsing? I heared that there is something like a RSSI (Received Signal Strength Indicator) but i'm not familiar with it.
Thanks in advance
Here's a wrokaround: the wireless channel attenuation from AP to a station/device and from that station to the same AP are identical at the same time. So, if transmission power of AP and stations are all the same, stations may report their RSS to AP using you current solution, and the work is done. Surely tx powers at different stations may be different, but they are constant. So find them out and make adjustments accordingly. Here's a simple example:
AP tx power 20 dBm;
Station 1 tx power 15 dBm with RSS -37 dBm;
Then the RSS from station 1 to AP link should be -42 dBm
I wonder how the major number is allocated for platform device driver.
For example, in the driver code, I don't see any of the function calls like
alloc_chrdev_region()
or
register_chrdev_region()
Somebody, please make me understand this.
Thank you.
Kernel creates a great deal of devices attached to various virtual buses (which may or may not represent a physical one). Only some of those devices can be meaningfully accessed directly from user space. And only a subset of those relies on "device node" interface to do so (as ample other options exist in modern kernels). If this particular interface is not used by a driver, then there's no need whatsoever to allocate device node numbers.
Inside the kernel devices are located by their affiliation to particular buses (using internal device names and bus ids). For example, mcspi driver registers as "device" on "platform bus" and as "bus master" on "spi bus". Upon seeing that bus master had registered, spi subsystem will trigger a "bus rescan" on a newly connected bus.
The spidev driver is rigged in such a way as to always "match" an imaginary device present on every spi bus, so it will get instantiated for every "bus master" registration. It will create the user space device node which can be used for direct communication with its "bus master" (spi bus controller, mcspi in this particular case).
Controller doesn't need to be exposed. Hence, no device nos.
On the other hand, SPI devices do require a MAJOR?MINOR no defined in spidev.c, here it is registering the device. And on the top of the same file, there's a macro for the major no defined as:
56 #define SPIDEV_MAJOR 153 /* assigned */
57 #define N_SPI_MINORS 32 /* ... up to 256 */