au Hikarie fiber 10G with Edgerouter Infinity

[lundman]

Hello! I'm aware that this utility isn't made for the situation that I am in, but perhaps it can help me get close to working. I have 10G KDDI Fiber in Japan, which comes with an "aterm-bl1000hw" router. I have replaced it with an Edgerouter Infinity (usg-xg-8).

1) Clone MAC from "aterm" to "eth1" (WAN) 2) When I plug in "eth1" (WAN) to the ONU I get DHCP address 3) Everything works...

... for about 24 hours. Then it drops, I have to plug in their router for a few seconds, repeat.

I have been told it uses EAPOL, which led me here.

I now have their aterm plugged into "eth0".

It refuses to DHCP; in that I'm probably supposed have some magic key in there;

dhcp tcpdump

``` 06:54:05.349948 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328) 192.168.1.1.67 > 192.168.1.10.68: BOOTP/DHCP, Reply, length 300, xid 0x8bd070a6, Flags [none] Your-IP 192.168.1.10 Client-Ethernet-Address ma:ca:dd:re:ss:ss Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Offer Server-ID Option 54, length 4: 192.168.1.1 Lease-Time Option 51, length 4: 3600 Subnet-Mask Option 1, length 4: 255.255.255.0 Default-Gateway Option 3, length 4: 192.168.1.1 Domain-Name-Server Option 6, length 4: 192.168.1.1 06:54:05.350351 IP (tos 0xa0, ttl 32, id 39920, offset 0, flags [DF], proto UDP (17), length 576) 0.0.0.0.68 > 192.168.1.1.67: BOOTP/DHCP, Request from 6c:e4:da:43:48:31, length 548, xid 0x4ad070a6, Flags [none] Client-IP 192.168.1.10 Client-Ethernet-Address ma:ca:dd:re:ss:ss Vendor-rfc1048 Extensions Magic Cookie 0x63825363 DHCP-Message Option 53, length 1: Release Client-ID Option 61, length 7: ether 6c:e4:da:43:48:31 Server-ID Option 54, length 4: 192.168.1.1 MSG Option 56, length 48: "I'm no longer need the IP address (192.168.1.10)" Inside the DHCP packet it has the string: `kddi-hgw1.13` which perhaps has a respond phrase? ```

---

But I left eap_proxy.py running while desperate googling was going on, and suddenly this showed up:

ubnt@ubnt:~$ sudo ./eap_proxy.py eth1 eth0 --ping-gateway
[2020-06-30 06:34:12,322]: starting proxy_loop
[2020-06-30 07:03:50,860]: eth0: ma:ca:dd:re:ss:ss > 01:80:c2:00:00:03, EAPOL start (1) v1, len 0 > eth1
[2020-06-30 07:03:50,889]: eth1: 74:3a:65:2a:63:75 > ma:ca:dd:re:ss:ss, EAP packet (0) v1, len 5, Request (1) id 89, len 5 [1] > eth0
[2020-06-30 07:03:50,890]: eth0: ma:ca:dd:re:ss:ss > 01:80:c2:00:00:03, EAP packet (0) v1, len 17, Response (2) id 89, len 17 [13] > eth1
[2020-06-30 07:03:50,915]: eth1: 74:3a:65:2a:63:75 > ma:ca:dd:re:ss:ss, EAP packet (0) v1, len 28, Request (1) id 90, len 28 [24] > eth0
[2020-06-30 07:03:50,915]: eth0: ma:ca:dd:re:ss:ss > 01:80:c2:00:00:03, EAP packet (0) v1, len 22, Response (2) id 90, len 22 [18] > eth1
[2020-06-30 07:03:50,984]: eth1: 74:3a:65:2a:63:75 > ma:ca:dd:re:ss:ss, EAP packet (0) v1, len 4, Success (3) id 91, len 4 [0] > eth0

Which fills me with some hope, especially since it is communicating to/fro a few times, ending with "success". Does their "aterm" router perhaps not need to DHCP for the EAP proxy to do it's work?

I will have to wait 22 hours to find out...

[closb]

Looks like it's working, I would check your IP6 settings and/or jumbo frames. It may just be bottleneck causing crash.

[lundman]

it's stopped twice, and both times no matter what troubleshooting I did, only started working once I pugged in their router for a bit. But I'm hoping it will not stop tomorrow as eap_proxy is running.

[lundman]

I have passed the daily hangup without issues, and I believe that was the last piece of the puzzle.

Thanks for much for your excellent utility.

[Kotter-9]

I am also using the same au Hikari ISP as lundman and have the same problem.

I installed eap_proxy on ER-X but it doesn't work. The FW of ER-X is 1.10.11.

I now have their HGW(Equivalent of RG) connected to 'eth1' and their ONU (Equivalent of AT&T ONT) to 'eth0'. Clone MAC from 'HGW' to "eth0" (ONU)

au Hikari, slightly different from AT&T, does not use VLAN tags. Therefore, I don't think it is necessary to create a VLAN.

Bypassing HGW only requires a MAC address and 802.1X authentication. Add DUID-LL if IPv6 is also needed.

Also, the HGW rejects DHCP, but since EAPOL is Layer 2 and does not require an IP address, there should be no problem.

Are there any other settings other than what is written here? Please tell me the solution.

show config interfaces

``` interfaces { ethernet eth0 { address dhcp description ONU duplex auto firewall { in { ipv6-name WANv6_IN name WAN_IN } local { ipv6-name WANv6_LOCAL name WAN_LOCAL } } mac a4:12:42:00:00:00 speed auto } ethernet eth1 { description HGW duplex auto speed auto } ethernet eth2 { description VoIP duplex auto speed auto } ethernet eth3 { description LAN duplex auto speed auto } ethernet eth4 { description Local duplex auto poe { output off } speed auto } loopback lo { } switch switch0 { address 192.168.1.1/24 description Local mtu 1500 switch-port { interface eth1 { } interface eth2 { } interface eth3 { } interface eth4 { } vlan-aware disable } } } service { dhcp-server { disabled false hostfile-update disable shared-network-name LAN { authoritative enable subnet 192.168.1.0/24 { default-router 192.168.1.1 dns-server 1.1.1.1 dns-server 1.0.0.1 lease 86400 start 192.168.1.100 { stop 192.168.1.200 } } } static-arp disable use-dnsmasq disable } dns { forwarding { cache-size 150 listen-on switch0 } } gui { http-port 80 https-port 443 older-ciphers enable } nat { rule 5010 { description "masquerade for WAN" outbound-interface eth0 type masquerade } } } ```

This is the execution log of eap_proxy.py. No response from HGW.

admin@EdgeRouter-X-5-Port:~$ sudo ./config/screpts/eap_proxy.py eth0 eth1 --ping-gateway
[2023-07-11 21:38:54,012]: starting proxy_loop
[2023-07-12 17:17:50,937]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 81, len 5 [1] > eth1
[2023-07-12 17:18:21,709]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 81, len 5 [1] > eth1
[2023-07-12 17:18:51,789]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 81, len 5 [1] > eth1
[2023-07-12 17:19:21,878]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 4, Failure (4) id 82, len 4 [0] > eth1
[2023-07-12 17:20:21,988]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 83, len 5 [1] > eth1
[2023-07-12 17:20:53,708]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 83, len 5 [1] > eth1
[2023-07-12 17:21:23,778]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 83, len 5 [1] > eth1
[2023-07-12 17:21:54,713]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 4, Failure (4) id 84, len 4 [0] > eth1
[2023-07-12 17:22:54,782]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 85, len 5 [1] > eth1
[2023-07-12 17:23:24,843]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 85, len 5 [1] > eth1
[2023-07-12 17:23:54,952]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 85, len 5 [1] > eth1
[2023-07-12 17:24:25,795]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 4, Failure (4) id 86, len 4 [0] > eth1

However, when I check the packet capture, it seems that EAPOL is being sent from HGW.

Ethernet II, Src: NECPlatf_ab:cd:ef (a4:12:42:00:00:00), Dst: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Destination: Nearest-non-TPMR-bridge (01:80:c2:00:00:03)
    Source: NECPlatf_ab:cd:ef (a4:12:42:00:00:00)
    Type: 802.1X Authentication (0x888e)
    Padding: 000000000000000000000000000000000000000000000000000000000000000000000000…
802.1X Authentication
    Version: 802.1X-2001 (1)
    Type: Start (1)
    Length: 0

[Kotter-9]

It was caused by my switch port including eth1.

switch switch0 {
        address 192.168.1.1/24
        description Local
        mtu 1500
        switch-port {
            interface eth1 {
            }
            interface eth2 {
            }
            interface eth3 {
            }
            interface eth4 {
            }
            vlan-aware disable
        }
    }

Removing eth1 from the switch port worked fine.

[2023-07-12 22:30:51,206]: eth1: a4:12:42:00:00:00 > 01:80:c2:00:00:03, EAPOL start (1) v1, len 0 > eth0
[2023-07-12 22:30:51,891]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 5, Request (1) id 93, len 5 [1] > eth1
[2023-07-12 22:30:51,894]: eth1: a4:12:42:00:00:00 > 01:80:c2:00:00:03, EAP packet (0) v1, len 17, Response (2) id 93, len 17 [13] > eth0
[2023-07-12 22:30:51,915]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 22, Request (1) id 94, len 22 [18] > eth1
[2023-07-12 22:30:51,918]: eth1: a4:12:42:00:00:00 > 01:80:c2:00:00:03, EAP packet (0) v1, len 34, Response (2) id 94, len 34 [30] > eth0
[2023-07-12 22:30:51,955]: eth0: 08:00:70:00:00:00 > a4:12:42:00:00:00, EAP packet (0) v1, len 4, Success (3) id 94, len 4 [0] > eth1