Running into an mbuf leak with bridging and tap

[Maksim Yevmenkin]

Robert,

> I'm running an ethernet over TCP bridge using a combination of the native
> ethernet bridge support and the tap driver.  Basically, a daemon sits on
> /dev/tapX and bridges ethernet frames using a small header over a TCP
> connection.  The bridge support is loaded as a kld, as is the tap support,
> and both modules remain resident from then on.  After a couple of days,
> perhaps triggered by the connection going up and down and leaving bridging
> turned on even when nothing is listening on the tap device, the endpoints
> will run out of mbufs:
> 
>   26707 mbufs in use
>   25453/25600 mbuf clusters in use (current/max)
>   0/3/6656 sfbufs in use (current/peak/max)
>   57582 KBytes allocated to network
>   0 requests for sfbufs denied
>   0 requests for sfbufs delayed
>   0 requests for I/O initiated by sendfile
>   0 calls to protocol drain routines
> 
> Under normal circumstances (i.e., without tap and ethernet bridging on),
> this doesn't happen, suggesting that maybe there's a leak in the bridging
> code or tap code.  I've now seen this with three boxes, a blend of UP and
> SMP.  I haven't yet had a chance to sit down with a debugging kernel.  Has
> anyone else seen anything like this?


could you please try to use ng_bridge(4)? example scripts are in 
/usr/share/examples/netgraph. this could tell me if tap(4) is at fault.


max