[Bug 227461] [hast] regression, unable to start hast, pid XXX (hastd), uid 0: exited on signal 6 (core dumped)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227461 --- Comment #5 from e...@norma.perm.ru --- Created attachment 192583 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=192583&action=edit HAST nodebug patch This patch removes several debug lines leading to SIGABRT. -- 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 227461] [hast] regression, unable to start hast, pid XXX (hastd), uid 0: exited on signal 6 (core dumped)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227461 --- Comment #6 from e...@norma.perm.ru --- This patch removes the debugging leading to SIGABRT, the author is a...@freebsd.org. ae@ is pessimistic about it, saying that it solves nothing, and just makes HAST to contunue by removing the abort() call in pjdlog_abort(). However, this got me a working HAST, first time without a bunch of warning/error/assert messages on both nodes. This probably need more attention. -- 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 221919] ixl: TX queue hang when using TSO and having a high and mixed network load
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221919 Steven Hartland changed: What|Removed |Added CC||s...@freebsd.org --- Comment #18 from Steven Hartland --- That review is still pending. We've just had what appears to be a RX hang with TSO disabled, related? No messages in /var/log/messages tcpdump still showing outbound traffic but no inbound, had to reboot to recover. -- 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 227502] Unable to add pfsense as monitored target in ntopng
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227502 --- Comment #2 from Florin Samareanu --- Hello, I got this in the ntopng bug I raised ( https://github.com/ntop/ntopng/issues/1734 ): @fsamareanu sure. In SNMP some fields are encoded with TLV (Type Length Value), where the length specifies how many bytes to read on the next field. The daemon you are using seems to ignore the "Length" value from some SNMP fields (at least in version, error-status, error-index fields) and assume length 1. This works well with snmpwalk which uses a 1 byte values but it does not with ntopng which uses 4 bytes values. -- 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 227502] Unable to add pfsense as monitored target in ntopng
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227502 --- Comment #3 from Eugene Grosbein --- (In reply to Florin Samareanu from comment #2) The problem is more complex. Indeed, "In SNMP some fields are encoded with TLV (Type Length Value), where the length specifies how many bytes to read on the next field" - that's true. But ASN.1/DER encoding standard states that if integer value is small enought to be fit in single byte, it MUST be encoded with single byte and using 4 bytes is not allowed for such case by this standard. snmpwalk can send small or large integers and it encodes them just right using noted "minimal integer" encoding: 1 or more bytes correspongingly. bsnmpd parses both of small and large TLV fileds just fine. On the other hand, ejrh/snmp library used by ntopng ALWAYS encodes integers using 4 bytes, even for small values (R=1 in the test above). That is standard violation that does not pass bsnmpd's strict validation, but pass relaxed validation of net-snmpd. -- 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 193953] vlan(4) on LACP lagg(4) do not update if_baudrate value and thus SNMP daemons do not provide high capacity counters
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193953 Eugene Grosbein changed: What|Removed |Added See Also||https://reviews.freebsd.org ||/D15112 -- 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"
Changed behaviour of pf after new handling of EACCES in tcp_output() in r315514
In FreeBSD V11 the commit r315514 introduced a new handling of the error code EACCES from ip_output() in tcp_output.c: case EACCES: tp->t_softerror = error; return (0); If I use pf and block output with a rule like block out quick on em0 inet proto tcp from any to any port 23 and try date; telnet 192.168.0.122 23; date then I see in V10 immediately reply Di 17 Apr 2018 10:46:37 CEST Trying 192.168.0.122... telnet: connect to address 192.168.0.122: Permission denied telnet: Unable to connect to remote host Di 17 Apr 2018 10:46:37 CEST and in V11 with commit r315514 the same reply after 90 seconds, in the meantime telnet is waiting on WCHAN "connec": Di. 17 Apr. 2018 10:46:28 CEST Trying 192.168.0.122... telnet: connect to address 192.168.0.122: Permission denied telnet: Unable to connect to remote host Di. 17 Apr. 2018 10:47:43 CEST I like to know if this is intended behaviour. Andreas Longwitz ___ 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: Changed behaviour of pf after new handling of EACCES in tcp_output() in r315514
On 17.04.2018 17:02, Andreas Longwitz wrote:
> and in V11 with commit r315514 the same reply after 90 seconds, in the
> meantime telnet is waiting on WCHAN "connec":
>
> Di. 17 Apr. 2018 10:46:28 CEST
> Trying 192.168.0.122...
> telnet: connect to address 192.168.0.122: Permission denied
> telnet: Unable to connect to remote host
> Di. 17 Apr. 2018 10:47:43 CEST
>
> I like to know if this is intended behaviour.
This change was based on
https://svnweb.freebsd.org/base?view=revision&revision=309610
Now I think it can be removed, because:
1. SAs should be configured by application before initiating of TCP
connection;
2. If there are no matching SAs, connection will be dropped after
several tries.
3. Even if connection will be dropped after first failed SYN, there is
special tcps_sig_err_buildsig error counter, that will be incremented
and we can determine the cause.
So, can you try this patch? And maybe someone who uses TCP-MD5 can try
it too (with and without configured SAs)?
--
WBR, Andrey V. Elsukov
Index: tcp_output.c
===
--- tcp_output.c (revision 332505)
+++ tcp_output.c (working copy)
@@ -1586,8 +1586,6 @@ timer:
SOCKBUF_UNLOCK_ASSERT(&so->so_snd); /* Check gotos. */
switch (error) {
case EACCES:
- tp->t_softerror = error;
- return (0);
case EPERM:
tp->t_softerror = error;
return (error);
signature.asc
Description: OpenPGP digital signature
Re: Changed behaviour of pf after new handling of EACCES in tcp_output() in r315514
Thanks for quick answer, > This change was based on > https://svnweb.freebsd.org/base?view=revision&revision=309610 > > Now I think it can be removed, because: > > 1. SAs should be configured by application before initiating of TCP > connection; > 2. If there are no matching SAs, connection will be dropped after > several tries. > 3. Even if connection will be dropped after first failed SYN, there is > special tcps_sig_err_buildsig error counter, that will be incremented > and we can determine the cause. So you introduced the change as part of the new IPSec project and not to help pf in the special situation of reloading rukes (Bug 214613), correct ? > So, can you try this patch? And maybe someone who uses TCP-MD5 can try > it too (with and without configured SAs)? I tried your patch on FreeBSD 11 (r331217) and FreeBSD 12 (r328652) and pf workes in both cases as expected, the telnet command now returned immediately. Compared to the old behaviour your patch reverted two lines in tcp_output.c but not the line "EACCES:". I think thats what you wanted, tp->t_softerror is now set to EACCESS, when this error occurs. It seems to me that this does not make a big difference, but maybe I am wrong. Do you plan to commit your patch ? Andreas Longwitz ___ 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 227566] option RSS brokes conn to localhost
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227566 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@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"
[Bug 227566] option RSS brokes conn to localhost
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227566 Adrian Chadd changed: What|Removed |Added CC||adr...@freebsd.org --- Comment #1 from Adrian Chadd --- is it broken on -head? -adrian -- 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"
