From: Denis Kenzior <denkenz@gmail.com>
To: ofono@ofono.org
Subject: Re: [PATCH 03/11] gatppp: Add PPP server extension
Date: Fri, 18 Jun 2010 12:49:33 -0500 [thread overview]
Message-ID: <201006181249.33397.denkenz@gmail.com> (raw)
In-Reply-To: <1276321850-13307-4-git-send-email-zhenhua.zhang@intel.com>
[-- Attachment #1: Type: text/plain, Size: 5123 bytes --]
Hi Zhenhua,
> 1. Add interface to set PPP server info by g_at_ppp_set_server_info.
> 2. Pass local and peer address through IPCP handshaking.
> ---
Its great that you're working on the PPP Server extensions. Can I get you to
submit a patch taking ownership of this task? See ofono/TODO 'PPP Server
support'.
> +static void ipcp_generate_peer_config_options(struct ipcp_data *ipcp)
> +{
> + guint16 len = 0;
> +
> + FILL_IP(ipcp->req_options & REQ_OPTION_IPADDR,
> + IP_ADDRESS, &ipcp->peer_addr);
> + FILL_IP(ipcp->req_options & REQ_OPTION_DNS1,
> + PRIMARY_DNS_SERVER, &ipcp->dns1);
> + FILL_IP(ipcp->req_options & REQ_OPTION_DNS2,
> + SECONDARY_DNS_SERVER, &ipcp->dns2);
> + FILL_IP(ipcp->req_options & REQ_OPTION_NBNS1,
> + PRIMARY_NBNS_SERVER, &ipcp->nbns1);
> + FILL_IP(ipcp->req_options & REQ_OPTION_NBNS2,
> + SECONDARY_NBNS_SERVER, &ipcp->nbns2);
> +
Using ipcp->req_options is the wrong thing here. That is used for options
sent in a Configure-Req. Here you're filling in options to be sent in a
Configure-Nak, Configure-Reject or a Configure-Ack. You should simply be filling
these in ipcp_rcr. Feel free to modify the FILL_IP macro to take an
additional destination parameter.
> + ipcp->options_len = len;
> +}
> +
> +void ipcp_set_server_info(struct pppcp_data *pppcp, guint32 local_addr,
> + guint32 peer_addr,
> + guint32 dns1, guint32 dns2,
> + guint32 nbns1, guint32 nbns2)
> +{
> + struct ipcp_data *ipcp = pppcp_get_data(pppcp);
> +
> + ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
> + REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
> + REQ_OPTION_NBNS2;
> +
> + ipcp->local_addr = local_addr;
> + ipcp->peer_addr = peer_addr;
> + ipcp->dns1 = dns1;
> + ipcp->dns2 = dns2;
> + ipcp->nbns1 = nbns1;
> + ipcp->nbns2 = nbns2;
> +
> + ipcp_generate_config_options(ipcp);
Please note that this function is currently having no effect, you're missing a
call to pppcp_set_local_options. However, in the case of a server, we
actually do not want to request DNS or NBNS, and we should only send our local
address to the peer if it is non-zero. Please note that all PPP modems we
have encountered so far, do not send their local IP address in a Configure-
Request. Thus calling ipcp_set_server_info should end up generating an empty
Configure-Request or with only the local IP address present.
> +}
> +
> static void ipcp_reset_config_options(struct ipcp_data *ipcp)
> {
> ipcp->req_options = REQ_OPTION_IPADDR | REQ_OPTION_DNS1 |
> REQ_OPTION_DNS2 | REQ_OPTION_NBNS1 |
> REQ_OPTION_NBNS2;
> - ipcp->ipaddr = 0;
> + ipcp->local_addr = 0;
In the case of a server, the local_address should not be reset.
> + ipcp->peer_addr = 0;
> ipcp->dns1 = 0;
> ipcp->dns2 = 0;
> ipcp->nbns1 = 0;
> @@ -274,11 +321,54 @@ static enum rcr_result ipcp_rcr(struct pppcp_data
> *pppcp, guint8 **new_options, guint16 *new_len)
> {
> struct ppp_option_iter iter;
> + struct ipcp_data *ipcp = pppcp_get_data(pppcp);
> + guint32 peer_addr;
> + guint32 dns1;
> + guint32 dns2;
>
> ppp_option_iter_init(&iter, packet);
>
> - if (ppp_option_iter_next(&iter) == FALSE)
> - return RCR_ACCEPT;
Again, be careful here. In the case of a client we should only accept the
Server's IP-Address, nothing else.
> + while (ppp_option_iter_next(&iter) == TRUE) {
> + const guint8 *data = ppp_option_iter_get_data(&iter);
> +
> + switch (ppp_option_iter_get_type(&iter)) {
> + case IP_ADDRESS:
> + memcpy(&peer_addr, data, 4);
> + break;
> + case PRIMARY_DNS_SERVER:
> + memcpy(&dns1, data, 4);
> + break;
> + case SECONDARY_DNS_SERVER:
> + memcpy(&dns2, data, 4);
> + break;
> + default:
> + break;
> + }
> + }
> +
> + if (peer_addr && dns1 && dns2) {
> + if (ipcp->peer_addr == 0) {
> + /* RFC 1332 Section 3.3
> + * Accept the value of IP address as peer IP address
> + */
> + ipcp->peer_addr = peer_addr;
> +
This part doesn't really make any sense, if peer is sending 0, he's asking us
for an IP.
> + return RCR_ACCEPT;
> + } else if (ipcp->peer_addr == peer_addr)
> + return RCR_ACCEPT;
You need to ensure that not only the peer_addr matches, but also the dns /
nbns addresses. In our case we should be Configure-Rejecting the NBNS options
and Configure-Naking DNS ones if they're set to zero or don't match what the
peer is sending us.
> + } else {
> + /* Peer requests us to send ip address in config options */
> + if (ipcp->peer_addr) {
> + struct ipcp_data *peer;
> +
> + peer = g_memdup(ipcp, sizeof(struct ipcp_data));
> + ipcp_generate_peer_config_options(peer);
Yuck, please don't do this. The main PPPCP layer will take care of freeing
new_options, however you're now leaking the rest of the ipcp_data structure.
> +
> + *new_len = peer->options_len;
> + *new_options = peer->options;
> + return RCR_NAK;
> + }
> + }
>
> /* Reject all options */
> *new_len = packet->length - sizeof(*packet);
>
Regards,
-Denis
next prev parent reply other threads:[~2010-06-18 17:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-12 5:50 [PATCH 00/11] Add PPP server support Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 01/11] gatserver: Suspend/resume GAtServer with GAtIO Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 02/11] gatserver: Check for disconnection when resuming Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 03/11] gatppp: Add PPP server extension Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 04/11] atmodem: Fix GAtPPPConnectFunc interface change Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 05/11] test-server: Fix GIOChannel leak in create_tty Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 06/11] test-server: Add PPP server support Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 07/11] test-server: Configure network interface Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 08/11] gsmdial: Configure network interface for PPP Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 09/11] gsmdial: Unref ppp when we get disconnected Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 10/11] test-server: Delay ppp_unref after IO processing Zhenhua Zhang
2010-06-12 5:50 ` [PATCH 11/11] gsmdial: " Zhenhua Zhang
2010-06-12 6:03 ` Zhang, Zhenhua
2010-06-18 17:51 ` Denis Kenzior
2010-06-18 17:50 ` [PATCH 09/11] gsmdial: Unref ppp when we get disconnected Denis Kenzior
2010-06-18 17:50 ` [PATCH 05/11] test-server: Fix GIOChannel leak in create_tty Denis Kenzior
2010-06-18 17:49 ` Denis Kenzior [this message]
2010-06-21 2:38 ` [PATCH 03/11] gatppp: Add PPP server extension Zhang, Zhenhua
2010-06-22 4:26 ` Denis Kenzior
2010-06-22 6:31 ` Zhang, Zhenhua
2010-06-18 17:31 ` [PATCH 02/11] gatserver: Check for disconnection when resuming Denis Kenzior
2010-06-18 17:31 ` [PATCH 01/11] gatserver: Suspend/resume GAtServer with GAtIO Denis Kenzior
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=201006181249.33397.denkenz@gmail.com \
--to=denkenz@gmail.com \
--cc=ofono@ofono.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.