headers
C.J | 4 Jun 03:17
Picon

cannot connect to pppoe socket

Hi all,

There is a test demo code for making a 'pppoe socket' and connect it. In my machine it cannot connect well but
some others not.

>>>>>
code below(some headers are useless here):
#include <linux/types.h>
#include <syslog.h>
#include <sys/ioctl.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <linux/if.h>
#include <string.h>
#include <stdlib.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <net/ethernet.h>
#include <net/if_arp.h>
#include <linux/ppp_defs.h>
#include <linux/in.h>
#include <linux/if_pppox.h>
int main(void)
{
	struct sockaddr_pppox sp;
	int sock;
	/* Make the session socket */
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pierre-Yves Paulus | 6 Jun 10:45
Picon

PPP difficulties regarding connection establishment and bogus DNS received

Hello,

I've a Debian etch system connected to the web through a GPRS/UMTS
PCMCIA card. I'm using pppd to connect it to the ISP. However, I see
quite a lot of connection failures (connection establishment has to be
tried quite a few times before it succeeds), and even worse, the
connection often succeeds, but with bogus DNS servers IP's supplied
(10.11.12.13 and 10.11.12.14), rendering it useless.

I've looked through the archives
(http://www.opensubscriber.com/message/linux-ppp <at> vger.kernel.org/7889888.html),
and found that the bogus DNS problem has already been seen when the
peer insists on wins servers, but this is not the case here.

So I suppose that there are some differences between the various peers
available by the ISP, and that only some of them accept the way "my"
pppd deals with them, but I've no idea about how and what to change to
increase the success rate and most importantly avoid this bogus DNS
problem.

I've attached below 3 typical pppd log:
-first is a successful connection.
-second one is a successful connection, but I get the bogus DNS servers
-third one is a failed connection

Any hint would be very welcome.

1. SUCCESSFUL CONNECTION:

 pppd 2.4.4 started by root, uid 0
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gustavo Fernando Padovan | 9 Jun 20:23
Picon

possible bug on ppp_async

Hello,

I found out a problem on drivers/net/ppp_async.c: I'm testing a modem
(Motorola SM56 Data Fax Modem [1057:3052] that uses the slmodem
driver) and I noted that it stopped to work correctly with kernel
2.6.24 or greater. The modem connects once and at the second try it
becomes busy and I have to restart its driver to put it to work again.
I tested this only with this hardware, but I think this is a hardware
independent issue.

Theses changes make it stop to work:

http://lkml.org/lkml/2007/11/2/100
http://lkml.org/lkml/2007/11/2/131

The problem occurs when the execution enters on switch's default case
and call tty_mode_ioctl() and the cmd is not TCGETS or cmd is not
TCGETA. I don't know why this happens, but happens. On kernel 2.6.23
the switch's default case returns immediately with an error. But now
on kernel 2.6.24 and 2.6.25 switch's default case call
tty_mode_ioctl(). This is the unique real change between the two
versions, the others are only code restructuring. Then I made this
patch to revert part of changes and make modem works again. I don't
know if this is correct. I just put the modem to work.

--- a/drivers/net/ppp_async.c.     2008-06-09 13:12:25.000000000 -0300
+++ b/drivers/net/ppp_async.c      2008-06-09 13:15:57.000000000 -0300
@@ -309,6 +309,11 @@
                err = 0;
                break;
(Continue reading)

Permalink | Reply | 9 comments |
headers
Charlie Brady | 9 Jun 20:52
Picon
Picon

Re: possible bug on ppp_async


On Mon, 9 Jun 2008, Gustavo Fernando Padovan wrote:

> I found out a problem on drivers/net/ppp_async.c: I'm testing a modem
> (Motorola SM56 Data Fax Modem [1057:3052] that uses the slmodem
> driver) and I noted that it stopped to work correctly with kernel
> 2.6.24 or greater. The modem connects once and at the second try it
> becomes busy and I have to restart its driver to put it to work again.

Why do you not suspect the slmodem driver?
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Gustavo Fernando Padovan | 9 Jun 21:06
Picon

Re: possible bug on ppp_async

On Mon, Jun 9, 2008 at 3:52 PM, Charlie Brady
<charlieb <at> budge.apana.org.au> wrote:
>
> On Mon, 9 Jun 2008, Gustavo Fernando Padovan wrote:
>
>> I found out a problem on drivers/net/ppp_async.c: I'm testing a modem
>> (Motorola SM56 Data Fax Modem [1057:3052] that uses the slmodem
>> driver) and I noted that it stopped to work correctly with kernel
>> 2.6.24 or greater. The modem connects once and at the second try it
>> becomes busy and I have to restart its driver to put it to work again.
>
> Why do you not suspect the slmodem driver?
Because the slmodem driver is the same. It didn't change. And I think
that ppp don't need to know what is the modem driver, it only knows it
have a modem. I think.

>

--

-- 
----------------------------------------------
Gustavo Fernando Padovan
Engenharia de Computação 2006
LAS - Laboratório de Administração e Segurança de Sistemas
Instituto de Computação - UNICAMP

gfpadovan <at> gmail.com
ra061316 <at> students.ic.unicamp.br
pao <at> jabber.org
-------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 9 Jun 23:03
Picon
Favicon

Re: possible bug on ppp_async

On Mon, Jun 09, 2008 at 03:23:33PM -0300, Gustavo Fernando Padovan wrote:
> The problem occurs when the execution enters on switch's default case
> and call tty_mode_ioctl() and the cmd is not TCGETS or cmd is not
> TCGETA. I don't know why this happens, but happens. On kernel 2.6.23

Which ioctl is making it go silly ?

> tty_mode_ioctl(). This is the unique real change between the two
> versions, the others are only code restructuring. Then I made this
> patch to revert part of changes and make modem works again. I don't
> know if this is correct. I just put the modem to work.

It's very useful as we now know what change has had the effect, but not
what your pppd is doing which is breaking it (and thus where the real bug
may lie)

> --- a/drivers/net/ppp_async.c.     2008-06-09 13:12:25.000000000 -0300
> +++ b/drivers/net/ppp_async.c      2008-06-09 13:15:57.000000000 -0300
> @@ -309,6 +309,11 @@
>                 err = 0;
>                 break;
> 
> +       case TCGETS:
> +       case TCGETA:
> +               err = tty_mode_ioctl(tty, file, cmd, arg);
> +               break;
> +
>         case TCFLSH:
>                 /* flush our buffers and the serial port's buffer */
>                 if (arg == TCIOFLUSH || arg == TCOFLUSH)
(Continue reading)

Permalink | Reply | 6 comments |
headers
James Cameron | 10 Jun 01:32
Picon
Favicon

Re: PPP difficulties regarding connection establishment and bogus DNS received

G'day,

This is common.  There exist many implementations.  The "modem" device
contains firmware that invents DNS server IPs and presents them to the
host before the radio network has provided them.  I see 10.11.12.13 and
10.11.12.14 quite often.

(The modem firmware is the PPP peer, acting as a protocol translator to
the radio network, and is not compliant with the RFC, in my opinion).

This delay in providing IP addresses can be caused by either:

1.  invalid access point name (APN), set by AT+CGDCONT ... which causes
the modem to not receive any reply from any access point on the
provider's network,

2.  incorrect profile set, causing incorrect APN to be used,

3.  refusal of the provider's access point to send an IP address,

4.  use of incorrect username and password, (it is reported by the modem
as valid before it is checked by the radio network),

5.  incorrect username and password set on modem, (for some reason the
modem can also keep the username and password in AT commands),

6.  use of incorrect authentication method (PAP vs CHAP),

7.  modem has not yet finished attaching to the radio network, because
there is no signal, or too much radio noise,
(Continue reading)

Permalink | Reply | 0 comments |
headers
C.J | 10 Jun 20:37
Picon

How to build up a bridge between eth0 and ppp0?

Hi list,

I use linux 2.6.16 and it's not support ppp interface for bridge. 
There is a patch of bcp for pppd-2.4.1 in this list: http://marc.info/?l=linux-ppp&m=107772784930462&w=2

But I don't think it can work with currently kernel version.
Is there a newer patch for this case? Only I want to get it's ppp0 and eth0 interfaces work as a bridge. But now I
have no idea how to resolve it?

Another question: what's the definition of ppp half-bridge? 

Reg&Thx
 				
--
c.j

--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Gustavo Fernando Padovan | 11 Jun 22:55
Picon

Re: possible bug on ppp_async

On Mon, Jun 9, 2008 at 6:03 PM, Alan Cox <alan <at> redhat.com> wrote:
> On Mon, Jun 09, 2008 at 03:23:33PM -0300, Gustavo Fernando Padovan wrote:
>> The problem occurs when the execution enters on switch's default case
>> and call tty_mode_ioctl() and the cmd is not TCGETS or cmd is not
>> TCGETA. I don't know why this happens, but happens. On kernel 2.6.23
>
> Which ioctl is making it go silly ?
>
>> tty_mode_ioctl(). This is the unique real change between the two
>> versions, the others are only code restructuring. Then I made this
>> patch to revert part of changes and make modem works again. I don't
>> know if this is correct. I just put the modem to work.
>
> It's very useful as we now know what change has had the effect, but not
> what your pppd is doing which is breaking it (and thus where the real bug
> may lie)
>
>> --- a/drivers/net/ppp_async.c.     2008-06-09 13:12:25.000000000 -0300
>> +++ b/drivers/net/ppp_async.c      2008-06-09 13:15:57.000000000 -0300
>> @@ -309,6 +309,11 @@
>>                 err = 0;
>>                 break;
>>
>> +       case TCGETS:
>> +       case TCGETA:
>> +               err = tty_mode_ioctl(tty, file, cmd, arg);
>> +               break;
>> +
>>         case TCFLSH:
>>                 /* flush our buffers and the serial port's buffer */
(Continue reading)

Permalink | Reply | 5 comments |
headers
Gustavo Fernando Padovan | 13 Jun 20:01
Picon

Re: possible bug on ppp_async

On Wed, Jun 11, 2008 at 5:55 PM, Gustavo Fernando Padovan
<gfpadovan <at> gmail.com> wrote:
> On Mon, Jun 9, 2008 at 6:03 PM, Alan Cox <alan <at> redhat.com> wrote:
>> On Mon, Jun 09, 2008 at 03:23:33PM -0300, Gustavo Fernando Padovan wrote:
>>> The problem occurs when the execution enters on switch's default case
>>> and call tty_mode_ioctl() and the cmd is not TCGETS or cmd is not
>>> TCGETA. I don't know why this happens, but happens. On kernel 2.6.23
>>
>> Which ioctl is making it go silly ?
>>
>>> tty_mode_ioctl(). This is the unique real change between the two
>>> versions, the others are only code restructuring. Then I made this
>>> patch to revert part of changes and make modem works again. I don't
>>> know if this is correct. I just put the modem to work.
>>
>> It's very useful as we now know what change has had the effect, but not
>> what your pppd is doing which is breaking it (and thus where the real bug
>> may lie)
>>
>>> --- a/drivers/net/ppp_async.c.     2008-06-09 13:12:25.000000000 -0300
>>> +++ b/drivers/net/ppp_async.c      2008-06-09 13:15:57.000000000 -0300
>>> @@ -309,6 +309,11 @@
>>>                 err = 0;
>>>                 break;
>>>
>>> +       case TCGETS:
>>> +       case TCGETA:
>>> +               err = tty_mode_ioctl(tty, file, cmd, arg);
>>> +               break;
>>> +
(Continue reading)

Permalink | Reply | 4 comments |

Gmane