> On 3 Dec 2018, at 08:15, O. Hartmann wrote:
>
>
> The documentation lacks in many aspects how to deal with IPv6, especially
> when it comes
> to "well known things from the old IPv4 world". Since DDNS also is still
> something people
> use with IPv6, MYADDR6 doesn't carry the IPV6
s an experimental feature", so I had to ask
> > to enable
> > the IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis
> > for a
> > router/firewall/PBX system, FreeBSD's onboard ppp client is performing the
> > uplink and
> > authetic
Discovery Protocol/Router Solicitation)
> > have been mentioned, the third option is IPV6CP (PPP options, just as
> > PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so...
>
> No, IPV6CP, to my very best 15 year old memory only negotiates the
> interface ident
As someone who controls both ends of the link (runs the ISP, has service
from the ISP), so far (a bit out of laziness) I have the following
solution...
Now... of note is that we statically assign addresses. This is not just
being nice, but being practical. We deal out IPv4 addresses vi IPCP,
## Bjoern A. Zeeb (bzeeb-li...@lists.zabbadoz.net):
> No, IPV6CP, to my very best 15 year old memory only negotiates the
> interface identifiers, which are used to generate the link-local addresses.
Ah, you're right - it's IPV6CP-then-NDP, not "IPV6CP or NDP".
I got ahead of the protocol...
On 11/30/2018 7:12 AM, O. Hartmann wrote:
>
> For IPv6, I only see my local linklocal address, fe80::...
>
> Checking the log of ppp (/var/log/ppp.log), there is also a fe80::
> linklocal address
> assigned to the variable HISADDR. Somehow, the tun0 never obtains a
> IPv6 ap
is that there's more than one way...
> DHCPv6 and NDP (IPV6 Neighbour Discovery Protocol/Router Solicitation)
> have been mentioned, the third option is IPV6CP (PPP options, just as
> PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so...
No, IPV6CP, to my very best 15 ye
Protocol/Router Solicitation)
have been mentioned, the third option is IPV6CP (PPP options, just as
PPP-with-IPv4 does with IPCP). I've no idea what your provider does, so...
If it's IPV6CP, make sure it's enabled in ppp (it is by default), and
check with "show ipv6cp".
If you expect NDP, amke
as the basis for a
> router/firewall/PBX system, FreeBSD's onboard ppp client is performing the
> uplink and
> authetication and this works well with IPv4 for years for now.
>
> I'm using IPFW as my filtering system, reading the standard
> /etc/rc.ipfirewall and add
> some
Hi,
> On 30 Nov 2018, at 12:12, O. Hartmann wrote:
>
> Signed PGP part
> My ISP is offering IPv6 only "as an experimental feature", so I had to ask to
> enable the
> IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a
> router/firewall/PB
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
My ISP is offering IPv6 only "as an experimental feature", so I had to ask to
enable the
IPv6 stack on my connection. I'm using FreeBSD 12-STABLE as the basis for a
router/firewall/PBX system, FreeBSD's onboard ppp client is performing t
I have palyed with a FreeBSD 12-CURRENT based router/firewall system and
realized, that the trias
service netif restart
service routing restart
service ipfw restart
(in any order) doesn't start/restart the ppp session properly, it doesn't even
restart ppp. tun0 is gone.
I had to manually
On Mon., 19 Dec. 2016 at 1:37 am, O. Hartmann <ohartm...@walstatt.org>
wrote:
> After changing paraemters on my router which uses a modem via ppp/pppoed,
> service netif restart
> does not bring up ppp and named!
>
> After "netif restart" and "routing
After changing paraemters on my router which uses a modem via ppp/pppoed,
service netif restart
does not bring up ppp and named!
After "netif restart" and "routing restart" (in this order), tun0 which is
supposed to
have the ISP's IP address is empty and named (the router
Hi,
I'd like to bring attention to the bugzilla bug in the subject:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210658
while it is a minor problem I think it should be fixed in time to get
into 11.0.
The problem is uncovered by compiling the system with many "WITHOUT_"
options that used
Can people that use PPP please review the following FAQs
What do we care about?
Is it factually correct?
Does it use deprecated functionality?
Is it completely outdated to the point we should remove it?
Does it need better examples?
Is it clear and concise?
Does it have typos or spelling
...@freebsd.org wrote:
While not commenting on the correctness of the current contents, the
userland
PPP section of the FAQ appears to mostly deal with dialup modems. I
suspect
more people use it now to do PPPoA or PPPoE for some form of DSL link
and
there probably needs to be some effort
Hi,
On Sat, 15 Dec 2012 01:14:10 -0500
Eitan Adler li...@eitanadler.com wrote:
On 3 December 2012 10:41, Gary Palmer gpal...@freebsd.org wrote:
While not commenting on the correctness of the current contents,
the userland PPP section of the FAQ appears to mostly deal with
dialup modems
On 3 December 2012 10:41, Gary Palmer gpal...@freebsd.org wrote:
While not commenting on the correctness of the current contents, the userland
PPP section of the FAQ appears to mostly deal with dialup modems. I suspect
more people use it now to do PPPoA or PPPoE for some form of DSL link
and would be a great help!
While not commenting on the correctness of the current contents, the userland
PPP section of the FAQ appears to mostly deal with dialup modems. I suspect
more people use it now to do PPPoA or PPPoE for some form of DSL link and
there probably needs to be some effort
Hey all,
I'm working on a project to review the FAQ: http://wiki.freebsd.org/ThwackAFAQ
I need volunteers to question through the questions starting userppp
through desperation and review them. If you don't have time to go
through them all, just pick one and make this a group process.
Is it
be a great help!
14.6 should probably read..
If you have Link Quality Reporting (LQR) configured, it is possible that too
many LQR packets are lost between your machine and the peer. The ppp(8) program
deduces that the line must therefore be bad, and disconnects. Prior to FreeBSD
version 2.2.5, LQR
add a section about MTU - I expect the dominant use case for PPP
is ADSL these days. In this case the MTU is usually limited to 1492 bytes
(1500 byte ethernet frame minus PPP framing overhead). If all ICMP is blocked
at some part of the link then packet fragmentation doesn't work properly
? Either way the feedback so far will be taken
into account.
I eyeballed all of the PPP FAQ entries and I couldn't find anything else wrong.
I didn't try them though and only relied on my memory.
For 14.17 and 14.23 I didn't really know about the gory details so I just
assumed it was correct..
I
Am 22.04.2010 20:43, schrieb Marin Atanasov:
Hello,
Thanks a lot for the patch, Qing!
It works fine. However I've noticed one thing, after I start mpd5 and
connect to my home network:
kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize()
Not very sure if this is
On 4/26/10 1:11 AM, Stefan Esser wrote:
Am 22.04.2010 20:43, schrieb Marin Atanasov:
Hello,
Thanks a lot for the patch, Qing!
It works fine. However I've noticed one thing, after I start mpd5 and
connect to my home network:
kernel: WARNING: attempt to domain_add(netgraph) after
I was using csup to track RELEN_8_0 branch. Currently I'm syncing to
RELENG_8.
If I understood you right, after getting the sources for RELENG_8, I need to
apply the patch and then rebuild world?
You only need to rebuild the kernel.
-- Qing
___
,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:
1. Unable to add proxy-arp entries for the remote ppp clients.
2. Log showing ifa_add_loopback_route
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
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 RFC
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
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
:-).
Again, I'm talking not about UPDATE packets and presence of any
attributes in RADIUS requests. I'm talking about wrong handling of
Acct-Input-Octets Acct-Output-Octets with current PPP RADIUS
implementation. How this will be done, by implementing RFC2869 support
or just by resending STOP request
are right, but your words - but a patch could be written :-).
Again, I'm talking not about UPDATE packets and presence of any
attributes in RADIUS requests. I'm talking about wrong handling of
Acct-Input-Octets Acct-Output-Octets with current PPP RADIUS
implementation. How this will be done
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
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,
Hello!
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_ACCT_OUTPUT_OCTETS,
stats-OctetsOut) in radius.c for OctetsOut (and
Hello,
I upgraded my machine to CURRENT of today. It was paniced at while the
ppp process was making the IPv6 tunnel. When I rebooted it several
times, the problem occurred in the same place (currnet process = ppp).
Now I'm using an older kernel(cvsuped October 2). This older kernel
works fine
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection works fine on my 4.8 with identical ppp.conf .
What can I do ?
Thanks,
Uli
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection works fine on my 4.8 with identical ppp.conf
Hi,
On Mon, 9 Jun 2003, Kris Kennaway wrote:
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection
On Mon, 9 Jun 2003, Kris Kennaway wrote:
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection works
On Tue, Jun 10, 2003 at 10:08:58AM +0200, P. U. Kruppa wrote:
On Mon, 9 Jun 2003, Kris Kennaway wrote:
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive
On Tue, 10 Jun 2003, leafy wrote:
On Tue, Jun 10, 2003 at 10:08:58AM +0200, P. U. Kruppa wrote:
On Mon, 9 Jun 2003, Kris Kennaway wrote:
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
Hi,
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
On Tue, Jun 10, 2003 at 10:48:31AM +0200, P. U. Kruppa wrote:
ng_ether not found? could you try loading ng_ether manually and
start ppp again?
I tried
kldload ng_ether.ko
but it said it couldn't because this file already exists.
Uli.
I mentioned about this problem in my mail
P.U.Kruppa [EMAIL PROTECTED] writes:
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection works fine on my 4.8 with identical ppp.conf .
I can confirm that 4.8-STABLE
On Tue, 10 Jun 2003, Farid Hajji wrote:
P.U.Kruppa [EMAIL PROTECTED] writes:
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive:
Unexpected node type socket (wanted ether)
The connection works fine on my 4.8 with identical
On Tuesday 10 June 2003 18:06, Farid Hajji wrote:
Ugh, I was just planning to switch to 5.1-RELEASE and cvsup
to CURRENT. Now, I'm reluctant to do this for my DSL router
-STABLE box.
FWIW, RELENG_5_1 works fine.
--
| Michael Nottebrock| KDE on FreeBSD | ,ww
Hi,
On Tue Jun 10, 2003 at 09:02AM +0200, Lukas Kaminski wrote:
On Mon, 9 Jun 2003, Kris Kennaway wrote:
On Tue, Jun 10, 2003 at 08:50:03AM +0200, P. U. Kruppa wrote:
after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect
anymore.
Using ppp manually I receive
On Tue, 10 Jun 2003, Michael Nottebrock wrote:
On Tuesday 10 June 2003 18:06, Farid Hajji wrote:
Ugh, I was just planning to switch to 5.1-RELEASE and cvsup
to CURRENT. Now, I'm reluctant to do this for my DSL router
-STABLE box.
FWIW, RELENG_5_1 works fine.
Yes, that works!
I hope
In the last episode (Jun 11), P. U. Kruppa said:
On Tue, 10 Jun 2003, Michael Nottebrock wrote:
On Tuesday 10 June 2003 18:06, Farid Hajji wrote:
Ugh, I was just planning to switch to 5.1-RELEASE and cvsup to
CURRENT. Now, I'm reluctant to do this for my DSL router
-STABLE box.
except ppp -nat. NAT just don't work on my network. All machines are
able to ping except ftp, http, etc.
I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It
compiles cleanly though, but I don't know enough about gcc optimizations
to find out how O2 might break it.
Upon
with
-march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
except ppp -nat. NAT just don't work on my network. All machines are
able to ping except ftp, http, etc.
I can confirm this. nat fails to work with -O2 for usr.sbin/ppp. It
compiles cleanly though, but I don't know
On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote:
For the first time I compile current-p3 - current-p4 with
-march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
except ppp -nat. NAT just don't work on my network. All machines are
able to ping except ftp, http, etc.
I can confirm
On Thu, Mar 06, 2003 at 09:22:06PM +0800, Khairil Yusof wrote:
On Thu, 2003-03-06 at 06:00, Nuno Teixeira wrote:
For the first time I compile current-p3 - current-p4 with
-march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
except ppp -nat. NAT just don't work on my network
On Thu, 6 Mar 2003, Bruce Cran wrote:
387 (FPU) code generation seems to be broken in gcc 3.2.1 when -O2 is used.
Would you happen to know if this is still broken in 3.2.2?
I can compile applications with no problems when -mfpmath=sse is added so
that the 387 unit won't be used, but without
Hello to all,
For the first time I compile current-p3 - current-p4 with
-march=pentium2 -O2 -mmmx -pipe and aparently everything works ok
except ppp -nat. NAT just don't work on my network. All machines are
able to ping except ftp, http, etc.
I rebuild everything with no CPUTYPE? and CFLAGS
On Wed, Mar 05, 2003 at 10:00:20PM +, Nuno Teixeira wrote:
I rebuild everything with no CPUTYPE? and CFLAGS and ppp -nat is working
again.
I know that this isn't a important issue or bug because there are lots
of warnings about gcc optimizations because the system may become unstable
I've just tried to start pppd on two different -CURRENT machines, one
built on 26 October, the other on 5 November. In each case I get the
following message:
pppd: This system lacks kernel support for PPP. To include PPP support
in the kernel, please follow the steps detailed
On Fri, Nov 08, 2002 at 12:31:13PM +1030, Greg 'groggy' Lehey wrote:
I've just tried to start pppd on two different -CURRENT machines, one
built on 26 October, the other on 5 November. In each case I get the
following message:
pppd: This system lacks kernel support for PPP. To include
Greg 'groggy' Lehey wrote:
I've just tried to start pppd on two different -CURRENT machines, one
built on 26 October, the other on 5 November. In each case I get the
following message:
pppd: This system lacks kernel support for PPP. To include PPP support
in the kernel, please follow
Once in a while, user ppp is killed rather abruptly
and it leaves a diagnostic socket behind, which blocks
the creation of a diagnostic socket after reboot.
Anyway, I propose adding another variable to rc.conf, something
along the lines of the three patches here. The default
value
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
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 going
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
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 going into the background and returning the prompt, leaving me
Hello.
brian 2002/03/30 04:30:11 PST
Modified files:
usr.sbin/ppp Makefile async.c async.h atm.c bundle.c
ccp.c ccp.h chap.c chap.h chat.c
command.c datalink.c datalink.h defs.c
defs.h
Hello.
brian 2002/03/30 04:30:11 PST
Modified files:
usr.sbin/ppp Makefile async.c async.h atm.c bundle.c
ccp.c ccp.h chap.c chap.h chat.c
command.c datalink.c datalink.h defs.c
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
Does anyone
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
Does anyone know what
I may have missed in the recent traffic on this list, but with the system svcup'ed on
11-Oct I am running into some problems with things network-related. In particular I
get:
WARNING: Driver mistake: repeat make_dev(net/xl0)
when I bring up a ppp link (with -nat and -auto parameters)
Then I
On Mon, Sep 10, 2001 at 03:24:31PM +0100, Brian Somers wrote:
What sort of problem do you have with ppp ?
1. pcmcia-modem
2. active ppp-link
zzz
wakeup - panic
the same problem is with pppd(as I remember).
I'll give you dump-information in 5-6 hours: my pcmcia-modem
What you are doing doesn't work for sure. You are piping in and out of
the control enpoint which won't work. Perhaps
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0.1
would work, if there is an endpoint 1-in and an endpoint 1-out and they
are both related to data transfer. Normally
On 30 Aug, Nick Hibma wrote:
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0.1
I was confused by the following from ppp's man-page:
-direct
This is used for receiving incoming connections. ppp ignores
the ``set device'' line and uses descriptor 0
As I was trying to let the Palm Pilot connect to my desktop
through usb using PPP, I tried to run
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0
FWIW, that should be:
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0
as ppp -direct needs to be able to write to descriptor 0 too
As I was trying to let the Palm Pilot connect to my desktop
through usb using PPP, I tried to run
/usr/sbin/ppp -quiet -direct -nat /dev/ugen0
While, perhaps, not the right way to do what I want (what is? aren't
serial devices the simplest?), it should not panic (nothing should
really
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute, but only after redialing.
I now had to put
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute, but only after redialing.
I now
Brian Somers schrieb:
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my
Brian Somers schrieb:
Hi,
after the latest updates I just noticed a different behaviour of ppp.
in /etc/ppp/ppp.linkup I had an additional line
iface clear
for my profile to get rid of stuffed up IP pairs. After the latest update
this entry also clears my defaultroute
Doing a make installworld with current -CURRENT can break on ppp.
install -c -s -o root -g network -m 4554 ppp /usr/sbin
m4 /usr/src/usr.sbin/ppp/ppp.8.m4 ppp.8
m4: not found
*** Error code 127
Stop in /usr/src/usr.sbin/ppp.
Both root and my normal user id include '/usr
On Sun, 19 Aug 2001, Jay wrote:
Doing a make installworld with current -CURRENT can break on ppp.
install -c -s -o root -g network -m 4554 ppp /usr/sbin
m4 /usr/src/usr.sbin/ppp/ppp.8.m4 ppp.8
m4: not found
*** Error code 127
Stop in /usr/src/usr.sbin/ppp.
Both
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 happens
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 redialing
From: [EMAIL PROTECTED] (Brian Somers)
Date: Fri 8 Jun, 2001
Subject: Re: Unrecognised CBCP packet [strange problems with ppp(8)]
To be honest, I have no idea what's going on here. It doesn't even
look as if you sent any data. I think you may have to ask your ISP
why they're closing
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 redialing.
About
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 and drop
Brian Somers wrote:
I've had reports of this in the past. The other end is sending a
``code 5'' packet - something that doesn't appear in the spec :(
ppp(8) just ignores these (emitting a warning), they shouldn't be
causing any problems themselves (even if CBCP is actually being used
Hi,
I'm having strange problems with one of local dial-up providers: without
any visible reasons from time to time I can't establish PPP connection
during 20-30 minutes. Shortly after going into `Network' mode ppp(8)
complains about `Unrecognised CBCP packet' and drops down line.
Restarting ppp
I've had reports of this in the past. The other end is sending a
``code 5'' packet - something that doesn't appear in the spec :(
ppp(8) just ignores these (emitting a warning), they shouldn't be
causing any problems themselves (even if CBCP is actually being used).
Try enabling IPCP logging
Leif Neland wrote:
I'd like to try pppoe to connect to poptop (on a linuxbox). The port is forbidden; I
should use ng_pppoe.
You're mixing apples and oranges. poptop is for pptp, not pppoe.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
[open_unixsock:pptp_callmgr.c:308]: Call manager for 123.123.123.123 is already
running.
fatal[callmgr_main:pptp_callmgr.c:124]: Could not open Unix socket for 123.123.123
fatal[launch_callmgr:pptp.c:214]: Call manager exited with error 256
But ps is not showing any ppp, pptp or call processes.
Neither is netstat showing
Leif,
I have written an article on how to set up PPPOE under FreeBSD using
userland PPP and Netgraph. The url is
http://pandaemonium.newmillennium.net.au.
Hope this helps.
--
Alastair D'Silva (mob: 0413 485 733)
Networking Consultant
New Millennium Networking (web: http
I'd like to try pppoe to connect to poptop (on a linuxbox). The port is forbidden; I
should use ng_pppoe.
I haven't done netgraph stuff before; afaiu I should attach ng_pppoe to a node which
is the physical device. But I'm doing userland ppp, and tun0 is not a node. ngctl list
shows
On 19 Mr, Ruslan Ermilov wrote:
3. The routing code was fixed to delete routes which use non-existent
interface addresses. This code will wipe such a route.
5. This affects not only ppp(8). Add default route that points to the
LAN; change the IP address on interface; observe
On 30 Mr, Ruslan Ermilov wrote:
- if I put the interface down the first time after a login I have to
readd the defaultroute (only once, after additional "ifconfig
down/up" I didn't have to readd the defaultroute, it stays)
This is only possible if you have a routing daemon running.
On Fri, Mar 30, 2001 at 01:36:39PM +0200, Alexander Leidinger wrote:
On 30 Mar, Ruslan Ermilov wrote:
- if I put the interface down the first time after a login I have to
readd the defaultroute (only once, after additional "ifconfig
down/up" I didn't have to readd the defaultroute,
On 30 Mr, Ruslan Ermilov wrote:
What to do in this situation? I didn't want add the defaultroute
everytime (POLA).
But if we don't do this, we may end up using the wrong source IP
address. Without my fixes, try this:
1) ifconfig isp1 X.X.X.1
2) route add default -iface isp1
3)
[Redirected to -net]
On Fri, Mar 30, 2001 at 03:39:40PM +0200, Alexander Leidinger wrote:
On 30 Mar, Ruslan Ermilov wrote:
What to do in this situation? I didn't want add the defaultroute
everytime (POLA).
But if we don't do this, we may end up using the wrong source IP
address.
On Sun, Mar 25, 2001 at 02:46:22AM +0100, Brian Somers wrote:
On Fri, Mar 23, 2001 at 23:11:56 +, Brian Somers wrote:
1. Ppp is in -auto mode (or a ``set mode auto'' has been done).
Here, ppp configures the interface as soon as it sees the ``set
ifaddr'' line
1 - 100 of 260 matches
Mail list logo
