[Bug 242406] mpd & 3G USB modem: Fatal trap 12: page fault while in kernel mode

[bugzilla-noreply]

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

Michael Muenz  changed:

   What|Removed |Added

 CC||m.mu...@gmail.com

--- Comment #11 from Michael Muenz  ---
We had the same issue in OPNsense project, since update to 20.7 which moves
from 11.2 to 12.1 the LTE modems were crashing.
I added your patch and build a new img which is reported to work great:

https://github.com/opnsense/core/issues/4218

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

Kaushal Shriyan's invitation is awaiting your response

[Kaushal Shriyan via LinkedIn via freebsd-net]

Hi ,

Kaushal would like to connect on LinkedIn. How would you like to respond?

Accept: 
https://www.linkedin.com/e/v2?e=xdi44-kcyc5geq-a1=urn%3Ali%3Apage%3Aemail_email_first_guest_reminder_03%3B%2BpC89%2BgXRW2LYRZmSX0BLA%3D%3D=suwj=email_first_guest_reminder_03=20=hero=accept_text

View Kaushal’s profile: 
https://www.linkedin.com/comm/in/kaushalshriyan?trk=eml-email_first_guest_reminder_03-hero-2-prof%7Ename=eml-email_first_guest_reminder_03-hero-2-prof%7Ename-null-xdi44%7Ekcyc5geq%7Ea1-null-neptune%2Fprofile%7Evanity%2Eview=urn%3Ali%3Apage%3Aemail_email_first_guest_reminder_03%3B%2BpC89%2BgXRW2LYRZmSX0BLA%3D%3D



.

Unsubscribe: 
https://www.linkedin.com/e/v2?e=xdi44-kcyc5geq-a1=lun=AQFmrFVhGEd36Q=email_first_guest_reminder_03=17=unsub=unsub=AQELAWSIi5uKwXN6EviLzg3pQETiAdERswwTJdVS7IsVqmmUcgvoBXyJ82iG3es9ksppS2tfh-EqZ0B9m6-XQ08khxJUmfO3zLlp47a5Vg=xdi44-kcyc5geq-a1

Help: 
https://www.linkedin.com/e/v2?e=xdi44-kcyc5geq-a1=urn%3Ali%3Apage%3Aemail_email_first_guest_reminder_03%3B%2BpC89%2BgXRW2LYRZmSX0BLA%3D%3D=customerServiceUrl=email_first_guest_reminder_03=16=footer=help=67


 LinkedIn will use your email address to make suggestions to our members in 
features like People You May Know.

This email was sent to freebsd-net@freebsd.org.

© 2020 LinkedIn Ireland Unlimited Company, Wilton Plaza, Wilton Place, Dublin 
2. LinkedIn is a registered business name of LinkedIn Ireland Unlimited 
Company. LinkedIn and the LinkedIn logo are registered trademarks of LinkedIn.
___
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"

Abandoning ifnet work

[Kyle Evans]

Hi,

Just a heads up... I had been doing some ifnet work that I'm now
abandoning because the review process for this area is simply not
worth it: D22691[0]. I'd quite like to see someone else pick it up and
finish out, though... I've been running with some success an earlier
version of this that coordinates if_vmove() and vnet shutdown's
evacuation of ifnets with if_detach() to render some of the common
epair/vnet races harmless.

Feel free to tag me for reviewing if you want to pick it up.

Thanks,

Kyle Evans

[0] https://reviews.freebsd.org/D22691
___
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 248005] nd6 initializes nd_ifinfo->maxmtu = 0 on newly inserted network interfaces

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

 Status|In Progress |Closed
  Flags|mfc-stable12?,  |mfc-stable12+,
   |mfc-stable11?   |mfc-stable11-
 Resolution|--- |FIXED

--- Comment #4 from Kyle Evans  ---
Fix will appear in 12.2; thanks!

-- 
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 248005] nd6 initializes nd_ifinfo->maxmtu = 0 on newly inserted network interfaces

[bugzilla-noreply]

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

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

Author: kevans
Date: Thu Jul 23 03:24:35 UTC 2020
New revision: 363442
URL: https://svnweb.freebsd.org/changeset/base/363442

Log:
  MFC r363244: ether_ifattach: set mtu before calling if_attach()

  if_attach() -> if_attach_internal() will call if_attachdomain1(ifp) any time
  an ethernet interface is setup *after*
  SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_FIRST.  This eventually leads to
  nd6_ifattach() -> nd6_setmtu0() stashing off ifp->if_mtu in ndi->maxmtu
  *before* ifp->if_mtu has been properly set in some scenarios, e.g., USB
  ethernet adapter plugged in later on.

  For interfaces that are created in early boot, we don't have this issue as
  domains aren't constructed enough for them to attach and thus it gets
  deferred to domainifattach at SI_SUB_PROTO_IFATTACHDOMAIN/SI_ORDER_SECOND
  *after* the mtu has been set earlier in ether_ifattach().

  PR:   248005

Changes:
_U  stable/12/
  stable/12/sys/net/if_ethersubr.c

-- 
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 247647] panic: page fault when opening netmap port (vmxnet3)

[bugzilla-noreply]

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

--- Comment #10 from Zhenlei Huang  ---
Glad to see the fix was merged into head master :)
I'm not familiar with FreeBSD's releasing policy, are there any est or schedule
releasing a new patched version?

-- 
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 248172] if_tuntap(4): OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

Summary|tun/tap: OpenVPN|if_tuntap(4): OpenVPN
   |configuring tun/tap devices |configuring tun/tap devices
   |ends up with IFDISABLED |ends up with IFDISABLED
   |interfaces  |interfaces

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

  Flags||maintainer-feedback?(bz@Fre
   ||eBSD.org)

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

Re: somewhat reproducable vimage panic

[John-Mark Gurney]

Bjoern A. Zeeb wrote this message on Wed, Jul 22, 2020 at 20:43 +:
> On 22 Jul 2020, at 19:34, John-Mark Gurney wrote:
> 
> > John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 
> > -0700:
> >> Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:
> >>> Is this related to
> >>>
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
> >>>  and 
> >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 
> >>> 
> >>
> >> Definitely not 234985..  I'm using ue interfaces, and so they don't
> >> get destroyed while the jail is going away...
> >>
> >> I don't think it's 238326 either.  This is 100% reliable and it's in
> >> the IP multicast code..  It looks like in_multi isn't holding an
> >> interface or address lock waiting for things to free up...
> >
> > Did a little more poking, and it looks like the vnet is free'd before
> > the ifnet is free'd causing this problem:
> > (kgdb) print inm->inm_ifp[0].if_refcount
> > $5 = 1
> > (kgdb) print inm->inm_ifp[0].if_vnet[0]
> > $6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 
> > 0xdeadc0dedeadc0de},
> >   vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054,
> >   vnet_sockcnt = 3735929054, vnet_state = 3735929054,
> >   vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = 
> > 16045693110842147038,
> >   vnet_shutdown = 222}
> >
> > So the multicast code is fine, it holds and releases a reference to
> > ifnet..
> >
> > The issue is that the reference to the ifnet doesn't involve a
> > reference to the vnet/prison.
> 
> Does it need to?  The ifnet cannot go away while something holds a 
> reference to it, right?

It's the other way around that's the problem.. the ifnet is holding an
invalid vnet pointer that got free'd.

Maybe the problem isn't the tear down, but that the vnet pointer isn't
changed/restored before the free?

> Sounds more like the teardown order is wrong (again)?
> 
> There should be no more multicast when IP etc. is gone.  That means MC 
> doesn???t properly cleanup itself.

Don't know, just know that it's easy to trigger right now...  I haven't
tested on prior releases, but if you'd like me to, it isn't too hard for
me to test...

> I guess I should go back now and re-read your original problem statement 
> on how you trigger this..

So, it's pretty easy to trigger, just attach a couple USB ethernet
adapters, in my case, they were ure, but likely any two spare ethernet
interfaces will work, and wire them back to back..

Run the script attached earlier in the thread, providing it the name
of the two interfaces as arguments, and run it a few times.  You might
get failures or not.  It shouldn't matter.  After a few runs, it'll
panic...

I just tested this (to make sure my ure changes weren't causing addition
problems) using
FreeBSD-13.0-CURRENT-amd64-20200625-r362596-memstick.img.xz, so it's
stock reproducable.

Thanks for looking into this!

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

Re: somewhat reproducable vimage panic

[Bjoern A. Zeeb]

On 22 Jul 2020, at 19:34, John-Mark Gurney wrote:

John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 
-0700:

Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:

Is this related to

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
 and 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 



Definitely not 234985..  I'm using ue interfaces, and so they don't
get destroyed while the jail is going away...

I don't think it's 238326 either.  This is 100% reliable and it's in
the IP multicast code..  It looks like in_multi isn't holding an
interface or address lock waiting for things to free up...


Did a little more poking, and it looks like the vnet is free'd before
the ifnet is free'd causing this problem:
(kgdb) print inm->inm_ifp[0].if_refcount
$5 = 1
(kgdb) print inm->inm_ifp[0].if_vnet[0]
$6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 
0xdeadc0dedeadc0de},

  vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054,
  vnet_sockcnt = 3735929054, vnet_state = 3735929054,
  vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = 
16045693110842147038,

  vnet_shutdown = 222}

So the multicast code is fine, it holds and releases a reference to
ifnet..

The issue is that the reference to the ifnet doesn't involve a
reference to the vnet/prison.


Does it need to?  The ifnet cannot go away while something holds a 
reference to it, right?


Sounds more like the teardown order is wrong (again)?

There should be no more multicast when IP etc. is gone.  That means MC 
doesn’t properly cleanup itself.


I guess I should go back now and re-read your original problem statement 
on how you trigger this..


/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 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context

[bugzilla-noreply]

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

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

Author: kp
Date: Wed Jul 22 20:13:13 UTC 2020
New revision: 363430
URL: https://svnweb.freebsd.org/changeset/base/363430

Log:
  bridge: Enter epoch for bridge_input()/bridge_output()

  In stable/12 epoch is not as wide as it is in head. The network stack isn't
yet
  in epoch when bridge_input()/bridge_output() get called, so rather than
assert
  this we must enter it ourselves.

  This is a direct commit to stable/12.

  PR:   248046
  Differential Revision:https://reviews.freebsd.org/D25715

Changes:
  stable/12/sys/net/if_bridge.c

-- 
You are receiving this mail because:
You are the assignee for the bug.
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 248046] if_bridge(4): Panic when creating an interface: malloc(M_WAITOK) in epoch context

[bugzilla-noreply]

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

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

Author: kp
Date: Wed Jul 22 19:43:56 UTC 2020
New revision: 363429
URL: https://svnweb.freebsd.org/changeset/base/363429

Log:
  MFC r363308:

  bridge: Don't sleep during epoch

  While it doesn't trigger INVARIANTS or WITNESS on head it does in stable/12.
  There's also no reason for it, as we can easily report the out of memory
error
  to the caller (i.e. userspace). All of these can already fail.

  PR:   248046

Changes:
_U  stable/12/
  stable/12/sys/net/if_bridge.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.
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: somewhat reproducable vimage panic

[John-Mark Gurney]

John-Mark Gurney wrote this message on Tue, Jul 21, 2020 at 23:05 -0700:
> Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:
> > Is this related to 
> > 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
> >  and 
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 
> > 
> 
> Definitely not 234985..  I'm using ue interfaces, and so they don't
> get destroyed while the jail is going away...
> 
> I don't think it's 238326 either.  This is 100% reliable and it's in
> the IP multicast code..  It looks like in_multi isn't holding an
> interface or address lock waiting for things to free up...

Did a little more poking, and it looks like the vnet is free'd before
the ifnet is free'd causing this problem:
(kgdb) print inm->inm_ifp[0].if_refcount 
$5 = 1
(kgdb) print inm->inm_ifp[0].if_vnet[0]  
$6 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 0xdeadc0dedeadc0de},
  vnet_magic_n = 3735929054, vnet_ifcnt = 3735929054,
  vnet_sockcnt = 3735929054, vnet_state = 3735929054,
  vnet_data_mem = 0xdeadc0dedeadc0de, vnet_data_base = 16045693110842147038,
  vnet_shutdown = 222}

So the multicast code is fine, it holds and releases a reference to
ifnet..

The issue is that the reference to the ifnet doesn't involve a
reference to the vnet/prison.

I have noticed that a number of times after a jail destroy that one
of my interfaces doesn't make it back to the main OS.. it's just gone..

I can "make" it reappear by reseting the hardware, but that does imply
that an ifnet is hanging out in limbo...

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"

[Bug 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #8 from Gert Doering  ---
I do not understand enough of the FreeBSD IPv6 magic bits to reasonably argue
either way.

The rc.conf of this system is very minimal

-- cut 
hostname="fbsd-tc.ov.greenie.net"
ifconfig_em0="inet 194.97.140.21 netmask 255.255.255.224"
defaultrouter="194.97.140.30"
ipv6_defaultrouter="2001:608:0:814::"
ifconfig_em0_ipv6="inet6 2001:608:0:814::f000:21/64"
sshd_enable="YES"
ntpdate_enable="YES"
ntpd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
inetd_enable=YES# gert, 30.9.19, amanda
-- cut 

but I'd still argue it should be deterministic either way, like "always
IFFIDSABLED" or "never".

Anyway, test program coming.  Might take until tomorrow.

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

Yatırımcılar İçin Şirket Değerleme

[Türkiye Sermaye Piyasaları Birliği]

TSPB Birlikte Eğitim Mesleki Gelişim Eğitimleri





Blteni Daha İyi Grntlemek İin Tıklayın
[http://track-5.track-my-url.com/0001D2389711|01019c00fdf926bb981d59ee664f79715a6a|10105354|1011469|01012436.html]TSPB
Birlikte Eğitim Mesleki Gelişim Eğitimleri
"Yatırımcılar İin Şirket Değerleme"
-

Online Eğitim"Zoom"uygulaması zerinden
gerekleştirilecektir.

Eğitimin 25 kişilik kontenjanı bulunmaktadır.

Başvurularını gerekleştirilen katılımcılara online eğitime
giriş iin gerekli bilgiler iletilecektir.

Başvuru iin: www.tspb.org.tr
[http://track-5.track-my-url.com/1011L2389711|01105354|010022069|1101T.html]


yelik ve başvurularınızla ilgili sorularınız iin:
info@birlikteeğitim.org [mailto:info@birlikteeğitim.org]
ve ya aşağıdaki telefon numarasından bize ulaşabilirsiniz.


   Eğitmen: Erkin Şahinz-Eski FED EkonomistiErste
Bank Ceo'su-Erkin Şahinz Danışmanlık

Eğitim Tarihi: 17 Ağustos 2020
Eğitim Sresi:  Gn
Ders Saati: 13:30-17:30

Eğitim creti: 200 TL (KDV dahil, kişi başı)

Eğitim Yeri: Online Eğitim-Zoom

Başvuru: www.tspb.org.tr
[http://track-5.track-my-url.com/1011L2389711|10105354|110022069|1010T.html]


TSPB Birlikte Eğitim
Bykdere Caddesi No: 173 1.Levent Plaza A Blok Kat4
Şişli-İstanbul
Telefon: 0212 280 85 67
i...@birlikteegitim.org [mailto:i...@birlikteegitim.org]
www.tspb.org.tr
[http://track-5.track-my-url.com/0011L2389711|10115354|00015892|0011T.html]


Şirket değerini etkileyen faktrler nelerdir?

Marka değerlemesi nasıl yapılır?

Hassasiyet analizinde dikkat edilmesi gereken hususlar nelerdir?

İndirgenmiş nakit akımı ile değerleme nasıl yapılır?

arpan seimindeki kritik parametreler nelerdir?

17 Ağustos 2020 tarihinde "Yatırımcılar İin Şirket
Değerleme" online eğitimimize bekliyoruz.

EĞİTİM KONULARI

Şirket değerini etkileyen faktrler

Marka, kontrat ve mşteri portfy gibi maddi olmayan
varlıkların değerlemesi

Şirket değerini arttırmaya ynelik neriler

Satın alma ve birleşme srelerinin ynetimi

Finansal gzden geirme (check-up)

Net varlık yntemi

İndirgenmiş nakit akımı yntemi

Piyasa arpanları yntemi

Hassasiyet analiziBu e-posta tarafınıza TSPB tarafından oluşturulan
ye veritabanına kayıtlı olduğunuz iin
gnderilmiştir.Beni bu listeden ıkar
[http://track-5.track-my-url.com/0010U2389711|00119c00fdf926bb981d59ee664f79715a6a|0101469|10015354.html]

___
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #7 from Kyle Evans  ---
(In reply to Kyle Evans from comment #6)

s/nd6/ndp/

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

 CC||b...@freebsd.org

--- Comment #6 from Kyle Evans  ---
(In reply to Gert Doering from comment #5)

Interesting; if you're not getting at least this message:

$ifname: possible hardware address duplication detected, disable IPv4

Then, AFAICT, this probably indicates that rtsold or nd6 has for some reason
explicitly disabled it... I guess probably the former. CC'ing bz@ because I'm
less sure now that it's specifically a tun/tap issue and not a broader issue.

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #5 from Gert Doering  ---
(In reply to Kyle Evans from comment #3)

nd6_dad_timer: cancel DAD on tun0 because of ND6_IFF_IFDISABLED.
nd6_dad_timer: cancel DAD on tun0 because of ND6_IFF_IFDISABLED.

this is what I have, but it's sort of not explaining "why ifdisabled" but just
logging the consequences.

Might this be related?

nd6_dad_timer: called with non-tentative address
fe80:3::250:56ff:fe9c:dffb(tun0)

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #4 from Gert Doering  ---
Hi,

thanks for your quick replies.  A few answers right away:


- Exact freebsd versions affected (uname -a)

FreeBSD fbsd-tc.ov.greenie.net 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC 
amd64

- Minimum network configuration necessary to reproduce (/etc/rc.conf, openvpn
or pure tun/tap config (ideally))

Sharing the actual OpenVPN config is complicated (the config is very simple,
but it's part of our CI tests, so without "the other end" it won't do much)

- truss or similar trace output under reproduction (as an attachment)
- /var/run/dmesg.boot output (as an attachment)
- confirmation whether openvpn/openvpn-devel from ports/packages also exhibits
this issue.

Right now, my system is stubbornly refusing to show the effect at all - but if
it does so, the effect is the same for openvpn (2.4.x) or openvpn-devel (which
is our git master state as of two days ago, with no FreeBSD specific patches).

While it nicely did this for "80%" of the cases beforehand...

I think the easiest way is to write a test program, which I'll do tonight and
attach it.

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #3 from Kyle Evans  ---
Is there any additional information about the interface in the syslog? It looks
like there's only three possible places that ND6_IFF_IFDISABLED can be set, and
two of them output errors:

$ifname: possible hardware address duplication detected, disable IPv4

Cannot enable an interface with a link-local address marked duplicate.

Noting that the second message doesn't indicate an interface name.

-- 
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

Kyle Evans  changed:

   What|Removed |Added

   Assignee|n...@freebsd.org |kev...@freebsd.org
 CC||kev...@freebsd.org

-- 
You are receiving this mail because:
You are on the CC list for the bug.
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

Kubilay Kocak  changed:

   What|Removed |Added

 Status|New |Open
   Keywords||needs-qa, regression
   Severity|Affects Only Me |Affects Some People
  Flags||mfc-stable12?
   Assignee|b...@freebsd.org|n...@freebsd.org
Summary|OpenVPN configuring tun/tap |tun/tap: OpenVPN
   |devices ends up with|configuring tun/tap devices
   |IFDISABLED interfacs|ends up with IFDISABLED
   ||interfaces
 CC||mand...@freebsd.org,
   ||n...@freebsd.org

--- Comment #1 from Kubilay Kocak  ---
Hi Gert, thank you for your report. 

A reduced test case/program would be certainly by ideal, but also the following
information would be useful if you can provide it:

- Exact freebsd versions affected (uname -a)
- Minimum network configuration necessary to reproduce (/etc/rc.conf, openvpn
or pure tun/tap config (ideally))
- truss or similar trace output under reproduction (as an attachment)
- /var/run/dmesg.boot output (as an attachment)
- confirmation whether openvpn/openvpn-devel from ports/packages also exhibits
this issue.

Additionally, we've had many changes in current since 12 was branched, I'd
probably test a 13-CURRENT snapshot too (the issue may have been identified and
resolved)

^Triage:  cc net/openvpn maintainer

-- 
You are receiving this mail because:
You are the assignee for the bug.
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 248172] tun/tap: OpenVPN configuring tun/tap devices ends up with IFDISABLED interfaces

[bugzilla-noreply]

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

--- Comment #2 from Kyle Evans  ---
(In reply to Gert Doering from comment #0)

Hi,

If you could provide me a test case that reproduces it somewhat reliably, I'd
appreciate it; in 12.2, tun/tap have been consolidated into a single driver and
some other races fixed along the way. You could try testing on recent stable/12
to see if you can reproduce it at all before reduced test case.

I'll look over the driver briefly and see if I can spot an immediate issue
along these lines.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
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: somewhat reproducable vimage panic

[John-Mark Gurney]

Peter Libassi wrote this message on Wed, Jul 22, 2020 at 06:54 +0200:
> Is this related to 
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 
>  and 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238326 
> 

Definitely not 234985..  I'm using ue interfaces, and so they don't
get destroyed while the jail is going away...

I don't think it's 238326 either.  This is 100% reliable and it's in
the IP multicast code..  It looks like in_multi isn't holding an
interface or address lock waiting for things to free up...

> > 21 juli 2020 kl. 22:23 skrev John-Mark Gurney :
> > 
> > Marko Zec wrote this message on Tue, Jul 21, 2020 at 11:31 +0200:
> >> On Tue, 21 Jul 2020 02:16:55 -0700
> >> John-Mark Gurney  wrote:
> >> 
> >>> I'm running:
> >>> FreeBSD test 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r362596: Thu Jun 25
> >>> 05:02:51 UTC 2020
> >>> r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
> >>> amd64
> >>> 
> >>> and I'm working on improve the if_ure driver.  I've put together a
> >>> little script that I've attached that I'm using to test the driver..
> >>> It puts a couple ue interfaces each into their own jail, configures
> >>> them, and tries to pass traffic.  This assumes that the two interfaces
> >>> are connected together.
> >>> 
> >>> Pretty regularly when destroying the jails, I get the following
> >>> panic: CURVNET_SET at /usr/src/sys/netinet/in_mcast.c:626
> >>> inm_release() curvnet=0 vnet=0xf80154c82a80
> >> 
> >> Perhaps the attached patch could help? (disclaimer: not even
> >> compile-tested)
> > 
> > The patch compiled, but it just moved the panic earlier than before.
> > 
> > #4  0x80bc2123 in panic (fmt=)
> >at ../../../kern/kern_shutdown.c:839
> > #5  0x80d61726 in inm_release_task (arg=, 
> >pending=) at ../../../netinet/in_mcast.c:633
> > #6  0x80c2166a in taskqueue_run_locked (queue=0xf800033cfd00)
> >at ../../../kern/subr_taskqueue.c:476
> > #7  0x80c226e4 in taskqueue_thread_loop (arg=)
> >at ../../../kern/subr_taskqueue.c:793
> > 
> > Now it panics at the location of the new CURVNET_SET and not the
> > old one..
> > 
> > Ok, decided to dump the contents of the vnet, and it looks like
> > it's a use after free:
> > (kgdb) print/x *(struct vnet *)0xf8012a283140
> > $2 = {vnet_le = {le_next = 0xdeadc0dedeadc0de, le_prev = 
> > 0xdeadc0dedeadc0de}, vnet_magic_n = 0xdeadc0de, 
> >  vnet_ifcnt = 0xdeadc0de, vnet_sockcnt = 0xdeadc0de, vnet_state = 
> > 0xdeadc0de, vnet_data_mem = 0xdeadc0dedeadc0de, 
> >  vnet_data_base = 0xdeadc0dedeadc0de, vnet_shutdown = 0xde}
> > 
> > The patch did seem to make it happen quicker, or maybe I was just more
> > lucky this morning...
> > 
> >>> (kgdb) #0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
> >>> #1  doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:394
> >>> #2  0x80bc6250 in kern_reboot (howto=260)
> >>>at /usr/src/sys/kern/kern_shutdown.c:481
> >>> #3  0x80bc66aa in vpanic (fmt=, ap= >>> out>) at /usr/src/sys/kern/kern_shutdown.c:913
> >>> #4  0x80bc6403 in panic (fmt=)
> >>>at /usr/src/sys/kern/kern_shutdown.c:839
> >>> #5  0x80d6553b in inm_release (inm=0xf80029043700)
> >>>at /usr/src/sys/netinet/in_mcast.c:630
> >>> #6  inm_release_task (arg=, pending=)
> >>>at /usr/src/sys/netinet/in_mcast.c:312
> >>> #7  0x80c2521a in taskqueue_run_locked
> >>> (queue=0xf80003116b00) at /usr/src/sys/kern/subr_taskqueue.c:476
> >>> #8  0x80c26294 in taskqueue_thread_loop (arg=)
> >>>at /usr/src/sys/kern/subr_taskqueue.c:793
> >>> #9  0x80b830f0 in fork_exit (
> >>>callout=0x80c26200 , 
> >>>arg=0x81cf4f70 ,
> >>> frame=0xfe0049e99b80) at /usr/src/sys/kern/kern_fork.c:1052
> >>> #10 
> >>> (kgdb) 
> >>> 
> >>> I have the core files so I can get additional information.
> >>> 
> >>> Let me know if you need any additional information.
> >>> 
> >> 
> > 
> >> Index: sys/netinet/in_mcast.c
> >> ===
> >> --- sys/netinet/in_mcast.c (revision 363386)
> >> +++ sys/netinet/in_mcast.c (working copy)
> >> @@ -309,8 +309,10 @@
> >>IN_MULTI_LOCK();
> >>SLIST_FOREACH_SAFE(inm, _free_tmp, inm_nrele, tinm) {
> >>SLIST_REMOVE_HEAD(_free_tmp, inm_nrele);
> >> +  CURVNET_SET(inm->inm_ifp->if_vnet);
> >>MPASS(inm);
> >>inm_release(inm);
> >> +  CURVNET_RESTORE();
> >>}
> >>IN_MULTI_UNLOCK();
> >> }

-- 
  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
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to