Open Brian0117 opened 2 years ago
i alse have this problem...
OpenBMC doesn't expose the VNC port externally; if you want to connect to it with a standard VNC client you can use an SSH port forward via something like:
$ ssh -L 5900:localhost:5900 root@$BMC
and then connecting to localhost:5900 instead.
However, note that obmc-ikvm takes some liberties with the RFB protocol and isn't entirely standards-compliant, so you might need to experiment a bit with different clients and/or client-side settings to make it interoperate.
I have expose the vnc port to all ipaddress. and I have use tight vnc client connect successful. but vnc view cannot connect.
this is the detail msg: libvncserver 0.9.13
Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Got connection from client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 0 other clients Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Client Protocol Version 3.8 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Protocol version sent 3.8, using 3.8 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientSecurityType: executing handler for type 1 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientSecurityType: returning securityResult for client rfb version >= 3.8 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000018) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000016) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000000F) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC6) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling full-color cursor updates for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling NewFBSize protocol extension for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Using ZRLE encoding for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Pixel format for client 172.16.91.16: Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 8 bpp, depth 6 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 true colour: max r 3 g 3 b 3, shift r 4 g 2 b 0 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000018) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000016) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000000F) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC6) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling full-color cursor updates for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling NewFBSize protocol extension for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Switching from ZRLE to raw Encoding for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000018) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x00000016) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0x0000000F) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 rfbProcessClientNormalMessage: ignoring unsupported encoding type Enc(0xFFFFFEC6) Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling full-color cursor updates for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Enabling NewFBSize protocol extension for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Switching from raw to ZRLE Encoding for client 172.16.91.16 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 Pixel format for client 172.16.91.16: Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 32 bpp, depth 24, little endian Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:19 true colour: max r 255 g 255 b 255, shift r 16 g 8 b 0 Feb 11 11:10:19 0000000000000001 obmc-ikvm[30775]: Video::start: host screen size changes (800x600) --> (1024x768)Server::doResize: screen size (1024x768)11/02/2022 11:10:19 Sending rfbEncodingNewFBSize for resize to (1024x768) Feb 11 11:10:20 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:20 ......rfbProcessClientNormalMessage: read: Connection reset by peer Feb 11 11:10:20 0000000000000001 obmc-ikvm[30775]: 11/02/2022 11:10:20 Client 172.16.91.16 gone
this code is where it disconnect
I have deal with this problem for more than 1 week....if someone can help...
Note the error message: Protocol error: unknown rect encoding 7
-- I suspect you're running into the sort of RFB protocol compatibility problems I alluded to earlier.
can you detail what this mean: "the sort of RFB protocol compatibility problems"
or how can I solve this problem?
It's been a while since I looked into it in any detail, but I seem to recall something in the negotiation of the pixel format to be used, with the server (obmc-ikvm) basically ignoring what the client advertises support for and forcing one particular format, which I think was ultimately constrained by the format produced by the aspeed-video v4l2 driver that it reads the framebuffer from (and that in turn may be constrained by the aspeed hardware). It's possible that I'm misremembering or that things may have changed in the meantime though, since that was a year or two back.
@pzh2386034 If you want to use other vnc clients, I suggest you to use tightvnc Refer encoding format in obmc-ikvm https://github.com/openbmc/obmc-ikvm/blob/2d2f3dab4253a3d6edf6bef98c5f880f51d2394b/ikvm_server.cpp#L164
@ all: It is good with UltraVNC? Current last one is 1.4.2.0.
@ all: It is good with UltraVNC? Current last one is 1.4.2.0.
It supports tight encoding. So yeah, as long as you choose tight encoding, it should work with aspeed-video driver.
I have expose the vnc port to all ipaddress. and I have use tight vnc client connect successful. but vnc view cannot connect.
Realvnc doesn't support tight encoding. But it supports JPEG encoding, which is compatible with aspeed video implementation. But to support JPEG encoding, need to patch libvncserver.
@mohammedjavitham: Can you try with the latest UltraVNC Viewer version to confirm that it is okay?
@mohammedjavitham: Can you try with the latest UltraVNC Viewer version to confirm that it is okay?
ssh -L 1234:localhost:5900 root@$BMC
My client is windows 11. Checked using AST2600-A3EVB.
I try to make a connection to BMC embeded VNC server from my laptop VNC viewer, but it's failed. Does OpenBMC support this connection method?