[Bridge] kernel doesn't support bridge with a ppp interface ?

[Bridge] kernel doesn't support bridge with a ppp interface ?

[c.j]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

Hi list,

From kernel code, I found it doesn't support bridge with a port that is a ppp interface:
# brctl addif br_name ppp0
# Invalid arg...

Is there a patch or way to do it if I want to make a kernel bridge with eth and ppp ports?

Reg&Tks

--
c.j

[-- Attachment #2: Type: text/html, Size: 1065 bytes --]

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[Marek Kierdelewicz]

>Hi list,

Hi,

>Is there a patch or way to do it if I want to make a kernel bridge with
>eth and ppp ports?

You can setup a tunnel with OpenVPN. You'd get a tap device on
both sides which can be bridged with eth.

Cheers,
Marek Kierdelewicz

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[c.j]

> You can setup a tunnel with OpenVPN. You'd get a tap device on
> both sides which can be bridged with eth.
Thanks. But maybe we don't want OpenVPN for VPN. Now I can't get why kernel
do not support that. Have some disadvantages?

Reg&Tks

--
c.j

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[Malcolm Scott]

At 21:02 today, c.j wrote:

>> You can setup a tunnel with OpenVPN. You'd get a tap device on
>> both sides which can be bridged with eth.
> Thanks. But maybe we don't want OpenVPN for VPN. Now I can't get why kernel
> do not support that. Have some disadvantages?

I'm not sure if this is even possible using standard protocols.  Bridging is 
for Ethernet; PPP is not Ethernet.  So this would require some sort of 
nonstandard Ethernet-over-PPP encapsulation protocol, and would only make 
sense if the PPP devices at both ends of the link talked this protocol.

This sounds like a job for something outside the kernel, e.g. OpenVPN as 
suggested or a simpler Ethernet-over-IP tunnelling app.

Malcolm

-- 
Malcolm Scott
Research Assistant
University of Cambridge Computer Laboratory

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[Francesco Dolcini]

Malcolm Scott wrote:
> At 21:02 today, c.j wrote:
> 
>>> You can setup a tunnel with OpenVPN. You'd get a tap device on
>>> both sides which can be bridged with eth.
>> Thanks. But maybe we don't want OpenVPN for VPN. Now I can't get why kernel
>> do not support that. Have some disadvantages?
> 
> I'm not sure if this is even possible using standard protocols.  Bridging is 
> for Ethernet; PPP is not Ethernet.  So this would require some sort of 
> nonstandard Ethernet-over-PPP encapsulation protocol, and would only make 
see standard rfc3518, http://www.ietf.org/rfc/rfc3518.txt, I think there 
is a (old?) patch  flying around for this ...

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[Dylan Hall]

[-- Attachment #1: Type: text/plain, Size: 1126 bytes --]

We use vtun which is a userland option, a little slow but offers
rate-limiting and some other nice to have features.

When we require the lowest possible overhead option, we use the etherip
kernel patches.


Dylan


On Wed, 2008-06-18 at 17:41 +0200, Francesco Dolcini wrote:

> Malcolm Scott wrote:
> > At 21:02 today, c.j wrote:
> > 
> >>> You can setup a tunnel with OpenVPN. You'd get a tap device on
> >>> both sides which can be bridged with eth.
> >> Thanks. But maybe we don't want OpenVPN for VPN. Now I can't get why kernel
> >> do not support that. Have some disadvantages?
> > 
> > I'm not sure if this is even possible using standard protocols.  Bridging is 
> > for Ethernet; PPP is not Ethernet.  So this would require some sort of 
> > nonstandard Ethernet-over-PPP encapsulation protocol, and would only make 
> see standard rfc3518, http://www.ietf.org/rfc/rfc3518.txt, I think there 
> is a (old?) patch  flying around for this ...
> 
> 
> _______________________________________________
> Bridge mailing list
> Bridge@lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/bridge

[-- Attachment #2: Type: text/html, Size: 2117 bytes --]

Re: [Bridge] kernel doesn't support bridge with a ppp interface ?

[Dylan Hall]

[-- Attachment #1: Type: text/plain, Size: 1804 bytes --]

It's a little unclear what your setup is, but let me take a guess and
make some suggestions :)

1)  Assuming a setup something like the following

LAN A --- (ETH) [LINUX A] (PPP) [LINUX B] (ETH) --- LAN B

In the above, I would assume the goal is to join (bridge) LAN A and LAN
B together?

You could configure basic IP across the PPP link so that the two linux
boxes can reach each other. 

You then configure something like vtun or etherip to run over the IP/PPP
link between the two linux boxes.

Finally you setup bridges at each end, the result would look something
like:

LAN A --- (ETH){BR on LINUX A}(TUN) --- (PPP) --- (TUN){BR on LINUX
B}(ETH) --- LAN B

The etherip has the caveat that it doesn't support fragmentation so will
only work if the PPP link supports a large MTU, say 1540 or greater.


2) A less likely scenario is

PPP Client --- (ETH)[LINUX](ETH) --- PPP Server

In the above you want to get your PPP session going through a linux box
in the middle.

If the PPP is PPPoE, adding the ETH's to a bridge on the linux box
should be sufficient. 

If it's some other variant of PPP you might be able to use L2TP to
tunnel the PPP between end points. I've seen this done in a DSL/BRAS
environment where the BRAS wasn't directly attached to the DSLAMs. I
suspect this is far from straight forward.



Dylan




On Thu, 2008-06-19 at 23:49 +0800, c.j wrote:

>  
> 
> >We use vtun which is a userland option, a little slow but offers
> rate-limiting and some other nice to have features.
> 
> >When we require the lowest possible overhead option, we use the
> etherip kernel patches.
>  
> Thanks for your kind suggestion.  Whether the etherip patches can
> transmit ppp packet? Since I'm not  familiar  with them , I need some
> time to read them if so.
>  
> Regards~
>  
> --
> c.j

[-- Attachment #2: Type: text/html, Size: 2984 bytes --]