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?