date:20150424

[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

2015-04-24 Thread bugzilla-noreply

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

--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:

Author: ngie
Date: Sat Apr 25 05:32:03 UTC 2015
New revision: 281974
URL: https://svnweb.freebsd.org/changeset/base/281974

Log:
  MFC
r261550,r281354,r281355,r281356,r281358,r281359,r281360,r281361,r281362,r281391,r281392,r281393,r281394,r281395,r281397,r281398,r281399,r281400,r281401,r281402,r281403,r281404,r281407,r281408,r281409,r281410,r281411:

  r261550 (by glebius):

  Add test case for kern/181741. Right now test fails.

  PR:181741
  Sponsored by:Nginx, Inc.

  r281354:

  Fix warnings, fix a typo in a testcase description, bump WARNS to 3

  - Remove argc/argv (-Wunused)
  - Cast len in comparison to size_t (-Wsign-compare)

  Sponsored by: EMC / Isilon Storage Division

  r281355:

  Fix -Wunused warnings, bump WARNS to 6

  The testcase fails today on subtest # 9

  The output is still broken if prove -rv is run and the testcase aborts
  prematurely (the testcase doesn't really conform to TAP protocol properly,
  except when it completes fully)

  Sponsored by: EMC / Isilon Storage Division

  r281356:

  Fix -Wunused warnings, bump WARNS to 6

  The output is still broken if prove -rv is run and the testcase aborts
  prematurely with fail_assertion (the testcase doesn't really conform to TAP
  protocol properly, except when it completes fully)

  Sponsored by: EMC / Isilon Storage Division

  r281358:

  - Parameterize out the number of accept/connect attempts
  - Randomize the bind port to allow 2+ consecutive calls in < 10 minutes, and
to also not fail if (for instance) there's a server already listening on
port
8080
  - Don't leak the listening socket / fds into the child process
  - Fix warnings:
  -- Remove argc/argv (-Wunused)
  -- Mark sig __unused (-Wunused)
  -- Mark quit static (-Wmissing-variable-declarations)

  Sponsored by: EMC / Isilon Storage Division

  r281359:

  Remove argc/argv (-Wunused)

  Sponsored by: EMC / Isilon Storage Division

  r281360:

  Fix warnings

  - Remove argc/argv (-Wunused)
  - Mark some parameters to socket_listen_update __unused (-Wunused)

  Sponsored by: EMC / Isilon Storage Division

  r281361:

  Remove argc/argv (-Wunused)

  Sponsored by: EMC / Isilon Storage Division

  r281362:

  Use _exit, not exit in forked process

  Sponsored by: EMC / Isilon Storage Division

  r281391:

  - Use static buffers for temporary file paths instead of strdup of constant
strings
  - Don't use /tmp because it's outside ATF's prescribed sandbox
  - Use mkstemp instead of mktemp to eliminate warning

  Sponsored by: EMC / Isilon Storage Division

  r281392:

  - Garbage collect argc/argv (-Wunused)
  - Bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281393:

  Fix warnings and bump WARNS to 6
  - Garbage collect argc/argv (-Wunused)
  - sleep(3) will always return an unsigned int; don't check for return codes
<0
(-Wsign-compare)

  Sponsored by: EMC / Isilon Storage Division

  r281394:

  - Don't use /tmp because it's outside ATF's prescribed sandbox
  - Replace a hardcoded PATH_MAX value with sizeof(path)
  - Use path like an array, not a pointer, and always try to unlink it in
cleanup

  Sponsored by: EMC / Isilon Storage Division

  r281395:

  Fix a -Wuninitialized warning by setting the socket to -1 and bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281397:

  Mark signum unused in signal_handler; bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281398:

  Garbage collect argc/argv and bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281399:

  Fix warnings and bump WARNS to 6
  - Staticize variables as needed
  - Garbage collect argc/argv
  - Fix -Wsign-compare warnings by casting small sizeof to (int)

  Sponsored by: EMC / Isilon Storage Division

  r281400:

  - Garbage collect argc/argv; bump WARNS to 6
  - Make the socket path random and move it out of /tmp as that's outside ATF's
prescribed path

  Sponsored by: EMC / Isilon Storage Division

  r281401:

  - Garbage collect argc/argv
  - Use random paths instead of one in /tmp

  Sponsored by: EMC / Isilon Storage Division

  r281402:

  Garbage collect argc/argv and bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281403:

  Garbage collect argc/argv and bump WARNS to 6

  Sponsored by: EMC / Isilon Storage Division

  r281404:

  Generate temporary files with mkstemp instead of mktemp

  Sponsored by: EMC / Isilon Storage Division

  r281407:

  Fix the knob twiddling to work properly per src.opts.mk

  Sponsored by: EMC / Isilon Storage Division

  r281408:

  - Remove the .t wrapper and put the "magic" of determining the number of
testcases into the .c file
  - Require root for now because it fails with SOCK_RAW without root privileges
  - Increment the test count properly on socket create failure

  Sponsored by: EMC / Isilon Storage Div

[Bug 194515] Fatal Trap 12 Kernel with vimage

2015-04-24 Thread bugzilla-noreply

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

Kubilay Kocak  changed:

   What|Removed |Added

 Status|New |Open
  Flags||mfc-stable10?
   Keywords||needs-qa
   Severity|Affects Only Me |Affects Many People

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

Re: net.inet.ip.forwarding impact on throughput

2015-04-24 Thread Scott Larson

 Thanks Navdeep, I figured there had to be more going on than just
allowing packets across interfaces. With forwarding automatically disabling
TSO/LRO that would entirely explain why my bandwidth throughput tests drop
off significantly.


*[image: userimage]Scott Larson[image: los angeles]
Lead
Systems Administrator[image: wdlogo]  [image:
linkedin]  [image: facebook]
 [image: twitter]
 [image: instagram]
T 310 823 8238 x1106
<310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*

On Thu, Apr 23, 2015 at 5:14 AM, Navdeep Parhar  wrote:

> On Tue, Apr 21, 2015 at 12:47:45PM -0700, Scott Larson wrote:
> >  We're in the process of migrating our network into the future with
> 40G
> > at the core, including our firewall/traffic routers with 40G interfaces.
> An
> > issue which this exposed and threw me for a week turns out to be directly
> > related to net.inet.ip.forwarding and I'm looking to just get some
> insight
> > on what exactly is occurring as a result of using it.
>
> Enabling forwarding disables LRO and TSO and that probably accounts for
> a large part of the difference in throughput that you've observed.  The
> number of packets passing through the stack (and not the amount of data
> passing through) is the dominant bottleneck.
>
> fastforwarding _should_ make a difference, but only if packets actually
> take the fast-forward path.  Check the counters available via netstat:
> # netstat -sp ip | grep forwarded
>
> Regards,
> Navdeep
>
> >  What I am seeing is when that knob is set to 0, an identical pair of
> > what will be PF/relayd servers with direct DAC links between each other
> > using Chelsio T580s can sustain around 38Gb/s on iperf runs. However the
> > moment I set that knob to 1, that throughput collapses down into the 3 to
> > 5Gb/s range. As the old gear this is replacing is all GigE I'd never
> > witnessed this. Twiddling net.inet.ip.fastforwarding has no apparent
> effect.
> >  I've not found any docs going in depth on what deeper changes
> enabling
> > forwarding does to the network stack. Does it ultimately put a lower
> > priority on traffic where the server functioning as the packet router is
> > the final endpoint in exchange for having more resources available to
> route
> > traffic across interfaces as would generally be the case?
> >
> >
> > *[image: userimage]Scott Larson[image: los angeles]
> > <
> https://www.google.com/maps/place/4216+Glencoe+Ave,+Marina+Del+Rey,+CA+90292/@33.9892151,-118.4421334,17z/data=!3m1!4b1!4m2!3m1!1s0x80c2ba88ffae914d:0x14e1d00084d4d09c
> >Lead
> > Systems Administrator[image: wdlogo] 
> [image:
> > linkedin]  [image: facebook]
> >  [image: twitter]
> >  [image: instagram]
> > T 310 823 8238 x1106
> > <310%20823%208238%20x1106>  |  M 310 904 8818 <310%20904%208818>*
> > ___
> > freebsd-net@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-net
> > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
>
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Commented On] D1944: PF and VIMAGE fixes

2015-04-24 Thread glebius (Gleb Smirnoff)

glebius added a comment.

Recently Nikos has asked questions on kernel debugging. So, I guess, he is 
working.


REVISION DETAIL
  https://reviews.freebsd.org/D1944

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn
Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Differential] [Commented On] D1944: PF and VIMAGE fixes

2015-04-24 Thread robak (Bartek Rutkowski)

robak added a subscriber: robak.
robak added a comment.

Is there any update on these fixes? I've just happened to bump my 10.1-RELEASE 
into 10-STABLE and created few VIMAGE based jails. As soon as I stop any of 
them, and I can reproduce it every time, the host OS crashes. That makes the 
entire VIMAGE completely unusable...


REVISION DETAIL
  https://reviews.freebsd.org/D1944

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: nvass-gmx.com, bz, zec, trociny, glebius, rodrigc, kristof, gnn
Cc: robak, freebsd-virtualization, freebsd-pf, freebsd-net
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 194515] Fatal Trap 12 Kernel with vimage

2015-04-24 Thread bugzilla-noreply

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

Bartek Rutkowski  changed:

   What|Removed |Added

 CC||ro...@freebsd.org

--- Comment #21 from Bartek Rutkowski  ---
Is there any update on these fixes? I've just happened to bump my 10.1-RELEASE
into 10-STABLE and created few VIMAGE based jails. As soon as I stop any of
them, and I can reproduce it every time, the host OS crashes. That makes the
entire VIMAGE completely unusable...

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

Re: bhyve with vlans - host and vm can't pass traffic

2015-04-24 Thread Scott O'Connell




On 4/23/2015 11:26 AM, Matthew Grooms wrote:

On 4/22/2015 8:34 PM, Scott O'Connell wrote:

I tried your suggestions.

I was successful  in changing the vmhost01 bridge to include vlan100 
and tap0, and in the vm (dev) binding the address directly to vtnet0.


On the VMHOST:
tap0: flags=8943 
metric 0 mtu 1500

options=8
ether 00:bd:4c:d1:02:00
media: Ethernet autoselect
status: active
Opened by PID 888
bridge0: flags=8843 metric 0 
mtu 1500

ether 02:d3:e4:02:03:00
id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200
root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
member: tap0 flags=143
ifmaxaddr 0 port 6 priority 128 path cost 200
member: vlan100 flags=143
ifmaxaddr 0 port 5 priority 128 path cost 200

In the VM:
vtnet0: flags=8943 
metric 0 mtu 1500

options=80028
ether 00:a0:98:2b:34:37
inet 10.0.1.6 netmask 0xff00 broadcast 10.0.1.255
nd6 options=29
media: Ethernet 10Gbase-T 
status: active
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
inet 127.0.0.1 netmask 0xff00
nd6 options=21

The same results with regard to connectivity.   Both the VMHOST and 
the VM can communicate everywhere, except with each other.


I'm not sure how much detail to post, or what protocol I should be 
testing from the tcpdump, but here are a couple of relevant 
portions.  Captured on the VMHOST with "tcpdump -i tap0 -n -vv", and 
on the VM with "tcpdump -i vtnet0 -n -vv"


A ping from the VM (10.0.1.6) to VMHOST (10.0.1.17):

Captured on tap0:
18:18:40.656407 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], 
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, 
length 64
18:18:40.656429 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], 
proto ICMP (1), length 84, bad cksum 0 (->55a3)!)

10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64

Captured on vtnet0:
18:18:40.906203 IP (tos 0x0, ttl 64, id 2398, offset 0, flags [none], 
proto ICMP (1), length 84)
10.0.1.6 > 10.0.1.17: ICMP echo request, id 46082, seq 689, 
length 64
18:18:40.906366 IP (tos 0x0, ttl 64, id 3824, offset 0, flags [none], 
proto ICMP (1), length 84, bad cksum 0 (->55a3)!)

10.0.1.17 > 10.0.1.6: ICMP echo reply, id 46082, seq 689, length 64

100% packet loss on the ping.

Here is the same traffic from both systems between the VM (10.0.1.6) 
and the switch (10.0.1.1) through the VMHOST:


Captured on tap0:
18:23:42.712065 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], 
proto ICMP (1), length 84)

10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64
18:23:42.712595 IP (tos 0x0, ttl 255, id 2858, offset 0, flags 
[none], proto ICMP (1), length 84)

10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64

Captured on vtnet0:
18:23:43.141890 IP (tos 0x0, ttl 64, id 2858, offset 0, flags [none], 
proto ICMP (1), length 84)

10.0.1.6 > 10.0.1.1: ICMP echo request, id 58626, seq 2, length 64
18:23:43.142553 IP (tos 0x0, ttl 255, id 2858, offset 0, flags 
[none], proto ICMP (1), length 84)

10.0.1.1 > 10.0.1.6: ICMP echo reply, id 58626, seq 2, length 64

100% packet success on the ping.

I'm never quite sure when checksum's with TCP Dump or Wireshark are 
expected, and when they aren't, but it appears that is where the 
problem lies here.


With that said, if I'm understanding this correctly, and checksums 
are the problem, I'm not sure what to try next.


Thanks again!



Hi Scott,

I certainly appears that ICMP echo reply packets are being returned 
but the host isn't processing them for some reason. Do you have any 
firewalls running on either system? You might try including a -e in 
the tcpdump command line arguments. IIRC, that will also show you VLAN 
and MAC address info from the packet headers. Maybe one of the network 
kernel developers could provide some additional insight as to what may 
be happening in this scenario.


-Matthew


The latest updates:

vmhost capture using "tcpdump -i tap0 -n -vv -e"
10:51:02.988660 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4 
(0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, flags [none], 
proto ICMP (1), length 84)

10.0.1.6 > 10.0.1.17: ICMP echo request, id 34069, seq 5, length 64
10:51:02.988689 f0:1f:af:dd:2e:c5 > 00:a0:98:2b:34:37, ethertype IPv4 
(0x0800), length 98: (tos 0x0, ttl 64, id 16775, offset 0, flags [none], 
proto ICMP (1), length 84, bad cksum 0 (->230c)!)

10.0.1.17 > 10.0.1.6: ICMP echo reply, id 34069, seq 5, length 64

vm capture using "tcpdump -i vtnet0 -n -vv -e"
10:51:03.462131 00:a0:98:2b:34:37 > f0:1f:af:dd:2e:c5, ethertype IPv4 
(0x0800), length 98: (tos 0x0, ttl 64, id 18864, offset 0, f

Re: should m_copyback possibly throw data away?

2015-04-24 Thread John-Mark Gurney

John-Mark Gurney wrote this message on Fri, Apr 24, 2015 at 11:11 -0700:
> I would also be fine w/ documenting this behavior, though I'm sure
> it'd be surprising to many that you'd have to check to make sure your
> data was properly copied.

Should have reviewed the m_copyback function before sending this
email...

It gets worse..  If the m_get to extend it fails, there is no
notification that your data didn't get copyied into the mbuf.. and no
warning in the man page that this function is unsafe and may cause
data loss...

Comments?

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

should m_copyback possibly throw data away?

2015-04-24 Thread John-Mark Gurney

I was reviewing m_copyback from some other code, and noticed that it does
this:
if (m0 == NULL)
return;

at the beginin... If you pass in a NULL mbuf, it will not copy any data
in..  This is clearly to avoid panics, but at the same time, this means
we'll have data loss...  If someone tried to copy into a NULL mbuf,
it's likely a bug, and papering over that bug doesn't seem wise...

I'd like to see that removed (or changed to a KASSERT), but as it's been
in there since 1994:
https://svnweb.freebsd.org/base/head/sys/kern/uipc_mbuf.c?r1=3351&r2=3352

That's a pretty fundamental change...  mbuf(9) does not document this
behavior that data may be thrown away...

I would also be fine w/ documenting this behavior, though I'm sure
it'd be surprising to many that you'd have to check to make sure your
data was properly copied.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread wishmaster

Hi,

 --- Original Message ---
 From: "Nikos Vassiliadis" 
 Date: 24 April 2015, 19:46:42
 


> Hi,
> 
> Just saw this. Can somebody re-produce this?
> 
> > root@m4fh2:~ # sysctl net.inet.ip.forwarding
> > net.inet.ip.forwarding: 1
> > root@m4fh2:~ # ifconfig bridge0 create
> > root@m4fh2:~ # sysctl net.inet.ip.forwarding
> > net.inet.ip.forwarding: 0
> 
> That's on GENERIC 10-STABLE from the day before yesterday.
> 

Put
 gateway_enable=YES
into rc.conf and try again.

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

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Nikos Vassiliadis




On 04/24/15 18:57, Paul Thornton wrote:

Hi

This happens when any interface is created if you've enabled forwarding
with the sysctl and not using gateway_enable in rc.conf.  It is easily
fixed though.

See this thread from January:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net


Ok, thanks for the pointer. Everything is clear now.

Nikos

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

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Nikos Vassiliadis




On 04/24/15 18:54, Gary Palmer wrote:

On Sat, Apr 25, 2015 at 01:47:50AM +0900, Paul S. wrote:

Can confirm that anything to do with netif restart on a forwarding
interface also creates the same problem.

On 4/25/2015 ?? 01:46, Nikos Vassiliadis wrote:

Hi,

Just saw this. Can somebody re-produce this?


root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
root@m4fh2:~ # ifconfig bridge0 create
root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0


That's on GENERIC 10-STABLE from the day before yesterday.

Thanks,
Nikos


What is your setting for gateway_enable in /etc/rc.conf?


Thanks Gary,

I was not using anything in rc.conf. I was just using
the sysctl in /etc/sysctl.conf. Setting gateway_enable to yes
fixes the issue.

I am kind of surprised. Is this behaviour new?


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

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Paul Thornton


Hi

This happens when any interface is created if you've enabled forwarding 
with the sysctl and not using gateway_enable in rc.conf.  It is easily 
fixed though.


See this thread from January:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=403720+0+archive/2015/freebsd-net/20150104.freebsd-net

Paul.

On 24/04/2015 17:47, Paul S. wrote:

Can confirm that anything to do with netif restart on a forwarding
interface also creates the same problem.

On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote:

Hi,

Just saw this. Can somebody re-produce this?


root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
root@m4fh2:~ # ifconfig bridge0 create
root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0


That's on GENERIC 10-STABLE from the day before yesterday.

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


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

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

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Gary Palmer

On Sat, Apr 25, 2015 at 01:47:50AM +0900, Paul S. wrote:
> Can confirm that anything to do with netif restart on a forwarding 
> interface also creates the same problem.
> 
> On 4/25/2015 ?? 01:46, Nikos Vassiliadis wrote:
> > Hi,
> >
> > Just saw this. Can somebody re-produce this?
> >
> >> root@m4fh2:~ # sysctl net.inet.ip.forwarding
> >> net.inet.ip.forwarding: 1
> >> root@m4fh2:~ # ifconfig bridge0 create
> >> root@m4fh2:~ # sysctl net.inet.ip.forwarding
> >> net.inet.ip.forwarding: 0
> >
> > That's on GENERIC 10-STABLE from the day before yesterday.
> >
> > Thanks,
> > Nikos

What is your setting for gateway_enable in /etc/rc.conf?

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

Re: net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Paul S.

Can confirm that anything to do with netif restart on a forwarding 
interface also creates the same problem.


On 4/25/2015 午前 01:46, Nikos Vassiliadis wrote:

Hi,

Just saw this. Can somebody re-produce this?


root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
root@m4fh2:~ # ifconfig bridge0 create
root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0


That's on GENERIC 10-STABLE from the day before yesterday.

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


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

net.inet.ip.forwarding is mysteriously set to 0

2015-04-24 Thread Nikos Vassiliadis


Hi,

Just saw this. Can somebody re-produce this?


root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 1
root@m4fh2:~ # ifconfig bridge0 create
root@m4fh2:~ # sysctl net.inet.ip.forwarding
net.inet.ip.forwarding: 0


That's on GENERIC 10-STABLE from the day before yesterday.

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

Re: CARP vhid: across interfaces?

2015-04-24 Thread Eugene Grosbein

On 01.01.2015 18:29, Aristedes Maniatis wrote:

> At any rate what does "interface groups that the carp(4) interface is a 
> member of" mean?

FreeBSD has interface groups. Any interface may be a member of one or multiple 
groups,
you can manually insert interface into a group, list groups etc. See man 
ifconfig.

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

[Bug 181741] [kernel] [patch] Packet loss when 'control' messages are present with large data (sendmsg(2))

[Bug 194515] Fatal Trap 12 Kernel with vimage

Re: net.inet.ip.forwarding impact on throughput

[Differential] [Commented On] D1944: PF and VIMAGE fixes

[Differential] [Commented On] D1944: PF and VIMAGE fixes

[Bug 194515] Fatal Trap 12 Kernel with vimage

Re: bhyve with vlans - host and vm can't pass traffic

Re: should m_copyback possibly throw data away?

should m_copyback possibly throw data away?

Re: net.inet.ip.forwarding is mysteriously set to 0

Re: net.inet.ip.forwarding is mysteriously set to 0

Re: net.inet.ip.forwarding is mysteriously set to 0

Re: net.inet.ip.forwarding is mysteriously set to 0

Re: net.inet.ip.forwarding is mysteriously set to 0

Re: net.inet.ip.forwarding is mysteriously set to 0

net.inet.ip.forwarding is mysteriously set to 0

Re: CARP vhid: across interfaces?

17 matches

Site Navigation

Mail list logo

Footer information