- User Since
- May 21 2014, 7:59 PM (282 w, 3 d)
Wed, Oct 16
Sun, Oct 13
Sat, Oct 12
Your change looks to me trying to add IPv6 support by a copy-and-paste of the logic used in IPv4. I do not think it is a good idea in general or even for rwhod. At the time when rwhod utility was written there was an IPv4-specific API only, but nowadays we have a lot of address family independent APIs. For multicast membership management, an API defined in RFC 3678 is the standard way to support IPv4 and IPv6 in a AF-agnostic manner. Therefore, multicast support of rwhod needs a major rewrite by using this new API to support both IPv4 and non-IPv4 protocols at least. While we welcome converting an IPv4-only program to support IPv6 in an AF-independent API such as getaddrinfo(3), we do not want to add another IPv6-only code path to every single IPv4-only utility unless it is the only way to do so.
Sun, Sep 22
- We do not have MPLS as described in RFC 4023 or NVGRE in RFC 7637 as a kernel feature.
- RFC 8086 (GRE-in-UDP) is supported.
- I am not sure why WCCP I-Ds should be listed here. They use GRE but it is usually implemented by a userland daemon, not by kernel.
Sat, Sep 21
Looks good to me.
Sep 15 2019
Sep 12 2019
Aug 29 2019
Aug 27 2019
Update based on jilles's comments:
Updated to include bcr's suggestions and fix a missing length check.
Aug 25 2019
Aug 10 2019
Aug 7 2019
Jul 10 2019
May 19 2019
As already pointed out on the mailing list, this example has a lot of problems which are not only style bugs. Ones I think as critical except for the style issues are the following:
- The function to compare two elements should accept the same type, not using an "age" field value by using a pointer type. It is a function to compare, not look up a matched element in the definition of bsearch(3). Passing a raw value as (void *) type is not impossible, but it is not suitable for a "textbook" example.
- Using assert() looks strange to me. Instead, this program should accept a value of "key" from the command line argument and show the results of bsearch(3) depending on the specified key, and this manual page should describe what results are expected.
May 16 2019
May 9 2019
Mar 19 2019
Mar 18 2019
Mar 17 2019
Mar 15 2019
Mar 12 2019
Adding jumbo frame support looks good to me. However, is it better to support this in ether_ioctl() instead of a driver-specific ioctl handler? Check of (ifr->ifr_mtu > ETHERMTU) in ether_ioctl() can be changed to check if the interface has IFCAP_JUMBO_MTU or not.
Fixed in a different way in r334094.
Mar 7 2019
One more comment: immediate change of the flag just after a link-down event may be problematic when the link is unstable. In such a situation, IPv4 packets can be allowed after a link-up and before another RA arrives even if the all of advertising routers keep sending ipv6only flag. We can assume that the interface should be configured to accept RA when the machine moves from a network to another, so sending a RS after a link-up then clearing ND6_IFF_IPV6_ONLY only when no RA arrives in a few seconds looks a more reasonable behavior. If at least one RA arrives after the RS, the normal handling of ipv6only flag works.
(1) looks good to me. For (2), I think the old version unconditionally runs rtsol (w/o "d") when rtsold_enable="NO", and does not when rtsold_enable="YES" because rtsold (w/ "d") will be invoked later by rc.d/rtsold should handle it. In short, the condition which determines if rtsol is invoked or not depends only on "accept_rtadv" flag. Isn't it enough?
Looks good to me. We might want to put an INFO log line when ND6_IFF_IPV6_ONLY flag is changed by receiving RA or link-down event so that the sysadmin can know what is going on.
Mar 5 2019
Mar 4 2019
Mar 3 2019
Mar 2 2019
Feb 28 2019
-nox11 should be removed and converted by using FLAVOR.
Feb 27 2019
Feb 19 2019
Sep 23 2018
Sep 22 2018
Aug 29 2018
I would suggest the following changes using getaddrinfo() instead of inet_aton() to avoid address-family dependency. Is cap_getaddrinfo() allowed by capdns?
@@ -147,8 +163,9 @@ const char *typelimit = "ADDR"; int familylimit; const char *ipstr = "127.0.0.1"; -struct in_addr ip; -struct hostent *hp; +char hname[NI_MAXHOST]; +struct addrinfo hints, *res; +int error;
Looks good to me.
Aug 10 2018
Jul 11 2018
This is my submission, so I will leave someone else to do further review of this change. Please do not count my "accept revision" as an immediate approval.
Jul 10 2018
IMHO strvisx(3) in machine.c should have a VIS_OCTAL flag as in my original submission because meta char encoding of strvisx(3), which uses iscntrl(3), does not make sense for most of multibyte encodings. Displaying characters not for the current locale in octal (or hexadecimal) number looks more intuitive to me.
Reverting a change does not need any approval or review. Please document the reason in the commit log instead of just saying "rollback".
Please split this changes into two commits; one is to revert r335836 and another is to add setlocale() and remove printable() function. A single commit including the both is confusing.