[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Blocks||212018


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018
[Bug 212018] Enable IPSEC_NAT_T in GENERIC kernel configuration
-- 
You are receiving this mail because:
You are on the CC list 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 212018] Enable IPSEC_NAT_T in GENERIC kernel configuration

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

   See Also|https://bugs.freebsd.org/bu |
   |gzilla/show_bug.cgi?id=1280 |
   |30  |
   Priority|--- |Normal
 Depends on||128030
   Severity|Affects Some People |Affects Many People

--- Comment #2 from Kubilay Kocak  ---
This actually depends on bug 128030 (IPSec in GENERIC *at all*) first


Referenced Bugs:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=128030
[Bug 128030] [ipsec] Enable IPSec in GENERIC kernel configuration
-- 
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 213232] [tcp] [panic] tcp_output() Panic String: tcp_output: len > IP_MAXPACKET on -head and stable/11

[bugzilla-noreply]

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

--- Comment #5 from Hiren Panchasara  ---

r306769 | jtl | 2016-10-06 09:28:34 -0700 (Thu, 06 Oct 2016) | 8 lines

Remove "long" variables from the TCP stack (not including the modular
congestion control framework).

may help. Updating my box and trying again if I get the same crash.

-- 
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 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

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

--- Comment #35 from s...@zxy.spb.ru ---
(In reply to Hiren Panchasara from comment #34)
> which value of 'm' should I trust? is it null in frame #22 or not? it seems 
> like null in the frames above it also.

Зartially. ether_input call with m set to 0xf8014eee7600 (and this is first
m for next invocation of further functions), do one (or more, w/ different m,
need access to vmcore by kgdb and analyse 0xf8014eee7600 for answer)
iteration w/  and call netisr_dispatch with passed m as second argument (in
%rsi register). All next invocation can don't preserve %rsi (or %rdx in case of
m passed as 3'th argument) and backtrace can incorrectly decode arguments call.

Just realyty check: frame #19, ether_input_internal (ifp=,
m=0x0), line 483:

if (m->m_len < ETHER_HDR_LEN) {

MUST occur kernel panic if m realy NULL.

This is just incorrect decoding of arguments.

-- 
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 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

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

--- Comment #34 from Hiren Panchasara  ---
(In reply to slw from comment #33)
Thanks but I am little confused.

which value of 'm' should I trust? is it null in frame #22 or not? it seems
like null in the frames above it also.

-- 
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 213232] [tcp] [panic] tcp_output() Panic String: tcp_output: len > IP_MAXPACKET on -head and stable/11

[bugzilla-noreply]

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

Hiren Panchasara  changed:

   What|Removed |Added

Summary|[tcp] [panic] tcp_output()  |[tcp] [panic] tcp_output()
   |Panic String: tcp_output:   |Panic String: tcp_output:
   |len > IP_MAXPACKET (at  |len > IP_MAXPACKET on -head
   |r306658)|and stable/11

--- Comment #4 from Hiren Panchasara  ---
Just hit this on uptodate stable/11 system.

-- 
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: FreeBSD10.3-RELEASE. Kernel panic.

[Cassiano Peixoto]

Hi guys,

First of all, thanks to share your thoughts about this issue. I think it’s
really important to find out a solution for this issue together.

I can see two behaviors related, but for me the root cause is the same:

1- mpd5 process stuck with umtxn flag
2- system crash

I’ve tested recently on FreeBSD 10.3 and FreeBSD-11-RC3. I’ve tried all
suggested tunings with no success.

My environment is:
-  About 430 clients connected (but i can add more)
- Using ZFS
- igb NICs.
- Generic kernel

Two days ago i updated my system to FreeBSD 11-RELEASE-p1 and after this my
system seems stable for almost 3 days. No crashes anymore. I need more days
to feel confident if something has changed. But anyway, my crashes before
happened every day.

If it crashs again i’ll apply Donald recommendation and let you guys know.

Let’s keep in touch, to try to at last fix it.

Thanks.

On Wed, Oct 12, 2016 at 8:24 PM, Donald Baud via freebsd-net <
freebsd-net@freebsd.org> wrote:

> On 10/12/16 3:24 PM, Zaphod Beeblebrox wrote:
>
> While my mp5 servers are possibly less busy (I havn't had common crashes),
>> I have noticed a "group" of problems.
>>
>> 1. The carrier dropping communication (ie: fiber cut or l2 switch
>> breakage) of the L2TP streams can leave mpd5 in a state where it will not
>> die and will not destroy interfaces (requires reboot to clear).
>>
> I've encountered that once on 10.3 and I had tweaked some sysctl values
> while monitoring :
> > vmstat -z | head -1; vmstat -z | grep -i netgraph
>
> you might want to search other people's experience with the following
> values:
> # net.graph.maxdgram   #this is set in /etc/sysctl.conf
> # net.graph.recvspace#this is set in /etc/sysctl.conf
> # net.graph.maxdata  #this is set in /boot/loader.conf
> # net.graph.maxalloc #this is set in /boot/loader.conf
>
> I'll leave others to comment on what's best to set as values with their
> experience on FreeBSD10.3.
> In my case, as I had explained, one of the recipes that worked for me is
> to comment out and leave those kernel values to their default.
>
> I've read in mpd5 mailing list some saying that FreeBSD-11 have had
> upgrades on the netgraph modules.
> I am now using FreeBSD-11 and It looks like I don't need any of the kernel
> tweaks that I've described.
>
> Also, may I suggest you troubleshoot the fiber-cut or L2 switch breakage
> by playing with some ipfw values to simulate a fiber-cut.:
> ex: ipfw add 100 deny ip from 10.10.10.10 to me
>
>> 2. There are race conditions between quagga and mpd5 for adding/dropping
>> routes.
>>
> While troubleshooting the crashes of the mpd5, I have removed net/quagga
> and installed net/bird instead.
> I am now using net/bird I've written a little howto to get you started
> with net/bird
> see: https://forums.freebsd.org/threads/56988/
>
> 3. if A is a pppoe client and B is the mpd5 server, A cannot access TCP
>> services on B.  It can access tcp services _beyond_ B, but not on B. (there
>> is a ticket open for this).
>>
>> On Wed, Oct 12, 2016 at 10:51 AM, Donald Baud via freebsd-net <
>> freebsd-net@freebsd.org > wrote:
>>
>>
>> On 10/12/16 1:13 AM, Julian Elischer wrote:
>>
>> On 11/10/2016 8:56 PM, Donald Baud via freebsd-net wrote:
>>
>> I've been plagued with these =daily= panics until I tried
>> the following recipes and the server has been up for 30
>> days so far:
>>
>> Normally I should expermient more to see which one of the
>> receipes is really the fix, but I'm just glad that the
>> server is stable for now.
>>
>>
>> this is really great information.
>> It makes debugging a lot more possible.
>> I know it is a hard question, but do you have a way to
>> simulate this workload?
>>
>> I have no real way to simulate this kind of workload
>>
>>
>> Sadly, I don't have a way to simulate the workload but I am very
>> interested to help fix these crashes since as Cassiano said, this
>> makes mpd5/freebsd useless for pppoe/l2tp termination.
>>
>> At this point, I would suggest that Cassiano and Андрей confirm
>> that they don't get panics when they apply the recipes that I am
>> using.
>>
>> I am still running many other cisco-vpdn gateways that I would
>> convert into mpd5/freebsd but my plan was stalled with the daily
>> crashes.
>> I'll wait a couple of weeks to be sure that my recipes are a valid
>> workaround before converting my remaining cisco gateways to mpd5.
>>
>> -Dbaud
>>
>>
>>
>> recipe-1: Don't let mpd5 start automatically when server
>> boots:
>> i.e. in: /etc/rc.conf
>> mpd5_enable="NO"
>> and wait about 5 minutes after server boots then issue:
>> /usr/local/etc/rc.d/mpd5 onestart
>>
>>
>> recipe-2: recompile the kernel with the NETGRAPH_DEBUG option:
>> options   

Re: Seamless steel pipe stockist--Threeway Steel Co.,Ltd in China

[srtsteel]

Dear Manager,


Good day! This is Villa from Hunan Threeway Steel Co.,Ltd .
We are one of the leading steel pipe manufacturer which can meet clients 
requirement for pipes with API, ASTM, EN, BS, DIN standard. all of our pipes 
can be strictly tested by SGS, BV, DNV, TUV, LLOYD'S third party inspection. 
also with competitive price in this market with short delivery time and 
flexable payment terms(L/C,T/T,O/A).
We have supplied the pipes to PEMEX (Mexico), IBERDROLA(Spain), PDSVA 
(Venezuela), PETROBRAS(Brazil), SAUDI ARAMCO, SWCC, EIED/NIOC (Iran) in recent 
years.
Please see the main product like below:

SEAMLESS STEEL PIPE
   ​​
Size: OD: 13.72 mm - 914.4 mm;   WT: 1.65 mm - 22 mm;  Length: 0.5 m - 20 m
Standard: API 5L, ASTM A106/A53, DIN2391, DIN1629, ASTM A179/A192, EN10210, 
EN10216, EN10208
Material: GR.B, X42, X46, X52, S355JOH, S355J2H, St 44.0, P265GH, P235GH, 
P265TR1
Usage: Chilled Water Pipe, Drinking water Pipe, Waste Water Pipe, Structural 
Tube, Fluid Pipe, Boiler Pipe, Oil and Gas Transportation Pipe, Mechanical 
Structure Pipe   


So,if you have any questions or interests pls feel free to contact me,looking 
forward to your kindly reply.


Thanks Regards 
 Villa Liaw


 Office: +86-0731-88678510  |  Fax: +86-0731-88678578
 Mob: +86-136 6739 4033 (Whats Up)  |  Skype: sale...@srtsteelpipe.com
 Email: sale...@srtsteelpipe.com  |  srtst...@163.com  
 Website: http://www.threewaysteel.com 
 Address: 22nd Floor,Royal Wing Tower,Long Champ International Building,No.9 
Xiangfu Road,Changsha ,Hunan,China
 STEEL PIPE MANUFACTURE & EXPORT EXPERIENCE FOR 25 YEARS
 P Please consider the environment before printing this e-mail
___
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"

Your recovery email address changed

[Google via freebsd-net]

Your recovery email address changed



Hi VNS娱乐城876502.com注册送88元,网上最火爆的游戏平台,超好赢钱游戏,
The recovery email for your Google Account deirdresimpson...@gmail.com was
recently changed.

*Don't recognize this activity?*
Review your recently used devices

now.

Best,
The Google Accounts team



This email can't receive replies. For more information, visit the Google
Accounts Help Center .



You received this mandatory email service announcement to update you about
important changes to your Google product or account.
© 2016 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
___
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 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

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

s...@zxy.spb.ru changed:

   What|Removed |Added

 CC||s...@zxy.spb.ru

--- Comment #33 from s...@zxy.spb.ru ---
(In reply to Hiren Panchasara from comment #31)

> Most interesting frames are these 2:
> 
> #22 0x80a6c546 in ether_input (ifp=, m=0x0) at 
> /d2/hiren/freebsd/sys/net/if_ethersubr.c:759
> #23 0x804e2b3c in igb_rx_input (rxr=, 
> ifp=0xf80115614800, m=0xf8014eee7600, 
>ptype=) at /d2/hiren/freebsd/sys/dev/e1000/if_igb.c:4957
>
> #23 has an mbuf while #22 has it null.

> Does this point to your hunch of
> "device-driver bugs involving modifications to the mbuf chain after 
> submitting the mbuf to the network stack (e.g., due to concurrency bugs in 
> the device driver)" ?

This is just result of compiler optimisation and stack decoding.
Compiler use for m same register as passed at call time and do

while (m) {  
 mn = m->m_nextpkt;
[...]
 m = mn;
}

as result m (as decoded argument) will be incorectly displayed.
Actualy this is just last loop iteration with last mbuf in chain.

-- 
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 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

[bugzilla-noreply]

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

Daniel Bilik  changed:

   What|Removed |Added

 CC||d...@neosystem.org

--- Comment #32 from Daniel Bilik  ---
(In reply to Robert Watson from comment #29)

> On the whole, my intuition is towards a device-driver bug based
> on past experience.

We've been also struggling this in past weeks, and I can confirm Robert's
intuition.

In our case, the bug affects two hosts running recent 10-STABLE, connected to
each other via igb(4) using a dedicated 100Mb switch. When trying to transfer
directory structure holding several gigabytes of data with rsync protocol,
either sender or receiver panics in less then a minute with:

Panic String: sbsndptr: sockbuf 0xf8000ccc76f8 and mbuf 0xf802a0145800
clashing

Interestingly, scp(1)ing data between the hosts doesn't seem to trigger this
panic such easily, but sometimes it does, mostly when copying larger (>1GB)
files.

We've fixed this just yesterday by limiting number of igb(4) txrx queues, ie.
adding this into loader.conf:

hw.igb.num_queues=1

Now the hosts run stable, periodically rsyncing data in both directions.

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