Is there any way to query the system's date/time via USB without installing anything on the host computer (maybe just drivers)?
Background of the original problem
To avoid the XY problem, let me explain a bit what I'm trying to do.
To be able to calculate a TOTP token for 2FA (e.g. like Google Authenticator app does) you need a real-time clock to get the date and time.
There's this USB device called SC4-HSM that I would like to use to calculate the tokens, however it doesn't have a clock and according to the designer, adding one would be too expensive (needs a battery, etc).
Possible solution to the original problem
This device is going to be used with a computer which already has an RTC of course. Thus I had the idea of querying the system for a date/time which would solve the issue.
(Note: I know that a USB device can be connected to all sorts of hosts and not all hosts will have an RTC, but since this only needs to work with a computer, I thought this shouldn't be an issue)
My first thought was that there might be some USB device class that had date/time needs, so I could register the device as that type and then I would be able to query the values.
After going through the device class codes list (Internet Archive) nothing jumped at me as needing date/time. The closest ones I could think of were:
Content Security (PDF)
Personal Healthcare
Smart Card Class (PDF)
I skimmed the device class documents in the USB Implementers Forum but there's nothing in there even remotely related to date or time.
Current problem
Since the USB specs seemed like a dead-end I thought that maybe there was a way to write a very simple USB driver that can be auto-loaded when the device is plugged in to a computer and then we can use the driver to return the date/time when the device asks for it (unless I'm misunderstanding something).
I am now looking through USB development docs like Michael Opdenacker's Linux USB drivers course, I tried the Linux USB Project which seems dead. Skimmed through Driver Development for Windows NT just to get an idea, however I am still not able to figure out if this is possible or not, and how hard it would be.
I'm a complete beginner at this and maybe this is something out of my skill level, but I would like to figure out if will I need weird hacks and workarounds or is there a much more straightforward way to do this?
There seems to be little information about it or I'm just searching the wrong places.
Any ideas/or pointers on either solving the original problem or the current one?
system time is not necessarily the general time i.e. the 'atomic' time you get from a NTP server
the most obvious solution is to use autorun, this is also possible on linux but normally autorun is blocked so the user explicitely has to activate it
https://askubuntu.com/questions/642511/how-to-autorun-files-and-scripts-in-ubuntu-when-inserting-a-usb-stick-like-autor
the linux command to get the time is date or hwclock or if the computer is connected to the net it may be possible to contact a NTP server (if the firewall does not block this)
then your autorun program has to send the data to the SC4-HSM. i do not know what USB classes the SC4-HSM implements if it implements CDC ACM (virtual COM port) this is easy:
Unable to sync computer time to Arduino via USB
(something like echo "T$(($(date +%s)+60*60*$TZ_adjust))" >/dev/tty.usbmodemfa131)
maybe it is possible to access system time over the USB drivers, i do not know this right now
Related
This may not be in the right location, so tell me and I'll move it.
I am a recent EE grad and I was hired to build a system that exists on a SoC with a simple 32-bit processor. The system basically monitors several external devices and performs some DSP on it, and then is supposed to send the results using a WiFi device (in my case I have the ESP8266 using UDP) to an email server for logging/notification.
I have been trying to find a library that I can use, but my uC can only program in C and I have it set up for UDP, and everything is in C++ using some other protocol, or something else completely.
I am great at DSP, decent at SoC's and uC's, but when it come to this email server communication thing I am at a loss.
I have successfully configured everything for the sensors, the datapath, the DSP, and connected the system to my WiFi via UDP, but I have yet to figure out how to send data to any servers.
Could someone help me understand how I should go about this?
I have looked into some simple SMTP commands such as HELO, MAIL, RCPT, DATA, etc. but I cannot understand how I actually should implement them in my code.
When I send out the WiFi data via UDP what type of data do I send and how do I format it? Do I need to send any other kind of flags? How should I expect the response? I also know the data has to be transformed into base 64 which is confusing me further.
I am also not super familiar with UDP to begin with, I have been using libraries that are part of the SoC's default library to connect to my WiFi.
I know these may either seem like obvious or stupid questions but it is were I no longer have any knowledge, and everything I find online doesn't make sense, or doesn't attempt to explain it, just gives a pre-made solution
I have found the RFC2821 but it doesn't get any clearer.
I know that's a lot but any help at all would be a lifesaver!
Since you are asking this question, I'm assuming that you are not booting and running an OS suitable for micro-controllers such as an embedded variant of Linux or such. If you were, you would simply be able to take advantage of possibly built in applications or other existing code.
But you don't mention having written an Ethernet stack, so are you using some other library or operating environment which might have some of the functionality needed for an implementation of SMTP?
If you don't and really do need to write your own SMTP client to run directly on the processor you are using, then you should be able to find plenty of examples of source code for this. A quick google search of How To Write an SMTP client showed a few articles with some example code. One article seems to be an exact hit, but you need to look at it further.
However, I would highly suggest just sitting down with a telnet client and connect to an SMTP server you are allowed to use and try the commands you need to just send a message. If you only need to send text, you don't need to get involved in MIME encoding or anything like that.
I would like to use C in order to get the last time the soundboard was playing a file. Is there a way I could do that?
None of the components you are using (tools, libraries, sound servers, drivers, kernel) logs the time when a sound is played.
If you are using one specific tool to play sounds, you could modify it to log the time.
Otherwise, you have to actively monitor the current status of the sound device.
(With ALSA, you could poll /proc/asound/card*/pcm*/sub*/status.)
I think it's not possible because of ALSA(Advanced Linux Sound Architecture) is just kernel component that provide device drivers for sound card.But i don't know if some user-space API's and library's like (alsa-ustils) can do that!,I advice may is better to check Sound-Player applications(VLC etc..) log ?!
I am student and I am writting simple application in C99 standard. Program should working on Ubuntu.
I have one problem - I don't know how can I get some Wifi parameters like bandwidth or delay. I haven't any idea how to do this. It is possible to do this using standard functions or any linux API (ech I am windows user)?.
In general, you don't know the bandwidth or delay of a wifi device.
Bandwidth and delay is the type of information from a link.
As far as I know, there is no such information holding in WiFi drivers.
The most link-related information is SINR.
For measuring bandwidth or delay, you should write your own code.
Maybe you should tell us more about your concrete problem. For now, I assume that you are interested in the throughput and latency of a specific wireless link, i.e. a link between two 802.11 stations. This could be a link between an access point and a client or between two ad-hoc stations.
The short answer is that there is no such API. In fact, it is not trivial even to estimate these two link parameters. They depend on the signal quality, on the data rate used by the sending station, on the interference, on the channel utilization, on the load of the computer systems at both ends, and probably a lot of other factors.
Depending on the wireless driver you are using it may be possible to obtain information about the currently used data rate and some packet loss statistics for the station you are communicating with. Have a look at net/mac80211/sta_info.h in your Linux kernel source tree. If you are using MadWifi, you may find useful information in the files below /proc/net/madwifi/ath0/ and in the output of wlanconfig ath0 list sta.
However, all you can do is to make a prediction. If the link quality changes suddenly, your prediction may be entirely wrong.
I am working with an embedded platform. Typical software in this devices are Linux 2.6 + Busybox, so resources are limited.
I need to run an user space application every time a USB device is connected. I need to pass as parameter to this user space app the DeviceID and ProductID.
I don't really know which strategy should I follow to achieve this:
Writing a linux kernel module.
Doing it from inside the kernel (usb drivers) i'm currently doing this, but i dont think its the best way to do it
A user space app that 'polls' for usb connected devices.?
Which one should be the best way?
Thanks for your answer!
If you want to remain in user space, then you can use libudev.
You have an example here. You can extract product id and device id from this.
Even though other options like #aisbaa mentioned, modifying kernel is interesting and challenging one. I suggest you to modify the USB driver. Reason is, you need to send the arguments to the user space application(Product ID, Device ID).
These Ids will be obtained in driver. so calling user space app with these Ids are my choice.
For calling user space app nice explanation available here.
To the best of my knowledge, there is a mechanism for USB hot plugging in the kernel.
When a hot plug event happens, the user can be notified. Unfortunately, I am not very familiar with the details.
Maybe linux-3.3.5/samples/kobject/kset-example.c will give you some ideas.
Let's suppose you deploy a network-attached appliances (small form factor PCs) in the field. You want to allow these to call home after being powered on, then be identified and activated by end users.
Our current plan involves the user entering the MAC address into an activation page on our web site. Later our software (running on the box) will read the address from the interface and transmit this in a "call home" packet. If it matches, the server response with customer information and the box is activated.
We like this approach because it's easy to access, and usually printed on external labels (FCC requirement?).
Any problems to watch out for? (The hardware in use is small form factor so all NICs, etc are embedded and would be very hard to change. Customers don't normally have direct acccess to the OS in any way).
I know Microsoft does some crazy fuzzy-hashing function for Windows activation using PCI device IDs, memory size, etc. But that seems overkill for our needs.
--
#Neall Basically, calling into our server, for purposes of this discussion you could call us the manufacturer.
Neall is correct, we're just using the address as a constant. We will read it and transmit it within another packet (let's say HTTP POST), not depending on getting it somehow from Ethernet frames.
I don't think that the well-known spoofability of MAC addresses is an issue in this case. I think tweakt is just wanting to use them for initial identification. The device can read its own MAC address, and the installer can (as long as it's printed on a label) read the same number and know, "OK - this is the box that I put at location A."
tweakt - would these boxes be calling into the manufacturer's server, or the server of the company/person using them (or are those the same thing in this case)?
I don't think there's anything magic about what you're doing here - couldn't what you're doing be described as:
"At production we burn a unique number into each of our devices which is both readable by the end user (it's on the label) and accessible to the internal processor. Our users have to enter this number into our website along with their credit-card details, and the box subsequently contacts to the website for permission to operate"
"Coincidentally we also use this number as the MAC address for network packets as we have to uniquely assign that during production anyway, so it saved us duplicating this bit of work"
I would say the two obvious hazards are:
People hack around with your device and change this address to one which someone else has already activated. Whether this is likely to happen depends on some relationship between how hard it is and how expensive whatever they get to steal is. You might want to think about how easily they can take a firmware upgrade file and get the code out of it.
Someone uses a combination of firewall/router rules and a bit of custom software to generate a server which replicates the operation of your 'auth server' and grants permission to the device to proceed. You could make this harder with some combination of hashing/PKE as part of the protocol.
As ever, some tedious, expensive one-off hack is largely irrelevant, what you don't want is a class-break which can be distributed over the internet to every thieving dweep.
The MAC address is as unique as a serial number printed on a manual/sticker.
Microsoft does hashing to prevent MAC address spoofing, and to allow a bit more privacy.
With the only MAC approach, you can easily match a device to a customer by only being in the same subnet. The hash prevents that, by being opaque to what criteria are used and no way to reverse engineer individual parts.
(see password hashing)
From a security perspective, I know that it is possible to spoof a MAC, though I am not entirely sure how difficult it is or what it entails.
Otherwise, if the customers don't have easy access to the hardware or the OS, you should be fairly safe doing this... probably best to put a warning sticker on saying that messing with anything will disrupt communication to the server.