https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285129
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
Keywords
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236888
--- Comment #4 from Patrick Mackinlay ---
I have been using mpd5, so its not an issue for me, but it would be nice if at
least the docs made it clear that you can't change the MTU for PPPoE
--
You are receiving this mail because:
Yo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236888
Mark Linimon changed:
What|Removed |Added
Flags|mfc-stable12?, |
|mfc-stable11?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #11 from Eugene Grosbein ---
(In reply to O. Hartmann from comment #10)
Please re-read comments above and provide requested debug information.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #10 from O. Hartmann ---
(In reply to Eugene Grosbein from comment #9)
Yes, it is. The above described problem can be easily reproduced on any APU we
run with nanobsd and mpd5 running and configured using PPPoE. A simple
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #9 from Eugene Grosbein ---
Is this problem still relevant?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #8 from O. Hartmann ---
(In reply to Eugene Grosbein from comment #7)
I'll do so as soon as building a new image for the appliances in question.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #7 from Eugene Grosbein ---
(In reply to O. Hartmann from comment #4)
You have to add "options KDB_TRACE" at very least.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
Eugene Grosbein changed:
What|Removed |Added
Blocks|272319 |
--- Comment #6 from Eugene Gros
which is about problem
in ng_ksocket(4). When mpd5 runs PPPoE, it doesn't use ng_ksocket.
We need backtrace for the panic to understand what's going on. Please
obtain it and post to the bug. More info on obtaining backtrace:
https://docs.freebsd.org/en/books/developers-hand
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #4 from O. Hartmann ---
(In reply to Eugene Grosbein from comment #2)
PR 272319 claims to have fixed the problem except for kernels with INVARIANTS
option.
My customized kernel has been stripped off almost every debugging and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
O. Hartmann changed:
What|Removed |Added
Blocks||272319
Referenced Bugs:
https://bu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
--- Comment #3 from O. Hartmann ---
As of today, the appliance has
FreeBSD 14.1-STABLE #2 stable/14-n267607-7e10c2d27a53: Sat May 4 08:33:15 CEST
2024 amd64
The router/FW was up a couple of days/weeks for now. We stopped triggering a
res
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
Eugene Grosbein changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=276294
Eugene Grosbein changed:
What|Removed |Added
Keywords||crash, needs-qa
Versi
> -Original Message-
> From: dri...@freebsd.org
> Sent: Saturday, 17 September 2022 10:18
> To: 'Evilham'
> Cc: freebsd-net@freebsd.org
> Subject: RE: PPPoE (mpd5) IPv6 issues
>
> > -Original Message-
> > From: Evilham
> >
> -Original Message-
> From: Evilham
> Sent: Friday, 16 September 2022 22:00
> To: dri...@freebsd.org
> Cc: freebsd-net@freebsd.org
> Subject: Re: PPPoE (mpd5) IPv6 issues
>
> Hey,
>
> On dv., set. 16 2022, dri...@freebsd.org wrote:
>
> > Hmm
Hey,
On dv., set. 16 2022, dri...@freebsd.org wrote:
Hmm this mail was not finished, sorry about that.
I will include the link that fell-off, IPv6 PPPoE MSS incorrect
| Netgate Forum
Any help or pointers are greatly appreciated!
PS: I use IPFW as my firewall, if this has anything to
Hmm this mail was not finished, sorry about that.
I will include the link that fell-off,
<https://forum.netgate.com/topic/152935/ipv6-pppoe-mss-incorrect> IPv6 PPPoE
MSS incorrect | Netgate Forum
Any help or pointers are greatly appreciated!
PS: I use IPFW as my firewall, if th
Hi freebsd-net!
After a lot of google and tinkering I have hit a brick wall trying to set-up
my new ISP which uses PPPoE.
I'm at the point where IPv4 works fine 100% for all websites. But from the
moment I turn on IPv6 all sites that prefer IPv6 stop working, I have
confirmed that ro
On dt., set. 21 2021, driesm.michi...@gmail.com wrote:
-Original Message-
From: Evilham
Sent: Tuesday, 21 September 2021 09:49
To: driesm.michi...@gmail.com
Cc: freebsd-net@freebsd.org
Subject: Re: Performance of PPPOE in FreeBSD
On dl., set. 20 2021, driesm.michi...@gmail.com
> -Original Message-
> From: Evilham
> Sent: Tuesday, 21 September 2021 09:49
> To: driesm.michi...@gmail.com
> Cc: freebsd-net@freebsd.org
> Subject: Re: Performance of PPPOE in FreeBSD
>
>
> On dl., set. 20 2021, driesm.michi...@gmail.com wrote:
50 up
(mbps).
They use PPPOE and was wondering what the max troughput looks
like with the
in-base PPPOE client?
I have also found some mentions of net/mpd5, is this a better
implementation?
Thanks
Dries
I wrote my experience with PPPoE for a dual-stack FreeBSD router
back in very late
21.09.2021 2:32, driesm.michi...@gmail.com wrote:
> I have also found some mentions of net/mpd5, is this a better
> implementation?
Basically, it all depends on available CPU horsepower and if you have plenty of
it unused,
you can stick with base ppp(8). But in any case, net/mpd5 provides huge C
Proximus seems to provide a fibre plan (if
> fibre is available, but it should be) that does 500 down / 50 up (mbps).
>
> They use PPPOE and was wondering what the max troughput looks like with the
> in-base PPPOE client?
>
On my small APU2C4 box the in-base PPPOE client used 1
).
But I really want a higher upload in my future appartment where I will be
moving is *soonTm*.
So looking for ISP's in Belgium, Proximus seems to provide a fibre plan (if
fibre is available, but it should be) that does 500 down / 50 up (mbps).
They use PPPOE and was wondering what th
I have CenturyLink GPON service, which uses PPPoE.
I've read about the performance bottleneck with PPPoE over igb
interfaces limiting throughput to only a few hundred Mbps unless run on
fairly capable hardware. Caveat: the posts that discuss this issue are
a few years old.
The hardw
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Kubilay Kocak changed:
What|Removed |Added
Flags|mfc-stable11?, |mfc-stable11+,
|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
--- Comment #9 from commit-h...@freebsd.org ---
A commit references this bug:
Author: emaste
Date: Wed Aug 14 13:15:39 UTC 2019
New revision: 351026
URL: https://svnweb.freebsd.org/changeset/base/351026
Log:
MFC r350497: ppp: correct ech
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Ed Maste changed:
What|Removed |Added
Status|In Progress |Closed
Resolution|---
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
--- Comment #8 from commit-h...@freebsd.org ---
A commit references this bug:
Author: emaste
Date: Wed Aug 14 13:14:48 UTC 2019
New revision: 351025
URL: https://svnweb.freebsd.org/changeset/base/351025
Log:
MFC r350497: ppp: correct ech
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Ed Maste changed:
What|Removed |Added
Status|Open|In Progress
--
You are receiving this
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Kubilay Kocak changed:
What|Removed |Added
Summary|[ppp] [patch] Kernel PPPoE |ppp: Kernel PPPoE sends bad
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
--- Comment #7 from commit-h...@freebsd.org ---
A commit references this bug:
Author: emaste
Date: Thu Aug 1 13:42:59 UTC 2019
New revision: 350497
URL: https://svnweb.freebsd.org/changeset/base/350497
Log:
ppp: correct echo-req magic n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Rodney W. Grimes changed:
What|Removed |Added
CC||n...@freebsd.org
--
You are re
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Ed Maste changed:
What|Removed |Added
Assignee|n...@freebsd.org |ema...@freebsd.org
--
You are receivi
?,
||mfc-stable12?
Summary|ppp daemon limits mtu to|ppp daemon: Allow MTU to be
|1492 for PPPoE |overridden for PPPoE in
||ppp.conf
Keywords
#2 from Eugene Grosbein ---
You can use mpd5 port or package that can act as PPPoE client and has support
for mtu over 1492.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236888
--- Comment #1 from Patrick Mackinlay ---
To be clear, this issue only applies to PPPoE,
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236888
Mark Linimon changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are receiv
22.02.2019 2:41, BulkMailForRudy wrote:
>
> On 2/20/19 1:13 PM, Eugene Grosbein wrote:
>> 21.02.2019 3:37, BulkMailForRudy wrote:
>>
>>> Dear FreeBSD-net,
>>>
>>> PPPoE has some broadcast ethernet frames...
>>>
>>> I have epair0a on m
On 2/20/19 1:13 PM, Eugene Grosbein wrote:
21.02.2019 3:37, BulkMailForRudy wrote:
Dear FreeBSD-net,
PPPoE has some broadcast ethernet frames...
I have epair0a on my bridge and epair0b in the jail, but the jail doesn't get
any PADI (PPPoE packets destinged to ff:ff:ff:ff:ff:ff).
Is
Hi all,
> Am 21.02.2019 um 08:23 schrieb Alexander Zagrebin :
> To pass PPPoE packets via bridge you have to set the kernel variable
> net.link.bridge.pfil_onlyip to 0 (`sysctl
> net.link.bridge.pfil_onlyip=0`)…
Doesn’t this apply only if you have some kind of packet filter active on
В Wed, 20 Feb 2019 12:37:39 -0800
BulkMailForRudy пишет:
> PPPoE has some broadcast ethernet frames...
>
> I have epair0a on my bridge and epair0b in the jail, but the jail
> doesn't get any PADI (PPPoE packets destinged to ff:ff:ff:ff:ff:ff).
>
> Is there a way to hav
21.02.2019 3:37, BulkMailForRudy wrote:
> Dear FreeBSD-net,
>
> PPPoE has some broadcast ethernet frames...
>
> I have epair0a on my bridge and epair0b in the jail, but the jail doesn't get
> any PADI (PPPoE packets destinged to ff:ff:ff:ff:ff:ff).
>
> Is th
Dear FreeBSD-net,
PPPoE has some broadcast ethernet frames...
I have epair0a on my bridge and epair0b in the jail, but the jail
doesn't get any PADI (PPPoE packets destinged to ff:ff:ff:ff:ff:ff).
Is there a way to have bridge pass broadcast ethernet frames? (tcpdump
in the jail sho
problem in first place: it tried to add
> a
> sysctl to disable flowid generation by igb(4) driver based on (always zero for
> PPPoE) hardware flow id assigned by the chip. It was meaningless from the
> beginning.
>
___
freebsd-net@freebsd.o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184141
Eugene Grosbein changed:
What|Removed |Added
Assignee|j...@freebsd.org |n...@freebsd.org
|--- |FIXED
CC||eu...@freebsd.org
--- Comment #1 from Eugene Grosbein ---
Just use net/mpd5 port/package that has requested RFC 4638 PPPoE client
support.
--
You are receiving this mail because:
You are the assignee for the bug
o add a
sysctl to disable flowid generation by igb(4) driver based on (always zero for
PPPoE) hardware flow id assigned by the chip. It was meaningless from the
beginning.
--
You are receiving this mail because:
You are the assignee for the bug.
___
fr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #30 from Kurt Jaeger ---
(In reply to anoteros from comment #1)
This link for a patch seems valid:
http://static.ipfw.ru/patches/igb_flowid.diff
Did anyone test with that ? Does that still apply ?
--
You are receiving this
27.07.2018 14:19, Richard Pasztor wrote:
> Hi Eugene,
>
> the details you requested:
>
> Router Hardware: PC Engines APU2C4 (http://pcengines.ch/apu2c4.htm)
> 3x i210AT NIC / AMD GX-412TC CPU / 4 GB DRAM
>
> Router Software: Opnsense 18.1.13
> OS: FreeBSD 11.1-RELEASE-p11 FreeBSD 11.1-RELEASE-p
pfil_local_phys="0"
net.link.bridge.pfil_member="1"
net.link.bridge.pfil_bridge="0"
net.link.tap.user_open="1"
kern.randompid="347"
net.inet.ip.intr_queue_maxlen="1000"
hw.syscons.kbd_reboot="0"
net.inet.tcp.log_debug="0"
net.inet.i
26.07.2018 21:40, Eugene Grosbein wrote:
> Show output of "top -SHPI" at receiving side while performing your test.
> Also, include output of "systat -vm 3" while traffic flows.
Also include output of "systat -ifstat 3" while traffic flows, too.
___
fr
26.07.2018 21:27, Richard Pasztor wrote:
> Note2: I am not at the level of building a proper PPPoE simlator network to
> properly validate the final performance, all my tests were performed using
> pure IP routing. So expect PPPoE can be by definition only worse than what
> I can po
Dear all,
continuing the discussion from here:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
summary:
(technically affects any NIC) Multi-queue NIC can use only RX queue "0", if
PPPoE session is established (due to point-to-point connection, the RSS
cannot load balance amon
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #29 from Vladimir ---
(In reply to Eugene Grosbein from comment #28)
No, just wanted to confirm.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #28 from Eugene Grosbein ---
(In reply to Vladimir from comment #27)
Yes. Have you missed comment #11 describing possible solutions including this?
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #27 from Vladimir ---
Do you mean something like net.isr.dispatch=deferred ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #26 from Eugene Grosbein ---
(In reply to ricsip from comment #24)
Please use our mailing lists or web forums for general support questions of
discussion and leave Bugzilla for bug reports. Again, the problem has nothing
to do
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #25 from Jan Bramkamp ---
Does Linux use RSS to achieve this performance or does it drain the NIC queue
in a single interrupt and load balance the rest? Did you try the netisr
workaround?
--
You are receiving this mail because
performance seen under Freebsd/opnsense. Same purely IP-routing based testing
as I did with opnsense, as I dont have the knowledge to build a proper PPPoE
simulator lab.
Well, using ipfire I could reach 850-900 Mbit/sec on single-flow iperf, that
was only possible with multi-flow iperf under
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #23 from Eugene Grosbein ---
(In reply to ricsip from comment #22)
This greatly depends on local conditions. There is exactly same problem for
PPtP-connected client using GRE encapsulation (not clean TCP) when all traffic
is de
NIC on
the market is a pure marketing gimmick, if the connection type on the NIC will
be set as ="PPPoE" and not as "pure-IP". Indeed, somebody with the necessary
network background could easily decrypt the true meaning of the various tables
(quote from Intel i210 datasheet
NIC on
the market is a pure marketing gimmick, if the connection type on the NIC will
be set as ="PPPoE" and not as "pure-IP". Indeed, somebody with the necessary
network background could easily decrypt the true meaning of the various tables
(Intel i210 datasheet):
RSS and MSI
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #20 from Eugene Grosbein ---
(In reply to ricsip from comment #19)
Again, this is not igb(4) driver "broken", these are corresponding network
cards having no hardware support to distribute PPPoE traffic per-queu
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #19 from ricsip ---
(In reply to Eugene Grosbein from comment #16)
Gents, if the igb (and any other NIC on the planet) is so fundamentally broken
for multi-queue + PPPoe, at least make this clear written in the drivers "
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #18 from Vladimir ---
I think most people expect that igb hardware works the same way under FreeBSD
like it works under other OSes like Linux or whatever... Windows, I think this
pointed me also to think that it is driver proble
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #17 from Vladimir ---
Thanks, Eugene.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mai
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #16 from Eugene Grosbein ---
(In reply to Vladimir from comment #14)
I guess you can read Russian, please take a look at my post
https://dadv.livejournal.com/139170.html , it may make things clearer for you.
--
You are receiv
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #15 from Eugene Grosbein ---
(In reply to Vladimir from comment #14)
The problem is in hardware card not supporting PPPoE per-queue load
distribution, not in the driver. Why anyone would think that igb-supported NICs
are
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #14 from Vladimir ---
If the problem is isolated to igb driver only, could it be igb driver problem,
no?
Why then there was patch for igb, that currently missing?
https://wiki.freebsd.org/NetworkPerformanceTuning (Traffic flow
dware support for PPPoE per-queue distribution,
period.
Though, feel free to open new PR if you have performance problems with
netisr(9) queues or "PPPoE instance lock" (no matter what is it).
--
You are receiving this mail because:
You are the assig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #12 from Jan Bramkamp ---
I may work as intended, but that doesn't mean that it works well, because if I
remember correctly there is a single lock in each PPPoE instance as well so you
just moved the bottleneck a little b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
Eugene Grosbein changed:
What|Removed |Added
Resolution|--- |Works As Intended
St
containing IPv4 or IPv6 packets are hashed using their IP addresses
as hash function arguments and, optionally, TCP port numbers.
This means that all incoming PPPoE ethernet frames are NOT hashed by such NIC
in hardware, as any other frames carrying no plain IPv4 nor IPv6 packets. This
is the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #10 from ricsip ---
(In reply to Jan Bramkamp from comment #9)
Your reply greatly appreciated. My intention was to see if a stone is dropped
into the lake, it may create some waves and progress may happen.
TBH I was unaware o
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
--- Comment #9 from Jan Bramkamp ---
(In reply to ricsip from comment #7)
The problem exists and can be fixed, but would require non-trivial changes. I
suspect that the problem isn't specific to the Intel NIC driver and that you'll
encount
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203856
Mark Linimon changed:
What|Removed |Added
Keywords||IntelNetworking
Assignee|
* This structure is used to send PADM messages from server to client.
+ */
+struct ngpppoe_padm {
+ char msg[PPPOE_PADM_VALUE_SIZE];
+};
+
/
* Constants and d
ale added a comment.
I'd like to see this in the next 11.2-RELEASE. @eugen_grosbein.net can you
please commit it and MFH?
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreference
franco_opnsense.org added a comment.
Any news on this? :)
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, wblock, #network, julian, mav, adrian, gl
wblock added a comment.
Man page changes look good to me. Please remember to bump .Dd. Thanks!
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, wb
eugen_grosbein.net accepted this revision.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, wblock, #network, julian, mav, adrian, glebius,
franco_opns
franco_opnsense.org accepted this revision.
franco_opnsense.org added a comment.
this one is stable, thank you @ale
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To:
-157,6 +163,13 @@
uint16_t data;
};
+/*
+ * This structure is used to send PADM messages from server to client.
+ */
+struct ngpppoe_padm {
+ char msg[PPPOE_PADM_VALUE_SIZE];
+};
+
/
* Constants and definitions spe
eugen_grosbein.net added a comment.
> No, I'm not asking for support that would take a few weeks of ping pong in
a bug tracker, if any. This is real world feedback for this review. Take it or
leave it. :)
I was going to deal with this problem but I need mentioned details to start
with.
franco_opnsense.org added a comment.
No, I'm not asking for support that would take a few weeks of ping pong in a
bug tracker, if any. This is real world feedback for this review. Take it or
leave it. :)
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9
eugen_grosbein.net added a comment.
In https://reviews.freebsd.org/D9270#251108, @franco_opnsense.org wrote:
> Thanks, but we've narrowed it down to this commit.
Anyway, Bugzilla should be used for bug reports. Don't forget to describe how
did you narrowed it to the commit in your
franco_opnsense.org added a comment.
Thanks, but we've narrowed it down to this commit.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, wblock, #ne
eugen_grosbein.net added a comment.
In https://reviews.freebsd.org/D9270#251087, @franco_opnsense.org wrote:
> We do seem to have a persistent problem with this patch in some PPPoE
environments that will cause a crash in ng_pppoe_rcvdata_ether():
>
> https://ibb.co/mRWKHF
franco_opnsense.org added a comment.
We do seem to have a persistent problem with this patch in some PPPoE
environments that will cause a crash in ng_pppoe_rcvdata_ether():
https://ibb.co/mRWKHF
https://ibb.co/iOxRxF
https://forum.opnsense.org/index.php?topic=5697.0
Please
ale added a comment.
> How the tag should be defined in mpd.conf then?
>
> set auth host-uniq "string" ?
No, to just set the host-uniq string you should use:
set pppoe service "string|"
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
http
mleone87_hotmail.com added a comment.
In https://reviews.freebsd.org/D9270#212547, @ale wrote:
> Addressed latest comments, updated also the pppoe disconnect function.
> Please check the correctness, and commit the patch if you are satisfied.
How the tag should be defi
ale marked 5 inline comments as done.
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/emailpreferences/
To: ale, #manpages, wblock, #network, julian, mav, adrian, glebius
Cc: glebius, wbloc
ale updated this revision to Diff 27059.
ale added a comment.
Addressed latest comments, updated also the pppoe disconnect function.
Please check the correctness, and commit the patch if you are satisfied.
REPOSITORY
rS FreeBSD src repository
CHANGES SINCE LAST UPDATE
https
ale added a comment.
The three mentioned comments apply also to the ng_pppoe_disconnect function
at line 2030 from which I took inspiration, do you want me to change that
function, too?
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERE
glebius requested changes to this revision.
glebius added a comment.
This revision now requires changes to proceed.
I got few minor comments.
INLINE COMMENTS
> ng_pppoe.c:1135
> + /* Generate a packet of that type. */
> + MGETHDR(m, M_NOWAIT, MT_DATA);
ale added a comment.
This revision now requires review to proceed.
Who is going to commit it in the src tree and merge in 11 branch?
REPOSITORY
rS FreeBSD src repository
REVISION DETAIL
https://reviews.freebsd.org/D9270
EMAIL PREFERENCES
https://reviews.freebsd.org/settings/panel/email
wblock accepted this revision.
wblock added a comment.
This revision has a positive review.
One suggestion, but looks good otherwise. Thank you!
INLINE COMMENTS
> ng_pppoe.4:115
> +.Qq Li 0x ,
> +eg.
> +.Qq Li 0x6d792d746167
Would prefer "like" or "for example" to exempli gratia here (see
1 - 100 of 631 matches
Mail list logo
