Lenovo m91p i7

[admin]

First issues found within dmesg, although not really affect working normally:

Code: Select all

[    0.024117] MDS CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html for more details.

Is about a vulnerability in CPU buffers. I don't think it will be a big issue, nothing is ' directly' connected to internet.

Next we see:

Code: Select all

[    0.040657] ENERGY_PERF_BIAS: Set to 'normal', was 'performance'

Not an error, but an adjustment of CPU settings.

Not yet checked:

Code: Select all

[    0.188211] PCI: MMCONFIG for domain 0000 [bus 00-ff] at [mem 0xe0000000-0xefffffff] (base 0xe0000000)
[    0.188259] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.188262] pmd_set_huge: Cannot satisfy [mem 0xe0000000-0xe0200000] with a huge-page mapping due to MTRR override.

Due to Realtek 8111 ethernet card? That does weird under windows, not yet under Linux, but also no connection (yet).

Code: Select all

[    0.976863] acpi PNP0C14:01: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:00)

Code: Select all

[    0.977994] ACPI Warning: SystemIO range 0x0000000000000428-0x000000000000042F conflicts with OpRegion 0x0000000000000400-0x000000000000043F (\PMB0) (20200925/utaddress-204)

Code: Select all

[    0.978039] lpc_ich: Resource conflict(s) found affecting gpio_ich

?? last 2 can be solved by:

Code: Select all

[    0.978002] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver

Code: Select all

[    2.441220] systemd[1]: /lib/systemd/system/plymouth-start.service:16: Unit configured to use KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update your service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.

Code: Select all

[    2.759234] at24 0-0051: supply vcc not found, using dummy regulator
[    2.762035] at24 0-0053: supply vcc not found, using dummy regulator

Missing driver for usb wireless ethernet:

Code: Select all

[    3.414665] mt7601u 1-1.1:1.0: Direct firmware load for mt7601u.bin failed with error -2
[    3.415353] mt7601u: probe of 1-1.1:1.0 failed with error -2

DG.

[admin]

More an issue is to use ttyUSB0 on my Debian gnome desktop (user, not root).
Have to check if my other PC is still working with the same USB -> ttl serial dongle and what settings it has.

But for now on this machine:

ls -al /dev/ttyUSB0

Code: Select all

crw--w---- 1 root tty 188, 0 Nov  4 13:43 /dev/ttyUSB0

So it;'s in group 'tty', let's see if I am in that group?

Code: Select all

:~$ id -Gn dolf
dolf tty dialout cdrom floppy sudo audio dip video plugdev netdev bluetooth lpadmin scanner

Yes, we are, but we still can not use the /dev/ttyUSB0 in minicom or putty, without sudo.
If we use sudo, it seems to work but until now only rubbish, although the settings are: 115200,8N1 as it did worked on Windows machine.

dmesg returns:

Code: Select all

[    1.940043] usb 1-1.2: new full-speed USB device number 4 using ehci-pci
[    2.049586] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
[    2.049590] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[    2.049592] usb 1-1.2: Product: USB-Serial Controller
[    2.049593] usb 1-1.2: Manufacturer: Prolific Technology Inc.

lsusb:

Code: Select all

Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P

And even with a udev definition in /etc/udev/rules.d it still does not work.

Also removed modemmanager within linux, no positive result.

The only thing that does work is: chown <USER> /dev/ttyUSB0
But only for that session. Logout and login again it is set back to root.
And the device only returns rubbish.

We even have segment fault in dmesg for putty:

Code: Select all

[35735.953772] show_signal_msg: 13 callbacks suppressed
[35735.953777] putty[9456]: segfault at 8900000002 ip 00005587305c3b21 sp 00007ffeebffd100 error 4 in putty[5587305b1000+a4000]
[35735.953806] Code: 8b 07 ff 50 58 0f b6 d0 eb aa 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 41 57 41 56 41 55 49 89 fd 41 54 55 53 48 83 ec 28 <48> 8b 3f 48 85 ff 0f 84 eb 08 00 00 48 89 f5 41 89 d4 89 cb 84 c9

We have more there (ok, i pulled the USB dongle, as the rubbish was not to follow on screen):

Code: Select all

[37028.601496] pl2303 ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
[37028.601526] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[37028.601980] pl2303 ttyUSB0: usb_serial_generic_write_bulk_callback - urb stopped: -32
[37028.602068] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32
[37028.755243] usb 1-1.2: USB disconnect, device number 4
[37028.756518] pl2303 ttyUSB0: pl2303_set_control_lines - failed: -19
[37028.756526] pl2303 ttyUSB0: error sending break = -19
[37028.756754] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[37028.756792] pl2303 1-1.2:1.0: device disconnected

Default USB to machine in dmesg:

Code: Select all

[37031.026283] usb 1-1.2: new full-speed USB device number 8 using ehci-pci
[37031.147743] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00
[37031.147749] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[37031.147751] usb 1-1.2: Product: USB-Serial Controller
[37031.147752] usb 1-1.2: Manufacturer: Prolific Technology Inc.
[37031.148313] pl2303 1-1.2:1.0: pl2303 converter detected
[37031.150225] usb 1-1.2: pl2303 converter now attached to ttyUSB0

syslog did show:

Code: Select all

Nov  5 01:12:57 DGPC101 systemd[1]: Started Getty on ttyUSB0.
Nov  5 01:13:07 DGPC101 systemd[1]: getty@ttyUSB0.service: Succeeded.
Nov  5 01:13:07 DGPC101 systemd[1]: getty@ttyUSB0.service: Scheduled restart job, restart counter is at 107.
Nov  5 01:13:07 DGPC101 systemd[1]: Stopped Getty on ttyUSB0.
Nov  5 01:13:07 DGPC101 systemd[1]: Started Getty on ttyUSB0.
Nov  5 01:13:17 DGPC101 systemd[1]: getty@ttyUSB0.service: Succeeded.
Nov  5 01:13:17 DGPC101 systemd[1]: getty@ttyUSB0.service: Scheduled restart job, restart counter is at 108.
Nov  5 01:13:17 DGPC101 systemd[1]: Stopped Getty on ttyUSB0.
Nov  5 01:13:17 DGPC101 systemd[1]: Started Getty on ttyUSB0.
Nov  5 01:13:27 DGPC101 systemd[1]: getty@ttyUSB0.service: Succeeded.
Nov  5 01:13:27 DGPC101 systemd[1]: getty@ttyUSB0.service: Scheduled restart job, restart counter is at 109.
Nov  5 01:13:27 DGPC101 systemd[1]: Stopped Getty on ttyUSB0.
Nov  5 01:13:27 DGPC101 systemd[1]: Started Getty on ttyUSB0.
Nov  5 01:13:37 DGPC101 systemd[1]: getty@ttyUSB0.service: Succeeded.
Nov  5 01:13:37 DGPC101 systemd[1]: getty@ttyUSB0.service: Scheduled restart job, restart counter is at 110.
Nov  5 01:13:37 DGPC101 systemd[1]: Stopped Getty on ttyUSB0.
Nov  5 01:13:37 DGPC101 systemd[1]: Started Getty on ttyUSB0.
Nov  5 01:13:47 DGPC101 systemd[1]: getty@ttyUSB0.service: Succeeded.
Nov  5 01:13:47 DGPC101 systemd[1]: getty@ttyUSB0.service: Scheduled restart job, restart counter is at 111.
Nov  5 01:13:47 DGPC101 systemd[1]: Stopped Getty on ttyUSB0.

That remind me of starting a weird service, checked within history i found: systemctl enable & start of getty@ttyUSB0.service
So stopped and disabled that and all working fine now, Putty & Minicom.
Minicom to transfer ASCII code to routers to re-flash them.
Checking if this also works after a reboot. Yes, it works like a charm now

(Really have to start my PC upstairs and see if it is still working there.)
DG.

[admin]

After a long time we found MeshCentral as tool to KVM to the ESXi machine.
This does the job to remote KVM to the ESXi machine.



About AMT and both machines:

According DHCP of the (Fritz!box) router:

Code: Select all

ESX:
DGESXi67-AMT	192.168.117.4		CC:52:AF:41:5D:5F
DGESXi67	192.168.117.5		CC:52:AF:41:5D:5E

Code: Select all

PC:
DGPC101-AMT	192.168.117.160		CC:52:AF:41:5E:04
DGPC101		192.168.117.169		CC:52:AF:41:5E:03

According ESXi the ip 192.168.117.5 is for mac CC:52:AF:41:5D:5F ?
It does work but seems rather weird, switched mac addresses?

Almost the same on the pc DGPC101, Linux OS returns 192.168.117.160 for mac CC:52:AF:41:5E:04, switched host-names?
Again seems rather weird and here it does not work properly.



Some times meshCentral can not connect to AMT, I can not connect with meshAgent the PC with AMT.
Only possible: 1 AMT only device and 1 PC with Agent, not both as seen on the yt video's of meshcentral.

On this PC we can try to clear the AMT fully and let meshCentral do all the things for this PC.
But now the PC has /dev/mei0 but the meshAgent still returns an error.

DG.

[admin]

OpenWrt (x86-64) on MeshCentral Server.

For this you need to know the name or ip of your MeshCentral Server (in my case 192.168.117.24), because you need to adjust the .msh file after installation.

First run the following command on the OpenWrt instance (device/vm).

Code: Select all

wget -O meshagent --no-check-certificate "https://192.168.117.24/meshagents?id=5K4nTjjf7F%24ePgdVWcptjV4WGU6oEuy7QlgfP4v7fPom9cOBivWzUGtwcFHY4yQU&installflags=0&meshinstall=36"

After this download of MeshAgent change it's properties to be executed:

Code: Select all

chmod +x meshagent

Now install of MeshAgent:

Code: Select all

./meshagent -install

I use nano as text editor, you can use other (your own) editors if you want.
Adjust the .msh file with your ip (or name):

Code: Select all

nano /usr/local/mesh_services/meshagent/meshagent.msh

Change rule:

Code: Select all

MeshServer=local

into:

Code: Select all

MeshServer=wss://192.168.117.24:443/agent.ashx

Change the above ip with your name or ip of your MeshCentral server.

Nest stop and (re)start the MeshAgent service:

Code: Select all

service meshagent stop
service meshagent start

Now the Agent should be running and add itself into MeshCentral Server.

If your OpenWrt is outside your LAN (or in different subdomain, make sure both can 'see' (ping) each other on tunneling or other way.

DG.