Hyper-V ICS 1.0 (w/Synthethic Network Driver) for pfSense 2.1 & 2.1.1

Guest

Also, please see here for many requests from the community for Hyper-V support:

https://blog.pfsense.org/?p=705#comments

Please, please, please can we have official Hyper-V support!

Peter

Yes, if the community will assist.

Guest

@peterclark4:

Is it possible for the pfSense team (or should I say ESF?) to implement this into 2.1.1???

Even if it means that we have to enable it in the Advanced settings or modify some System Tunables or something.

Peter

It probably won't make the 2.1.1 release train, but I think a test version based on 2.1.1 could be made available.
Then we could move to the 2.2 train for Hyper-V support (which eliminates the back port.)

peterclark4

@gonzopancho:

@peterclark4:

So what needs to happen for us to have an official pfSense build with Hyper-V support?

I thought I already outlined that. I'm willing to make it happen, but I'm going to need some help (perhaps from zootie),
and it will (of necessity) need to be buildable from source. Once that happens, we can produce an official 'snapshot' for
people (like you) to test, as well as setup for the test harness at work.

@peterclark4:

I understand that you are protecting your trademark and I think that pfSense is worth protecting.

Thank you.

@peterclark4:

If you need to test an official pfSense build with Hyper-V support I'll be more than happy to test so that this can be released.

Thank you.

Many thanks for replying, it's much appreciated, it's great to finally have a an acknowledgment and a response from the pfSense team!

Hopefully zootie will be more than happy to help out. He has spent considerable time already in supporting the Hyper-V part of the pfSense community.

I look forward to having an official build to play with in the future!

Peter

Guest

@doktornotor:

zootie, you'd better remove your VHDs before you receive "the most polite letter possible via the law firm". You know, you can only provide "genuine pfSense software". Not kidding ya. ::)

BTW, your Option C is useless due to actions taken by the pfSense guys, which they apparently wish to continue. You know, they think noone should have access to the build tools repo, unless it's "subject to certain contractual obligations". Otherwise you're gonna get accused exactly like the poor guy who built an early v2.2 image and posted that on the forum. And you'll become a horrible offender who "built something that clearly was not “pfSense”, named it “pfSense 2.2”, violating our registered trademark, and then announced on the pfSense forum with an adulterated logo."

This project has become a pile of legal BS. >:( >:( >:(

I'm sorry you feel that way. Perhaps you would like to explain your viewpoint more.

Guest

I have edited the original post to remove the links.

key4ce

Outch.

Even threatning with legal action to something what i see as a major contribution (helping pfsense work on a hypervisor).
We where about to release a fully working pfsense with Citrix Xenserver 6.2 for the community.

but i guess we will keep that build to our selfs after reading this.

For the admins in question: i would really wonder if thats a right way of handling things if you say you depend on the community yet shoot it down when they do actually contribute :-)

Regards,
Marco

zootie

@key4ce:

Outch.

Even threatning with legal action to something what i see as a major contribution (helping pfsense work on a hypervisor).
We where about to release a fully working pfsense with Citrix Xenserver 6.2 for the community.

but i guess we will keep that build to our selfs after reading this.

For the admins in question: i would really wonder if thats a right way of handling things if you say you depend on the community yet shoot it down when they do actually contribute :-)

Regards,
Marco

Try and stay positive, and try and find a way to keep contributing. We might be able to find common ground.

Sometimes, I'm somewhat reticent to keep contributing. I don't like that 2.2 might be having a community edition separate from a more formal (and functional) commercial edition: in my experience, the community edition ends up purposely crippled with only minor features to drive customers to the commercial edition. Then again, I might be misinformed (remember vaguely reading about the possibility of the split, can't remember if it was an official source, and even that might change) and maybe there are no plans on such a split, or even if it splits, the community edition might keep thriving and benefit from a more formal commercial endeavor that can channel more resources to improving the product. It is far too early to tell and the pfSense team deserves the benefit of the doubt.

In the end, I've benefited from past work from the pfSense and monowall community, and I intend to keep helping if I can find a way to do it.

If your modifications were based on the build process, we might be able to figure out how to integrate your changes (same way we're trying with the hyperv drivers).

zootie

@gonzopancho:

I thought I already outlined that. I'm willing to make it happen, but I'm going to need some help (perhaps from zootie),
and it will (of necessity) need to be buildable from source. Once that happens, we can produce an official 'snapshot' for
people (like you) to test, as well as setup for the test harness at work.

@peterclark4:

Many thanks for replying, it's much appreciated, it's great to finally have a an acknowledgment and a response from the pfSense team!

Hopefully zootie will be more than happy to help out.

Yes, I'd be happy to help. In Option C, the drivers were compiled from lightly modified hyperv for FreeBSD 8.3 port source (the only modifications were to Makefiles to get the patch to apply, but we can probably forgo these changes by creating a patch that only applies to sys/modules/hyperv - something I didn't know when I started, hence the more inclusive patch). The source compiles using pfSense-tools and get the ko modules included on the ISO (they're included with the other kernel modules). However, I just need some help to get the drivers installed/used by the installation process.

I can try to keep digging, figuring out pfsense-tools by trial an error (since I haven't found any documentation on the tools other than inline comments). However, I'd only be struggling to figure out info that someone more familiar with the build process already knows (saving me hours of running in circles). Maybe someone that worked to integrate the virtio drivers? Or someone that would know how to instruct the installer/builder to modify /boot/loader.conf (if that is the best way to do this, maybe there is a way to have the installer only make the modification only when Hyper-V is detected).

gonzopancho, can you put me in touch with someone more knowledgeable on the tools? I'll probably need access to the tools repo (as instructed in the development list, I emailed a week ago with an SSH key to gain access, didn't hear back).

Thank you

key4ce

hmm,

Well difficult to stay positive on this aspect :-)
we where actually planning on fixing up the CARP issue with hyper-v and your iso but few months later and it's no longer there.

(so now it seems we are going to build it from scratch like we did with XenServer).

Actually it's funny you mention the commercial edition rumors, as thats the feeling i had when reading about what happened with hyper-v + pfsense (and why we are now looking for more real community driven firewalls).

vyatta did that too.. even gone as far as removing the web gui from community.. now bought by another company and no more updates since 2012.

There's only very few who survive going from opensource to commercial with maybe a community branch, most just die out :-)

As far as how it's developped: we pretty much used freebsd 10 kernel as a roadmap so it's not easy to deploy on a existing pfsense (we do have a neat pre-build iso which also fixes even the xen guest boot and reboot issues, or the delayed press i to install where xen console tends to not refresh properly so we auto install :P)

doktornotor

@gonzopancho:

I'm sorry you feel that way. Perhaps you would like to explain your viewpoint more.

Uhm… explain what? Already posted my thoughts here and on another related threads, pretty clearly. Instead of providing people with a build tools switch to build unbranded code stripped of your trademarks, you nuke the repo access and red-tape an open-source project with tons of legal BS. Sigh.

bryan.paradis

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse. Now we have an opensource project that isn't buildable?

Is the solution going to be to have an internal branded buildtoolset and a unbranded copy of that on public git?

doktornotor

@bryan.paradis:

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse.

Knee-jerk reaction, borderline paranoia.

@bryan.paradis:

Now we have an opensource project that isn't buildable?

Which - for me - is a complete and utter fail of the BSD license…

Guest

@zootie:

Yes, I'd be happy to help. In Option C, the drivers were compiled from lightly modified hyperv for FreeBSD 8.3 port source (the only modifications were to Makefiles to get the patch to apply, but we can probably forgo these changes by creating a patch that only applies to sys/modules/hyperv - something I didn't know when I started, hence the more inclusive patch). The source compiles using pfSense-tools and get the ko modules included on the ISO (they're included with the other kernel modules). However, I just need some help to get the drivers installed/used by the installation process.

I can try to keep digging, figuring out pfsense-tools by trial an error (since I haven't found any documentation on the tools other than inline comments). However, I'd only be struggling to figure out info that someone more familiar with the build process already knows (saving me hours of running in circles). Maybe someone that worked to integrate the virtio drivers? Or someone that would know how to instruct the installer/builder to modify /boot/loader.conf (if that is the best way to do this, maybe there is a way to have the installer only make the modification only when Hyper-V is detected).

gonzopancho, can you put me in touch with someone more knowledgeable on the tools? I'll probably need access to the tools repo (as instructed in the development list, I emailed a week ago with an SSH key to gain access, didn't hear back).

Thank you

I'm certain that I have access to pfsense-tools. Several people I work with do, too. (This is because CMB and I own ESF.)
The larger issue is 'testing', and setup of a Hyper-V environment to do so.

Guest

@doktornotor:

@bryan.paradis:

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse.

Knee-jerk reaction, borderline paranoia.

@bryan.paradis:

Now we have an opensource project that isn't buildable?

Which - for me - is a complete and utter fail of the BSD license…

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

Guest

@key4ce:

Outch.

Even threatning with legal action to something what i see as a major contribution (helping pfsense work on a hypervisor).
We where about to release a fully working pfsense with Citrix Xenserver 6.2 for the community.

but i guess we will keep that build to our selfs after reading this.

For the admins in question: i would really wonder if thats a right way of handling things if you say you depend on the community yet shoot it down when they do actually contribute :-)

Regards,
Marco

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

Guest

@bryan.paradis:

The perversion of the project brought on by one person building and distributing, which was taken down after a request I think is far worse. Now we have an opensource project that isn't buildable?

Is the solution going to be to have an internal branded buildtoolset and a unbranded copy of that on public git?

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'

Someone else could do this, of course. The BSD license allows it. Some have even been successful.

doktornotor

@gonzopancho:

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

And I tried multiple times to suggest that if you are so paranoid about your trademarks, you should provide people with way to build unbranded code instead of removing access to build tools. I tried to explain, but you seem to not be listening. :o

(As for what I'm familiard with, I'd suggest reading the other thread.)

@gonzopancho:

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

So the code is no longer BSD-licensed? Good that it's clear now that it's not just Jim T. going wild. Pretty much finished this as open-source project. >:(

@gonzopancho:

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'
Someone else could do this, of course. The BSD license allows it. Some have even been successful.

Yah. Pissing people off with legal threats is surely a way to accomplish volunteer effort and motivation. You must be kidding. (Actually, they could not do it now, not without using the forked outdated repos at least.)

Guest

@doktornotor:

@gonzopancho:

You apparently are unfamiliar with trademark law. I tried to explain, but you seem to not be listening.

And I tried multiple times to suggest that if you are so paranoid about your trademarks, you should provide people with way to build unbranded code instead of removing access to build tools. I tried to explain, but you seem to not be listening. :o

(As for what I'm familiard with, I'd suggest reading the other thread.)

@gonzopancho:

When the -tools repo comes back, you'll be able to build something called "pfsense" with your changes, but you won't be able to distribute it without prior permission (a license) from ESF.

So the code is no longer BSD-licensed? Good that it's clear now that it's not just Jim T. going wild. Pretty much finished this as open-source project. >:(

@gonzopancho:

No, I'd considered this, but I'm not going to unbrand pfSense for the 57 companies that all want that from us now.'
Someone else could do this, of course. The BSD license allows it. Some have even been successful.

Yah. Pissing people off with legal threats is surely a way to accomplish volunteer effort and motivation. You must be kidding. (Actually, they could not do it now, not without using the forked outdated repos at least.)

Doing as you suggest, building a -tools repo with no branding, helps you, but it also helps many companies who want to rip-off pfSense and build their own 'firewall'. Right now, several companies actually pay for that.

Your thoughts seem to mostly consist of rants that ignore the legal realities. Even here you speak of "tons of legal BS", but
it is not BS.

What do we do, doktornotor, when someone eventually builds a version of 'pfSense' that contains a hostile payload? Remember that this is a security project/product.

I'm offering to open a dialogue, you're refusing. We both lose.

Yes, the project is still BSD-licensed. The BSD license covers copyright, not trademark (nor patents, which is why we have the MPL.)

Guest

doktornotor

Which part is it that concerns you most:

not currently having access to -tools
not being able to distribute your personal build and still call it pfsense

The situation with #1 will change.
The situation with #2 can not.

doktornotor

@gonzopancho:

Doing as you suggest, building a -tools repo with no branding, helps you, but it also helps many companies who want to rip-off pfSense and build their own 'firewall'.

Rip off? LOL. Yeah, and people rip off Ubuntu daily. And Debian. And… (Read the other thread, really.)

@gonzopancho:

Right now, several companies actually pay for that.

They do? Looks like the rebranding service no longer exists, plus you clearly refuse to do it - "I'm not going to unbrand pfSense for the 57 companies that all want that from us now."

@gonzopancho:

Yes, the project is still BSD-licensed. The BSD license covers copyright, not trademark (nor patents, which is why we have the MPL.)

Well, sorry, no. It is NOT BSD-licensed any more. Since "you won't be able to distribute it without prior permission (a license) from ESF." is directly incompatible with the BSD license.

@gonzopancho:

Which part is it that concerns you most:

not currently having access to -tools

not being able to distribute your personal build and still call it pfsense

The situation with #1 will change.
The situation with #2 can not.

Ad 1/ It won't for change anything for me. Clearly I'm NOT going to sign any licensing agreements to get access to build tools.
Ad 2/ Yes, because there's no –without-branding switch to build the code. Right, you feel ripped off, so there won't be one.