From: Patrick McHardy <kaber@trash.net>
To: James Chapman <jchapman@katalix.com>
Cc: netdev@vger.kernel.org
Subject: Re: [PATCH 1/5 2.6.21-rc4] l2tp: pppol2tp core
Date: Sat, 24 Mar 2007 21:56:44 +0100 [thread overview]
Message-ID: <4605908C.6050205@trash.net> (raw)
In-Reply-To: <4605758F.90205@katalix.com>
James Chapman wrote:
> Patrick McHardy wrote:
>
>> The interaction with UDP sockets looks pretty horrible IMO. On the
>> send side I don't see why you can't simply build the UDP header
>> yourself instead of doing these set_fs + sendmsgs hacks.
>
>
> Wouldn't that effectively duplicate the code in udp_sendmsg()? If I
> don't use a socket, I'd also have to build an IP header and feed the
> frame into the IP stack for outbound routing. It doesn't feel like the
> right thing to do.
Thats what other tunnel drivers do. Sending UDP is pretty simple, I'd
expect that it comes down to less code than now.
> One reason for using the L2TP tunnel's UDP socket directly was to have
> the data traffic carried by all sessions in that tunnel use the tunnel's
> socket buffer, thereby ensuring that one tunnel's data can't starve
> another tunnel.
If you use encapsulation sockets and process packets immediately
that should still not be possible.
>> On the
>> receive side I it would be nice if you could use the encapsulation
>> socket stuff thats also used by IPsec.
>
>
> Can you point me at some example code, please?
net/ipv4/udp.c: udp_encap_rcv()
>> - pppol2tp_fget: why do you want to open sockets for other processes?
>> I hope this can go together with the sendmsg hacks
>
>
> There are two userspace daemons: l2tpd and pppd. L2ptd opens a UDP
> tunnel socket and sets up one or more L2TP sessions in that tunnel. When
> a new session is established, l2tpd spawns a pppd process (per session).
> The pppd process creates a PPPoL2TP socket (this driver). The PPPoL2TP
> socket is associated with the tunnel UDP socket that was created by
> l2tpd. So on creating a new PPPoX socket, the connect() handling needs
> to find the UDP socket of the tunnel. Since connect() runs in the
> context of pppd, it needs a way of doing a sock lookup to find the UDP
> socket that was created by l2tpd.
How about just passing the file descriptor from l2tpd to pppd?
next prev parent reply other threads:[~2007-03-24 20:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-23 23:07 [PATCH 1/5 2.6.21-rc4] l2tp: pppol2tp core James Chapman
2007-03-24 0:22 ` Florian Zumbiehl
2007-03-24 17:37 ` James Chapman
2007-03-24 18:07 ` Florian Zumbiehl
2007-03-24 14:03 ` Patrick McHardy
2007-03-24 19:01 ` James Chapman
2007-03-24 19:26 ` David Miller
2007-03-24 20:56 ` Patrick McHardy [this message]
2007-03-25 16:00 ` James Chapman
2007-03-27 14:37 ` Patrick McHardy
2007-03-24 21:58 ` Patrick McHardy
2007-03-25 16:12 ` James Chapman
2007-03-27 11:32 ` Ingo Oeser
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4605908C.6050205@trash.net \
--to=kaber@trash.net \
--cc=jchapman@katalix.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.