i am making a micro-controller based dongle and i need it to interrogate host state when connected and display status (status={HOST_OFF,HOST_BOOTED,SERVICE_DOWN,SERVICE_STARTING,SERVICE_UP,SERVICE_ERROR}
i can get all the statuses from a terminal so i wanted the device to be able to login and run some commands to check stuff.
I considered the option of using CDC-ACM and a monitoring service running to update the device but that only works if the monitoring service doesn't fail (say because of disk space or port unavailable etc), and when it fails i cannot get errors.
I am basically trying to eliminate the reason for sending a tech just to look at the screen to see whats going on.
I tried just identifying device as tty device but this seems to expect a service to connect to it from the host side before i can send and characters
Related
I am using Windows Bluetooth LE GATT library to connect to and pair with a BLE-supporting device, D. Since D has a limited amount of storage space, if more than N Clients bond with it, then it will remove the first Long Term Key pair that was created during bonding.
Let's say that the device for which this key-pair was removed was a Windows Enabled machine. Let's call this W. The next time W attempts to connect with D, when it receives the LTK_Request_Event from W, it responds with Long_Term_Key_Requested_Negative_Reply, and W terminates the connection.
But here's where things get really exasperating. Even though the Windows BLE Stack seems to be aware of this response (because it disconnects), this does not seem to be communicated downstream to applications using the Bluetooth LE GATT library. In fact, from the application's side, a pairing request will return with "Already Paired", and does not indicate that anything went wrong. Of course, once the application tries to access protected characteristics, it won't be able to, and that, so far, is the only indication that Pairing was not successful. Even worse, the errors it receives aren't consistent. Sometimes, it gets "Unreachable". Sometimes, it gets protocol errors. Other times, it receives ABORTs.
Now, as a heuristic, I could use detection of this case as criteria for attempting to re-pair. Unfortunately, this is not ideal, since none of these errors actually imply that the device no longer honored the LTKs, and could, instead, indicate other issues, like that the device is out of range.
Is there any way to detect that existing LTKs have been rejected by the device?
Let's see what the Bluetooth specification says about this.
Bluetooth Core version 5.2, Vol 3 (Host), Part C (Generic Access Profile)
Section 10.3.2 Initiating a service request:
In this section the local device is the device initiating a service request to a
remote device. In the L2CAP protocol the local device sends the connection
request and the remote device sends the connection response. In GATT, the
local device is the GATT client and the remote device is the GATT server.
When a local device initiates a service request to a remote device it shall
behave according to the following rules:
[...]
If an LTK is available and encryption is required (LE security mode 1) then
encryption shall be enabled before the service request proceeds as defined proceed. If encryption fails either the bond no longer exists on the remote
device, or the wrong device has been connected. The local device must,
after user interaction to confirm the remote device, re-bond, perform service
discovery and re-configure the remote device. [...]
If Windows's BLE stack doesn't allow for what the specification mandates, it is not specification compliant, in my eyes, so please file an issue report at Microsoft.
The reason for requiring user interaction and not blindly re-bond is to avoid a situation where a hacker can simply spoof the bluetooth device address, indicate it has lost the bond and automatically re-bond without the user noticing anything.
EDIT:
The Security Manager chapter also has a table of actions to do when encryption fails due to deleted keys. See section 2.4.4.2 of Vol 3, Part H.
It specifically says when the devices were bonded before that the action to take when enabling encryption fails is to "Notify user of security failure."
I am building a project utilizing Wifi on the ESP32 module. Using RTOS, I am running a web server on 1 core and a web client on another core. This works very well and I can access the web server remotely via my browser and the WiFi provided IP address. The Web client reads some sensors and sends the data via WiFi to my database. All good and everything works as desired.
Now I need to do the next step and move beyond the reach of the WiFi and reproduce the same result via 3/4G cellular. I looked at the "easy" solution to use an industrial 3/4G WiFi router and simply keep what I have. Cost of these "industrial" type routers are on the high side, where as 3/4G module which also include a GPS chip are around half or less. Problem is that I cannot get my head around how I will "replace" my current WiFi functionality with one of these modules. The modules seems to expect you to connect via serial (rs232) and using modem AT commands establish a connection to the internet. Question is, after connecting to the internet, how do you continue to have "network functionality" same as with the built-in WiFi? Is there some library that will do ethernet over the serial port? Can I still have the WiFi and the "serial ethernet" running at the same time or switch between the two?
Thanks!
It seems that with MikroTik RouterOS 6.43.4 setting a device to CAP mode is not persistent across reboots.
More detailed, steps I took that reproduce the problem:
Connected the wAP AC to my CAPsMAN router's POE port while holding the reset button for ten seconds, until the AP/CAP led starts blinking.
Verified that the wAP device went into CAP mode.
Verified the connection in the CAPsMAN Remote CAP list, and connected over wifi with the SSID set in the CAPsMAN config to the device.
Verified my connection in the registration table.
So far all good.
unplugged the wAP device, and plugged it back.
The device has reset itself, it broadcasts the default wifi SSID, and did not set a persistent CAP mode.
RouterOS 6.43.2 with the same setup worked fine.
Can anyone confirm this as a bug in this version?
After consulting with MikroTik support, it seems that this is a kind of new security feature. So here are all the steps to set a routerOS device to a permanent CAP client.
Connect to the default MikroTik-MAC based wireless network
Access WebFig under 192.168.88.1 or use any other access method
under System -> Packages, Check for Updates
Update to the latest version.
Poweroff, the hold reset while powering on.
The 2Ghz 5Ghz LED's will be blinking, and after about 10 seconds, when the AP/CAP LED starts blinking instead, release the reset button.
The device is now in a temporary CAP mode when the boot process completes.
Log in to your router running the DHCP server on your network, and find out what IP address the device has.
Either use a native Terminal, or the web based terminal next to the WebFig button, and connect to the device via shell.
The login banner will contain the current configuration set to CAP mode, and it will stop for a dialoge-question, to remove configuration with keypress of r or to continue with conforming configuration with any other key. Press enter.
With version 6.48.3 the step to confirm CAP mode became obsolete. New it is enough to set CAP mode via reset button after the update of packages.
Sorry for asking such a mundane question, but I'm suddenly curious. If I open the network connections dialog on my Windows machine, it shows me a cute little picture of my computer connecting to a router and then to a globe (labeled Internet). What is Windows trying to connect to in order for it to decide that the computer has Internet connectivity? I assume there is no IP4 address for 'The Internet', so where is it going? Is it just sending a ping to an address back at the Microsoft home office? If that address were to disappear, would my window's machine suddenly decide that it no longer has a route to the Internet? Would Windows boxes that were 'close' to that address incorrectly report that they could get to the Internet when they couldn't.
I'll stop now before this gets too silly. But seriously, what criteria does a Windows box use to determine that it has Internet connectivity? I'm assuming that Linux and iOS systems have an equivalent feature. Do they use the same criteria?
The general IP address that is used for 'the internet' is 8.8.8.8 - or Google.com.
If you can ping it, and get a web page from it, then there's a pretty good chance you can get to at least some of the internet.
But for specifically Windows - Network Connectivity Status Indicator - it uses a different domain: dns.msftncsi.com
It will (unless disabled by GPO):
resolve the name, and verify it has the 'right' IP (131.107.255.255
fd3e:4f5a:5b81::1 )
Perform a HTTP get to this address and check it gets a result. NCSI
Presumably if different responses are retrieved, then it can tell if it has a wi-fi login or similar.
Your intuitions seem correct. I am not on a Windows machine but you could find out by firing netstat and then connecting.
If I was programming this I'd make Ping, TCP and HTTP requests. Some devices are connected through proxies such as firewalls, captive portals and others. the only way to be sure is to send something and receive a reply.
My Android device for example can detect captive portals. It probably does that by trying to HTTP connect somewhere.
I configured my Windows 8 machine that it listens to magic packages send from other PCs to start it. It works very good. BUT I don't want to explicitly send a magic package, I would rather prefer it if I could send a magic package automatically when I try to access the PC over network.
I tryed using an smbclient event (30803). I configured this event to trigger a command line WOL. But This command will be triggered each time I get this event, no matter which PC I try to reach. I don't want to wake up PC-X when I actually try to access PC-Y.
Is there another way?
This sounds interesting... a possible solution would be, create a windows service and install it on the server or a computer that uses to be up. This service basically would be a network sniffer that captures all tcp traffic in network. It would have a table with ips and MAC addresses (to get MAC from an IP) that should be filled previously with manually or better... from ARP table (I did a program that gets IP / MAC from ARP table but has its issues... so each machine plugged on the LAN will get its MAC / IP), also this service would have last date ping done to each IP.
Then... how it would work... the service would capture all TCP packets and make a list of distinct IP, then each second or two get all distinct IPs (this will guarantee that the service is not consuming a lot of system resources), and on each distinct ip check last ping: if last ping was done successfully in last 5 or 10 minutes nothing is done (machine is guessed up), if no ping done or success in 5-10 minutes a ping is made. Based on ping response... if the machine is not responging magic packet is sent to MAC (provided from ARP when machine is up or manually as commented before). If ping responds nothing is done. Ping result and date is stored to avoid pings to all machines every time. Instead of ping also its possible to do it reading ARP table.
I this approach, system resources are preserved, and pings are made with sense, also magic packets are not sent if machine is up or guessed up.
Note that firewall should allow ICMP.