noVNC
noVNC copied to clipboard
novnc
Does they have iKVM support schedule?
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
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.
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.
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 https://github.com/kanaka/noVNC/issues/396 too.
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.
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).
Yes, it uses VNC over port 5900/tcp. ATEN have just 'forked' the VNC protocol into something...else :-/
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.
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.
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.
@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?
@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?
@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 :-)
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?
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
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
When I try this against IPMI on a X9DRi-LN4F+ Supermicro, it hangs at "Starting VNC handshake"
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 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.
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.
+1 That would be awesome. There is a way to connect media through samba, but the console client is not vnc compatible unfortunately.
+1 that would be fantastic We would be happy to provide demo equipment for you
@disaster123 I spent some time on this a few weeks ago, and I'm pretty sure that I have the JPEG side of things pretty well figured out. At that point, I got distracted by life.
When next I can set aside an afternoon, I'll try capturing some sample traffic and implementing something that can actually decode video frames. (It is also possible that I may need to dump the Huffman and quantization tables from the client, since they're hardwired; they may be fairly normal ones, or they may not be.) Once that's done, we'll just need to figure out what the best way of integrating it into noVNC is.
Just wanted to reassure everybody that I'm still working on this.
I've got it almost entirely figured out. There's a lot of dead code in the client corresponding to features that are simply never used, as far as I can tell, so I wound up reverse engineering way, way more than would otherwise have been necessary.
I've also finished reimplementing the majority of what I've learned about how the 0x57 video encoding works. Unfortunately, there's still a problem (or two); the output is not reasonable. (Drat.) At the moment I'm working on trying to determine whether this is because I screwed something up during the reimplementation effort, or because of something I'm misunderstanding about the data format.
Hope to have good news soon!
@disaster123 @MartinVerges @andrew-azarov What hardware (boards) are you guys using? I have a few to test with, but different BMCs and/or different firmware revisions might use different features of the protocol/format.