On Fri, Jul 09, 2021 at 02:58:50PM +0200, Alexander Bluhm wrote:
> 1. With non parallel forwarding the IPsec traffic stalls after a while.
> esp_input_cb: authentication failed for packet in SA 10.3.45.35/83089fff
Together with tobhe@ we found the issue. The authentication before
decryption uses
I think we see two problems here:
1. With non parallel forwarding the IPsec traffic stalls after a while.
Compiled with ENCDEBUG I get this message for each received ESP packet:
esp_input_cb: authentication failed for packet in SA 10.3.45.35/83089fff
I can reproduce it more or less after 30 sec
On Thu, Jul 08, 2021 at 08:08:23AM +0200, Hrvoje Popovski wrote:
> On 8.7.2021. 0:10, Vitaliy Makkoveev wrote:
> > On Wed, Jul 07, 2021 at 11:07:08PM +0200, Hrvoje Popovski wrote:
> >> On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
> >>> Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
> >>>
>
On 8.7.2021. 0:10, Vitaliy Makkoveev wrote:
> On Wed, Jul 07, 2021 at 11:07:08PM +0200, Hrvoje Popovski wrote:
>> On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
>>> Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
>>>
>>> I guess the panics continue because simultaneous modifications of
>>> 't
On Wed, Jul 07, 2021 at 11:07:08PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
> > Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
> >
> > I guess the panics continue because simultaneous modifications of
> > 'tdbp->tdb_policy_head' break it. Could you try
On 7.7.2021. 22:36, Vitaliy Makkoveev wrote:
> Thanks. ipsp_spd_lookup() stopped panic in pool_get(9).
>
> I guess the panics continue because simultaneous modifications of
> 'tdbp->tdb_policy_head' break it. Could you try the diff below? It
> introduces `tdb_polhd_mtx' mutex(9) and uses it to pro
On Wed, Jul 07, 2021 at 10:01:59PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 19:38, Vitaliy Makkoveev wrote:
> > Hi,
> >
> > It seems the first the first panic occured because ipsp_spd_lookup()
> > modifies tdbp->tdb_policy_head and simultaneous execution breaks it.
> > I guess at least mutex(9
On 7.7.2021. 19:38, Vitaliy Makkoveev wrote:
> Hi,
>
> It seems the first the first panic occured because ipsp_spd_lookup()
> modifies tdbp->tdb_policy_head and simultaneous execution breaks it.
> I guess at least mutex(9) should be used to protect `tdb_policy_head'.
>
> The second panic occured
On Wed, Jul 07, 2021 at 08:38:23PM +0300, Vitaliy Makkoveev wrote:
> The second panic occured because ipsp_acquire_sa() does
> `ipsec_acquire_pool' initialization in runtime so parallel execution
> breaks it. It's easy to fix.
>
> Could you try the diff below? It moves `ipsec_acquire_pool'
> initi
On Wed, Jul 07, 2021 at 02:09:23PM +0200, Alexander Bluhm wrote:
> On Wed, Jul 07, 2021 at 12:52:26PM +0200, Hrvoje Popovski wrote:
> > On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> > > Panic can be triggered when i have parallel diff and sending traffic
> > Different panic on same setup ...
>
> Th
On Wed, Jul 07, 2021 at 12:52:26PM +0200, Hrvoje Popovski wrote:
> On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> > Panic can be triggered when i have parallel diff and sending traffic
> Different panic on same setup ...
Thanks a lot for the report.
I can see the same stop of traffic and crashes he
On 7.7.2021. 12:46, Hrvoje Popovski wrote:
> Panic can be triggered when i have parallel diff and sending traffic
> over ipsec tunnel and on other side while traffic is flowing i'm
> restarting isakmpd daemon and while negotiating ipsec doing ifconfig ix1
> down && ifconfig ix1 up ... sometimes it
Hi,
i don't want to pollute bluhm@ parallel forwarding mail on tech@ so i'm
sending this report as a separate thread. this panic it's dependent on
bluhm@ parallel diff ... and i found it yesterday
I'm having ipsec tunnel between two hosts without pf and i'm sending
traffic over that tunnel .. i'm
13 matches
Mail list logo
