Skip to content

add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum #28636

Closed
dotnet/corefx
#37315

Description

@wfurt

Both protocols are currently only supported on Linux but both provide interesting capabilities and been asked for by community.

AF_PACET sockets allow access to link-layer beyond limits of IP RAW sockets.

Netlink is used widely for various system communications (like route update notifications), can allow communication with kernel modules and support message multicasting.

I did some testing and existing socket functions seems to work well with new protocol families so changes to actually support them would be small.

Here is proposed change to public API:

 namespace System.Net.Sockets
 {
     public enum ProtocolFamily
     {
+        Netlink = AddressFamily.Netlink,
+        Packet = AddressFamily.Packet,
+        ControllerAreaNetwork = AddressFamily.ControllerAreaNetwork,
     }
     public enum AddressFamily
     {
+        Netlink = 30,           // Netlink protocol
+        Packet = 31,            // Linux Packet
+        ControllerAreaNetwork = 32, // Controller Area Network automotive bus protocol
     }
 }

Socket constructor takes protocol family but also protocol type and current enum is mostly IP oriented. Packet protocol uses Link layer type and can be possibly pretty large. For Netlink, there are several subgroups (https://en.wikipedia.org/wiki/Netlink) but it is also possible to define and use custom one via extensibility model.

Since this is specific to Linux and probably out of mainstream developers, I suggest for now that we do not enumerate all possibilities now and we let users of specific applications to cast int and provide direct value.
This could be re-visited later if implementation goes beyond Linux.

When one attempt to use them on Windows and OSX, existing code throws reasonable exception:

Windows

System.Net.Sockets.SocketException (10047): An address incompatible with the requested protocol was used
at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

OSX

System.Net.Sockets.SocketException (47): Address family not supported by protocol family
at System.Net.Sockets.Socket..ctor(AddressFamily addressFamily, SocketType socketType, ProtocolType protocolType)

cc: @karelz

Activity

  1. self-assigned this
    on Feb 7, 2019
  2. stephentoub commented on Feb 7, 2019

    @stephentoub
    Member

    What is the existing Max value in both AddressFamily and ProtocolFamily?

    It seems like it's referring to the maximum value in the enums, which would have been a really unfortunate design to be made public, and changing it now is technically a breaking change, plus if anyone is using it in their code and has an existing binary compiled using it, that binary will retain the old value even after we change it. That said, I don't see a particularly good alternative; the main other one would be to simply not change Max and have it no longer be the max value.

    However, is that actually what Max is? The docs are fairly non-descript, but state that it's the "MAX protocol" and "MAX address"... the capitalization there is confusing me. Is there some protocol and address family that's actually named "MAX"? If so, that'd be good news, as we wouldn't have to break anything... we just keep those values as they were.

  3. wfurt commented on Feb 7, 2019

    @wfurt
    MemberAuthor

    I did not find protocol MAX. However, I was looking for others like AddressFamily.Firefox and found https://stackoverflow.com/questions/1302494/what-does-addressfamily-firefox-refer-to-in-net-sockets

    That has references to Winsock from 1996. My suspicion is that we took values verbatim from C header. But it seems like we never establish MAX as special value in C#. I think best option is to keep MAX as as and simply add new values to enum. Netlink=30 and PACET=31.

    Also note, that this will not pop-up anyhow (in let say received message) unless explicitly asked for. One needs to create socket first and pass values in.

  4. wfurt commented on Feb 7, 2019

    @wfurt
    MemberAuthor

    More references to Winsock: https://searchcode.com/codesearch/view/10558954/

    This instance has 3 more protocols and AF_MAX changed. However it is C #define, not even enum.

  5. krwq commented on Apr 23, 2019

    @krwq
    Member

    Adding CAN (Controller Area Network) to the list per offline conversation with @wfurt - this will be really useful in IoT scenarios.

    This should be very simple additions but would allow us to utilize Socket for CAN bus scenarios without repeating sockets code and would also close couple of networking issues.

    cc: @karelz for bar check for 3.0 (would be useful if we have shipped these enum values earlier so that we could utilize this in IoT in the next release without targeting preview bits)

  6. karelz commented on Apr 24, 2019

    @karelz
    Member

    @wfurt can you please update the top post with proper API proposal form? Something that is clear to anyone not familiar with the space (e.g. me ;)).

  7. krwq commented on Apr 24, 2019

    @krwq
    Member

    I've updated the diff to be clearer

  8. changed the title [-]add Netlink and Packet to AddressFamily and ProtocolFamily enum[/-] [+]add Netlink, Packet and Can to AddressFamily and ProtocolFamily enum[/+] on Apr 25, 2019
  9. terrajobst commented on Apr 30, 2019

    @terrajobst
    Contributor

    Video

    We should rename Can to ControllerAreaNetwork to avoid confusion with it being a word in English. Packet seems generic, but we can't think of a better, so it's fine.

  10. transferred this issue fromdotnet/corefxon Feb 1, 2020
  11. added this to the 3.0 milestone on Feb 1, 2020
  12. ghost locked as resolved and limited conversation to collaborators on Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions