Re: PPPoE bridge / vlan? setup help needed
- Reply: Gary Aitken : "Re: PPPoE bridge / vlan? setup help needed"
- In reply to: Gary Aitken : "Re: PPPoE bridge / vlan? setup help needed"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 03 May 2023 19:24:34 UTC
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Did you do a "make config" on mpd5?<br>
</p>
<div class="moz-signature">
<p>root@serendipity35-copy:/usr/local/share/doc/mpd5 # ls<br>
README mpd17.html mpd27.html mpd37.html
mpd47.html mpd57.html mpd67.html<br>
mpd.html mpd18.html mpd28.html mpd38.html
mpd48.html mpd58.html mpd68.html<br>
mpd.ps mpd19.html mpd29.html mpd39.html
mpd49.html mpd59.html mpd69.html<br>
mpd1.html mpd2.html mpd3.html mpd4.html mpd5.html
mpd6.html mpd7.html<br>
mpd10.html mpd20.html mpd30.html mpd40.html
mpd50.html mpd60.html mpd70.html<br>
mpd11.html mpd21.html mpd31.html mpd41.html
mpd51.html mpd61.html mpd8.html<br>
mpd12.html mpd22.html mpd32.html mpd42.html
mpd52.html mpd62.html mpd9.html<br>
mpd13.html mpd23.html mpd33.html mpd43.html
mpd53.html mpd63.html mpd_toc.html<br>
mpd14.html mpd24.html mpd34.html mpd44.html
mpd54.html mpd64.html<br>
mpd15.html mpd25.html mpd35.html mpd45.html
mpd55.html mpd65.ht</p>
<p><br>
</p>
<p>Tim<br>
</p>
<font size="2" face="sans-serif" color="gray">
<!-- a href="http://twitter.com/njitcpe"><img alt="CPE Twitter" style="padding:2px;" hspace="2" vspace="2" src="http://dl1.njit.edu/~bpenczak1/tw.png"></img></a>
<a href="https://www.laverne.edu"><img alt="CPE Facebook" style="padding:2px;" hspace="2" vspace="2" src="http://dl1.njit.edu/~bpenczak1/fb.png"></img></a -->
</font></div>
<div class="moz-cite-prefix">On 5/3/23 1:49 PM, Gary Aitken wrote:<br>
</div>
<blockquote type="cite"
cite="mid:b8c78059-94ab-cb2c-e60d-6db11683f0cf@dreamchaser.org">Thanks
all for your replies;
<br>
Slow following up; trying not to ask questions I can find the
answer
<br>
to somewhere else, trying to do my due diligence...
<br>
<br>
On 5/2/23 00:37, Kristof Provost wrote:
<br>
<blockquote type="cite">On 2 May 2023, at 3:32, Gary Aitken wrote:
<br>
<blockquote type="cite">Having trouble setting up a dsl modem as
a bridge. ISP info: Fixed IP LLC-Based multiplexing VPI 0 VCI
100
<br>
</blockquote>
</blockquote>
...
<br>
<blockquote type="cite">With the disclaimer that it’s been ~15
years since I last looked at the relevant tech, but I think
you’re confusing PPP over ATM (PPPoA) with PPP over Ethernet
(PPPoE).
<br>
<br>
VPI/VCI are ATM concepts, and do not exist in Ethernet land.
<br>
</blockquote>
<br>
Having never done this before I've had trouble understanding how
to
<br>
go about it, and more trouble finding info. Obviously have/had
some
<br>
things cross-wired in my head, and probably still do.
<br>
<br>
It's my understanding that the modem connects to the ADSL line
using
<br>
ATM technology, and as such uses the vpi and vci I've given it in
its
<br>
configuration. As nearly as I can tell it makes that connection
ok.
<br>
In its status report I see the line up and at the proper speed,
proper
<br>
vpi and vci. It also reports the IP addr and mask for my LAN end
of
<br>
the link, but no IP info for the ADSL port.
<br>
<br>
So the question becomes how does it connect to the fbsd firewall?
<br>
Do I actually need to run ppp or mpd if it's bridged?
<br>
In talking to my ISP, who's limiting information because they
<br>
don't like to deal with customer-owned equipment (i.e. not rented
<br>
from them, but also understandably avoid the time needed to
educate
<br>
the uneducated), I asked if in bridged mode they ran PPPoE or
PPPoA,
<br>
and he said the modem should "just connect to the firewall machine
<br>
like any other network". I've not been successful finding
references
<br>
so I could be wrong, but I tried leaving ppp out of the link:
<br>
<br>
Relevant IPs reported by modem in modem-router mode, linked up:
<br>
ADSL Port:
<br>
66.109.136.47 255.255.255.255 ADSL link IP
<br>
69.51.80.35 gateway address
<br>
LAN Port:
<br>
66.109.141.58 255.255.255.248 fbsd end
<br>
In modem-only (bridge) mode, there is no LAN ip/mask nor gateway
ip
<br>
<br>
So, with modem in bridge mode, I set up:
<br>
Relevant part of routing table:
<br>
<br>
Destination Gateway Flags Netif Expire
<br>
default 69.51.80.35 UGS xl0
<br>
66.109.141.56/29 link#1 U xl0
<br>
66.109.141.57 link#1 UHS lo0
<br>
69.51.80.35 66.109.141.58 UGHS xl0
<br>
127.0.0.1 link#3 UH lo0
<br>
<br>
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
metric 0 mtu 1500
<br>
options=80008<VLAN_MTU,LINKSTATE>
<br>
inet 66.109.141.57 netmask 0xfffffff8 broadcast
66.109.141.63
<br>
<br>
From the fbsd machine (.57), ping results:
<br>
<br>
# ping 66.109.141.58 (modem, fbsd end)
<br>
PING 66.109.141.58 (66.109.141.58): 56 data bytes
<br>
64 bytes from 66.109.141.58: icmp_seq=0 ttl=64 time=1.211 ms
<br>
<br>
but
<br>
<br>
# ping 66.109.136.47 (IP at ADSL port when modem is in routed
mode)
<br>
PING 66.109.136.47 (66.109.136.47): 56 data bytes
<br>
^C
<br>
--- 66.109.136.47 ping statistics ---
<br>
4 packets transmitted, 0 packets received, 100.0% packet loss
<br>
<br>
# ping 69.51.80.35 (gateway on ISP end of line)
<br>
PING 69.51.80.35 (69.51.80.35): 56 data bytes
<br>
92 bytes from 66.109.141.58: Destination Net Unreachable
<br>
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
<br>
4 5 00 0054 3f08 0 0000 40 01 d6a4 66.109.141.57
69.51.80.35
<br>
<br>
Since a ping of the modem IP succeeds but neither a ping of the
gateway
<br>
nor the ADSL link end worked, given the net unreachable for the
gateway,
<br>
I added an alias to the fbsd xl0 port:
<br>
<br>
# ifconfig xl0 66.109.141.58/29 alias
<br>
<br>
That simply changed the ping of the ADSL port from no response
<br>
to a Destination Net Unreachable error.
<br>
<br>
Upshot of all that is it looks like a direct connection without
PPPoE
<br>
doesn't work.
<br>
<br>
Aside: I ISP asked about renting their preferred modem
<br>
(Zyxel VMG 4005 B50B)
<br>
and they said they don/t rent them separately, you have to rent
them
<br>
with their preferred router... Also looked but couldn't find one
<br>
elsewhere.
<br>
<br>
so...
<br>
<br>
On 5/2/23 08:08, Ian Smith wrote:
<br>
<br>
<blockquote type="cite">It's most likely already set 0/100 for
your country or region. Here
<br>
it's 0/35 (IIRC). Similarly LLC or ... the other one :)
<br>
</blockquote>
<br>
yep
<br>
<br>
<blockquote type="cite">Does the ISP offer ipv6? If so, is this
all you have to dl to
<br>
disable it?
<br>
</blockquote>
<br>
I'm pretty sure no ipv6 from isp.
<br>
I found the disable ... somewhere, and put it in.
<br>
I see no IP6CP in the exchanges so I think it works.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">my.isp.assigned.ip/29 0.0.0.0 add!
default HISADDR # Override
<br>
existing default route with new one
<br>
</blockquote>
<br>
Not sure you need the '!' ?
<br>
</blockquote>
<br>
Without the ! it won't overwrite an old existing one.
<br>
At least that's what I determined once upon a time 15 yrs ago.
<br>
Can't remember where I read/learned that but I did verify it (I
think)
<br>
while doing all this messing around.
<br>
<br>
<blockquote type="cite">I think that's ok ... chatty, ain't it ..
<br>
</blockquote>
<br>
Chatty is good, in this case :-)
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">tun0: CCP: FSM: Using "deflink" as a
transport
<br>
tun0: CCP: deflink: State change Initial --> Closed
<br>
tun0: CCP: deflink: LayerStart. tun0: CCP: MPPE: Not usable
without CHAP81
<br>
</blockquote>
<br>
This looks maybe ominous.
<br>
</blockquote>
<br>
I wondered about that but thought it would just send uncompressed?
<br>
I haven't seen ppp options to set no compression.
<br>
So at this point hoping for the best, you get a nak and don't do
it.
<br>
Docs from Allied Telesis
<br>
<a class="moz-txt-link-freetext" href="https://www.alliedtelesis.com/sites/default/files/ppp_feature_config_guide_rev_b.pdf">https://www.alliedtelesis.com/sites/default/files/ppp_feature_config_guide_rev_b.pdf</a><br>
says the config request is a "wish list", and if it gets a nak or
<br>
reject reply it should come up with a new wish list. I think I
see
<br>
that sent out in the lines:
<br>
IPCP: deflink: SendConfigReq(2) state = Ack-Sent
<br>
IPCP: IPADDR[6] 66.109.141.58
<br>
right before the reject of the other address.
<br>
I'm inferring that a reject reply allows for renegotiation but a
nak
<br>
is a flat-out can't do it, given that the nak (unacceptable
address)
<br>
on the other addr later results in closing the connection.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">tun0: IPCP: deflink: RecvConfigRej(1)
state = Ack-Sent
<br>
tun0: LCP: deflink: SendIdent(1) state = Opened
<br>
tun0: LCP: MAGICNUM 3bbf5181 tun0: LCP: TEXT user-ppp 3.4.2
<br>
tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
<br>
tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent
<br>
tun0: IPCP: IPADDR[6] my.isp.assigned.ip
<br>
tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent
<br>
tun0: IPCP: IPADDR[6] 66.109.136.47
<br>
</blockquote>
<br>
But they want you to use this 66. address, is that related or
similar
<br>
to the address 'my.isp.assigned.ip'? Within your /29?
<br>
</blockquote>
<br>
It's the IP addr reported by the modem for the ADSL line when in
routed
<br>
mode. Not exactly sure what that means when in bridge mode. My
ISP
<br>
couldn't / wouldn't tell me exactly what it was, did some vague
<br>
hand-waving saying that really wasn't what it was and I didn't
need to
<br>
know and that if I configured my end properly it would just work
and to
<br>
not worry about it. Uh-huh. Repeated when I said "but that's the
addr
<br>
which is causing trouble.)
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">*** tun0: IPCP: 66.109.136.47:
Unacceptable address!
<br>
</blockquote>
<br>
So you reject it. Maybe if you don't insist on
'my.isp.assigned.ip'
<br>
it might go - but then they've provided the wrong info.
<br>
</blockquote>
<br>
Thought maybe I reject it because it's not in my /29; or because I
<br>
already accepted the previous addr they asked for. I suppose if
it's
<br>
not in my /29 and I accepted it, all I would need to do is add a
route
<br>
to the routing table, which might happen automatically with the
<br>
add! default HISADDR.
<br>
<br>
This smells like different ppp code in the router and fbsd, and
the
<br>
router code may simply throw out the first agreed-upon addr when
it
<br>
gets the second suggested.
<br>
<br>
I tried using 0.0.0.0 as my suggested IP, to see if they would
come
<br>
up with the 66.109.136.47 the first time:
<br>
<br>
1 tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent
<br>
2 tun0: IPCP: IPADDR[6] 0.0.0.0
<br>
3 tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent
<br>
4 tun0: IPCP: IPADDR[6] 66.109.136.47
<br>
5 tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 -->
66.109.136.47
<br>
6 tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent
<br>
7 tun0: IPCP: IPADDR[6] 66.109.136.47
<br>
8 tun0: LCP: deflink: RecvTerminateReq(8) state = Opened
<br>
<br>
So when I send back a config request to use that addr on line 7
<br>
why do I get a terminate back?
<br>
It would be really handy to be able to see the negotiation on the
<br>
back side of the modem, but I have no way to do that.
<br>
<br>
<blockquote type="cite">At this stage I'd send them the log and
ask what's up?
<br>
</blockquote>
<br>
I think I'm going to try mpd first, if I can figure that out
without
<br>
documentation other than the example.conf. When I pointed out to
them
<br>
many years ago that they had a routing problem it was like pulling
<br>
teeth to get them to admit it and fix it. "No one else is having
<br>
problems, (i.e. complaining) so it has to be at your end." A
<br>
traceroute eventually convinced them, but it took a while.
<br>
<br>
<blockquote type="cite">We moved from user ppp to mpd C. '07, and
found it better and easier,
<br>
but that won't help if their setup info is wrong.
<br>
</blockquote>
<br>
Thanks, I'll see if I can figure out mpd and maybe it will work
better.
<br>
Have the mpd5 port installed, but I can't seem to find docs
anywhere.
<br>
<br>
The Handbook, ch 29.5.1, refers to a "Complete guide to configure
mpd"
<br>
in /usr/ports/shared/doc/mpd. There is no /usr/ports/shared, and
I
<br>
see nothing other than mpd5 in /usr/ports that looks like it might
be
<br>
relevant. Also nothing in /usr/local/share/doc/.
<br>
<br>
Thanks,
<br>
<br>
Gary
<br>
<br>
</blockquote>
</body>
</html>