mdlayher/arp

Package arp implements the ARP protocol, as described in RFC 826. MIT Licensed.

arp's Issues

I need example to learn your code, Have you time? please, i need it~

email : [email protected]

Indirect dependency library `golang.org/x/textv0.3.0` has a security issue

Indirect dependency golang.org/x/textv0.3.0 has a security issue, please found this dependency library at: https://github.com/mdlayher/arp/blob/master/go.sum#L13
CVE link: https://nvd.nist.gov/vuln/detail/CVE-2020-14040
Could you consider to upgrade this library to version v0.3.7?

Not implemented on Windows

listen packet ab:cd:ef:5d:0b:11: packet: not implemented on windows

Linux (docker and raspberry pi): Resolve() not returning

I have the following code:

func sendArp(ip net.IP, arpClient *arp.Client, config chirpdconfig) (net.HardwareAddr, error) {

	l.Println("sendArp: in sendarp for ", ip)
	timeout := time.Now().Add(config.arpResponseTimeout)
	l.Println("sendArp: timeout = ", timeout)
	err := arpClient.SetDeadline(timeout)
	if  err != nil {
		panic(fmt.Sprintln("sendArp: cannot set deadline: ", err))
	}

	l.Println("sendArp: post SetDeadline")
	macaddr, err := arpClient.Resolve(ip)
	l.Println("sendArp: post Resolve")
	if err != nil {
		l.Println("sendArp: err = ", err)
	}
	l.Println("macaddr = ", macaddr)
	return macaddr, err
}

I get the following output:

2017/10/12 sendArp: in sendarp for  10.0.1.222
2017/10/12 sendArp: timeout =  2017-10-12 21:19:36.879028782 -0700 PDT m=+7.533864643
2017/10/12 sendArp: post SetDeadline

and then things just hang.

I understand from #12 that SetDeadline doesn't work on MacOS, so that might explain the linux/docker failure, but I tried this on a raspberry pi running raspbian and it's not working either. What am I doing wrong?

raw.ProtocolARP no longer exists

Due to upstream library commits mdlayher/raw@9c904de and mdlayher/raw@8bb4b2c, raw.ProtocolARP no longer exist. This is causing builds to fail.

I've created PR #14 to move that to this library, as they're no longer constants which can be used in raw.

Support infiniband device

Trying to use a downsteam package that references this repo. I ran into an issue using IP over Infiniband device type in a mix ethernet/infiniband environment.

 ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 4092 qdisc mq state UP mode DEFAULT group default qlen 256
    link/infiniband 20:00:00:67:fe:80:00:00:00:00:00:00:e0:07:1b:ff:ff:7d:e2:e8 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff

Infiniband devices use 12 digit mac addresses and this probably unnecessary sanity check in packet.go causes error.
Lines 90-92:

	if len(srcHW) != len(dstHW) {
		return nil, ErrInvalidHardwareAddr
	}

It assumes all MAC addresses are 6 character.
Removing the check and recompiling allowed downstream Metallb to work on my IP over Infiniband interconnects.

WriteTo doesn't respect destination hardware address

I need to send broadcast ARP requests to devices that only respond when the ARP target MAC address is set to 00:00:00:00:00:00. The Ethernet frame destination MAC address still needs to be FF:FF:FF:FF:FF:FF, though. I would have expected to be able to accomplish this by using distinct MAC addresses when calling NewPacket and when calling WriteTo. However, it turns out that WriteTo reuses the packet-internal target address (p.TargetHardwareAddr) when setting the Ethernet destination address, rather than using the addr parameter.

arp/client.go

Lines 151 to 162 in 98a83c8

	func (c *Client) WriteTo(p *Packet, addr net.HardwareAddr) error {
	pb, err := p.MarshalBinary()
	if err != nil {
	return err
	}
	f := &ethernet.Frame{
	Destination: p.TargetHardwareAddr,
	Source: p.SenderHardwareAddr,
	EtherType: ethernet.EtherTypeARP,
	Payload: pb,
	}

Is there a reason for this, or is it a bug?

Suggestion: Continuous Fuzzing

Hi, I'm Yevgeny Pats Founder of Fuzzit - Continuous fuzzing as a service platform.

I saw that you implemented Fuzz targets but they are currently not running as part of the CI.

We have a free plan for OSS and I would be happy to contribute a PR if that's interesting.
The PR will include the following

• Continuous Fuzzing of master branch which will generate new corpus and look for new crashes
• Regression on every PR that will run the fuzzers through all the generated corpus and fixed crashes from previous step. This will prevent new or old bugs from crippling into master.

You can see our basic example here and you can see an example of "in the wild" integration here.

Let me know if this is something worth working on.

Cheers,
Yevgeny

go generate produces error

Hi thanks for this package.

I was looking through the source and seeing that string.go and packet.go are generated (this comes from the go std lib I assume) as such 'go generate' does not work:

packet.go:26: running "stringer": exec: "stringer": executable file not found in $PATH

string.go also has some lint issues; I don't know if you want to keep this "this is generated code" in these files or clean them up?

Suggestion: provide a New...() for mock/fake client

Hey @mdlayher, thanks for this package and the others you've provided. They've been very helpful.

I want to be able to unit test code that is using arp.Client and see the packets that I'm sending by providing a mock PacketConn. The code in client_test.go is pretty close to what I want to do, but users of this package cannot set the PacketConn on the client without using New(), which requires a net.Interface. I believe creating a net.Interface for my tests would require NET_ADMIN capabilities.

I could mock out the Client as an interface, but then I cannot see the packets that go on the wire.

Is it possible that another New...() function could be created that allows you to set the net.IP, net.HardwareAddr and net.PacketConn directly for use in testing?

This might require adjustments to the Client struct. I believe you only use the net.Interface to get Addrs() during initialization and for getting the HardwareAddr during various functions.

My suggestion would look something like this and I can submit a PR if you're willing to accept it :) I'm iffy on the name, love to hear your suggestions if you don't like it.

type Client struct {
        addr net.HardwareAddr
	ip  net.IP
	p   net.PacketConn
}

func NewForTesting(addr net.HardwareAddr, ip net.IP, p net.PacketConn) *Client { ... }

No matching arp response on MacOS

Sorry, issue was for a different project :)

How is SetDeadline supposed to work?

My code:

	arpInterface, err := net.InterfaceByName("en0"); if err != nil {
		panic("Cannot open en0")
	}
	arpClient, err := arp.Dial(arpInterface); if err != nil {
		panic("sendArp: Cannot bind client to interface")
	}

	fmt.Println("ip = ", ip)
	timeout := time.Now().Add(3*time.Second)
	fmt.Println("timeout set to ", timeout )
	arpClient.SetDeadline(timeout)
	macaddr, err := arpClient.Resolve(ip); if err != nil {
		fmt.Println("Request error is ", err)
	} else {
		fmt.Println("Resolved ", ip, " to ", macaddr)
	}

When I try to resolve a nonexistent IP, arpClient.Resolve() hangs indefinitely. I'd like to specify a timeout, and I thought that SetDeadline or SetReadDeadline would work. Obviously I'm doing something wrong. Advice appreciated.

Windows Support?

Currently I need to listen for arp requests sent, and the raw depend fails to work on windows.

Possible to implement?

Operation not permitted

Hi, I'm trying to use this library for sending some ARP requests, and I get an

operation not permitted

error when I try to create a client. I'm getting the interfacing, passing it's pointer to the NewClient method. like so:

ifaces, _ := net.Interfaces()
// The third for me is the relevant one.
client, err := arp.NewClient(&ifaces[2])
if err != nil {
    fmt.Println(err)
}

target := net.ParseIP("10.0.18.70")
err = client.Request(target)
if err != nil {
    fmt.Println(err)
}

So I then get a nil error when I call client.Request, because the original client is not permitted. Is this the correct way to proceed? Should I be using sudo? When I do that it complains that the GOPATH isn't set, and things get tricky.