Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tcpreplay not working on MacOS Mojave 10.14.1 - /dev/bpfX limit hard coded to 10 #550

Closed
jestacio-circle opened this issue Mar 18, 2019 · 4 comments
Assignees
Labels
Projects

Comments

@jestacio-circle
Copy link

I am running into an issue where tcpreplay fails with the error "Fatal Error: failed to open device en0: Unable to open /dev/bpfX: Resource busy" when trying to replay a pcap file through my wifi interface (en0)

Looking at https://github.com/appneta/tcpreplay/blob/master/src/common/sendpacket.c#L1056

the maximum bpf device files tried is 10 which is hardcoded as a magic number. Increasing this by doing something like #define BPFDEV_LIMIT 10 and replacing the loop condition and array declaration seems to resolve the issue. An even better approach may be to parameterize that value by defining a new flag.

I am running MacOS Mojave 10.14.1 on a Macbook Pro 15" 2016

The brew installed version of tcpreplay has the same issue.

@fklassen fklassen added this to To do in 4.3.3 via automation Mar 19, 2019
@fklassen fklassen added the bug label Mar 19, 2019
@fklassen
Copy link
Member

Do you have permissions set up properly for /dev/bpf*? If not, it means that you don't have proper libpcap access. All programs that require libpcap access have had permissions issues with latest version of macOS. There are a few fixes available.

  • set permissions manually, e.g. (substitute 'fklassen' with your user ID):
    sudo chown fklassen:admin /dev/bp*
  • set up libpcap ChmodBPF
  • install Wireshark which will install Wireshark's ChmodBPF

@jestacio-circle
Copy link
Author

I believe my permissions were set up correctly. /dev/bpf* are owned by root:access_bpf by default and my user is part of the access_bpf group which has rw access.

On second look I misunderstood the code-the only change needed was to change the string buffer to 12 to fit something like "/dev/bpf255" and let the loop go up to 255.

Previously it was failing because bpf0-bpf9 were already in use. With those changes tcpreplay was able to open /dev/bpf17 and things started working (I ran make test and the smallFlows.pcap sample file)

@fklassen
Copy link
Member

Definite bug. Scheduled for 4.3.3.

@fklassen fklassen self-assigned this Mar 19, 2019
@fklassen fklassen moved this from To do to In progress in 4.3.3 Jun 7, 2020
fklassen added a commit that referenced this issue Jun 7, 2020
Increase number of interfaces from 10 to 512. Now test
/dev/bpf0 to /dev/bpf511 to find and available BPF devices.

This fixes issues introduced in macOS Mojave (10.14).
fklassen added a commit that referenced this issue Jun 7, 2020
Increase number of interfaces from 10 to 512. Now test
/dev/bpf0 to /dev/bpf511 to find and available BPF devices.

This fixes issues introduced in macOS Mojave (10.14).
fklassen added a commit that referenced this issue Jun 7, 2020
@fklassen
Copy link
Member

fklassen commented Jun 7, 2020

Fixed in PR #607

@fklassen fklassen closed this as completed Jun 7, 2020
4.3.3 automation moved this from In progress to Done Jun 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
No open projects
4.3.3
  
Done
Development

No branches or pull requests

2 participants