Попробуйте добавить [ipoe]offer-timeout=60 и посмотрите, будет ли интерфейс в UP. Но это после accel-cmd reload

сделал  [log]level=5 [ipoe]offer-timeout=60

Интерфейс в down
Через минуту теперь интерфейс отваливается

[2020-07-01 13:56:52]:  info: ipoe18: create interface ipoe18 parent enp5s0f0.3016
[2020-07-01 13:56:52]:  info: ipoe18: send [RADIUS(1) Access-Request id=1 <User-Name "00:1b:fc:22:4c:89"> <NAS-Identifier "Accel-172.17.166.8"> <NAS-IP-Address 172.17.166.8> <NAS-Port 12717> <NAS-Port-Id "ipoe18"> <NAS-Port-Type Ethernet> <Calling-Station-Id "00:1b:fc:22:4c:89"> <Called-Station-Id "enp5s0f0.3016"> <DHCP-Option82 0x01060001401ee210> <AccelCircuitId 0x0001401ee210> <User-Password 0xf0be5b0f640785943348dd0b3d7168c29f2c234d4484ed9ea053d6f4bce46d5f>]
[2020-07-01 13:56:52]:  info: ipoe18: recv [RADIUS(1) Access-Accept id=1 <PPPD-Downstream-Speed-Limit 204800> <Framed-IP-Address 172.19.2.88> <Acct-Interim-Interval 300> <Framed-IP-Netmask 255.255.224.0> <PPPD-Upstream-Speed-Limit 204800> <Framed-IP-Netmask 255.255.224.0>]
[2020-07-01 13:56:52]:  info: ipoe18: 00:1b:fc:22:4c:89: authentication succeeded
[2020-07-01 13:56:52]:  info: ipoe18: send [DHCPv4 Offer xid=9ae71089 yiaddr=172.19.2.88 giaddr=172.17.8.40 chaddr=00:1b:fc:22:4c:89 <Message-Type Offer> <Server-ID 172.19.0.1> <Lease-Time 300> <T1 150> <Router 172.19.0.1> <Subnet 255.255.224.0> <DNS 8.8.8.8>]


[2020-07-01 13:57:52]:  info: ipoe18: ipoe: session timed out
[2020-07-01 13:57:52]: debug: ipoe18: terminate
[2020-07-01 13:57:52]:  info: ipoe18: ipoe: session finished


ip ad | grep ipoe18
12723: ipoe18: <POINTOPOINT,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 100

Через минуту отваливается

Эм... потому что на offer нет request?

да, посылает его аксель в интерфейс ipoe , тот в down. Поэтому offer не доходит

А если tcpdump на парент интерфейсе с ether host 00:1b:fc:22:4c:89

Yuriy и ещё вопрос, ядро какое?

uname -r
4.4.0-143-generic

парент интерфейс похоже только discover показывает, аксель же офер в ipoe шлет
tcpdump  -i enp5s0f0.3016
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp5s0f0.3016, link-type EN10MB (Ethernet), capture size 262144 bytes

14:21:29.809835 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 315
14:21:29.809964 IP 0.0.0.0.bootps > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 259
14:21:29.809999 IP 0.0.0.0.bootps > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 259
14:21:33.806377 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 315
14:21:33.806483 IP 0.0.0.0.bootps > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 259
14:21:40.800715 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 00:1b:fc:22:4c:89 (oui Unknown), length 315

В emerge лог и core log нет ничего?

core.log
emerg.log
пустые файлы

Yuriy у сервера есть роут до 172.17.8.40

Это похоже на mode L3 проведение

Yuriy сможете пакет Discover в pcap сохранить?

accel-ppp# ping 172.17.8.40
PING 172.17.8.40 (172.17.8.40) 56(84) bytes of data.
64 bytes from 172.17.8.40: icmp_seq=1 ttl=62 time=1.06 ms
64 bytes from 172.17.8.40: icmp_seq=2 ttl=62 time=1.22 ms
Ну он его пингует через дефолт - в аплинк акселя.
172.17.8.40   - это управляющий IP HPNA Master , он в управляющем совсем другом влане

Нужен пакет, возможно есть недочёты в обработке

это лучше на абонском хосте wireshark-ом ? или на акселе tcpdump-ом ?

думаю, что на акселе tcpdump - Dynamix HPNA вносит же в него изменения 82 опцией. без 82 опции - аутентификация по маку - все работает.

На accel

Нужна помощь в понимании как работает check-mac-change=1 - accel-ppp version 1.12.0-72-ged7b287

check-mac-change=1
interface=re:^vlan(204|205|206|618|621|622)$,ifcfg=1,mode=L2,start=dhcpv4,shared=1,ip-unnumbered=1,username=lua:username_vlan
interface=re:^vlan(86|87|519)$,ifcfg=1,mode=L2,start=dhcpv4,shared=0,ip-unnumbered=1,username=lua:username_vlan_mac

т.е. есть пару общих 205|206   вланов, и  86|87| - влан на абонента - и для этого мне нужен check-mac-change=1, но в общих вланах мне не нужно проверять маки.
и что у меня вышло:
в сети есть свитчи D-link где включено dhcp_local_relay
и там где абонент имеет уникальный  <Relay-Agent {Agent-Circuit-ID _0004026e0003} {Agent-Remote-ID _00065cd998fafbe0}> - проблем нет в общем влане
и есть где  dhcp_local_relay включено на магистральном порту и соотв. Relay-Agent общий для  разных клиентов.
вопросы: 1.  делаю вывод check-mac-change - проверяет Relay-Agent если они есть, иначе мак клиента ?
2.
3.  check-mac-change - включается только глобально ?
4. наверное в смоем случает стоит разделить и запустить два демона 1й с общими вланами и check-mac-change=0 и 2й в check-mac-change=1 при VPU