From a conversation in https://github.com/mdlayher/raw/pull/40.

This commit broke router7’s dhcp4 client: rtr7/router7#25

After a git revert f434146a17ecdf185e28b9ae8457ef45ee82077a, everything works as expected. At HEAD, dhcp4 gets one reply, then fails to ever send packets on the network interface, resulting in the > DHCP lease expiring.

Haven’t investigated it any further, but perhaps this is sufficient to spot the mistake?

/cc @hugelgupf @stapelberg

Syscall BIOCSSEESENT as used in setBPFDirection is deprecated on OpenBSD. Some quick checking in CVS makes me wonder if it was ever supported. BIOCSDIRFILT however does work as intended.

Should the flag be 1 instead of 0? 1 will allow for MAC spoofing on the wire which i believe is what the comment is suggesting.

Line 202 // Do not automatically complete source address in ethernet headers if err := syscall.SetBpfHeadercmpl(fd, 0); err != nil { return 0, err }

0 flag sets automatic header completion per BPF man page (read interface address will be written in place of frame provided to BPF for outgoing transaction) BIOCSHDRCMPLT BIOCGHDRCMPLT (u_int) Set or get the status of the ``header complete'' flag. Set to zero if the link level source address should be filled in automatically by the interface output routine. Set to one if the link level source address will be written, as provided, to the wire. This flag is initialized to zero by default.

$ go  get github.com/mdlayher/arp
# github.com/mdlayher/raw
../../_go/src/github.com/mdlayher/raw/raw_linux.go:86:14: f.SyscallConn undefined (type *os.File has no field or method SyscallConn)

I get this because I'm trying to build vip-manager, which apparently depends on github.com/mdlayher/arp which apparently depends on github.com/mdlayher/raw.

Not being experienced with building go stuff I do not have a clue on how to fix this. The only thing I can google up is https://github.com/bettercap/bettercap/issues/468 which I'm unable to translate into a fix for not being able to go get github.com/mdlayher/raw.

Any help is very appreciated.

Is it possible to send and receive beacon frames with this package? I'm hoping to implement very simple network-less wifi connectivity. Aiming to send and receive a custom frame containing a small amount of numerical information.

On macOS, I can monitor beacon frames with:

tcpdump "type mgt subtype beacon" -I -e -i en0

hello, I listen packet use: conn, err := raw.ListenPacket(&ifi, uint16(lldp.EtherType), &raw.Config{}) when read package : n, addr, err := conn.ReadFrom(b)

the lldp package can not be captured, but when change IPv4 and ARP, the packages can be captured.

Any suggestions?

root@31e07f454ad2:~# go get github.com/mdlayher/raw
# github.com/mdlayher/raw
/go/src/github.com/mdlayher/raw/raw_linux.go:317: undefined: unix.Errno
/go/src/github.com/mdlayher/raw/raw_linux.go:330: undefined: unix.Errno
root@31e07f454ad2:/go/src/github.com/mdlayher/raw# uname -a
Linux 31e07f454ad2 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 UTC 2018 x86_64 GNU/Linux
root@31e07f454ad2:/go/src/github.com/mdlayher/raw# cat /etc/*elease
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

While getting the library:

go get github.com/mdlayher/raw

github.com\mdlayher\raw\raw.go:136:37: cannot use *cfg (type Config) as type *Config in argument to listenPacket

Add interface promisc to raw_bsd.go and raw_linux.go, include raw_others.go with 'not implemented' error. Expose SetPromisc(m int) method from raw.go, SetPromisc(m int) accepts integer similar to reference C implementation in BSD however it expects 1 for enable and 0 for disable, other values are not trapped.

BSD implementation uses syscall.SetBpfPromisc, Linux implementation uses setsockopt.

@mdlayher hello expert, I have an question that how to capture lldp packets without promiscuous mode,I want use your code handle this, please help me ,thanks!

This PR removes the strict length checking of the hardware address length, this is necessary to use other link types (for example, a tun0 interface from OpenVPN).

func htons should take host endianness into account:

func htons(i uint16) uint16 {
	return (i<<8)&0xff00 | i>>8
}

Depending on host endianness this should be a no-op or not.

The issue was spotted when trying to use this lib on a device with a different endianness...

Hello, I encountered a problem during use in Macos, As follows:

panic: runtime error: slice bounds out of range [:4098] with capacity 4096

goroutine 886516 [running]:
github.com/mdlayher/raw.(*packetConn).ReadFrom(0xc0061cd6e0, {0xc005833280, 0x80, 0x80})
    /github.com/mdlayher/raw/raw_bsd.go:163 +0x9e5
github.com/mdlayher/raw.(*Conn).ReadFrom(0xc00462e278, {0xc005833280, 0x80, 0x80})
    /github.com/mdlayher/raw/raw.go:47 +0x99

I searched the source code and found the problem here on raw_bsd.go:

func (p *packetConn) ReadFrom(b []byte) (int, net.Addr, error) {
 ......
 
	  // Skip past BPF header to retrieve ethernet frame
	  out := copy(b, buf[bpfl:bpfl+n])
 ......
 }

I carefully sorted out your logic. I think there's a small problem. Should it be:

  func (p *packetConn) ReadFrom(b []byte) (int, net.Addr, error) {
  .......
  
	  // Skip past BPF header to retrieve ethernet frame
	  out := copy(b, buf[bpfl:n])
  ......
  }

I don't know if the understanding is correct. Please correct it. Thank you!

Specifying a socketaddr is unnecessary when writing packets to a raw socket. According to packet(7) the supplied buffer should contain a physical-layer header. The sockaddr_ll is used for SOCK_DGRAM.

SOCK_RAW packets are passed to and from the device driver without any changes in the packet data. When receiving a packet, the address is still parsed and passed in a standard sockaddr_ll address structure. When transmitting a packet, the user-supplied buffer should contain the physical-layer header. That packet is then queued unmodified to the network driver of the interface defined by the destination address.

SOCK_DGRAM operates on a slightly higher level. The physical header is removed before the packet is passed to the user. Packets sent through a SOCK_DGRAM packet socket get a suitable physical-layer header based on the information in the sockaddr_ll destination address before they are queued.

http://man7.org/linux/man-pages/man7/packet.7.html

This allows the interface to subscribe to a link-layer multicast address.

I've written a small program to proxy eap packets from one interface to another. EAP (802.1x Auth) packets are sent to a link-layer multicast address. The Interface must either subscribe to the Multicast Address or be put in promisc mode. https://github.com/pyther/goeap_proxy/

I wanted to put this out there as a starting point for discussion. Let me know what you think. Not sure if this is the best way to accomplish this? Maybe exposing SetSockoptPacketMreq to raw.conn is some capacity would allow for more flexibility?