Re: PPPoE bridge / vlan? setup help needed
Date: Wed, 03 May 2023 17:49:57 UTC
Thanks all for your replies;
Slow following up; trying not to ask questions I can find the answer
to somewhere else, trying to do my due diligence...
On 5/2/23 00:37, Kristof Provost wrote:
> On 2 May 2023, at 3:32, Gary Aitken wrote:
>> Having trouble setting up a dsl modem as a bridge. ISP info: Fixed
>> IP LLC-Based multiplexing VPI 0 VCI 100
...
> 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).
>
> VPI/VCI are ATM concepts, and do not exist in Ethernet land.
Having never done this before I've had trouble understanding how to
go about it, and more trouble finding info. Obviously have/had some
things cross-wired in my head, and probably still do.
It's my understanding that the modem connects to the ADSL line using
ATM technology, and as such uses the vpi and vci I've given it in its
configuration. As nearly as I can tell it makes that connection ok.
In its status report I see the line up and at the proper speed, proper
vpi and vci. It also reports the IP addr and mask for my LAN end of
the link, but no IP info for the ADSL port.
So the question becomes how does it connect to the fbsd firewall?
Do I actually need to run ppp or mpd if it's bridged?
In talking to my ISP, who's limiting information because they
don't like to deal with customer-owned equipment (i.e. not rented
from them, but also understandably avoid the time needed to educate
the uneducated), I asked if in bridged mode they ran PPPoE or PPPoA,
and he said the modem should "just connect to the firewall machine
like any other network". I've not been successful finding references
so I could be wrong, but I tried leaving ppp out of the link:
Relevant IPs reported by modem in modem-router mode, linked up:
ADSL Port:
66.109.136.47 255.255.255.255 ADSL link IP
69.51.80.35 gateway address
LAN Port:
66.109.141.58 255.255.255.248 fbsd end
In modem-only (bridge) mode, there is no LAN ip/mask nor gateway ip
So, with modem in bridge mode, I set up:
Relevant part of routing table:
Destination Gateway Flags Netif Expire
default 69.51.80.35 UGS xl0
66.109.141.56/29 link#1 U xl0
66.109.141.57 link#1 UHS lo0
69.51.80.35 66.109.141.58 UGHS xl0
127.0.0.1 link#3 UH lo0
xl0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=80008<VLAN_MTU,LINKSTATE>
inet 66.109.141.57 netmask 0xfffffff8 broadcast 66.109.141.63
From the fbsd machine (.57), ping results:
# ping 66.109.141.58 (modem, fbsd end)
PING 66.109.141.58 (66.109.141.58): 56 data bytes
64 bytes from 66.109.141.58: icmp_seq=0 ttl=64 time=1.211 ms
but
# ping 66.109.136.47 (IP at ADSL port when modem is in routed mode)
PING 66.109.136.47 (66.109.136.47): 56 data bytes
^C
--- 66.109.136.47 ping statistics ---
4 packets transmitted, 0 packets received, 100.0% packet loss
# ping 69.51.80.35 (gateway on ISP end of line)
PING 69.51.80.35 (69.51.80.35): 56 data bytes
92 bytes from 66.109.141.58: Destination Net Unreachable
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 3f08 0 0000 40 01 d6a4 66.109.141.57 69.51.80.35
Since a ping of the modem IP succeeds but neither a ping of the gateway
nor the ADSL link end worked, given the net unreachable for the gateway,
I added an alias to the fbsd xl0 port:
# ifconfig xl0 66.109.141.58/29 alias
That simply changed the ping of the ADSL port from no response
to a Destination Net Unreachable error.
Upshot of all that is it looks like a direct connection without PPPoE
doesn't work.
Aside: I ISP asked about renting their preferred modem
(Zyxel VMG 4005 B50B)
and they said they don/t rent them separately, you have to rent them
with their preferred router... Also looked but couldn't find one
elsewhere.
so...
On 5/2/23 08:08, Ian Smith wrote:
> It's most likely already set 0/100 for your country or region. Here
> it's 0/35 (IIRC). Similarly LLC or ... the other one :)
yep
> Does the ISP offer ipv6? If so, is this all you have to dl to
> disable it?
I'm pretty sure no ipv6 from isp.
I found the disable ... somewhere, and put it in.
I see no IP6CP in the exchanges so I think it works.
>> my.isp.assigned.ip/29 0.0.0.0 add! default HISADDR # Override
>> existing default route with new one
>
> Not sure you need the '!' ?
Without the ! it won't overwrite an old existing one.
At least that's what I determined once upon a time 15 yrs ago.
Can't remember where I read/learned that but I did verify it (I think)
while doing all this messing around.
> I think that's ok ... chatty, ain't it ..
Chatty is good, in this case :-)
>> tun0: CCP: FSM: Using "deflink" as a transport
>> tun0: CCP: deflink: State change Initial --> Closed
>> tun0: CCP: deflink: LayerStart.
>> tun0: CCP: MPPE: Not usable without CHAP81
>
> This looks maybe ominous.
I wondered about that but thought it would just send uncompressed?
I haven't seen ppp options to set no compression.
So at this point hoping for the best, you get a nak and don't do it.
Docs from Allied Telesis
https://www.alliedtelesis.com/sites/default/files/ppp_feature_config_guide_rev_b.pdf
says the config request is a "wish list", and if it gets a nak or
reject reply it should come up with a new wish list. I think I see
that sent out in the lines:
IPCP: deflink: SendConfigReq(2) state = Ack-Sent
IPCP: IPADDR[6] 66.109.141.58
right before the reject of the other address.
I'm inferring that a reject reply allows for renegotiation but a nak
is a flat-out can't do it, given that the nak (unacceptable address)
on the other addr later results in closing the connection.
>> tun0: IPCP: deflink: RecvConfigRej(1) state = Ack-Sent
>> tun0: LCP: deflink: SendIdent(1) state = Opened
>> tun0: LCP: MAGICNUM 3bbf5181
>> tun0: LCP: TEXT user-ppp 3.4.2
>> tun0: IPCP: COMPPROTO[6] 16 VJ slots with slot compression
>> tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent
>> tun0: IPCP: IPADDR[6] my.isp.assigned.ip
>> tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent
>> tun0: IPCP: IPADDR[6] 66.109.136.47
>
> But they want you to use this 66. address, is that related or similar
> to the address 'my.isp.assigned.ip'? Within your /29?
It's the IP addr reported by the modem for the ADSL line when in routed
mode. Not exactly sure what that means when in bridge mode. My ISP
couldn't / wouldn't tell me exactly what it was, did some vague
hand-waving saying that really wasn't what it was and I didn't need to
know and that if I configured my end properly it would just work and to
not worry about it. Uh-huh. Repeated when I said "but that's the addr
which is causing trouble.)
>> *** tun0: IPCP: 66.109.136.47: Unacceptable address!
>
> So you reject it. Maybe if you don't insist on 'my.isp.assigned.ip'
> it might go - but then they've provided the wrong info.
Thought maybe I reject it because it's not in my /29; or because I
already accepted the previous addr they asked for. I suppose if it's
not in my /29 and I accepted it, all I would need to do is add a route
to the routing table, which might happen automatically with the
add! default HISADDR.
This smells like different ppp code in the router and fbsd, and the
router code may simply throw out the first agreed-upon addr when it
gets the second suggested.
I tried using 0.0.0.0 as my suggested IP, to see if they would come
up with the 66.109.136.47 the first time:
1 tun0: IPCP: deflink: SendConfigReq(2) state = Ack-Sent
2 tun0: IPCP: IPADDR[6] 0.0.0.0
3 tun0: IPCP: deflink: RecvConfigNak(2) state = Ack-Sent
4 tun0: IPCP: IPADDR[6] 66.109.136.47
5 tun0: IPCP: IPADDR[6] changing address: 0.0.0.0 --> 66.109.136.47
6 tun0: IPCP: deflink: SendConfigReq(3) state = Ack-Sent
7 tun0: IPCP: IPADDR[6] 66.109.136.47
8 tun0: LCP: deflink: RecvTerminateReq(8) state = Opened
So when I send back a config request to use that addr on line 7
why do I get a terminate back?
It would be really handy to be able to see the negotiation on the
back side of the modem, but I have no way to do that.
> At this stage I'd send them the log and ask what's up?
I think I'm going to try mpd first, if I can figure that out without
documentation other than the example.conf. When I pointed out to them
many years ago that they had a routing problem it was like pulling
teeth to get them to admit it and fix it. "No one else is having
problems, (i.e. complaining) so it has to be at your end." A
traceroute eventually convinced them, but it took a while.
> We moved from user ppp to mpd C. '07, and found it better and easier,
> but that won't help if their setup info is wrong.
Thanks, I'll see if I can figure out mpd and maybe it will work better.
Have the mpd5 port installed, but I can't seem to find docs anywhere.
The Handbook, ch 29.5.1, refers to a "Complete guide to configure mpd"
in /usr/ports/shared/doc/mpd. There is no /usr/ports/shared, and I
see nothing other than mpd5 in /usr/ports that looks like it might be
relevant. Also nothing in /usr/local/share/doc/.
Thanks,
Gary