user ppp and PPPoE bridging

I'm attempting to change a DSL link from using PPPoE in the
DSL modem
to doing PPPoE on 6.1, with the modem in bridging mode.

I've put the DSL modem in bridging mode, and it brings up
the link
properly -- or at least it reports it as up (DSL led steady;
modem status
report shows it as up, rfc 1483.

Using user ppp, when I attempt to establish the PPPoE
connection, I
never get very far -- ppp dies when it tries to acquire
carrier.  I
don't understand this, as there isn't a carrier signal to
acquire on
an ethernet.  I tried disabling cd in ppp.conf but as noted
in the doc,
it's required for a PPPoE connection and is forced on.

Also, how do I know know which interface it is attempting to
connect to?
The debug log shows it found five interfaces, but doesn't
indicate which
one it is trying to connect to.

Thanks for any clues,

Gary

============  log file:  =============

Oct 22 16:34:15 nightmare ppp[84336]: Phase: Using
interface: tun0 Oct 22 16:34:15 nightmare ppp[84336]: Phase:
deflink: Created in closed state
Oct 22 16:34:15 nightmare ppp[84336]: tun0: Command:
default: set log -timer
Oct 22 16:34:15 nightmare ppp[84336]: tun0: Command:
default: ident user-ppp VERSION (built COMPILATIONDATE)
Oct 22 16:34:15 nightmare ppp[84336]: tun0: Command:
default: set redial 15 0
Oct 22 16:34:15 nightmare ppp[84336]: tun0: Command:
default: set reconnect 15 10000
Oct 22 16:34:15 nightmare ppp[84336]: tun0: Phase: PPP
Started (interactive mode).
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
/dev/ttyp3: dial blackfoot
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0x282e72e0
= fopen("/etc/ppp/ppp.conf", "r")
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:
ReadSystem: Checking default (/etc/ppp/ppp.conf).
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0x282e72e0
= fopen("/etc/ppp/ppp.conf", "r")
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:
ReadSystem: Checking blackfoot (/etc/ppp/ppp.conf).
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0x282e72e0
= fopen("/etc/ppp/ppp.conf", "r")
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:
ReadSystem: Checking blackfoot (/etc/ppp/ppp.conf).
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set device PPPoE:ed1
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: disable acfcomp protocomp
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: deny acfcomp
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set mtu max 1492
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set mru max 1492
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: enable mssfixup
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set speed sync
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: enable lqr
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set lqrperiod 5
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set ctsrts off
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: disable ipv6cp
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set dial
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set login
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set timeout 0
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set authname xxxxxxxx
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: set authkey ********
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Command:
blackfoot: add! default HISADDR
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 3 =
socket(17, 3, 0)
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Phase: bundle:
Establish
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Phase: deflink:
closed -> opening
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0 =
NgMkSockNode("", &cs, &ds)
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug: List of
netgraph node ``ed1:'' (id 2) hooks:
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:   Found
orphans -> ethernet
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:
Connecting netgraph socket .:tun0 -> [8]::tun0
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 4 =
socket(2, 2, 0)
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0 =
ioctl(4, 3223349521, 0xbfbfda00)
Oct 22 16:34:24 nightmare ppp[84336]: tun0: ID0: 0 =
ioctl(4, 2149607696, 0xbfbfda00)
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug: Sending
PPPOE_CONNECT to .:tun0
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug: Found the
following interfaces:
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:  Index 1,
name "ep0"
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:  Index 2,
name "plip0"
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:  Index 3,
name "ed1"
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:  Index 4,
name "lo0"
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug:  Index 5,
name "tun0"
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Phase: deflink:
Connected!
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Phase: deflink:
opening -> dial
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Phase: deflink:
dial -> carrier
Oct 22 16:34:24 nightmare ppp[84336]: tun0: Debug: Waiting
for carrier
Oct 22 16:34:28 nightmare last message repeated 4 times
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: deflink:
Disconnected!
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: deflink:
carrier -> hangup
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: deflink:
Close
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: deflink:
Connect time: 5 secs: 0 octets in, 0 octets out
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: deflink:
0 packets in, 0 packets out
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase:  total 0
bytes/sec, peak 0 bytes/sec on Mon Oct 22 16:34:24 2007
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: deflink:
hangup -> closed
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug:
route_IfDelete (5)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: Found
ff01:5::/32 <AF_UNSPEC>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: Found
ff02:5::/32 <AF_UNSPEC>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: Found
ff01:5::/32 <AF_UNSPEC>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 2 =
socket(17, 3, 0)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 148 =
write(2, data, 148)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: wrote
148: cmd = Delete, dst = ff01:5::/32, gateway =
<none>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: Found
ff02:5::/32 <AF_UNSPEC>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 2 =
socket(17, 3, 0)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 148 =
write(2, data, 148)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Debug: wrote
148: cmd = Delete, dst = ff02:5::/32, gateway =
<none>
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 2 =
socket(2, 2, 0)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 0 =
ioctl(2, 3223349521, 0xbfbfe660)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: ID0: 0 =
ioctl(2, 2149607696, 0xbfbfe660)
Oct 22 16:34:29 nightmare ppp[84336]: tun0: Phase: bundle:
Dead
Oct 22 16:34:37 nightmare ppp[84336]: tun0: Command:
/dev/ttyp3: quit
Oct 22 16:34:37 nightmare ppp[84336]: tun0: Debug: DoLoop
done.
Oct 22 16:34:37 nightmare ppp[84336]: tun0: Phase: PPP
Terminated (normal).

============  ppp.conf:  ===========

default:
  set log all
  set log -timer
  ident user-ppp VERSION (built COMPILATIONDATE)
  set redial 15 0
  set reconnect 15 10000
isp:
  set device PPPoE:ed1
  disable acfcomp protocomp
  deny acfcomp
  set mtu max 1492
  set mru max 1492
  enable mssfixup
  set speed sync
  enable lqr
  set lqrperiod 5
  set ctsrts off
  disable ipv6cp
  set dial
  set login
  set timeout 0
  set authname xxxxxx
  set authkey yyyyyy
  add! default HISADDR


_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Tuesday 23 October 2007 05:31:45 freebsddreamchaser.org wrote:
> I'm attempting to change a DSL link from using PPPoE in
the DSL modem
> to doing PPPoE on 6.1, with the modem in bridging
mode.
>
> I've put the DSL modem in bridging mode, and it brings
up the link
> properly -- or at least it reports it as up (DSL led
steady; modem
> status report shows it as up, rfc 1483.
>
> Using user ppp, when I attempt to establish the PPPoE
connection, I
> never get very far -- ppp dies when it tries to acquire
carrier.  I
> don't understand this, as there isn't a carrier signal
to acquire on
> an ethernet.  

There is carrier on ethernet. Ethernet belongs to the
CSMA/DA model
where CS means carrier sense.

> I tried disabling cd in ppp.conf but as noted in the
doc, 
> it's required for a PPPoE connection and is forced on.
>
> Also, how do I know know which interface it is
attempting to connect to?
> The debug log shows it found five interfaces, but
doesn't indicate which
> one it is trying to connect to.

It tries to use ed1 for PPPoE(set device PPPoE:ed1)
Can you use the minimal configuration labelled pppoe
from /usr/share/examples/ppp/ppp.conf.sample?
The only things you have to change are:
The ethernet interface it will try PPPoE.
username and password.

Is your ed1 connected to the modem directly?
Or it goes through a switch? Can you try connecting
your ed1 directly on your DSL modem's ethernet port?
You might need a crossover cable to do this(
http://en.wikipedia.org/wiki/Ethernet_crossover_cable)
or not since these days many ethernet ports do
this automatically.


Please post also ifconfig and run tcpdump on ed1
during try.


>
[snip]
>
> ============  ppp.conf:  ===========
>
> default:
>   set log all
>   set log -timer
>   ident user-ppp VERSION (built COMPILATIONDATE)
>   set redial 15 0
>   set reconnect 15 10000
> isp:
>   set device PPPoE:ed1
>   disable acfcomp protocomp
>   deny acfcomp
>   set mtu max 1492
>   set mru max 1492
>   enable mssfixup
>   set speed sync
>   enable lqr
>   set lqrperiod 5
>   set ctsrts off
>   disable ipv6cp
>   set dial
>   set login
>   set timeout 0
>   set authname xxxxxx
>   set authkey yyyyyy
>   add! default HISADDR
>

I dont'see anything wrong, but I may be wrong. The small
sample configuration always worked for me. Why don't you
use it as a starting point?

Nikos
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Hi Nikos,

Thank you and rw for your replies.

The freebsd box is connected directly via ed1 to the dsl
modem;
a crossover cable is used; the packets are clearly reaching
the modem,
as it records them as received.
I've simplified ppp.conf to the following, essentially the
ppp.conf.sample:

default:
  set log all -timer

blackfoot:
  set device PPPoE:ed1
  enable lqr echo
  set cd 5
  set redial 0 0
  set dial
  set login
  set authname xxxxxxxx
  set authkey yyyyyyyy
  add! default HISADDR


#ifconfig ed1
ed1:
flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST
> mtu 1500
         inet6 fe80::220:18ff:fe72:8b72%ed1 prefixlen 64
scopeid 0x3
         ether 00:20:18:72:8b:72

#tcpdump -efntl -i ed1
tcpdump: WARNING: ed1: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode
listening on ed1, link-type EN10MB (Ethernet), capture size
96 bytes
00:20:18:72:8b:72 > ff:ff:ff:ff:ff:ff, ethertype PPPoE D
(0x8863), length 32: PPPoE PADI [Host-Uniq 0x402DA4C1]
[Service-Name]
00:20:18:72:8b:72 > ff:ff:ff:ff:ff:ff, ethertype PPPoE D
(0x8863), length 32: PPPoE PADI [Host-Uniq 0x402DA4C1]
[Service-Name]

It appears that no PADO reply is being received by the
modem;
the modem shows two packets being transmitted, but non being
received.
Since the line is marked as up by the modem,
and since the line comes up properly when the modem is
operating in
full PPPoE mode, I'm puzzled as to what kind of mismatch
could be
preventing the ISP end from responding.
This is a zyxel 642r modem; I can't try my other modem, a
cisco 678,
because it doesn't support a vci > 63.

The modem is set to use VC-based multiplexing, vpi=0,
vci=100
These are the parameters used for PPPoE, and I presume are
still
required as part of the ATM layer when bridging.

I am assuming there should be no need for my ISP to be
notified that I
am trying to use bridging in the modem, since it should be
transparent
on their end.  They claim not to support bridging, but I
don't see how
they can say that, other than that they don't want to deal
with the
support issues.  Is this a reasonable assumption?

Nikos Vassiliadis wrote:
> On Tuesday 23 October 2007 05:31:45 freebsddreamchaser.org wrote:
>> I'm attempting to change a DSL link from using
PPPoE in the DSL modem
>> to doing PPPoE on 6.1, with the modem in bridging
mode.
>>
>> I've put the DSL modem in bridging mode, and it
brings up the link
>> properly -- or at least it reports it as up (DSL
led steady; modem
>> status report shows it as up, rfc 1483.
>>
>> Using user ppp, when I attempt to establish the
PPPoE connection, I
>> never get very far -- ppp dies when it tries to
acquire carrier.  I
>> don't understand this, as there isn't a carrier
signal to acquire on
>> an ethernet.  
> 
> There is carrier on ethernet. Ethernet belongs to the
CSMA/DA model
> where CS means carrier sense.
> 
>> I tried disabling cd in ppp.conf but as noted in
the doc, 
>> it's required for a PPPoE connection and is forced
on.
>>
>> Also, how do I know know which interface it is
attempting to connect to?
>> The debug log shows it found five interfaces, but
doesn't indicate which
>> one it is trying to connect to.
> 
> It tries to use ed1 for PPPoE(set device PPPoE:ed1)
> Can you use the minimal configuration labelled pppoe
> from /usr/share/examples/ppp/ppp.conf.sample?
> The only things you have to change are:
> The ethernet interface it will try PPPoE.
> username and password.
> 
> Is your ed1 connected to the modem directly?
> Or it goes through a switch? Can you try connecting
> your ed1 directly on your DSL modem's ethernet port?
> You might need a crossover cable to do this(
> http://en.wikipedia.org/wiki/Ethernet_crossover_cable)
> or not since these days many ethernet ports do
> this automatically.
> 
> 
> Please post also ifconfig and run tcpdump on ed1
> during try.
> 
...
> I dont'see anything wrong, but I may be wrong. The
small
> sample configuration always worked for me. Why don't
you
> use it as a starting point?


_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Tuesday 23 October 2007 21:04:48 freebsddreamchaser.org wrote:
> This is a zyxel 642r modem; I can't try my other modem,
a cisco 678,
> because it doesn't support a vci > 63.

Oh cisco  Be
thankful to cisco for not creating
other proprietary protocols to replace the existing
ATM/DSL combination 

>
> The modem is set to use VC-based multiplexing, vpi=0,
vci=100
> These are the parameters used for PPPoE, and I presume
are still
> required as part of the ATM layer when bridging.
>
> I am assuming there should be no need for my ISP to be
notified that I
> am trying to use bridging in the modem, since it should
be transparent
> on their end.  They claim not to support bridging, but
I don't see how
> they can say that, other than that they don't want to
deal with the
> support issues.  Is this a reasonable assumption?

My knowledge about ATM is minimal. So, I don't realy know
how to answer
to your question about bridging being transparent to the
ISP. But I can
tell you for sure that ISPs do not bother if you cannot
connect using
FreeBSD and PPPoE. You are mainly on your own.

I assume that if you use the same settings your modem uses
to do PPPoE it won't make a difference to the ISP end.

You said you had wrong encapsulation type. Did you make any
progress?

> The packets are clearly reaching the modem, as it
records them as
> received. 

Can you also check the number of cells going out/coming in
from the ATM
interface?

Nikos
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Nikos Vassiliadis wrote:

> You said you had wrong encapsulation type. Did you make
any progress?

Yes.
Changing the encapsulation type brought the line up,
and things hobbled along...
However, the line is dropped after a few minutes,
apparently a result of not being able to determine line
quality:

Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink: **
Too many LQR packets lost **
Oct 24 12:39:06 nightmare ppp[859]: tun0: LQM: deflink: Too
many LQR packets lost
Oct 24 12:39:06 nightmare ppp[859]: tun0: CCP: deflink:
State change Stopped --> Closed
Oct 24 12:39:06 nightmare ppp[859]: tun0: CCP: deflink:
State change Closed --> Initial
Oct 24 12:39:06 nightmare ppp[859]: tun0: LCP: deflink:
LayerDown
Oct 24 12:39:06 nightmare ppp[859]: tun0: LCP: deflink:
State change Opened --> Starting
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
open -> lcp
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_UpdateMTU (5)
Oct 24 12:39:06 nightmare ppp[859]: tun0: TCP/IP:
route_UpdateMTU: Netif: 5 (tun0), dst 0.0.0.0/0, mtu 1500
Oct 24 12:39:06 nightmare ppp[859]: tun0: TCP/IP:
route_UpdateMTU: Netif: 5 (tun0), dst 216.47.48.1, mtu 1500
Oct 24 12:39:06 nightmare ppp[859]: tun0: TCP/IP:
route_UpdateMTU: Netif: 5 (tun0), dst ff01:5::/32, mtu 1500
Oct 24 12:39:06 nightmare ppp[859]: tun0: TCP/IP:
route_UpdateMTU: Netif: 5 (tun0), dst ff02:5::/32, mtu 1500
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: deflink:
LayerDown: 12.32.44.142
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: ReadSystem:
Can't open /etc/ppp/ppp.linkdown.
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: ReadSystem:
Can't open /etc/ppp/ppp.linkdown.
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: ReadSystem:
Can't open /etc/ppp/ppp.linkdown.
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: deflink:
State change Opened --> Starting
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: deflink:
LayerFinish.
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: Connect
time: 331 secs: 2253 octets in, 1584 octets out
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: 24 packets
in, 25 packets out
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP:  total 11
bytes/sec, peak 275 bytes/sec on Wed Oct 24 12:34:43 2007
Oct 24 12:39:06 nightmare ppp[859]: tun0: IPCP: deflink:
State change Starting --> Initial
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: bundle:
Terminate
Oct 24 12:39:06 nightmare ppp[859]: tun0: LCP: deflink:
LayerFinish
Oct 24 12:39:06 nightmare ppp[859]: tun0: LCP: deflink:
State change Starting --> Initial
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
Disconnected!
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
lcp -> logout
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
Disconnected!
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
logout -> hangup
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: deflink:
Close
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
Connect time: 332 secs: 3044 octets in, 2789 octets out
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink: 70
packets in, 77 packets out
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase:  total 17
bytes/sec, peak 315 bytes/sec on Wed Oct 24 12:34:46 2007
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: deflink:
hangup -> closed
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_IfDelete (5)
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
0.0.0.0/0 216.47.48.1
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
216.47.48.1 12.32.44.142
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
ff01:5::/32 <AF_UNSPEC>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
ff02:5::/32 <AF_UNSPEC>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug:
route_IfDelete: Skip it (pass 0)
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
0.0.0.0/0 216.47.48.1
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: wrote 124:
cmd = Delete, dst = 0.0.0.0/0, gateway = <none>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
216.47.48.1 12.32.44.142
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: wrote 108:
cmd = Delete, dst = 216.47.48.1, gateway = <none>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
ff01:5::/32 <AF_UNSPEC>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: wrote 148:
cmd = Delete, dst = ff01:5::/32, gateway = <none>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: Found
ff02:5::/32 <AF_UNSPEC>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Debug: wrote 148:
cmd = Delete, dst = ff02:5::/32, gateway = <none>
Oct 24 12:39:06 nightmare ppp[859]: tun0: Phase: bundle:
Dead

During initial protocol negotiation, it looks like come sort
of compression
is disallowed, but it doesn't seem like that should cause
the line to be
dropped later:

Oct 24 12:33:35 nightmare ppp[859]: tun0: LCP: deflink:
RecvProtocolRej(2) state = Opened
Oct 24 12:33:35 nightmare ppp[859]: tun0: LCP: deflink: --
Protocol 0x80fd (Compression Control Protocol) was
rejected!
Oct 24 12:33:35 nightmare ppp[859]: tun0: CCP: deflink:
State change Req-Sent --> Stopped
Oct 24 12:33:35 nightmare ppp[859]: tun0: IPCP: deflink:
RecvConfigRej(1) state = Ack-Sent
Oct 24 12:33:35 nightmare ppp[859]: tun0: IPCP: 
COMPPROTO[6] 16 VJ slots with slot compression
Oct 24 12:33:35 nightmare ppp[859]: tun0: IPCP: deflink:
SendConfigReq(2) state = Ack-Sent

And after the line is up, I see this:

Oct 24 12:33:35 nightmare ppp[859]: tun0: Debug: deflink:
PPPoE:ed1: Cannot determine bandwidth

I presume this is a result of the lost LQR packets.

Prior to closing the line, there are a number of what look
like sync
attempts; they look to me like they succeed:

Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug: deflink:
DescriptorRead: read 14/2048 from 3
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:
proto_LayerPull: unknown -> 0xc021
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:
link_PullPacket: Despatch proto 0xc021
Oct 24 12:38:36 nightmare ppp[859]: tun0: LCP: deflink:
RecvEchoRequest(30) state = Opened
Oct 24 12:38:36 nightmare ppp[859]: tun0: LCP: deflink:
SendEchoReply(30) state = Opened
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug: fsm_Output
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:  0a 1e 00
0c 0b 58 fc 84 0b 58 fc 84              .....X...X..
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:
proto_LayerPush: Using 0xc021
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:
link_PushPacket: Transmit proto 0xc021
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug: m_enqueue:
len = 1
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug: m_dequeue:
queue len = 1
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug:
link_Dequeue: Dequeued from queue 1, containing 0 more
packets
Oct 24 12:38:36 nightmare ppp[859]: tun0: Debug: deflink:
DescriptorWrite: wrote 14(14) to 3
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM: deflink:
Output:
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:   Magic:     
    0b58fc84   LastOutLQRs:    00000005
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:  
LastOutPackets: 20464846   LastOutOctets:  46454d44
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:   PeerInLQRs:
    00000005   PeerInPackets:  0000002f
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:  
PeerInDiscards: 00000000   PeerInErrors:   00000000
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:  
PeerInOctets:   00000a6c   PeerOutLQRs:    0000000b
Oct 24 12:38:36 nightmare ppp[859]: tun0: LQM:  
PeerOutPackets: 00000049   PeerOutOctets:  00000ac2

The above summary appears to indicate that line quality
requests are
being transferred; so what's with the too many LQR packets
lost message?

Finally,
Where does the initial IP address used in the negotiation
come from?
I did not specify specific IP address assignment,
yet the request appears to have asked for 12.32.36.65
This is the IP of the other interface on the machine,
and my ppp.conf has no mention of it.

  Can you also check the number of cells going out/coming in
from the ATM
> interface?

I'm not sure what you mean by this...

Thanks for any help;
I'm going to be out for a day or so,
so may be slow to reply

Gary
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"