Finally found out from where this mysterious 'mcad' service message came from. It turns out that one of my Unifi AP appliances was the culprit and was configured to do remote Syslog server logging to my server gateway. Thanks Nick for your suggestions.
Hello Nick, this is so weird, same here I also can not find what is this 'mcad' process. Nothing pops out from your suggestions, B.T.W. thanks.
I think I might have to change business and start growing potatoes instead.
I had a blip happen to my Gateway vm yesterday. This issue occurred between 2021-04-14 17:00:10 and 2021-04-14 20:55:51. I was notified by email of the issue, the server seem to respond appropriately. The issue stopped without my intervention.
I ran the following cmd while the issue was happening with no results.
I also restarted the vm during the event with no changes to the issue.
Does any one know what is the 'mcad' service?
Dudley Ali wrote:
Philippe Eveleigh wrote:
I could be wrong about this but I do not think you can. I believe there is no connection on cable, you join the Ethernet Network of your ISP.
If you had a PPP (ADSL, VDSL) you would have a better chance at doing this since you actually login for that protocol, you would still need to contact your ISP to see if they allow you to connect more than once. Note this does not provide more bandwidth since that is a feature of the line not the connection.
Thank you I will give it a look
My answer at the time might not be correct. I have learned over time that some ISP's may allow more than one connection by monitoring the MAC addresses used; anyways for ISP’s here in Canada. If you are allowed more than one connection and notice that you are denied your allocated number. You may be required to contact your ISP to clear the MAC addresses that are not in use anymore.
Yes that is what I was concerned with. That this may cause me more grief then needed... as the saying: “if it works, don't touch it”.
For the change of configuration on the ESXi side of things. Yes indeed I can configure the vm as requested to: Other 3.x Linux (64-bit) and that might be a better approach to the issue? I tried and I do not think this configuration will have any ill effect with ESXi since the status of the vm went from warning to normal. For both configuration the vm-tools service is acknowledge as running by ESXi. The only thing that I do not know is if ESXi does any specific type of optimization for a CentOS configuration that might have been beneficiary?
I wish to change the symbolic link:: /etc/centos-release in ClearOS for the following information: CentOS Linux release 7.8.1 (Core)
I am receiving the following log message from ESXi on my setup with the ClearOS current configuration of /etc/centos-release: ClearOS release 7.8.1 (Final)
The configured guest OS (CentOS 4/5/6 (64-bit)) for this virtual machine does not match the guest that is currently running (Other 3.x Linux (64-bit)). You should specify the correct guest OS to allow for guest-specific optimizations.
It appears that this change seems to be relevant for optimizing the performance of ClearOS within an ESXi environment (both being Community Versions). Note that all my ClearOS vm's within my ESXi configuration are all set to CentOS... (which I believe to be the most accurate for ESXi ClearOS combination). I am assuming that vm-tools is providing CLearOS vm the Guest OS version that are set in /etc/centos-release. Having changed the information to the above seems satisfy my ESXI server. Now what I am wondering is if I have created myself future update release issues with CLearOS?
For your information it appears that VMware is only looking at the first digit for the version:
Nick I think you are correct miniUPnP even if it is part of the UPnP Protocol Stack is more involved at the end of the Stack, if port forwarding is required by the device/appliance i.e. TV, receiver, etc...The second issue that I was having has more to do with the Simple Service Discovery Protocol even if SSDP was incorporated in the UPnP Protocol Stack not really related to miniUPnp tasks. In retrospect I confused the two different actions and I should probably have created a second forum entry for my second question.
But all is good with your help I was able to confine miniUPnP port forwarding to the interface of my choice, which is what I wanted. The second issue was to limit the access to my Standalone Server to port 8060 acting as an Emulated Roku device. I think I got that resolved by adding the following two custom rules.
I wish to apologize for the confusion with the interfaces. The interface: ens224 belongs to the Gateway Server HotLan, where the above interface: ens192 belongs to the Standalone server running the emulated Roku device. The first rule is to open the discovery process to the Harmony Hub, this is a standard SSDP process required for the discovery of devices. The second rule is for allowing the Harmony Hub access to the Emulated Roku Device.
For the audience that is wondering how can ClearOS become a Roku device? Well in this particular case it does for my Harmony Hub. The Harmony Remote activities sees the server as a Roku device and triggers Home Assistant events such as controlling lights, motorized curtains, etc... running on the same Standalone ClearOS server.
Thank you again to Nick for all the help.
Nick Howitt wrote:
As far as I am aware, uPnP does not feature in this. I think MiniuPnP's role is to just map external port forwards automatically. I don't know how device discovery works for other devices.
Interesting, I thought it also allowed the devices on your home network to discover each other and access certain services. Thanks for your help in all of this, if I find additional information I will chime in.
Nick Howitt wrote:
Good catch with the loop.
I am lost with the other. Where are the Roku emulator and Harmony Hub (IP's and interfaces)? Have you thought of some packet sniffing with tcpdump?
I agree a little confusing let me try again. For the interface that one is easy, it is all happening on the same my HotLAN: ens224.
The Roku Emulator is the ClearOS Server it run on IP: 192.168.4.26 port 8060 can be accessed with or without the firewall enable via the browser:
The Harmony Hub sits on IP: 192.168.4.205
The Harmony Hub can be asked to discover all appliances and with the help of UPNP it seems to find all the appliances T:V, Receiver etc including the above Emulated Roku 4 on Server 192.168.4.26 when the firewall is disabled. If the firewall is enable all the appliances are found except for the Emulated Roku.
Never used tcpdump, if I can not find the above issue might be a good solution, thanks for the suggestion