Bug 239371
| Summary: | epair(4) doesn't expose network traffic to bpf(4), ex. wireshark doesn't see it | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Yuri Victorovich <yuri> |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Only Me | CC: | kp |
| Priority: | --- | ||
| Version: | CURRENT | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Yuri Victorovich
2019-07-22 05:23:19 UTC
Is this amd64 or i386? (In reply to Kristof Provost from comment #1) amd64 lo interface suffers from the same problem when it is used in a similar way. Jail sends packets into lo1, because it is the only interface with the IP address in a jail, but wireshark never sees any packets on lo1. I asked because there seem to be issues with bpf on i386. Those cause the pf tests to fail there. Are these old-style (i.e. non-vnet) jails? In that case I wonder if you're not looking on the wrong interface. Looped back packets always turn up on lo0, even if from looking at the IP addresses you'd expect to see them on the interface. (Because there's a more specific route for the IP that tells it to use lo0.) (In reply to Kristof Provost from comment #4) Yes, it's a non-vnet jail. I'm looking at the interface that has the internal IP address of jail. Yes, that sounds like the expected behaviour. Take a look at `netstat -r`. You'll almost certainly see something like '10.0.0.2 link#1 UHS lo0' (In reply to Kristof Provost from comment #6) Actually, it is on lo1: $ netstat -r Routing tables Internet: Destination Gateway Flags Netif Expire 10.0.0.2 link#5 UH lo1 But watching lo1 with wireshark shows nothing even when the connection to the host system succeeds (to 192.168.5.5). Is this expected? (In reply to Yuri Victorovich from comment #7) I believe so, but I'm not at home in the details of the loopback interface. Do you see your packets on lo0? (In reply to Kristof Provost from comment #8) The routing table only has 10.0.0.2 on lo1. When I send something to the host's IP 192.168.5.5 (which is in a different net), it indeed shows on lo0. But when I send something to some other IP 96.47.72.132, it doesn't show on lo0 as well. This behavior is confusing: 1. Why lo0 gets involved when it isn't used from jail? 2. Why packets to host's IP appear on lo0 and the packets to the remote IP don't even though both of the IP addresses are equally unroutable based on the jail's routing table? I guess I need to change to vnet-based jails. (In reply to Yuri Victorovich from comment #9) lo0 is used for loopback traffic, and that includes connections from a public IP of your machine to a public IP from your machine. So, if your machine has re0, with 10.0.0.1/24 assigned to it, connecting to 10.0.0.1:1234 will pass over lo0, even though you might expect to see that traffic on re0. The same thing applies when that connection is made from a (non-vnet) jail to the host machine. It still applies if you have IP addresses in different nets. Anything to yourself will pass over lo0. If you connect to a different (i.e. non-local) IP, you will see the traffic on re0. That's all expected behaviour. Thank you, Kristof, for your explanation. |