Hello!
So sending interim update packets won't help.
Like I said :)
looking for someone who supervises my patch and commit it if no problems
will be founded.
this can be a problem :-)
This is the problem now :) I'm wondering if I only one useing ppp with
RADIUS accounting with FreeBSD.
R
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
>
> >The RFC says:
> >
> >5.4. Acct-Output-Octets
> >
> >blabla
> >
> >can only be
> > present in Accounting-Request records where the Acct-Status-Type
> > is set to Stop.
> >
> >It looks like, that these counters must not present in accou
The RFC says:
5.4. Acct-Output-Octets
blabla
can only be
present in Accounting-Request records where the Acct-Status-Type
is set to Stop.
It looks like, that these counters must not present in accounting updates.
You are right, but your words - "but a patch could be written :-)".
A
Hi Boris,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
> Hello!
>
> Standard PPP does not support UPDATE packets, and of course (as my
but a patch could be written :-)
> RADIUS knowledge) the counters should not be resetted, because RADIUS
> updates the same record.
The RFC says:
5.4. Acct-O
Hello!
Standard PPP does not support UPDATE packets, and of course (as my
RADIUS knowledge) the counters should not be resetted, because RADIUS
updates the same record.
Regards,
Boris
Michael Bretterklieber wrote:
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
Hello!
Yes, unsign
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
> Hello!
>
> Yes, unsigned, so we have 4G limit, which may simple be overflowed
> by (for example) PPPoE connection. Yes, RADIUS standard defines new
> attributes for big words, but current PPP does not supports it (it, so
> our knowledge about R
Hello!
Yes, unsigned, so we have 4G limit, which may simple be overflowed
by (for example) PPPoE connection. Yes, RADIUS standard defines new
attributes for big words, but current PPP does not supports it (it, so
our knowledge about RFC is useless :) Again, rad_put_int defined
u_int32_t par
On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote:
>
>I found a serious bug in RADIUS accounting code. The problem is that
> OctetsIn and OctetsOut are defined as unsingned long long, but the
> RADIUS supports only INT32 values, so, when
> we're doing rad_put_int(r->cx.rad, RAD_
>You were not, by any chance, using the "-nat" option with ppp?
A Sure was. Thanks.
Andrew Lankford
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Sun, Jul 07, 2002 at 08:43:45PM -0400, Andrew Lankford wrote:
>
> Just thought I'd throw in some more bad news >:-). ppp in current
> core dumps on me. It starts up in ddial mode ok, does its job for a while,
> and then dies. I tried starting it again, and it just sat there instead
> of g
Hello,
You were not, by any chance, using the "-nat" option with ppp? If you
were, and have a recent -CURRENT with the new ipfw code, then *that*
will make ppp dump core with a sig10 just fine. (Same behaviour as with
natd)
--
Regards:
Szilveszter ADAM
Szombathely Hungary
To Unsubscribe: send
>
> I rebuilt 'Current' over the weekend with a make buildworld/install world
> and make buildkernel/install kernel and 'ppp -ddial papchap' gives the
> following error(s) when trying to dial an external modem:
>
> Warning set ifadr: Invalid command
> Warning set ifadr: Falied 1
>
>
> Doe
> With new PPP I can't dial to my provider anymore. Two variants:
>
> 1) PPP says "Clearing choked output queue" and connection stuck forever
> with carrier on. Nothing else happens.
>
> 2) PPP says "Too many IPCP NAKs sent - abandoning negotiation" and drop
> carrier forever without further red
On Tue, Jun 12, 2001 at 10:45:58 +0930, Daniel O'Connor wrote:
>
> On 11-Jun-2001 Andrey A. Chernov wrote:
> > With new PPP I can't dial to my provider anymore. Two variants:
> >
> > 1) PPP says "Clearing choked output queue" and connection stuck forever
> > with carrier on. Nothing else hap
On 11-Jun-2001 Andrey A. Chernov wrote:
> With new PPP I can't dial to my provider anymore. Two variants:
>
> 1) PPP says "Clearing choked output queue" and connection stuck forever
> with carrier on. Nothing else happens.
>
> 2) PPP says "Too many IPCP NAKs sent - abandoning negotiation"
You should get away with adding your ``set ifaddr'' line to
ppp.linkdown (you can remove the ``iface clear'' too).
> If this isn't the right place for this, I apologize. Feel free to set
> followups appropriately.
>
> I'm running ppp on a -current system (12/7/2000 vintage) named `moran'.
> I'
Sorry to chime in so late, but ppp(8) already has ATM support... I
must confess that I haven't tested it and don't know how it works,
but it may be worth looking at. A netgraph node would definitely be
preferable.
> On Sun, 22 Oct 2000 03:41:27 +0200, Poul-Henning Kamp wrote:
>
> Who kn
Hi,
Thanks for the patches. I've committed the changes although I'm
having problems with MPPE. I suspect the problems are actually in
the CCP stuff though - and I've suspected this for some time,
something to do with running ppp back-to-back (and not over a tty).
I'll look into this soon.
Brian Smith writes:
> >> Ok, well if I were to netgraphify the ATM code, would mpd be sufficient
> >> to get PPP over ATM working? (I have a lot of reading up to do, but
> >
> >Mpd can do PPP over any netgraph hook, so unless there's some particular
> >weirdness to the framing of PPP frames over
On Sun, 22 Oct 2000 20:36:52 -0700 (PDT), Archie Cobbs wrote:
>> Ok, well if I were to netgraphify the ATM code, would mpd be sufficient
>> to get PPP over ATM working? (I have a lot of reading up to do, but
>
>Mpd can do PPP over any netgraph hook, so unless there's some particular
>weirdness t
Brian Smith writes:
> >>Are you aware of any efforts to add PPP over ATM or Netgraph
> >>support to the current ATM code?
> >
> >I'm not aware of any activity in the ATM code at all...
>
> Ok, well if I were to netgraphify the ATM code, would mpd be sufficient
> to get PPP over ATM working? (I
On Sun, 22 Oct 2000 03:41:27 +0200, Poul-Henning Kamp wrote:
Who knows about the ATM stuff in the kernel?
>>>
>>>We have two ATM stacks:
>>> * The minimalist "chuck" stack.
>>> * The full-blown HARP stack.
>>>
>>>Neither support netgraph.
>>
>>Are you aware of any efforts to add PPP o
In message <[EMAIL PROTECTED]
lting.com>, "Brian Smith" writes:
>On Sun, 22 Oct 2000 03:16:38 +0200, Poul-Henning Kamp wrote:
>
>>
>>>Who knows about the ATM stuff in the kernel?
>>
>>We have two ATM stacks:
>> * The minimalist "chuck" stack.
>> * The full-blown HARP stack.
>>
>>Neither
On Sun, 22 Oct 2000 03:16:38 +0200, Poul-Henning Kamp wrote:
>
>>Who knows about the ATM stuff in the kernel?
>
>We have two ATM stacks:
> * The minimalist "chuck" stack.
> * The full-blown HARP stack.
>
>Neither support netgraph.
Are you aware of any efforts to add PPP over ATM or N
>Who knows about the ATM stuff in the kernel?
We have two ATM stacks:
* The minimalist "chuck" stack.
* The full-blown HARP stack.
Neither support netgraph.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committe
On Sun, 22 Oct 2000 04:30:30 -0700, Julian Elischer wrote:
>Don't forget to consider how you could do this with netgraph.
>We already have ppp over ethernet and other transports using netgraph,
>(and mpd (in ports) already uses teh netgraph kernel ppp stack)
I am not familiar with netgraph
Brian Smith wrote:
>
> I was wondering what the state of PPP over ATM is, if there is at all. And would
>like to offer my services in it's
> development if it isn't finished (or started) yet. I inquired on #FreeBSDHelp on
>EFNet but I didn't get any
> useful results. I am not sure if this is
> On Fri, Aug 11, 2000 at 08:58:48PM -0700, Eric Anholt <[EMAIL PROTECTED]> wrote:
>
> > I've been seeing these errors for about a month now. When PPP is
> > first started, it outputs:
> > calwell:/usr/src/bzflag>ppp -ddial -nat papchap
> > Working in ddial mode
> > Using interface: tun0
> > Wa
On Fri, Aug 11, 2000 at 08:58:48PM -0700, Eric Anholt <[EMAIL PROTECTED]> wrote:
> I've been seeing these errors for about a month now. When PPP is
> first started, it outputs:
> calwell:/usr/src/bzflag>ppp -ddial -nat papchap
> Working in ddial mode
> Using interface: tun0
> Warning: Add route
On Wed, 2 Aug 2000, Piotr [iso-8859-1] Woniak wrote:
> Hi,
> Below I have part of ppp.log.
> Could you tell me what the fifth line does mean?
> What is CD?
Carrier Detect?
> When I try to connect using ATDT12345
> I get message 'BUSY'.
>
> Udo Erdelhoff schrieb:
> >
> > Hi,
> > ppp -auto stopped working fater I've updated my box from 06/17-Sources
> > to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0
> > shows the traffic but that's it. ppp.log doesn't show any obvious
> > problems. -ddial works, sending a manual
I'd like to disclaim all responsibility :-I
I'd normally try to figure out what the problem is or ask for more
info, but seen as ppp caused a kernel panic on me this morning on the
train, and since then cvsup has caused a similar panic, htc panics
and just about anything else interesting I do
On Sun, Jul 09, 2000 at 06:04:47PM +0200, Daniel Rock wrote:
> - if (pri > 0)
> + if (pri >= 0)
Groan. "The problem must be somewhere in ip.c, the other changes were
purely cosmetic". Famous last words.
Thanks, I've re-reverted to the current version, applied your patch and
-auto mode
Udo Erdelhoff schrieb:
>
> Hi,
> ppp -auto stopped working fater I've updated my box from 06/17-Sources
> to yesterday's version (07/06, approx. 1500 GMT). tcpdump -ni tun0
> shows the traffic but that's it. ppp.log doesn't show any obvious
> problems. -ddial works, sending a manual dial command
On Wed, Jun 14, 2000 at 06:46:07PM +0400, Andrey A. Chernov wrote:
> Fresh -current, "ppp -auto system" not react on outgoing packets and not
> dial, it seems they routed to dead end. Direct "dial system" command
> dials in, but packets not routed too. Restoring ppp from 8 Jun fix it.
Forget it,
Brian Somers writes:
>Sorry, I should have done more than a few greps when reviewing this.
While we're in self-castigation mode here ;), _I_ should have done
more than a few greps before *committing* this.
My first pointy hat in 5 years, not bad (of course, I don't do all
that much committing).
Sorry, I should have done more than a few greps when reviewing this.
The slcompress code is diving into the TCP header that comes after
the IP header There's some nasty stuff going on here between
vjcomp.c and slcompress.c - namely, the pointer passed into
sl_uncompress_tcp is expected t
Maxim Sobolev writes:
>Hi,
>
>The ppp built from the just cvsup'ed -current sources segfaulting. Following i
>s
>backtrace. Please contact me of some additional debugging info will be
>necessary.
>
>-Maxim
>
>PPP ON vega>
>Program received signal SIGSEGV, Segmentation fault.
>0x806e98e in sl_compr
Check out http://www.FreeBSD.org/FAQ/userppp.html.
The remote end is reflecting your data back at you.
> usually ppp from laptop (3.4+pao) to home (4.0-stable) works fine. and then
> sometimes it will get stuck in the following mode three N in a row.
>
> ppp[547]: tun0: Chat: Send: AT^M
> ppp
Leif Neland wrote:
> I now get dynamic ip's from my ISP, using user-ppp and i4b.
> I don't think this is a problem (unless there is some limit of the number
> of adresses remebmered), but I wonder why the previous ip's are shown on
> ifconfig -a:
>
> tun0: flags=8051 mtu 1524
> inet6 fe80
From: "Jonathan M. Bresler" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Tuesday, January 18, 2000 3:07 AM
Subject: Re: ppp, incoming mail keeping the line up.
> >
> > I run user-ppp, and I have a mx-record for my system, so
>
> I run user-ppp, and I have a mx-record for my system, so incoming mail =
> goes directly to my system.
this is asking for trouble. you should get yourself an MX
that is online all the time and will store your mail for you. you can
then pick it up whenever you want using APOP or POP
How do I disable compression
On 12-Jan-00 Andrew Kenneth Milton wrote:
> +[ Brian Somers ]-
>| > Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial
>| > out
>| > I connect for about 30 seconds then it dies...here is a copy of
> +[ Brian Somers ]-
> | > Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial out
> | > I connect for about 30 seconds then it dies...here is a copy of the ppp.log
> | [.]
> |
> | Well, you're receiving data from the peer
+[ Brian Somers ]-
| > Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial out
| > I connect for about 30 seconds then it dies...here is a copy of the ppp.log
| [.]
|
| Well, you're receiving data from the peer, but the pe
> Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial out
> I connect for about 30 seconds then it dies...here is a copy of the ppp.log
[.]
Well, you're receiving data from the peer, but the peer is not
sending any response to your config request. From what I can see,
> On Sun, Jan 09, 2000 at 02:20:51PM -0800, William Woods wrote:
> > Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial out
> > I connect for about 30 seconds then it dies...here is a copy of the ppp.log
>
> I got the same thing once in a while. I'm using PPPoE. I cannot q
On Sun, Jan 09, 2000 at 02:20:51PM -0800, William Woods wrote:
> Running 4.0 -current as of today.on a DEC Alphaststion 233 when I dial out
> I connect for about 30 seconds then it dies...here is a copy of the ppp.log
I got the same thing once in a while. I'm using PPPoE. I cannot quote the
4
[.]
> tun0: Command: ip-telecom: set dial ABORT BUSY ABORT NO\sCARRIER ABORT
> NO\sDIAL\sTONE TIMEOUT 5 "" AT OK-AT-OK AT&F OK
> AT#F0$R1%E0S20=8&E2S48=16 OK \dATDP\T TIMEOUT 40 CONNECT
[.]
ppp was treating everything from the # to the end of line as a
comment. It should be fixed now.
-
> With latest ppp I hear no phone numbers dial sounds at the stage:
> Phase: Phone: N
> ppp does _nothing_ until timeout occurse, then redial happens
> with the same unsuccessful result.
Erk! Fixed now. Thanks for the report.
> --
> Andrey A. Chernov
> http://nagual.pp.ru/~ache/
> MTH
Christopher Nielsen wrote:
> On Tue, 21 Dec 1999, Andrey A. Chernov wrote:
>
> > With latest ppp I hear no phone numbers dial sounds at the stage:
> > Phase: Phone: N
> > ppp does _nothing_ until timeout occurse, then redial happens
> > with the same unsuccessful result.
>
> I'm seeing th
On Tue, 21 Dec 1999, Andrey A. Chernov wrote:
> With latest ppp I hear no phone numbers dial sounds at the stage:
> Phase: Phone: N
> ppp does _nothing_ until timeout occurse, then redial happens
> with the same unsuccessful result.
I'm seeing the exact same thing. It appears that the ph
This is now fixed in -stable (and -current).
> > > "JH" == Jon Hamilton <[EMAIL PROTECTED]> writes:
> >
> > JH> Running -current from this afternoon, I am having a strange
> > JH> symptom with ppp over a pty; ppp does not detect that the pty
> > JH> does not support carrier, and
Ah, I see the problem. I have a fix - I'm about to apply it to
-current and ask jkh for permission to MFC.
I've attached the -stable patch for your viewing enjoyment
> > "JH" == Jon Hamilton <[EMAIL PROTECTED]> writes:
>
> JH> Running -current from this afternoon, I am having a st
> "JH" == Jon Hamilton <[EMAIL PROTECTED]> writes:
JH> Running -current from this afternoon, I am having a strange
JH> symptom with ppp over a pty; ppp does not detect that the pty
JH> does not support carrier, and will cycle once per second
JH> waiting for CD to appear. Put
> everything is working fine as it used to after installing current but i get this
>error message when ppp tries to connect
>
> "ppp[52]: tun0: Warning: deflink: /dev/cuaa1: Bad file descriptor" i'm not sure
>how to fix this any ideas ?
[.]
You'll need to explain a bit more, and maybe sh
[.]
> I removed the `set openmode passive' and got
[.]
How about ``set openmode active 5''. The problem you're seeing is
that the other side is `reflecting' you data back because it hasn't
yet turned ECHO off on the port. By the time the peer wakes up and
does something, everything's
Brian Somers writes:
> > Well, I'd hoped I'd be able to do a little more before bothering the list,
> > but...
> >
> > I'd last built world around the end of April, with no problems. I then
> > grew a fairly heavy workload, and so didn't get a chance to build world
> > again until 2 days ag
> Well, I'd hoped I'd be able to do a little more before bothering the list,
> but...
>
> I'd last built world around the end of April, with no problems. I then
> grew a fairly heavy workload, and so didn't get a chance to build world
> again until 2 days ago (May 24). During that time, somethin
> On Sun, May 9, 1999, Brian Somers wrote:
> > [.]
> > >I'm using the 3.1R PPP right now, until the problem is
> > > resolved. I'm sending a problem report, as well.
> >
> > It should be resolved now. A NULL mbuf value is valid - it just
> > means that there's nothing in it. I changed
On Sun, May 9, 1999, Brian Somers wrote:
> [.]
> >I'm using the 3.1R PPP right now, until the problem is
> > resolved. I'm sending a problem report, as well.
>
> It should be resolved now. A NULL mbuf value is valid - it just
> means that there's nothing in it. I changed fsm_Input() wi
[.]
>I'm using the 3.1R PPP right now, until the problem is
> resolved. I'm sending a problem report, as well.
It should be resolved now. A NULL mbuf value is valid - it just
means that there's nothing in it. I changed fsm_Input() with the
last commits, and didn't notice the MBUF_CTOP
On Sat, May 8, 1999, Chuck Robey wrote:
> On Sat, 8 May 1999, Chris Costello wrote:
>
> >
> >Somewhere in the mbuf code, either mbuf_Alloc or mbuf_Prepend,
> > there is code that causes ppp to assign a particular mbuf
> > structure pointer to a null pointer, causing ppp to dump core.
> > Cont
On Sat, 8 May 1999, Chris Costello wrote:
>
>Somewhere in the mbuf code, either mbuf_Alloc or mbuf_Prepend,
> there is code that causes ppp to assign a particular mbuf
> structure pointer to a null pointer, causing ppp to dump core.
> Contrary to somebody else's email to this list, it is, in
Hi,
Any chance of sending me the logs for both when the connection works
(3.1) and when it doesn't work (4.0) ?
set log command tun phase chat lcp ipcp
TIA.
> At 09:24 4/9/99 +0100, Brian Somers wrote:
> >Does anything different happen if you
> >
> > set accmap 000a
> >
> >in your ppp.c
At 09:24 4/9/99 +0100, Brian Somers wrote:
>Does anything different happen if you
>
> set accmap 000a
>
>in your ppp.conf ? If not, you're going to have to approach your ISP
>and ask them why their ppp implementation is ignoring our requests
>(which needless to say violates the rfc).
It wo
Does anything different happen if you
set accmap 000a
in your ppp.conf ? If not, you're going to have to approach your ISP
and ask them why their ppp implementation is ignoring our requests
(which needless to say violates the rfc).
> cvsupped, built CURRENT as of April 8th, upgrading a
> Would it be possible to add an exponential delay when connecting fails for
> either reason?
>
> I just received my specified phone-bill. It filled 42 pages, with hundreds
> of calls with a duration of 17 seconds. (Because my modem needs to be
> software-reset; I have mentioned this before).
>
>
On Fri, 29 Jan 1999, Brian Somers wrote:
> > Would it be possible to add an exponential delay when connecting fails for
> > either reason?
> >
> > I just received my specified phone-bill. It filled 42 pages, with hundreds
> > of calls with a duration of 17 seconds. (Because my modem needs to be
> Would it be possible to add an exponential delay when connecting fails for
> either reason?
>
> I just received my specified phone-bill. It filled 42 pages, with hundreds
> of calls with a duration of 17 seconds. (Because my modem needs to be
> software-reset; I have mentioned this before).
>
>
> Brian Somers wrote:
> >
> > > So there are now 2 possibilities for this problem:
> > >
> > > a) I was out of sync :(
> > > b) Someone fixed ppp
> >
> > Last nights commit was for RADIUS support in ppp. There was another
> > latency problem that I fixed about a week ago - maybe that was it :-)
Brian Somers wrote:
>
> > So there are now 2 possibilities for this problem:
> >
> > a) I was out of sync :(
> > b) Someone fixed ppp
>
> Last nights commit was for RADIUS support in ppp. There was another
> latency problem that I fixed about a week ago - maybe that was it :-)
Yuck! (jumping in
> So there are now 2 possibilities for this problem:
>
> a) I was out of sync :(
> b) Someone fixed ppp
Last nights commit was for RADIUS support in ppp. There was another
latency problem that I fixed about a week ago - maybe that was it :-)
> --
> # /AS/ http://
On Wed, 27 Jan 1999, Brian Somers wrote:
> To find out if this is the problem, can you try connecting
> interactively. You should see the same delay. You can then try
> again, but during the delay, pressing return a few times at the
> prompt should wake ppp up. Is this happening ?
Well, I t
Hi,
It's quite possible that this is another latency problem introduced
by my recent timer changes... the changes make the .1 second
latencies into longer - possibly indefinite - latencies.
To find out if this is the problem, can you try connecting
interactively. You should see the same dela
On Tue, 26 Jan 1999, Brian Somers wrote:
> Are you using a routing daemon ? Also, have you tried just having
> ``add default HISADDR'' in ppp.conf and leaving everything out of
> ppp.linkup ? What do your routing tables look like before/during/after
> the hang ?
I usually run routed, yes, an
> Hi!
>
> I'am not sure where this comes from, but at the moment I have some
> troubles with the userland ppp.
>
> The symptoms: After establishing the connection and setting the
> defaultroute *nothing* works, that means, the line seems
> to be completely dead. Not even
>
> FYI, when I rcp (actually, rsync) a certain makefile (ppp -alias), I
> get lots of these, and it never completes:
>
> Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored
> Warning: CCP: deflink: Incorrect ResetAck (id 49, not 50) ignored
> Warning: CCP: deflink: Unexpected Reset
78 matches
Mail list logo
