Re: tcp between tap interfaces

[Vikash Badal]

On 11/12/2016 07:54, dkle...@phy.ucsf.edu wrote:

I'm trying to setup a private testing environment using the bhyve
hypervisor and some virtual machines connected with tap interfaces
to a bridge.  My network configuration for this environment looks like
this:

I have a bridge interface with 5 tap interfaces, but no real interface as
this is to be virtual.  The bridge interface has interface: 192.168.1.1
This is the gateway for the VMs.  Each tap interface on the (virtual) bridge 
to each VM is on the 192.168.1.0/24 network.  I nat the private network out 
through a real interface on the host.


I use the pf packet filter and nat is working great, each VM can connect out 
to the world.  The host can connect into each VM through the bridge and icmp 
and udp seem to work great between the VMs on the private network, but tcp 
does not seem to work.


add
skip on bridgeX
to your pf rules

alternatively you can add the filtering rules you want

That is, I cannot ssh between the VMs, but ping works and I've setup a DNS 
server on one of the VMs and that works for resolving the different private VM 
host names and external names. The host can ssh into each VM OK.


I'm totally at a loss where to go with this.

I'm running FreeBSD 10.1 on the host.





___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196361

Alan Somers  changed:

   What|Removed |Added

 CC||asom...@freebsd.org

--- Comment #10 from Alan Somers  ---
jhujhiti it looks good so far.  Do you think you could also add regression
tests to tests/sys/netinet/fibs_test.sh?  You can probably just mirror the
logic in the existing loopback_and_network_routes_on_nondefault_fib,
default_route_with_multiple_fibs_on_same_subnet, same_ip_multiple_ifaces_fib0,
and subnet_route_with_multiple_fibs_on_same_subnet tests.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 196361] Constrain IPv6 routes to each FIB (Consistent with IPv4 route behaviour)

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196361

--- Comment #9 from jhujh...@adjectivism.org ---
Created attachment 178192
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=178192=edit
Respect net.add_addr_allfibs=0 for inet6 (revision 1)

I didn't forget about this! I implemented against 10.3 about a year ago and
finally found the time to port it to HEAD. This patch essentially makes IPv6
respect net.add_addr_allfibs the same way IPv4 does. This is my first patch
against base - any feedback is welcome.

The changes here are mostly straightforward: where we have an ifp, we can use
its FIB, and where we've previously assumed the default FIB, we should consider
that local routes can exist outside of it now. A couple changes are more
noteworthy:

* Default router selection (defrouter_ functions) can select multiple routers,
up to one per FIB. defrouter_select() now takes a FIB argument to simplify the
logic inside the function. It is up to the caller to determine if we should
re-select routers for all FIBs, by making multiple calls, or not.
* In icmp6_reflect(), there may be an edge case where source address selection
fails to use the correct FIB if in6ifa_ifwithaddr() returns NULL. I don't fully
understand the situations in which this can happen (or if it's possible at
all).
* rtinit() didn't use the interface's FIB for both AF_INET as well as AF_INET6
and I don't understand why. For all uses of the function in AF_INET context,
using the interface FIB seems correct to me, but previous in_addprefix() and
rip_ctlinput() seem a little strange.

Here's what this looks like when net.add_addr_allfibs is 0. em0 and epair0b
here are bridged together and there is a router advertising fd00::/64.

em0: flags=8943 metric 0 mtu
1500
options=42098
ether e0:cb:4e:00:5c:99
inet6 fe80::e2cb:4eff:fe00:5c99%em0 prefixlen 64 scopeid 0x1 
inet6 fd00::e2cb:4eff:fe00:5c99 prefixlen 64 autoconf 
nd6 options=23
media: Ethernet autoselect (1000baseT )
status: active
epair0b: flags=8843 metric 0 mtu 1500
options=8
ether 04:ef:30:02:88:af
inet6 fe80::6ef:30ff:fe02:88af%epair0b prefixlen 64 scopeid 0x6 
inet6 fd00::6ef:30ff:fe02:88af prefixlen 64 autoconf 
nd6 options=23
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
fib: 1
groups: epair 

% ndp -na
Neighbor Linklayer Address  Netif ExpireS Flags
fe80::ff:30ff:fe02:80d%epair0b   02:ff:30:02:08:0d epair0b 23h45m16s S R
fd00::6ef:30ff:fe02:88af 04:ef:30:02:88:af epair0b permanent R 
fe80::6ef:30ff:fe02:88af%epair0b 04:ef:30:02:88:af epair0b permanent R 
fe80::ff:30ff:fe02:80d%em0   02:ff:30:02:08:0dem0 23h43m46s S R
fd00::e2cb:4eff:fe00:5c99e0:cb:4e:00:5c:99em0 permanent R 
fe80::e2cb:4eff:fe00:5c99%em0e0:cb:4e:00:5c:99em0 permanent R

% ndp -np 
fd00::/64 if=epair0b
flags=LAO vltime=600, pltime=300, expire=8m8s, ref=1
  advertised by
fe80::ff:30ff:fe02:80d%epair0b (reachable)
fe80::%epair0b/64 if=epair0b
flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0
  No advertising router
fd00::/64 if=em0
flags=LAO vltime=600, pltime=300, expire=8m8s, ref=1
  advertised by
fe80::ff:30ff:fe02:80d%em0 (reachable)
fe80::%em0/64 if=em0
flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0
  No advertising router
fe80::%lo0/64 if=lo0
flags=LAO vltime=infinity, pltime=infinity, expire=Never, ref=0
  No advertising router

% netstat -rnf inet6 -F0
Routing tables

Internet6:
Destination   Gateway   Flags Netif
Expire
::/96 ::1   UGRSlo0
default   fe80::ff:30ff:fe02:80d%em0UG  em0
::1   link#3UH  lo0
:::0.0.0.0/96 ::1   UGRSlo0
fd00::/64 link#1U   em0
fd00::e2cb:4eff:fe00:5c99 link#1UHS lo0
fe80::/10 ::1   UGRSlo0
fe80::%em0/64 link#1U   em0
fe80::e2cb:4eff:fe00:5c99%em0 link#1UHS lo0
fe80::%lo0/64 link#3U   lo0
fe80::1%lo0   link#3UHS lo0
ff02::/16 ::1   UGRSlo0

% netstat -rnf inet6 -F1
Routing tables (fib: 1)

Internet6:
Destination   Gateway   

Re: cxgbe's native netmap support broken since r307394

[Vincenzo Maffione]

Hi Luigi,
  I attached a minimal change containing two fixes:

- change IFNET_WLOCK into IFNET_RLOCK, to fix the cxgbe issue related
to this thread
- use the proper locking functions for the "worker_lock", unrelated
but needed to avoid the O.S. to trap because of a mismatch between
MTX_SPIN and MTX_DEF.

Cheers,
  Vincenzo

2016-12-21 20:30 GMT+01:00 Luigi Rizzo :
> On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione
>  wrote:
>> Hi,
>>   There is no commit related to that in the FreeBSD svn or git.
>>
>> The fix has been published to the github netmap repository here
>> (branch master): https://github.com/luigirizzo/netmap
>>
>> What we should do is to import all the recent updates from the github
>> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me
>> know.
>
> I just checked and the diff between FreeBSD head and netmap head
> in github is almost 3k lines due to a lot of recent refactoring.
> So, if there is an easy way to extract just the locking change that would
> be preferable as an interim solution.
>
> cheers
> luigi
>
>>
>> Cheers,
>>   Vincenzo
>>
>>
>> 2016-12-20 21:45 GMT+01:00 Adrian Chadd :
>>> hi,
>>>
>>> What's the commit? We should get it into -HEAD asap.
>>>
>>>
>>> -adrian
>>>
>>>
>>> On 20 December 2016 at 01:25, Vincenzo Maffione  
>>> wrote:
 Ok, applied to the netmap github repo.
 This fix will be published when Luigi does the next commit on FreeBSD.

 Cheers,
   Vincenzo

 2016-12-19 20:05 GMT+01:00 Navdeep Parhar :
> IFNET_RLOCK will work, thanks.
>
> Navdeep
>
> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione  
> wrote:
>> Hi Navdeep,
>>
>>   Indeed, we have reviewed the code, and we think it is ok to
>> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using
>> IFNET_WLOCK().
>> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue.
>>
>> On FreeBSD, this locking is needed to protect a flag read by 
>> nm_iszombie().
>> However, on Linux the same lock is also needed to protect the call to
>> the nm_hw_register() callback, so we prefer to have an "unified"
>> locking scheme, i.e. always calling nm_hw_register under the lock.
>>
>> Does this make sense to you? Would it be easy for you to make a quick
>> test by replacing IFNET_WLOCK with IFNET_RLOCK?
>>
>> Thanks,
>>   Vincenzo
>>
>> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar :
>>> Luigi, Vincenzo,
>>>
>>> The last major update to netmap (r307394 and followups) broke cxgbe's
>>> native netmap support.  The problem is that netmap_hw_reg now holds an
>>> rw_lock around the driver's netmap_on/off routines.  It has always been
>>> safe for the driver to sleep during these operations but now it panics
>>> instead.
>>>
>>> Why is IFNET_WLOCK needed here?  It seems like a regression to disallow
>>> sleep on the control path.
>>>
>>> Regards,
>>> Navdeep
>>>
>>> begin_synchronized_op with the following non-sleepable locks held:
>>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0x8271d680) locked @
>>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95
>>> stack backtrace:
>>> #0 0x810837a5 at witness_debugger+0xe5
>>> #1 0x81084d88 at witness_warn+0x3b8
>>> #2 0x83ef2bcc at begin_synchronized_op+0x6c
>>> #3 0x83f14beb at cxgbe_netmap_reg+0x5b
>>> #4 0x809846f1 at netmap_hw_reg+0x81
>>> #5 0x809806de at netmap_do_regif+0x19e
>>> #6 0x8098121d at netmap_ioctl+0x7ad
>>> #7 0x8098682f at freebsd_netmap_ioctl+0x5f
>>
>>
>>
>> --
>> Vincenzo Maffione
>> ___
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



 --
 Vincenzo Maffione
 ___
 freebsd-net@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>
>>
>>
>> --
>> Vincenzo Maffione
>
>
>
> --
> -+---
>  Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
>  http://www.iet.unipi.it/~luigi/. Universita` di Pisa
>  TEL  +39-050-2217533   . via Diotisalvi 2
>  Mobile   +39-338-6809875   . 56122 PISA (Italy)
> -+---



-- 
Vincenzo Maffione
diff --git a/sys/dev/netmap/netmap_freebsd.c b/sys/dev/netmap/netmap_freebsd.c
index fd4592b7b5a..515be6648ea 

[Bug 213115] ifconfig ipfw create inside a VNET jail leads to kernel Panic

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213115

Ed Maste  changed:

   What|Removed |Added

 Status|New |Open

--- Comment #3 from Ed Maste  ---
Can you test with 11.0?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: cxgbe's native netmap support broken since r307394

[Luigi Rizzo]

On Wed, Dec 21, 2016 at 11:15 AM, Vincenzo Maffione
 wrote:
> Hi,
>   There is no commit related to that in the FreeBSD svn or git.
>
> The fix has been published to the github netmap repository here
> (branch master): https://github.com/luigirizzo/netmap
>
> What we should do is to import all the recent updates from the github
> into HEAD. I can prepare a patch for HEAD, if you wish. Just let me
> know.

I just checked and the diff between FreeBSD head and netmap head
in github is almost 3k lines due to a lot of recent refactoring.
So, if there is an easy way to extract just the locking change that would
be preferable as an interim solution.

cheers
luigi

>
> Cheers,
>   Vincenzo
>
>
> 2016-12-20 21:45 GMT+01:00 Adrian Chadd :
>> hi,
>>
>> What's the commit? We should get it into -HEAD asap.
>>
>>
>> -adrian
>>
>>
>> On 20 December 2016 at 01:25, Vincenzo Maffione  wrote:
>>> Ok, applied to the netmap github repo.
>>> This fix will be published when Luigi does the next commit on FreeBSD.
>>>
>>> Cheers,
>>>   Vincenzo
>>>
>>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar :
 IFNET_RLOCK will work, thanks.

 Navdeep

 On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione  
 wrote:
> Hi Navdeep,
>
>   Indeed, we have reviewed the code, and we think it is ok to
> implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using
> IFNET_WLOCK().
> Since IFNET_RLOCK() results into sx_slock(), this should fix the issue.
>
> On FreeBSD, this locking is needed to protect a flag read by 
> nm_iszombie().
> However, on Linux the same lock is also needed to protect the call to
> the nm_hw_register() callback, so we prefer to have an "unified"
> locking scheme, i.e. always calling nm_hw_register under the lock.
>
> Does this make sense to you? Would it be easy for you to make a quick
> test by replacing IFNET_WLOCK with IFNET_RLOCK?
>
> Thanks,
>   Vincenzo
>
> 2016-12-17 23:28 GMT+01:00 Navdeep Parhar :
>> Luigi, Vincenzo,
>>
>> The last major update to netmap (r307394 and followups) broke cxgbe's
>> native netmap support.  The problem is that netmap_hw_reg now holds an
>> rw_lock around the driver's netmap_on/off routines.  It has always been
>> safe for the driver to sleep during these operations but now it panics
>> instead.
>>
>> Why is IFNET_WLOCK needed here?  It seems like a regression to disallow
>> sleep on the control path.
>>
>> Regards,
>> Navdeep
>>
>> begin_synchronized_op with the following non-sleepable locks held:
>> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0x8271d680) locked @
>> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95
>> stack backtrace:
>> #0 0x810837a5 at witness_debugger+0xe5
>> #1 0x81084d88 at witness_warn+0x3b8
>> #2 0x83ef2bcc at begin_synchronized_op+0x6c
>> #3 0x83f14beb at cxgbe_netmap_reg+0x5b
>> #4 0x809846f1 at netmap_hw_reg+0x81
>> #5 0x809806de at netmap_do_regif+0x19e
>> #6 0x8098121d at netmap_ioctl+0x7ad
>> #7 0x8098682f at freebsd_netmap_ioctl+0x5f
>
>
>
> --
> Vincenzo Maffione
> ___
> freebsd-net@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>>
>>>
>>>
>>> --
>>> Vincenzo Maffione
>>> ___
>>> freebsd-net@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
>
>
> --
> Vincenzo Maffione



-- 
-+---
 Prof. Luigi RIZZO, ri...@iet.unipi.it  . Dip. di Ing. dell'Informazione
 http://www.iet.unipi.it/~luigi/. Universita` di Pisa
 TEL  +39-050-2217533   . via Diotisalvi 2
 Mobile   +39-338-6809875   . 56122 PISA (Italy)
-+---
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: cxgbe's native netmap support broken since r307394

[Vincenzo Maffione]

Hi,
  There is no commit related to that in the FreeBSD svn or git.

The fix has been published to the github netmap repository here
(branch master): https://github.com/luigirizzo/netmap

What we should do is to import all the recent updates from the github
into HEAD. I can prepare a patch for HEAD, if you wish. Just let me
know.

Cheers,
  Vincenzo


2016-12-20 21:45 GMT+01:00 Adrian Chadd :
> hi,
>
> What's the commit? We should get it into -HEAD asap.
>
>
> -adrian
>
>
> On 20 December 2016 at 01:25, Vincenzo Maffione  wrote:
>> Ok, applied to the netmap github repo.
>> This fix will be published when Luigi does the next commit on FreeBSD.
>>
>> Cheers,
>>   Vincenzo
>>
>> 2016-12-19 20:05 GMT+01:00 Navdeep Parhar :
>>> IFNET_RLOCK will work, thanks.
>>>
>>> Navdeep
>>>
>>> On Mon, Dec 19, 2016 at 3:21 AM, Vincenzo Maffione  
>>> wrote:
 Hi Navdeep,

   Indeed, we have reviewed the code, and we think it is ok to
 implement nm_os_ifnet_lock() with IFNET_RLOCK(), instead of using
 IFNET_WLOCK().
 Since IFNET_RLOCK() results into sx_slock(), this should fix the issue.

 On FreeBSD, this locking is needed to protect a flag read by nm_iszombie().
 However, on Linux the same lock is also needed to protect the call to
 the nm_hw_register() callback, so we prefer to have an "unified"
 locking scheme, i.e. always calling nm_hw_register under the lock.

 Does this make sense to you? Would it be easy for you to make a quick
 test by replacing IFNET_WLOCK with IFNET_RLOCK?

 Thanks,
   Vincenzo

 2016-12-17 23:28 GMT+01:00 Navdeep Parhar :
> Luigi, Vincenzo,
>
> The last major update to netmap (r307394 and followups) broke cxgbe's
> native netmap support.  The problem is that netmap_hw_reg now holds an
> rw_lock around the driver's netmap_on/off routines.  It has always been
> safe for the driver to sleep during these operations but now it panics
> instead.
>
> Why is IFNET_WLOCK needed here?  It seems like a regression to disallow
> sleep on the control path.
>
> Regards,
> Navdeep
>
> begin_synchronized_op with the following non-sleepable locks held:
> exclusive rw ifnet_rw (ifnet_rw) r = 0 (0x8271d680) locked @
> /root/ws/head/sys/dev/netmap/netmap_freebsd.c:95
> stack backtrace:
> #0 0x810837a5 at witness_debugger+0xe5
> #1 0x81084d88 at witness_warn+0x3b8
> #2 0x83ef2bcc at begin_synchronized_op+0x6c
> #3 0x83f14beb at cxgbe_netmap_reg+0x5b
> #4 0x809846f1 at netmap_hw_reg+0x81
> #5 0x809806de at netmap_do_regif+0x19e
> #6 0x8098121d at netmap_ioctl+0x7ad
> #7 0x8098682f at freebsd_netmap_ioctl+0x5f



 --
 Vincenzo Maffione
 ___
 freebsd-net@freebsd.org mailing list
 https://lists.freebsd.org/mailman/listinfo/freebsd-net
 To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>>
>>
>>
>> --
>> Vincenzo Maffione
>> ___
>> freebsd-net@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-net
>> To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"



-- 
Vincenzo Maffione
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

qualified vale(4) uplink interface clones

[Harry Schmalzbauer]

 Dear netmap gurus,

I'm getting different crashes if using vale(4) as a drop in replacement
for if_bridge(4).

Before collecting dumps I'd like to know if the setup, which I need to
keep (including a MTU of 9000 bytes), is meant to be supported at all
with netmap.

Usually I have two GbE ports forming one lagg(4) interface, like this:
lagg0mplx: flags=8943
metric 0 mtu 9000
…
laggproto lacp lagghash l2,l3,l4
laggport: igb0 flags=1c
laggport: igb1 flags=1c

Then I have lots of cloned VLAN-specific interfaces (utilizing Kawela's
hardware VLAN filter):
vldmz: flags=8942 metric 0
mtu 9000
…
vlan: 1 vlanpcp: 0 parent interface: lagg0mplx
groups: vlan
vlvnl: flags=8942 metric 0
mtu 9000
…
vlan: 2 vlanpcp: 0 parent interface: lagg0mplx
groups: vlan
vlegn: flags=8943 metric
0 mtu 9000
…
vlan: 3 vlanpcp: 0 parent interface: lagg0mplx
groups: vlan

These are then uplink interfaces for different if_bridge(4)es.

Now I can use 'vale-ctl -h vale0:vlegn' , but as soon as there's any
traffic over lagg0mplx (even not related to the vlegn cloned interface),
the machine crashes.

Is somebody interested in dumps?
Or is this a too weird setup?

Thanks,

-harry
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 212283] oversized IP datagrams on raw socket with IP_RAWOUTPUT hang network interface drivers

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212283

--- Comment #19 from Mathieu Arnold  ---
Still a problem with 11.0-RELEASE-p5.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"