/cc @mikioh

Ping, @mikioh .

Thank you for your proposal. A few random thoughts.

• Perhaps datalink might be a better package name
  • I'm not keen on providing Ethernet marshaler/unmarshaler
• It's okay that this package focuses on a bit slow BPF/LSF and AF_PACKET socket IO
  • Having a separate package that implements Netmap/DPDK-like faster stuff sounds reasonable
• s/Conn/PacketConn/
• It's fine to have an internal kqueue/epoll code fragments
• Probably we need a type that can be used to configure BPF/LSF files and AF_PACKET sockets; maybe 'type Listener struct { }`?

A simple question: What's the reason why we need to provide RawConn on Linux?

• Perhaps datalink might be a better package name
  • I'm not keen on providing Ethernet marshaler/unmarshaler

I'd be okay with making this package called datalink, but since I assume most folks would use it for ethernet sockets anyway, I figured I would go for the more common use case. If this package were to be a raw datalink package, should another package be created to leverage it with ethernet sockets (x/net/ethernet or maybe even x/net/datalink/ethernet)?

• It's okay that this package focuses on a bit slow BPF/LSF and AF_PACKET socket IO
  • Having a separate package that implements Netmap/DPDK-like faster stuff sounds reasonable

I'm not familiar with Netmap or DPDK, but perhaps they could be cleanly integrated into this package at some point too.

• Probably we need a type that can be used to configure BPF/LSF files and AF_PACKET sockets; maybe 'type Listener struct { }`?

Sure, but what type of options would need to be configured? Would this be things like the ability to set the socket to nonblocking, or change the direction of traffic to capture using BPF?

A simple question: What's the reason why we need to provide RawConn on Linux?

Maybe we don't. My intention for the RawConn type was to enable writing arbitrary ethernet frames, but perhaps it isn't needed after all. If this package only focuses on "datalink" sockets, then this functionality is totally unneeded.

I think that providing separated datalink IO and datalink wire-format/coding packages makes sense. Because the former needs to work on abstraction of various kernel system calls and data types, and the latter should take a burden of various wire-formats/codings come from IEEE wildcats. For example,

package datalink

type PacketConn struct { /* TBD */ } // implements net.PacketConn interface and a few fancy datalink IO specific methods
type Listener struct {} // or Datalink or Config or something else
func (ln Listener) Listen(ifi *net.Inteface) (PacketConn, error)

--

package ether // or ethernet

type Frame interface { Tag; Stack }
type Tag interface { Len() int; Marshal() ([]byte, error) } 
type Stack interface { Lower() Tag; Upper() Tag }

type Dot3 struct {}
  :
type Dot1ad struct {}

If this package were to be a raw datalink package, should another package be created to leverage it with ethernet sockets (x/net/ethernet or maybe even x/net/datalink/ethernet)?

For the package that provides Ethernet encoding/decoding functionality, all of us know a variety of MAC/LLC sublayers from DIX/dot3 through dot22, and dot1 higher layers including MAC bridging through congestion notification. Ah, I have no strong opinion on it. Probably we can use github.com/google/gopacket package.

Sure, but what type of options would need to be configured?

There are a few options that should be configured before calling bind on AF_PACKET sockets, I guess.

Assigning to @mikioh to make a decision.

A simple question: What's the reason why we need to provide RawConn on Linux?

I just found this proposal because I was searching for a way to read and emit raw ethernet frames in Go. My intended project is a "universal auto-join" tool which is used in security testing settings to join any network, regardless of configuration (presence of DHCP, MAC filtering, etc). I need to have direct access to raw frames for this project to do things like packet sniffing, ARP spoofing, manually speaking DHCP, etc.

@joshlf as an interim solution, you can use my packages:

• https://github.com/mdlayher/raw
• https://github.com/mdlayher/ethernet

@mdlayher Thanks, I will :)

While we're on the subject - if this proposal ends up getting adopted, I'd suggest two additions from your raw package:

• Be able to create a connection which returns frames of any protocol/ethertype
• Be able to listen for ethernet frames not destined to the current host or to the broadcast MAC address (ie, promiscuous mode)

Hey @mikioh :

package datalink

type PacketConn struct { /* TBD */ } // implements net.PacketConn interface and a few fancy datalink IO specific methods
type Listener struct {} // or Datalink or Config or something else
func (ln Listener) Listen(ifi *net.Inteface) (PacketConn, error)

^ I'd be happy to look into implementing your proposed API here for a x/net/datalink. Does that work for you?

Looks like it's up to you to accept the proposal, if I understand the process correctly.

We can leave ethernet and things that run on top of x/net/datalink for later.

func (ln Listener) Listen(ifi *net.Inteface) (PacketConn, error)

Why have a Listener type? Why not just a Listen function at the top level?

Why have a Listener type? Why not just a Listen function at the top level?

The Listener type could hold socket options to be set during the Listen call. For example, Listener could have a Promiscuous bool, where the a call to Listen would only succeed on a successful call to setsockopt(sockfd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, ...) with mr_type=PACKET_MR_PROMISC (for the linux implementation).

@freddierice That's a good point; I suppose if you had a top-level Listen function, it'd still have to create a listening socket under the hood (at least on Unix).

@mdlayher,

Sorry for being late. I'd like to postpone decision making to follow the consensus of #17244. Also we need to work on #15984 first.

On hold for #17244.

At this point in time, I don't think it's necessary for this functionality to live under x/net; especially since it isn't needed in the standard library or similar. I'd be okay with closing this out, unless there are strong objections to doing so.

Punch it, please!