Re: [RFC] net: towards a generic PON framework

[Gaoyang Wei <yhyxwgy@gmail.com>]

Hi Andrew,

Thanks, the hostapd/wpa_supplicant analogy is useful.

 > But having a dedicated net_device seems wrong to me. However what
 > you mentioned made me think of hostapd and wpa_supplicant. Can that
 > sort of model be used? It does not require an additional interface
 > by the side of the wifi interface.

Yes, I think that is worth considering.

One reason I initially found a packet net_device attractive was that
OMCI itself is a packet-oriented protocol, and an ARPHRD_NONE device
would give userspace a natural AF_PACKET interface without pretending
that OMCI is Ethernet.

But I agree that this does not necessarily mean it has to be modeled
as a separate network interface.

A model closer to nl80211 could instead keep the Ethernet service
datapath as the normal net_device and expose OMCI transport through
the xPON control interface, for example using Generic Netlink messages
associated with a PON device:

         userspace OMCI daemon
                  |
           Generic Netlink
                  |
              net/xpon
                  |
               PON MAC

with no separate omci0 device.

There is one property of the packet-interface model which I think is
important to preserve somehow, though: observability.

With a packet interface, raw OMCI traffic has a natural capture point.
It can be captured with the normal packet tooling and inspected with
Wireshark.  There are already OMCI dissectors available, for example:

   https://github.com/0liv1er/omci-wireshark-dissector

This is particularly useful for PON interoperability work.

Although G.988 defines the standard OMCI model, deployed PON networks
are not as uniform at the management-model level as the 802.11 analogy
might suggest.  Operators and vendors commonly add private MEs,
profiles, or behavioral quirks.

One concrete example is China Telecom's GPON profile.  It defines a
private "LOID authentication" ME, class 65530 (0xfffa), carrying the
operator ID, LOID, password, and authentication status.  Its behavior
also differs from an ordinary MIB object; for example it is excluded
from MIB Upload.

Cases like this make packet-level inspection very useful when an ONU
works with one OLT but fails with another.  Being able to capture the
actual OMCI exchange and feed it directly into protocol-analysis tools
can make the difference between finding an interoperability problem
quickly and debugging it indirectly through daemon logs.

So I think this also reinforces the distinction between two separate
questions:

   1. whether the G.988 agent should live in kernel or userspace;
   2. how raw OMCI PDUs should cross the kernel/userspace boundary.

Generic Netlink may well be the cleaner control abstraction, but I
would like to understand what the Linux-native equivalent of that
packet observation/debugging point should be if we do not use a
management net_device.

Do you have a particular part of the hostapd/nl80211 model in mind
for the management PDU transport itself, for example something
analogous to management frame registration/TX/RX?

And if Generic Netlink is the preferred transport, is there an
existing mechanism you would recommend for exposing the raw management
PDU stream to packet-capture/debugging tools without creating a
separate net_device?

Thanks,
Gaoyang