Does they have iKVM support schedule?

[NorihisaNakai]

Hi,
We want to connect to iKVM (Supermicro motherboard IPMI VNC Server) on noVNC.
But, iKVM VNC protocol use original future on VNC protocol.
if project have to support iKVM, would you tell me schedule?

Thank you for your cooperation.

Norihisa Nakai

[DirectXMan12]

So, it looks like someone took a shot at it. If you can provide some documentation on how the IPMI VNC Server works, we will consider attempting to add support. It's difficult, however, since we do not have an actual device to test against, AFAIK.

[jimdigriz]

I'm working on it (doing this on and off in my spare time):

https://github.com/jimdigriz/noVNC/tree/aten-ikvm (rebased regularly from pixelformat, which its-self is rebased against upstream master)

Had to first solve the pixel format constraint (iKVM uses RGB555 and noVNC is hardcoded for RGB888) which is done (https://github.com/jimdigriz/noVNC/tree/pixelformat), but it does bump the IE dependency to 10 as we have to handle endian/bitshifting conditions.

[jimdigriz]

My aten-ikvm branch seems to work (lots of wisdom from https://github.com/thefloweringash/chicken-aten-ikvm/blob/master/lens/lens.rb), needs others to test it though and things to bear in mind:

• to send your credentials, you use 'username:password' in the password field; similar to how xvp does things
• browser linky would look like http://localhost:6080/vnc.html?host=localhost&port=6080&logging=warn&password=USERNAME:PASSWORD
• not tried resolution changing, but should work
• no remote media support, but I recommend folks just use floppy images (uploadable with curl) with iPXE - http://www.digriz.org.uk/ipmi
• mouse support in there, not tested
• someone needs to try this against other 'normal' VNC servers, I have tested against Debian 'wheezy's tightvnc 1.3.9-6.4 server
• the Intel ATM tweak needs testing, but should work due to the pixelformat stuff

The pixelformat branch, which the aten-ikvm branch branches off, should hopefully lay down some of the code needed to address #396 too.

[jimdigriz]

Now tested against the following Supermicro motherboards:

• X8DTL
• X9SCL/X9SCM
• X9SCM-F - thanks to Brian Rak for testing!
• X9DRD-iF
• X9SRE/X9SRE-3F/X9SRi/X9SRi-3F
• X10SLD

Unfortunately it seems newer models (e.g. X10SLM-F and X10SLE) use some new encoding method 0x57 (87) which needs to be reverse engineered.

[DirectXMan12]

Sweet! We'd be glad to merge your branch once you think it's finished. Please include unit tests, if you can, and then just add a pull request (reference this bug).

[bkanuka]

Do we need websockify to use iKVM?

[jimdigriz]

Yes, it uses VNC over port 5900/tcp. ATEN have just 'forked' the VNC protocol into something...else :-/

[astrand]

I'm not sure it's a good idea to merge support for an undocumented "forked" VNC protocol. How are we supposed to be able to maintain that, without some reference? In my opinion, noVNC shouldn't implement anything that's not documented by https://github.com/rfbproto/rfbproto. So if you really care about this ATEN protocol, my suggestion would be to first submit patches to the rfbproto project that documents this stuff.

[jimdigriz]

Congratulations astrand for volunteering!

Alas, if this is where the party is going, I am going to get my coat.

DirectXMain12, if you find any technical problems with the patch (regressions, patch sucks, sets pants on fire, etc) then let me know and I will jump back in and fix it. At some stage I will dip in and try to figure out the encoding ATEN have started to use on their newer systems so we can get that squished and spare folks enduring the ghastly Java client.

[astrand]

I'm not volunteering for anything. I just want to make sure that me and my team doesn't need to spend many years trying to maintain code that implements some undefined hackish protocol that we have no interest in.

This is just my opinion, the other developers might think differently. Also, if you are willing to maintain the code for some time (rather than just providing a one time patch), that would also help.

[samhed]

@jimdigriz thanks for the work on this!

As mentioned, I don't think anyone in the noVNC team has any hardware for testing this though. This is why I agree with @astrand in the way that we need to be cautious with merging stuff regarding the RFB protocol which is undocumented.

@DirectXMan12 and @kanaka what do you think about this?

[DirectXMan12]

@jimdigriz : There's a couple things that I'd like you to fix on the pull request before we even consider merging it. I've left comments there

@samhed , @astrand , @kanaka : So, I'm a bit divided on this. One the one hand, supporting undocumented features is always tricky. On the other hand, I've used the Java client (it might not have been the ATEN one, but something similar), and, boy, was it horrible. Having an alternative, especially one that companies could easily embed in their standard interface (i.e. noVNC), would be really nice, and would also look good for the noVNC project itself ("Use noVNC to simplify administering your lab, even without an OS installed!").

I wonder if there's any way we could support this via some sort of plugin system? Between this and the issues with Tight, I'm beginning to wonder if we shouldn't have some sort of pluggable encoding architecture. @jimdigriz : could you envision this working inside something like that?

[bkanuka]

@DirectXMan12 I fall exactly into the group you mentioned. I was exposed to this bug report and noVNC by searching for alternatives to that horrible horrible Java client. Your hesitation to merge undocumented protocols is completely understandable, but man would I love to use noVNC instead of java :-)

[jimdigriz]

I originally started writing the ATEN support for Debian's tightvnc viewer, but as I prefer to code myself with a reference implementation to hand, I quickly shifted to using noVNC as everyone and their dog can read Javascript. This was my primary objective, to help someone else write their own client implementation. That my infrastructure team no longer has to endure using the Java client, was just a cherry on the cake. For me, thats "mission accomplished".

I would be careful with using the word 'plugin', I have no idea what the implications (or need) to have something working via "some sort of plugin system". Code is code, it can be written in whatever way needed. If you want to try your plugin approach, really, just write a prototype, if it takes more than two days, abandon it, what you have is good enough already. If you want to try anything, I would recommend noting that the RFB protocol lends its self to a client implementation that just builds a tree and walks up and down it, as in if there is a conditional (if/switch) statement in the code, it probably is being done wrong. The gripe I had with noVNC codebase was nothing to do with OO/seperation/etc, it was the byte queue/dequeuing handling and the twisty maze of if statements that staple together a state machine (the encoder handlers should not have conditionals in there).

To the patch, if you look at pixelformat..aten-ikvm, I actually thought it all slotted in rather neatly without too much pain. The auth hook could be made nicer and I agree it looks scary, but it does just seem to work automatically, including for tightvncserver. Writing the whole patch really was just me battling with Javascript and the quirks of the ATEN protocol; noVNC its-self was really nice to work with here. Thanks!

What concerns me though is that master..pixelformat patch is intrusive, and it was a complete ballache to write as noVNC completely ignored that maybe it would be forced to do local pixel transformation its self; all my time here was spent trying to minimise the impact of the patch. Being that that it covers something already documented plus a major (albeit hard) part of the RFB protocol, makes me feel that there is some bike shedding going on where the focus is on the minor patch and not the major intrusive work. Why is there even talk of plugins at this point?

I know this patch works with tightvnc and the seven different models of ATEN chaff I have access to at work and I have had one random Internet stranger I approached out of the blue try it with success too. Has anyone with write access to the project actually put aside what the patch is/does and just tested it for real regressions on real hardware in real life? If not, really can we deal with technical rather than abstract problems first. If they did, what did I break?

[DirectXMan12]

What concerns me though is that master..pixelformat patch is intrusive, and it was a complete ballache to write as noVNC completely ignored that maybe it would be forced to do local pixel transformation its self

I suspect @kanaka did that for convenience when he wrote it, but I'm not sure

Why is there even talk of plugins at this point?

I wouldn't use a plugin for the PixelFormat stuff -- it's just something we should have. Thanks for taking the time to work through that. If nothing else, I'll definitely merge that (although I really hope we can merge the rest as well ;-) ). The reason I was considering a plugin system is that it would make it easier for deployers of noVNC to chose which encodings they wanted to enable and disable.

I know this patch works with tightvnc and the seven different models of ATEN chaff I have access to at work and I have had one random Internet stranger I approached out of the blue try it with success too.

That's good to hear. Unfortunately, I'm not sure if any of us has access to hardware (I'm check with work to see if I do), so I'm mainly relying on you here to test the iKVM parts. I'll run some more local tests to make sure the patch works on normal RFB servers.

Thank you for all your hard work, and know that I really do want to see this in noVNC in some form. I just want to be careful not to get bitten by any bugs WRT "normal" RFB communication

[MartinVerges]

Hello,

we can provide some test systems for ATEN IPMI (Supermicro Servers) and would like to support your effort to implement it in noVNC. As you might know, IPMI is widely used on server systems and the java viewer is a pain in the a**. I personal want to get rid of that java viewer for better customer experience.

We are also willing to spend some money to get this solved and if somebody can do it, we would be glad to push noVNC to IPMI / KVM Support.

At the moment, it does not work in my test with X9SCM-F (other than stated) as it response "No supported sub-auth types!"

Best Regards
Martin

[sbrynen]

When I try this against IPMI on a X9DRi-LN4F+ Supermicro, it hangs at "Starting VNC handshake"

[frovik]

I tested this software and can confirm it actually works quite well. The motherboard we tested it to work on was X7SPT-DF-D525+ . However, I expect most of x7-x8-x9 motherboards should work.

How can we get more momentum with this? I would be more than happy to provide access or even donate hardware to get more testing going here so we can have this integrated and even maintained.

[andrew-azarov]

We can provide the X10 system to test and debug

[DirectXMan12]

@andrew-azarov While I will not have time to work on this in the near future (I'm busy with some other stuff for work), we did, I some point, have some people interested in working on this. I will see if I can get them in touch with you.

[kelleyk]

I reverse-engineered the 0x57 format (and decent chunks of the iKVM client and server binaries) last year and got distracted by life before finishing a reimplementation of it. If there's renewed interest in merging 0x56/0x57 support into noVNC, I'd be happy to dust off my work.

It's worth nothing that the ATEN formats (and the underlying BMC hardware) support multiple different types of encoding and compression (one that's like JPEG with fixed tables and two types of color quantization, if memory serves), even if the current firmware only seems to use a very limited subset of that functionality (just the JPEG format, even at a black-and-white prompt; a fixed screen resolution; etc).

I have X9 (WPCM450) and X10 (AST2400) hardware handy to test with. There is also some X8/X9 hardware that uses a Renesas SH7757/7758, which I do not have access to.

[disaster123]

+1 that would be great the Java client just sucks

[andrew-azarov]

+1 That would be awesome.
There is a way to connect media through samba, but the console client is not vnc compatible unfortunately.

[MartinVerges]

+1 that would be fantastic
We would be happy to provide demo equipment for you

[disaster123]

@kelleyk any news on this topic?

[devicenull]

Enabling --ssl-target on websockify gets you a step closer, but in my case I'm then getting 'Invalid server version: 055.008)

[disaster123]

I modified the code so it accepts 055.008 but when novnc sends a client version of 003.008 the server closes the connection ;-(

[devicenull]

Yea, take a look at kelleyk#1 . It gets you a step further, but then fails to actually auth.

What's funny is this board has kellyk's noVNC fork embedded in it. It certainly makes figuring out what's wrong easier

[devicenull]

I added auth support in kelleyk#2 , but it still won't actually work.

[kelleyk]

@disaster123 That's the current version, yes.

Let me see if I can find a moment to take a look. If other people are being impacted by the way that the newer firmware behaves, please speak up!

[disaster123]

@kelleyk
Hi, see here kelleyk#2 (comment)

[phil21]

It may be useful if someone with an affected X11 board can make it available for @kelleyk (hey!) to debug directly against. This of course means a non-production machine suitable for lab use.

I honestly haven't had the time (or yet need) to dig deeper into the new html5 firmware on the BMC, but I suspect a few changes.

[jleroy]

I don't know if it's the right place to ask this question, but since I've updated my noVNC setup from kelleyk/noVNC@63cc01f to kelleyk/noVNC@eb386b7 I can no longer connect to any of my servers.

I get an "Unsupported server" error in noVNC UI.

Here's the motherboards I use:

• X9SRI-F
• X9SRH-7TF
• X10SRi-F

Is this a known issue?

[kelleyk]

@jleroy Hm -- no, I wasn't aware of issues like that. Would you mind opening an issue in kelleyk/noVNC and repeating that information, along with the firmware version of each board you've tried?

[jleroy]

@kelleyk The "Issues" tab seems to be disabled on kelleyk/noVNC repository (or maybe I'm really tired).

[Marlinc]

@jleroy @kelleyk I noticed the same "Unsupported server" error on X8SIL-F (version 03.16) using that commit.

[kelleyk]

I've enabled issues on that repository.

Yikes; I'm sorry to have caused trouble for so many of you! Please file issues and tell me which version (commit SHA) of noVNC you're using, which board you're trying to connect to, what version its firmware is, and what happens.

[jleroy]

@kelleyk: Thank you. I've created an issue on your repository.

[devicenull]

BTW, X11SSE-F now works correctly using kelleyk#2

[vtolstov]

what about hp ILO support ?

[disaster123]

@kelleyk @devicenull is there a current branch merging all open pull requests regarding kvm? I lost the overview / current status of this one.

Also is there any chance this gets merged into novnc?

[DirectXMan12]

I'm still open to merging this, assuming it gets rebased. If it has been rebased (and I've just missed it), please let me know and I'll start reviewing.

[vtolstov]

does anybody can helps me understand how aten ikvm subrect encoding transform to basic raw encoding?
I'm try to write server side proxy to convert aten ikvm traffic to plain vnc. And now i don't understand how to convert subrect..

[beren12]

This is great, would love to see it merged. How different is the AMI hardware, do you know at all? I was so excited to be able to not need java to do server maintaince, then I found out my X8 has the AMI board, not the ATEN.

[kelleyk]

@vtolstov The best documentation is probably my implementation, which you can see here: https://github.com/kelleyk/noVNC/tree/bmc-support/core/ast2100

Each frame is a list of MCUs, which could feasibly be translated into a subrect. The loop that decodes each block (MCU) in a frame is here: https://github.com/kelleyk/noVNC/blob/bmc-support/core/ast2100/ast2100.js#L235

Each MCU begins with a four-bit value that indicates how it is encoded. There are two distinct types of compression involved. The first is based on vector quantization (with 0, 1, or 2-bit codewords, producing 1, 2, or 4 colors) and the other is similar to how JPEG/JFIF MCUs are compressed. The Huffman and quantization tables are not contained in the data stream, but you can extract them from my work. There is also support for 4:2:0 chroma subsampling; in this mode, there won't be any VQ blocks.

Like in JPEG/JFIF, the MCUs are 8x8 pixels (for either compression method) when chroma subsampling is disabled, and 16x16 pixels when chroma subsampling is enabled.

[kelleyk]

@beren12 The AMI board is unlikely to be very similar; it's a different SoC and different software stack. Sorry!

[beren12]

Ah, figures. I'll just have to keep using a vm with java installed.

[beren12]

Great work though!

[leakira]

Hi

I have an server with iLO and IPMI access.
I want to create a web console with this server using ipmi sol (serial over lan). The solution I think is redirect sol connection (ipmitool sol activate) to a kvm device.

Searching in DigitalOcean console, I see they are using noVNC to create the console, and searching more I got a way to connect an Ubuntu console using qemu (qemu-system-i386 -vnc :1 -nographic -serial mon:stdio -append 'console=ttyS0' binary.img -kernel /boot/vmlinuz-3.13.0-141-generic) and output it using noVNC (./utils/launch.sh --vnc localhost:5901).

So now I need to remotelly redirect ipmi sol to access this server console, but I don't have idea in how to create this redirection, and if it is possible.
I have tried an other solution using iLO configured ports to connect it direct to noVNC, but not worked and got Connection refused.

Anyone has a suggestion about this case?
Thanks

[dlenwell]

Did this ever get merged into the main repo?

[kelleyk]

No, it hasn't been, yet--sorry! I've been pressed for time.

…

On Sat, Aug 25, 2018 at 12:28 PM, David Lenwell ***@***.***> wrote: Did this ever get merged into the main repo? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#385 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAx_hscHEvIc7920Q2OSayTRuD5r4A69ks5uUaV7gaJpZM4CYH0E> .

[joshbgosh10592]

Figured I'd chime in as well - I'm having the same error as a few above - "Unsupported server" on my X9DRD SuperMicro board using FW: 3.39.

[dsully]

Checking in on this a few years later..

[JornS-pexip]

Me3 - would love for this to get merged!