On Tuesday July 27, j...@yonan.net wrote:
> Neil,
>
> Comments Inline below...
>
> Neil Brown said:
>
> >
> >
> > As was hinted at with the previous patch, this patch introduces a new
> > config option "net-type". It can be either "ptp" or "subnet".
> >
> > If net-type is not explicitly giv
On Tuesday July 27, j...@yonan.net wrote:
> I agree with you that tunnel device type and subnet vs. point-to-point mode
> are mutually exclusive properties.
>
> My main concern is preventing an explosion in the size of the parameter
> permutation space, where the code has to handle 4 cases of dev/
On Tuesday 27 July 2004 11:25, James Yonan wrote:
> Neil,
>
> Thanks for the patches... here are some comments:
>
> * You've obviously put a lot of effort into understanding the code to write
> this patch. But did you consider any alternative approaches, such as
> starting multiple OpenVPN instanc
On Tuesday July 27, j...@yonan.net wrote:
> PUSH_DEFINED is currently unused, so overall I don't have any problem with
> this. Probably when something gets written that needs PUSH_DEFINED, the
> subtletes of how it should operate will become more apparent.
>
It was used in beta6 which is what I
Neil,
Comments Inline below...
Neil Brown said:
>
>
> As was hinted at with the previous patch, this patch introduces a new
> config option "net-type". It can be either "ptp" or "subnet".
>
> If net-type is not explicitly given then:
> if "dev" is "tun", "net-type" will be "ptp"
> if "d
I agree with you that tunnel device type and subnet vs. point-to-point mode
are mutually exclusive properties.
My main concern is preventing an explosion in the size of the parameter
permutation space, where the code has to handle 4 cases of dev/net
permutations instead of only two.
$ grep DEV_TY
PUSH_DEFINED is currently unused, so overall I don't have any problem with
this. Probably when something gets written that needs PUSH_DEFINED, the
subtletes of how it should operate will become more apparent.
James
Neil Brown said:
>
> This patch is of little import, but I thought I would sub
Neil,
Thanks for the patches... here are some comments:
* You've obviously put a lot of effort into understanding the code to write
this patch. But did you consider any alternative approaches, such as starting
multiple OpenVPN instances and binding each to a separate local interface?
* A lot of
