On 02/15/2017 08:56, Mark Martinec wrote:
In a similar vein, I noticed also the following in our logs,
with net.inet.tcp.log_in_vain=1.
Looks like messages got concatenated somehow:
Jan 25 01:37:53 mildred kernel: TCP: [2607:ff10:c5:509a::10]:26459 to
[2001:1470:ff80::80:16]:4911 tcpflags 0x2;
2017-02-06 18:04, Eric van Gyzen wrote:
On 02/06/2017 10:19, Mark Martinec wrote:
Hope the fix finds its way into 11.1 (or better yet, as a patch level
in 10.0). Should I open a bug report?
It will quite likely get into 11.1. As for a 10.x patch, you would
have
to ask re@ (I think), but I
On 02/06/2017 10:19, Mark Martinec wrote:
>
> One minor nit:
> instead of a hack:
>
> char src[4*sizeof "123"];
> char dst[4*sizeof "123"];
>
> it would be cleaner and in sync with the equivalent code in
> sys/netinet6/udp6_usrreq.c
> to use the INET_ADDRSTRLEN constant (from sys/netinet
On 2017-02-02 12:55, Mark Martinec wrote:
11.0-RELEASE-p7, net.inet.udp.log_in_vain=1
The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).
(the actual failed connection attempts were indeed there,
it's just that the
On 02/02/2017 12:55, Mark Martinec wrote:
11.0-RELEASE-p7, net.inet.udp.log_in_vain=1
The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).
(the actual failed connection attempts were indeed there,
it's just that the
11.0-RELEASE-p7, net.inet.udp.log_in_vain=1
The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).
(the actual failed connection attempts were indeed there,
it's just that the reported IP address is highly suspicious)
