Re: May I ask where could I find the TCP BBR patches?

[Jov]

Maybe you are also interested in kcp/kcptun:
https://github.com/xtaci/kcptun

There is also a FreeBSD new ports PR：
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219449

Jov

2017-07-21 10:30 GMT+08:00 Kuankuan Yang :
> Hi Hiren,
>
> Thanks a lot for your reply, this helps a lot. I’m looking forward to 
> BBR/FreeBSD feature very much, wish to see that great job soon :P
>
> Best regards,
> - Kuankuan
>
>> 在 2017年7月21日，上午2:54，hiren panchasara  写道：
>>
>> On 07/19/17 at 12:26P, Kuankuan Yang wrote:
>>> Dear All,
>>>
>>> I?m a newbie for FreeBSD development. May I ask a stupid question where 
>>> could I find the TCP BBR patches  :P
>>
>> Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, 
>> nothing
>> is public yet.
>>
>> Cheers,
>> Hiren
>
> ___
> 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"

locking anti-patterns

[Matt Macy]

The immediate solution that anyone could have made is to not call stats
collection (or any other routines that use this dubious synchronization
mechanism) from swi context:

https://github.com/mattmacy/networking/commit/421da0083e4325e242bdece18fa198
e1a96a6c67



The *_acquire_swfw code seems to be a common anti-pattern amongst drivers.
I found something very similar in bxe. My hypothesis in both cases is that
they rolled their own simply because they don't know any better.
Understanding the locking hierarchy on either Linux or FreeBSD is something
that we all have to do a better job of educating people on the periphery of
kernel development about. I have no words to describe calling DELAY(50) up
to 200 times in a row to poll for release of device resources that I would
use in a durable medium such as this.

This "lock" serializes:
i2c read/write
EEPROM access
PHY _read_/write

As an immediate addendum we want to assert that no real locks are held
while we're engaged in these shenanigans:

https://github.com/mattmacy/networking/commit/5437e3109bbd0c21a5d4bfcc3d807f
20c6ee5751

And to avoid further foot shooting we'll want to assert that these routines
are never called from swi context or one serving as an ithread. Eventually
these constructs should be replaced by sx locks and the DELAYs replaced
with sleeps.

-- 
[image: Limelight Networks] 
Matt Macy - *Consultant*
 +1 650 440 8947
www.limelight.com Delivering Faster Better

Join the conversation

at Limelight Connect 
[image: Facebook] 
[image: Facebook]  [image:
LinkedIn]  [image:
Twitter] 

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.

___
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: May I ask where could I find the TCP BBR patches?

[Kuankuan Yang]

Hi Hiren,

Thanks a lot for your reply, this helps a lot. I’m looking forward to 
BBR/FreeBSD feature very much, wish to see that great job soon :P

Best regards,
- Kuankuan

> 在 2017年7月21日，上午2:54，hiren panchasara  写道：
> 
> On 07/19/17 at 12:26P, Kuankuan Yang wrote:
>> Dear All,
>> 
>> I?m a newbie for FreeBSD development. May I ask a stupid question where 
>> could I find the TCP BBR patches  :P 
> 
> Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, 
> nothing
> is public yet.
> 
> Cheers,
> Hiren

___
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: IPsec tunnel mode with gif

[Bjoern A. Zeeb]

On 20 Jul 2017, at 22:02, Kajetan Staszkiewicz wrote:

Yet for a reason beyond my understanding FreeBSD handbook proposes a 
3rd mode:
using a GIF tunnel together with IPSec tunnel mode. I really don't 
understand
how is that supposed to work. People On The Internet also seem not to 
be able

..

Am I wrong? Or is the Handbook wrong?


The handbook is outdated and I think what you are referring to is from 
the early days of the IPv6/IPsec stack implementation times probably 
during FreeBSD 4.


What you are doing (gre/gif inside transport mode to possibly get a 
link-state change as well, or BGP over transport mode directly is both 
fine.



I think the short answer:  updates to the handbook would be very 
welcome!


/bz
___
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 220882] m_move_pkthdr leaves m_nextpkt 'dangling'

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org
   Keywords||patch

-- 
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 220888] [panic][patch] Race between ngs_rcvdata() and soclose()

[bugzilla-noreply]

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

Mark Linimon  changed:

   What|Removed |Added

   Assignee|freebsd-b...@freebsd.org|freebsd-net@FreeBSD.org

-- 
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"

IPsec tunnel mode with gif

[Kajetan Staszkiewicz]

Hi group,

For many years I have used the trick of running a GRE or GIF tunnel encrypted 
with IPSec transport mode, both on FreeBSD and Linux. That allows me to run 
BGP or OSPF on the tunnels.

I am also aware of IPsec tunnel mode which kind of works for me, although is 
not my personal choice.

Both modes of operation seem quite straightforward.

Yet for a reason beyond my understanding FreeBSD handbook proposes a 3rd mode: 
using a GIF tunnel together with IPSec tunnel mode. I really don't understand 
how is that supposed to work. People On The Internet also seem not to be able 
to understand the reasoning behind such solution. Since IPSec stack provides 
its own encapsulation in tunnel mode, packets coming to a router would never 
reach the GIF interface and would never be encapsulated by it. Same for 
packets received, they would be deencapsulated by IPsec stack and reinjected 
with internal IP addresses on a public interface of router or they would 
appear on enc0 interface if it is in use.

Am I wrong? Or is the Handbook wrong?

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|Vegeta  | www: http://vegeta.tuxpowered.net |
`^---'

signature.asc
Description: This is a digitally signed message part.

Re: May I ask where could I find the TCP BBR patches?

[hiren panchasara]

On 07/19/17 at 12:26P, Kuankuan Yang wrote:
> Dear All,
> 
> I?m a newbie for FreeBSD development. May I ask a stupid question where could 
> I find the TCP BBR patches  :P 

Hi! Thanks for your interest in BBR/FreeBSD. Other than what you listed, nothing
is public yet.

Cheers,
Hiren


pgpOixqc2A1lJ.pgp
Description: PGP signature

ipsec encryption only via given route

[Kajetan Staszkiewicz]

Hey group,

Across a few data centers I have a some routers running IPsec+BGP tunnels to 
Azure.

Microsoft side is nicely following BGP sessions.

My routers are unfortunately not. Routes in route table are updated just fine 
from BIRD but unfortunately they are overridden by IPSec policy which is 
static. That means that all hosts in given data center will route to Azure via 
tunnel on this data center's router whenever the IPsec tunnel is established, 
disregarding BGP. That seems to work for now, but I already see problems with 
failover, that is IPsec timeout is way longer than BGP timeout and I expect 
more problems with balancing traffic.

Routers are running FreeBSD 11.0 with Bird as routing daemon. IPsec daemon of 
choice is Strongswan.

Tunnels are IKEv2 with single static subnet on Azure side and one big subnet 
on my side covering all datacenters and a few extra ones covering some other 
locations that route through datacenters.

Can I somehow make IPsec encryption to happen AFTER routing decision and 
ensure that it happens only when traffic leaves via specified interface?

-- 
| pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS |
|  Kajetan Staszkiewicz  | jabber,email: vegeta()tuxpowered net  |
|Vegeta  | www: http://vegeta.tuxpowered.net |
`^---'

signature.asc
Description: This is a digitally signed message part.