Re: Discarding inbound ICMP REDIRECT by default
> On Fri, 14 Jun 2024 at 11:13, Rodney W. Grimes > wrote: > > > > That section is about how the router responds to an ICMP redirect > > set to IT, not one that is going THROUGH it. > > Sorry I wasn't explicit, in all cases I'm talking about ICMP REDIRECTs > destined for the machine (as a host or as a router). This is > icmp_input dropping when either drop_redirect or ipforwarding is true. Ok, so long as we are not dropping ICMP REDIRECTS that are NOT destined for the router we are fine, which is the behavior I expected and observed on my network, though it is a bit older code. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> On Fri, 14 Jun 2024 at 09:52, Rodney W. Grimes > wrote: > > > > > > I would argue that having IP forwarding enabled (i.e. > > > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > > > router, and ICMP REDIRECT messages are already dropped in kernel in > > > that case. > > > > Yet another mistake by FreeBSD. These ICMP dropping or not dropping > > are SITE SPECIFIC POLICIES, and should never be hard coded to wrong > > knobs. > > This change dates to 2004: > > commit 87c3bd275523515dc67444b900a8f1d39ae257cd > Author: Andre Oppermann > Date: Tue Jan 6 23:20:07 2004 + > > According to RFC1812 we have to ignore ICMP redirects when we ^^ Incorrect interpretation of ietf keyword "MAY". > are acting as router (ipforwarding enabled). > > This doesn't fix the problem that host routes from ICMP redirects > are never removed from the kernel routing table but removes the > problem for machines doing packet forwarding. > > RFC1812 is not quite that explicit, but: > > | A router using a routing protocol (other than static routes) MUST NOT > | consider paths learned from ICMP Redirects when forwarding a packet. > | If a router is not using a routing protocol, a router MAY have a > | configuration that, if set, allows the router to consider routes > | learned through ICMP Redirects when forwarding packets. That section is about how the router responds to an ICMP redirect set to IT, not one that is going THROUGH it. 5.2.7.2 about generating redirects is also not relavant here, as we are discussing forwarding redirects. As far as I can find RFC1812 does NOT discuss the issue of forwarind ICMP REDIRECTs. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> > > > Discarding ICMP redirects on a internet host is non-conformant with > > > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > > > > > In that case our default of "auto" is non-conformant if you have a > > > routing daemon. > > > > NO, because then your not subject to rfc-1122 as your now a router, > > not a host. > > I would argue that having IP forwarding enabled (i.e. > net.inet.ip.forwarding for IPv4) is what establishes FreeBSD as a > router, and ICMP REDIRECT messages are already dropped in kernel in > that case. Yet another mistake by FreeBSD. These ICMP dropping or not dropping are SITE SPECIFIC POLICIES, and should never be hard coded to wrong knobs. One can easily be using FreeBSD as a router inside an AS that has a need for ICMP REDIRECT to pass through that router unfiltered. But I would agree in general that the better detection mechanism for the "auto" keyword of /etc/rc.conf icmp_drop_redirects is probably the value of net.inet.ip.forwarding and net.inet6.ip6.forwarding, but iirc the is an ordering issue. Could use the *GATWEAY_ENABLE rc.conf variables though. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> On Wed, 12 Jun 2024 at 18:05, Chris wrote: > > > > As Rodeney already effectively explains; dropping packets makes routing, > > and discovery exceedingly difficult. Which is NOT what the average user > > wants, > > This is on end hosts only, not routers (which already drop ICMP REDIRECT). Probably a mistake, see other email. > > or expects. I use "set block-policy drop" in pf(4). But as already noted, > > this is for "filtering" purposes. Your suggestion also has the negative > > affect > > of hanging remote ports. Which can result in other negative results by > > peers. > > I don't follow -- how does a host not processing ICMP REDIRECT cause > these effects? I am not sure that it would "hang" the port, but by ignoring the rediect your going to place additional burden on the router that is trying to redirect you as all packets would have to be forwarded by that router. I suppose it could hang you if infact the router sent the redirect but did not forward the packet for you expecting that a retransmission with your updated routing table due to the redirect would get the flow going. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
[ Charset UTF-8 unsupported, converting... ] > On Thu, 13 Jun 2024 at 09:39, Rodney W. Grimes > wrote: > > > > Discarding ICMP redirects on a internet host is non-conformant with > > STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. > > In that case our default of "auto" is non-conformant if you have a > routing daemon. NO, because then your not subject to rfc-1122 as your now a router, not a host. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> I propose that we start dropping inbound ICMP REDIRECTs by default, by > setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > changing the associated rc.conf machinery). I've opened a Phabricator > review at https://reviews.freebsd.org/D45102. > > ICMP REDIRECTs served a useful purpose in earlier networks, but on > balance are more likely to represent a security issue today than to > provide a routing benefit. With the change in review it is of course > still possible to enable them if desired for a given installation. > This change would appear in FreeBSD 15.0 and would not be MFC'd. > > One question raised in the review is about switching the default to > YES but keeping the special handling for "auto" (dropping ICMP > REDIRECT if a routing daemon is in use, honouring them if not). I > don't think this is particularly valuable given that auto was > introduced to override the default NO when necessary; there's no need > for it with the default being YES. That functionality could be > maintained if there is a compelling use case, though. > > If you have any questions or feedback please follow up here or in the review. Discarding ICMP redirects on a internet host is non-conformant with STD-3 via rfc-1122. Processing of ICMP rediects is a MUST for hosts. -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> On 2024-06-12 15:05, Chris wrote: > > On 2024-06-12 14:47, Rodney W. Grimes wrote: > >>> I propose that we start dropping inbound ICMP REDIRECTs by default, by > >>> setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > >>> changing the associated rc.conf machinery). I've opened a Phabricator > >>> review at https://reviews.freebsd.org/D45102. > >> > >> I propse that we NOT do this. If you need this to protect your end > >> node your probably doing something really unsafe network wise. The > >> place that ICMP REDIRECTS should be dropped, and is most places, is > >> at access routers and firewalls. > >> > >> Any one that needs this change to protect there network has larger > >> issues than an ICMP REDIECT causing some issues. > >> > >> ICMP redirectr are very usefull for not having to run routing > >> protocols on all your end nodes and allowing your edge/access > >> routers tell your internal hosts via redirects how to get to > >> places more efficiently. > >> > >>> > >>> ICMP REDIRECTs served a useful purpose in earlier networks, but on > >> They still serve this very usefull purpose. > >> > >>> balance are more likely to represent a security issue today than to > >>> provide a routing benefit. With the change in review it is of course > >>> still possible to enable them if desired for a given installation. > >>> This change would appear in FreeBSD 15.0 and would not be MFC'd. > >>> > >>> One question raised in the review is about switching the default to > >>> YES but keeping the special handling for "auto" (dropping ICMP > >>> REDIRECT if a routing daemon is in use, honouring them if not). I > >>> don't think this is particularly valuable given that auto was > >>> introduced to override the default NO when necessary; there's no need > >>> for it with the default being YES. That functionality could be > >>> maintained if there is a compelling use case, though. > >> > >> The policy that is there now is exactly how things should be configured > >> for a host in a network protected by a proper router w/firewall. > >> The existing "auto" does exactly the right thing. > >> > >>> > >>> If you have any questions or feedback please follow up here or in the > >>> review. > > As Rodeney already effectively explains; dropping packets makes routing, > > and discovery exceedingly difficult. Which is NOT what the average user > > wants, > > or expects. I use "set block-policy drop" in pf(4). But as already noted, > > this is for "filtering" purposes. Your suggestion also has the negative > > affect > > of hanging remote ports. Which can result in other negative results by > > peers. > > > > Please don't. :) > >>> > >>> > > --Chris > OK, now having actually read the (phab) review. I'm of the opposite opinion. > Your review seems to make the right decision. :) You do get that the final effect of the change is that by default ALL freeBSD boxes well be dropping ICMP REDIRECTS, both routers and end nodes. I know first hand that this change WOULD break my network(s) in locations that have more than 1 router as all of the interior hosts simply depend on an ICMP redirect to get them using the optimal router after they wrongly use the default router for a packet. A quick check on Ubunty 22.04 and Debian 12 indicate these are stlll accepted by default on those systems. Again, this is gona be one of those "bite someone in the ass" and your actually not providing any real security to anyone by making this change. If this is such a security issue, how come FREEFALL.freebsd.org still has: net.inet.icmp.drop_redirect: 0 Because it does not need to do that, because it is properly protected by routers and firewalls that do the dropping for them. DOG food Dog FOOD DOG FOOD!!! -- Rod Grimes rgri...@freebsd.org
Re: Discarding inbound ICMP REDIRECT by default
> I propose that we start dropping inbound ICMP REDIRECTs by default, by > setting the net.inet.icmp.drop_redirect sysctl to 1 by default (and > changing the associated rc.conf machinery). I've opened a Phabricator > review at https://reviews.freebsd.org/D45102. I propse that we NOT do this. If you need this to protect your end node your probably doing something really unsafe network wise. The place that ICMP REDIRECTS should be dropped, and is most places, is at access routers and firewalls. Any one that needs this change to protect there network has larger issues than an ICMP REDIECT causing some issues. ICMP redirectr are very usefull for not having to run routing protocols on all your end nodes and allowing your edge/access routers tell your internal hosts via redirects how to get to places more efficiently. > > ICMP REDIRECTs served a useful purpose in earlier networks, but on They still serve this very usefull purpose. > balance are more likely to represent a security issue today than to > provide a routing benefit. With the change in review it is of course > still possible to enable them if desired for a given installation. > This change would appear in FreeBSD 15.0 and would not be MFC'd. > > One question raised in the review is about switching the default to > YES but keeping the special handling for "auto" (dropping ICMP > REDIRECT if a routing daemon is in use, honouring them if not). I > don't think this is particularly valuable given that auto was > introduced to override the default NO when necessary; there's no need > for it with the default being YES. That functionality could be > maintained if there is a compelling use case, though. The policy that is there now is exactly how things should be configured for a host in a network protected by a proper router w/firewall. The existing "auto" does exactly the right thing. > > If you have any questions or feedback please follow up here or in the review. > > -- Rod Grimes rgri...@freebsd.org
Re: removing RIP/RIPng (routed/route6d)
> Scott writes: > > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation > > provide the rules under which code is added or removed from base and then > > we'd all be the wiser. > > The FreeBSD Foundation does not set project policy, the FreeBSD Core > Team does. Sadly that was never my intent when I created the original "Core", the core team was to help the developers in setting project policy based on there inputs and interactions, not to just elect some group of people and then bow down to them for all decisions. The DEVELOPERS as a whole is who should be setting all project policies. -- Rod Grimes rgri...@freebsd.org
Re: Source IPv4 address selection vs BGP IX connection
> > of course, gethostid(3) is now deprecated in favour of sysctl(3), and the > > hostid(8) command is gone, and there's now more than one flavour of > > Internet-capable UNIX in the world, and there's more than one Internet > > address family now. so what i did in 1990 is a guide only inasmuch as some > > way should exist to change the default local address of a socket so that it > > isn't the address of the interface used for the destination. if that happens > > i hope we coordinate with Linux and with the other BSD's. > > Linux already has a model to give a hint for source address selection via > route table "hints". When adding routes (either manually via `ip route' > or via things like bird2 BGP daemon), Linux supports setting a source IP > for when that route is used. > > Interestingly, JunOS (which I believe is based on FreeBSD) also supports > a way to specify a default IPv4 source address, preferring the primary address > on lo0 that is not 127.0.0.1. The part of JunOS which is FreeBSD based runs inside a VM on Juniper routers and is a control plane only thing, what your probably seing is an artifact of the switch to Linux by Juniper. > It is a common practice for BGP systems to > attach their announced IPs to the loopback interface. These routers are almost always reject type routes and used to hold the routes 'UP' even if the IGP of an AS flaps them. This is not done to effect source IP address selection. > > https://www.juniper.net/documentation/us/en/software/junos/cli-reference/topics/ref/statement/default-address-selection-edit-system.html > > For the Linux and bird (BGP) documentation: > > Linux > - > http://linux-ip.net/html/tools-ip-route.html#ex-tools-ip-route-add-src > > "The src option provides a hint to the kernel for source address selection. > When you are working with multiple routing tables and different classes of > traffic, you can ease your administrative burden, by hosting several > different IPs on your linux machine and setting the source address > differently, depending on the type of traffic. > > In the example below, let's assume that our masquerading host also runs a DNS > resolver for the internal network and we have selected all of the outbound > DNS packets to be routed according to table 7 [53]. Now, any packet which > originates on this box (or is masqueraded through this table) will have its > source IP set to 205.254.211.198. This is in effect what someone else suggested using multiple route tables in freeBSD and ipfw rules, iirc. > > Example D.19. Using src in a routing command with route add > > [root@masq-gw]# ip route add default via 205.254.211.254 src 205.254.211.198 > table 7 > " > > man ip-route > > "src ADDRESS > the source address to prefer when sending to the > destinations covered by the route prefix." > > > Bird (BGP Daemon) > > "The Kernel protocol defines several attributes. These attributes are > translated to appropriate system (and OS-specific) route attributes. We > support these attributes: > .. > ip krt_prefsrc > (Linux) The preferred source address. Used in source address selection for > outgoing packets. Has to be one of the IP addresses of the router." This is for the purpose of bird process only and does not effect other processes. This is mainly used to control the source addressed used for eBGP sessions, though this can fail misserably when you have multiple interfaces speaking eBGP. Though I can see some merit in what your suggesting to do, I also know that it comes with a many problems as it might solve, like ping would stop working on a local link if the assigned "src IP" is not routable by the entity your trying to ping, which for me would be the case in many places as the IX IP only appears on the IX interface and nothing any place inside or outside my AS has a route to it. I believe this is the intent of the IX IP policy on use of unrouteable IP addresses. -- Rod Grimes rgri...@freebsd.org
Re: Source IPv4 address selection vs BGP IX connection
> Short version: > > Using FreeBSD as a BGP router has network issues caused by suboptimal > default IPv4 source address selection when connected to Internet > Exchanges (which are required to use IPs that aren't routable on the > Internet). I was hoping to find more elegant workarounds or encourage > FreeBSD to add source IPv4 selection akin to the existing IPv6 source > address selection (no_prefer_iface and prefer_source). > > > Long version: > > Unless I'm mistaken, today, there is no way to set the default > IPv4 source address for connections like there is with IPv6 (using > no_prefer_iface and prefer_source). > > It appears the default source IP is chosen based on IP address of > the outbound interface for the packet. This presents a problem on > FreeBSD systems acting as BGP routers that have connections to Internet > exchanges (IX). One of the rules of IX IP addresses is that they are > must not be routable on the Internet. > > As a simple example, a system with two Ethernet interfaces, one to the > transit provider and one to an IX would look like this: > > vtnet0: flags=1008843 metric > 0 mtu 1500 > description: Uplink > inet 193.148.250.141 netmask 0xff00 broadcast 193.148.250.255 > vtnet1: flags=1008843 metric > 0 mtu 1500 > description: IX > inet 185.1.147.211 netmask 0xff00 broadcast 185.1.147.255 > > Then if /etc/resolv.conf contains 8.8.8.8 and BGP selects a route for > 8.8.8.0/24 over the IX, you end up with: > > # route -n get 8.8.8.8 >route to: 8.8.8.8 > destination: 8.8.8.0 >mask: 255.255.255.0 > gateway: 185.1.147.22 > fib: 0 > interface: vtnet1 > flags: > recvpipe sendpipe ssthresh rtt,msecmtuweightexpire >0 0 0 0 1500 1 0 > > And DNS on the system doesn't work as all DNS requests go out with a > source address of 185.1.147.211 (the IX endpoint) which isn't exported > as an Internet route. > > While I can set a static route for 8.8.8.8 for this particular case, it > would be messy to have to set up static routes for every possible local > connection (other DNS servers, outbound SMTP for periodic/cron mail, > etc.). The mistake your making, IMHO, is that an IX connected eBGP FreeBSD router _SHOULD NOT_ be doing ANYTHING other than BGP on the IX connected interface, and anything like DNS and outbound SMTP should be going inward on the AS, not outward to the internet. I must ask why your using 8.8.8.8 and not your own nameservers? Why would you want or even allow outbound SMTP from such a critical infustructure point go out over the unwashed internet? One of the reasons for using the non-routable IP on IX connected eBGP routers is to minimize the exposure footprint, and what you seem to be doing is defeating that minimization by wanting to expose another IP on that very box to the public internet. > > I assume that there is a group of BGP enthusiasts using FreeBSD lurking > on freebsd-net. What have you done to solve this problem? I only trust AS internal objects from my eBGP routers, they have no need to speak to the unwashed internet other than to IX peers. > I'd also love to hear other tips for running BGP on FreeBSD. Lock it down as tight as you can if your IX connected. I dont even allow inbound BGP connection setup, all eBGP sessions have to be initiated by my router. ipfw -a list 20179 20179 23854 1131316 deny log tcp from any to any 179 This is at an ISP peer, not an IX, so not a private IX IP range, but 23854 attempts to connect to my bgp. -- Rod Grimes rgri...@freebsd.org
Re: how to troubleshoot "arpresolve: can't allocate llinfo for " errorr ?
> I get the following error "arpresolve: can't allocate llinfo for 1.1.245.192 > on vlan320" I can't explain. (IP edited). I only setup 1.1.245.192/31 between > this vlan which parent is a VF from a MLX5EN(4) card . > > I am using a generated mac address and distribute IPs over OSPF with bird. > > What could trigger this error? The doc says > > ``` > It "arpresolve: can't allocate llinfo for %d.%d.%d.%d" > The route for the referenced host points to a device upon which ARP is > required, but ARP was unable to allocate a routing table entry in which > to store the host's MAC address. > This usually points to a misconfigured routing table. Mis matched netmask on this network segment is a common cause of this issue. Check all your hosts that there netmask matches the /31 you show below. I could also be a bad netmask on a route entry, check your routing table to make sure it has a /31 route or a pair of /32 routes. > It can also occur if the kernel cannot allocate memory. > ``` > > But I am not sure what to check. Any hint is welcome :) > > The configuration for this vlan is locally: > > ``` > vlan320: flags=1008843 > metric 0 mtu > 1500options=1c680703 > ether 02:01:02:01:01:01 > inet 1.1245.193 netmask 0xfffe broadcast 255.255.255.255 not a valid address, so when tiy "obscured" this you also created invalid data. I think this was suppose to be 1.1.245.193 > inet6 fe80::1:2ff:fe01:101%vlan320 prefixlen 64 scopeid 0x9 > inet6 ::1:fe02::2 prefixlen 64 > groups: vlan > vlan: 320 vlanproto: 802.1q vlanpcp: 0 parent interface: mce1 > media: Ethernet 25GBase-SR > status: active > nd6 options=21 > > > > ``` > vlan320: flags=1008843 > metric 0 mtu 1500 > > options=1c680703 > ether 02:01:02:02:01:01 > inet 1.1.245.192 netmask 0xfffe broadcast 255.255.255.255 > inet6 fe80::1:2ff:fe02:101%vlan320 prefixlen 64 scopeid 0xa > groups: vlan > vlan: 320 vlanproto: 802.1q vlanpcp: 0 parent interface: mce1 > media: Ethernet 25GBase-SR > status: active > nd6 options=21 > ``` > on remote: > > ``` > > > Beno?t > > > -- Rod Grimes rgri...@freebsd.org
Re: Problem with Ethernet port BCM57416 NetXtreme-E Dual-Media 10G
> Hello, I have a problem with the installation of OPNSense 24.1. I am unable > to activate the Ethernet port BCM57416 NetXtreme-E Dual-Media 10G RDMA > Ethernet Controller. > > He doesn't recognize them, does anyone have a solution? > > The same problem with Realtek Semi conductor co. RTL8125 2.5GbE controller > Ethernet Controller. For this one you need to install the "port" of the re driver, pkg install realtek-re-kmod > Thanks > Marcos Lage -- Rod Grimes rgri...@freebsd.org
Re: Cwnd grows slowly during slow-start due to LRO of the receiver side.
Second attempt, first one failed due to not being a member of the list :-(. > Adding freebsd-transp...@freebsd.org to get that specific groups > eyes on this issue. > > Rod > > > As per newreno_ack_received() in sys/netinet/cc/cc_newreno.c, > > FreeBSD TCP sender strictly follows RFC 5681 with RFC 3465 extension > > That is, during slow-start, when receiving an ACK of 'bytes_acked' > > > > cwnd += min(bytes_acked, abc_l_var * SMSS); // abc_l_var = 2 dflt > > > > As discussed in sec3.2 of RFC 3465, L=2*SMSS bytes exactly balances > > the negative impact of the delayed ACK algorithm. RFC 5681 also > > requires that a receiver SHOULD generate an ACK for at least every > > second full-sized segment, so bytes_acked per ACK is at most 2 * SMSS. > > If both sender and receiver follow it. cwnd should grow exponentially > > during slow-slow: > > > > cwnd *= 2(per RTT) > > > > However, LRO and TSO are widely used today, so receiver may generate > > much less ACKs than it used to do. As I observed, Both FreeBSD and > > Linux generates at most one ACK per segment assembled by LRO/GRO. > > The worst case is one ACK per 45 MSS, as 45 * 1448 = 65160 < 65535. > > > > Sending 1MB over a link of 100ms delay from FreeBSD 13.2: > > > > 0.000 IP sender > sink: Flags [S], seq 205083268, win 65535, options > > [mss 1460,nop,wscale 10,sackOK,TS val 495212525 ecr 0], length 0 > > 0.100 IP sink > sender: Flags [S.], seq 708257395, ack 205083269, win > > 65160, options [mss 1460,sackOK,TS val 563185696 ecr > > 495212525,nop,wscale 7], length 0 > > 0.100 IP sender > sink: Flags [.], ack 1, win 65, options [nop,nop,TS > > val 495212626 ecr 563185696], length 0 > > // TSopt omitted below for brevity. > > > > // cwnd = 10 * MSS, sent 10 * MSS > > 0.101 IP sender > sink: Flags [.], seq 1:14481, ack 1, win 65, length 14480 > > > > // got one ACK for 10 * MSS, cwnd += 2 * MSS, sent 12 * MSS > > 0.201 IP sink > sender: Flags [.], ack 14481, win 427, length 0 > > 0.201 IP sender > sink: Flags [.], seq 14481:31857, ack 1, win 65, length > > 17376 > > > > // got ACK of 12*MSS above, cwnd += 2 * MSS, sent 14 * MSS > > 0.301 IP sink > sender: Flags [.], ack 31857, win 411, length 0 > > 0.301 IP sender > sink: Flags [.], seq 31857:52129, ack 1, win 65, length > > 20272 > > > > // got ACK of 14*MSS above, cwnd += 2 * MSS, sent 16 * MSS > > 0.402 IP sink > sender: Flags [.], ack 52129, win 395, length 0 > > 0.402 IP sender > sink: Flags [P.], seq 52129:73629, ack 1, win 65, > > length 21500 > > 0.402 IP sender > sink: Flags [.], seq 73629:75077, ack 1, win 65, length > > 1448 > > > > As a consequence, instead of growing exponentially, cwnd grows > > more-or-less quadratically during slow-start, unless abc_l_var is > > set to a sufficiently large value. > > > > NewReno took more than 20 seconds to ramp up throughput to 100Mbps > > over an emulated 100ms delay link. While Linux took ~2 seconds. > > I can provide the pcap file if anyone is interested. > > > > Switching to CUBIC won't help, because it uses the logic in NewReno > > ack_received() for slow start. > > > > Is this a well-known issue and abc_l_var is the only cure for it? > > https://calomel.org/freebsd_network_tuning.html > > > > Thank you! > > > > Best, > > Shuo Chen > > > > > > -- > Rod Grimes rgri...@freebsd.org > > -- Rod Grimes rgri...@freebsd.org
Re: Cwnd grows slowly during slow-start due to LRO of the receiver side.
Adding freebsd-transp...@freebsd.org to get that specific groups eyes on this issue. Rod > As per newreno_ack_received() in sys/netinet/cc/cc_newreno.c, > FreeBSD TCP sender strictly follows RFC 5681 with RFC 3465 extension > That is, during slow-start, when receiving an ACK of 'bytes_acked' > > cwnd += min(bytes_acked, abc_l_var * SMSS); // abc_l_var = 2 dflt > > As discussed in sec3.2 of RFC 3465, L=2*SMSS bytes exactly balances > the negative impact of the delayed ACK algorithm. RFC 5681 also > requires that a receiver SHOULD generate an ACK for at least every > second full-sized segment, so bytes_acked per ACK is at most 2 * SMSS. > If both sender and receiver follow it. cwnd should grow exponentially > during slow-slow: > > cwnd *= 2(per RTT) > > However, LRO and TSO are widely used today, so receiver may generate > much less ACKs than it used to do. As I observed, Both FreeBSD and > Linux generates at most one ACK per segment assembled by LRO/GRO. > The worst case is one ACK per 45 MSS, as 45 * 1448 = 65160 < 65535. > > Sending 1MB over a link of 100ms delay from FreeBSD 13.2: > > 0.000 IP sender > sink: Flags [S], seq 205083268, win 65535, options > [mss 1460,nop,wscale 10,sackOK,TS val 495212525 ecr 0], length 0 > 0.100 IP sink > sender: Flags [S.], seq 708257395, ack 205083269, win > 65160, options [mss 1460,sackOK,TS val 563185696 ecr > 495212525,nop,wscale 7], length 0 > 0.100 IP sender > sink: Flags [.], ack 1, win 65, options [nop,nop,TS > val 495212626 ecr 563185696], length 0 > // TSopt omitted below for brevity. > > // cwnd = 10 * MSS, sent 10 * MSS > 0.101 IP sender > sink: Flags [.], seq 1:14481, ack 1, win 65, length 14480 > > // got one ACK for 10 * MSS, cwnd += 2 * MSS, sent 12 * MSS > 0.201 IP sink > sender: Flags [.], ack 14481, win 427, length 0 > 0.201 IP sender > sink: Flags [.], seq 14481:31857, ack 1, win 65, length > 17376 > > // got ACK of 12*MSS above, cwnd += 2 * MSS, sent 14 * MSS > 0.301 IP sink > sender: Flags [.], ack 31857, win 411, length 0 > 0.301 IP sender > sink: Flags [.], seq 31857:52129, ack 1, win 65, length > 20272 > > // got ACK of 14*MSS above, cwnd += 2 * MSS, sent 16 * MSS > 0.402 IP sink > sender: Flags [.], ack 52129, win 395, length 0 > 0.402 IP sender > sink: Flags [P.], seq 52129:73629, ack 1, win 65, > length 21500 > 0.402 IP sender > sink: Flags [.], seq 73629:75077, ack 1, win 65, length > 1448 > > As a consequence, instead of growing exponentially, cwnd grows > more-or-less quadratically during slow-start, unless abc_l_var is > set to a sufficiently large value. > > NewReno took more than 20 seconds to ramp up throughput to 100Mbps > over an emulated 100ms delay link. While Linux took ~2 seconds. > I can provide the pcap file if anyone is interested. > > Switching to CUBIC won't help, because it uses the logic in NewReno > ack_received() for slow start. > > Is this a well-known issue and abc_l_var is the only cure for it? > https://calomel.org/freebsd_network_tuning.html > > Thank you! > > Best, > Shuo Chen > > -- Rod Grimes rgri...@freebsd.org
Re: BPF to filter/mod ARP
> > On 3. Mar 2023, at 14:52, Rodney W. Grimes > > wrote: > > > >>> On 2. Mar 2023, at 18:20, Rodney W. Grimes > >>> wrote: > >>> > >>>>> On 2. Mar 2023, at 02:24, Rodney W. Grimes > >>>>> wrote: > >>>>> > >>>>>> Hi group, > >>>>>> > >>>>>> Maybe someone can help me with this question - as I am usually only > >>>>>> looking at L4 and the top side of L3 ;) > >>>>>> > >>>>>> In order to validate a peculiar switches behavior, I want to adjust > >>>>>> some > >>>>>> fields in gracious arps sent out by an interface, after a new IP is > >>>>>> assigned or changed. > >>>>> > >>>>> Gracious or Gratuitous? > >>>>> > >>>>>> > >>>>>> I believe BPF can effectively filter on arbitrary bit patterns and > >>>>>> modify packets on the fly. > >>>>> > >>>>> It can. > >>>>> > >>>>>> > >>>>>> However, as ARP doesn't seem to be accessible in the ipfw > >>>>>> infrastructure, I was wondering how to go about setting up an BPF to > >>>>>> tweak (temporarily) some of these ARPs to validate how the switch will > >>>>>> behave. > >>>>> > >>>>> ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, > >>>>> so very hard to do much with it in ipfw, but perhaps the layer2 > >>>>> keyword, and some use of mac-type can get it to match an arp > >>>>> packet. Arp is ethernet type 0x806. > >>>>> > >>>>> ipfw add 111 count log all from any to any layer2 mac-type arp > >>>>> That does seem to work > >>>>> ipfw -a list 111 > >>>>> 001114 0 count log ip from any to any layer2 mac-type 0x0806 > >>>>> > >>>>> Also normally ipfw does NOT pick packets up early enough to see > >>>>> them, to get the layer2 option to work you need: > >>>>> sysctl net.link.ether.ipfw=1 so that the filters at ether_demux > >>>>> get turned on. > >>>>> > >>>>> So perhaps use a divert rule and send them to a socket where > >>>>> a program can mangle them, and then return them to ipfw > >>>>> and hopefully the kernel does what you want after that... > >>>> I thought that you receive/send an IP packet on a divert socket, not > >>>> an ethernet frame. Am I wrong? > >>> > >>> That is unclear to me, technically it should just be a binary > >>> blob and the kernel and userland just have to agree as to > >>> what it is. Understand that ipfw originally only had IP layer > >>> functionality. The ability to muck with layer2 was added > >>> later, so I suspect the documentation about what is sent > >>> over the divert socket may be out of date. Simple enough > >>> to test though, just setup as I show above only change > >>> to: > >>> ipfw add 111 divert all from any to any layer2 mac-type arp > >>> and write a program to dump what you get on the divert socket. > >>> I suspect you get an ethernet frame. > >>> > >>> And finally divert(4) says: NAME: divert kernel packet diversion mechanism > >>> That says packet, so again, IMHO, it should be arbitrary to what layer. > >>> It also later says "Divert sockets are similar to raw IP sockets", > >>> I think similar is the key aspect here, they are not identical. > >> I can confirm that using > >> sudo sysctl net.link.ether.ipfw=1 > >> sudo ipfw add 111 count log all from any to any layer2 mac-type arp > >> ... wait some time and observe ARP traffic via tcpdump > >> sudo ipfw show > >> 00111 22 0 count log logamount 5 ip from any to any layer2 mac-type > >> 0x0806 > >> 65535 7892 849004 allow ip from any to any > >> So the rule is hit. > >> > >> However, now doing > >> sudo ipfw delete 111 > >> sudo ipfw add 111 divert 1234 all from any to any layer2 mac-type arp > >> ... wait some time and observe ARP traffic via tcpdump > >> tuexen@head:~ % sudo ipfw show > >> 00111 0 0 divert 12
Re: BPF to filter/mod ARP
> > On 2. Mar 2023, at 18:20, Rodney W. Grimes > > wrote: > > > >>> On 2. Mar 2023, at 02:24, Rodney W. Grimes > >>> wrote: > >>> > >>>> Hi group, > >>>> > >>>> Maybe someone can help me with this question - as I am usually only > >>>> looking at L4 and the top side of L3 ;) > >>>> > >>>> In order to validate a peculiar switches behavior, I want to adjust some > >>>> fields in gracious arps sent out by an interface, after a new IP is > >>>> assigned or changed. > >>> > >>> Gracious or Gratuitous? > >>> > >>>> > >>>> I believe BPF can effectively filter on arbitrary bit patterns and > >>>> modify packets on the fly. > >>> > >>> It can. > >>> > >>>> > >>>> However, as ARP doesn't seem to be accessible in the ipfw > >>>> infrastructure, I was wondering how to go about setting up an BPF to > >>>> tweak (temporarily) some of these ARPs to validate how the switch will > >>>> behave. > >>> > >>> ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, > >>> so very hard to do much with it in ipfw, but perhaps the layer2 > >>> keyword, and some use of mac-type can get it to match an arp > >>> packet. Arp is ethernet type 0x806. > >>> > >>> ipfw add 111 count log all from any to any layer2 mac-type arp > >>> That does seem to work > >>> ipfw -a list 111 > >>> 001114 0 count log ip from any to any layer2 mac-type 0x0806 > >>> > >>> Also normally ipfw does NOT pick packets up early enough to see > >>> them, to get the layer2 option to work you need: > >>> sysctl net.link.ether.ipfw=1 so that the filters at ether_demux > >>> get turned on. > >>> > >>> So perhaps use a divert rule and send them to a socket where > >>> a program can mangle them, and then return them to ipfw > >>> and hopefully the kernel does what you want after that... > >> I thought that you receive/send an IP packet on a divert socket, not > >> an ethernet frame. Am I wrong? > > > > That is unclear to me, technically it should just be a binary > > blob and the kernel and userland just have to agree as to > > what it is. Understand that ipfw originally only had IP layer > > functionality. The ability to muck with layer2 was added > > later, so I suspect the documentation about what is sent > > over the divert socket may be out of date. Simple enough > > to test though, just setup as I show above only change > > to: > > ipfw add 111 divert all from any to any layer2 mac-type arp > > and write a program to dump what you get on the divert socket. > > I suspect you get an ethernet frame. > > > > And finally divert(4) says: NAME: divert kernel packet diversion mechanism > > That says packet, so again, IMHO, it should be arbitrary to what layer. > > It also later says "Divert sockets are similar to raw IP sockets", > > I think similar is the key aspect here, they are not identical. > I can confirm that using > sudo sysctl net.link.ether.ipfw=1 > sudo ipfw add 111 count log all from any to any layer2 mac-type arp > ... wait some time and observe ARP traffic via tcpdump > sudo ipfw show > 00111 22 0 count log logamount 5 ip from any to any layer2 mac-type > 0x0806 > 65535 7892 849004 allow ip from any to any > So the rule is hit. > > However, now doing > sudo ipfw delete 111 > sudo ipfw add 111 divert 1234 all from any to any layer2 mac-type arp > ... wait some time and observe ARP traffic via tcpdump > tuexen@head:~ % sudo ipfw show > 00111 0 0 divert 1234 ip from any to any layer2 mac-type 0x0806 > 65535 10048 1000948 allow ip from any to any > So this time, rule 111 is not hit. I also ran Nice work, to me I would classify this behavior as some form of bug, the action verb of a rule in ipfw should in no way change what is matched by the rule filter. I am assuming you either had IPDIVERT compiled into your kernel, or you you had loaded the module, as you dont clearly state this. I am also uncertain on what the results are if you use the divert keyword without ipdivert.ko loaded, is it an error when the rule gets created, or is it silently ignored? > > #include > #include > #include > #include > #include > #include > > #define BUFFER_SIZE (1<<16) &
Re: BPF to filter/mod ARP
> > On 2. Mar 2023, at 02:24, Rodney W. Grimes > > wrote: > > > >> Hi group, > >> > >> Maybe someone can help me with this question - as I am usually only > >> looking at L4 and the top side of L3 ;) > >> > >> In order to validate a peculiar switches behavior, I want to adjust some > >> fields in gracious arps sent out by an interface, after a new IP is > >> assigned or changed. > > > > Gracious or Gratuitous? > > > >> > >> I believe BPF can effectively filter on arbitrary bit patterns and > >> modify packets on the fly. > > > > It can. > > > >> > >> However, as ARP doesn't seem to be accessible in the ipfw > >> infrastructure, I was wondering how to go about setting up an BPF to > >> tweak (temporarily) some of these ARPs to validate how the switch will > >> behave. > > > > ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, > > so very hard to do much with it in ipfw, but perhaps the layer2 > > keyword, and some use of mac-type can get it to match an arp > > packet. Arp is ethernet type 0x806. > > > > ipfw add 111 count log all from any to any layer2 mac-type arp > > That does seem to work > > ipfw -a list 111 > > 001114 0 count log ip from any to any layer2 mac-type 0x0806 > > > > Also normally ipfw does NOT pick packets up early enough to see > > them, to get the layer2 option to work you need: > > sysctl net.link.ether.ipfw=1 so that the filters at ether_demux > > get turned on. > > > > So perhaps use a divert rule and send them to a socket where > > a program can mangle them, and then return them to ipfw > > and hopefully the kernel does what you want after that... > I thought that you receive/send an IP packet on a divert socket, not > an ethernet frame. Am I wrong? That is unclear to me, technically it should just be a binary blob and the kernel and userland just have to agree as to what it is. Understand that ipfw originally only had IP layer functionality. The ability to muck with layer2 was added later, so I suspect the documentation about what is sent over the divert socket may be out of date. Simple enough to test though, just setup as I show above only change to: ipfw add 111 divert all from any to any layer2 mac-type arp and write a program to dump what you get on the divert socket. I suspect you get an ethernet frame. And finally divert(4) says: NAME: divert kernel packet diversion mechanism That says packet, so again, IMHO, it should be arbitrary to what layer. It also later says "Divert sockets are similar to raw IP sockets", I think similar is the key aspect here, they are not identical. > > Best regards > Michael > > > >> (I need to validate, if there is some difference when the target > >> hardware address doesn't conform to RFC5227 - which states it SHOULD be > >> zero and is ignored on the receiving side; i have reasons to believe > >> that the switch needs either a target hardware address of > >> ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's > >> entries.) > >> > >> Thanks a lot! > >> > >> Richard > >> > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > > > > -- Rod Grimes rgri...@freebsd.org
Re: BPF to filter/mod ARP
> Hi group, > > Maybe someone can help me with this question - as I am usually only > looking at L4 and the top side of L3 ;) > > In order to validate a peculiar switches behavior, I want to adjust some > fields in gracious arps sent out by an interface, after a new IP is > assigned or changed. Gracious or Gratuitous? > > I believe BPF can effectively filter on arbitrary bit patterns and > modify packets on the fly. It can. > > However, as ARP doesn't seem to be accessible in the ipfw > infrastructure, I was wondering how to go about setting up an BPF to > tweak (temporarily) some of these ARPs to validate how the switch will > behave. ipfw is IP firewall, a layer 3 function. Arp is a layer 2 protocol, so very hard to do much with it in ipfw, but perhaps the layer2 keyword, and some use of mac-type can get it to match an arp packet. Arp is ethernet type 0x806. ipfw add 111 count log all from any to any layer2 mac-type arp That does seem to work ipfw -a list 111 001114 0 count log ip from any to any layer2 mac-type 0x0806 Also normally ipfw does NOT pick packets up early enough to see them, to get the layer2 option to work you need: sysctl net.link.ether.ipfw=1 so that the filters at ether_demux get turned on. So perhaps use a divert rule and send them to a socket where a program can mangle them, and then return them to ipfw and hopefully the kernel does what you want after that... > (I need to validate, if there is some difference when the target > hardware address doesn't conform to RFC5227 - which states it SHOULD be > zero and is ignored on the receiving side; i have reasons to believe > that the switch needs either a target hardware address of > ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's > entries.) > > Thanks a lot! > > Richard > -- Rod Grimes rgri...@freebsd.org
Re: getaddrinfo error for existing host without requested address family
Mike, Just commenting to clarify what seems to be unclear about some RFC's. Rod > I recently noticed the following behavior: > > % ping6 redrock > ping6: Name does not resolve > % host redrock > redrock.karels.net has address 10.0.2.2 > redrock.karels.net mail is handled by 10 mail.karels.net. > % ping6 nonexistenthost > ping6: Name does not resolve > > The first error message is misleading, because the name *does* resolve, > but has no record, and it is the same error message as for a name > that truly does not exist. The problem comes from the set of error > codes that getaddrinfo() returns in these two cases. The problem did > not exist with gethostbyname(), which has separate error codes for the > two (although gethostbyname did not have provision for IPv6, it handled > cases like domain names and mail domains without IPv4 addresses). > > getaddrinfo() uses a richer set of error codes than gethostbyname(), but > still misses this case. However, looking at , I see > > #if 0 > /* Obsoleted on RFC 2553bis-02 */ > #define EAI_ADDRFAMILY 1 /* address family for hostname not > supported */ > #endif > ... > #if 0 > /* Obsoleted on RFC 2553bis-02 */ > #define EAI_NODATA 7 /* no address associated with hostname > */ > #endif > > I don't know why these two were omitted from the update to RFC 2553, but > the first seems to me to be the correct error for an existing name without > an address for the requested address family. Also, that is the error > message produced by Linux (Ubuntu 22.04.1). > > NetBSD and OpenBSD produce the second of these two errors for a host > without the requested address. But they also produce the same error > when a name does not exist. > > RFC 2553bis-02 has timed out, and is replaced by RFC 3493, which is also > missing EAI_ADDRFAMILY. These are informational RFCs, not specifying an > Internet standard. RFC2553bis-02 is an old version of a draft that went to -09, this draft existed from May 2000 to March 2003, when it was changed to RFC3493 and published. When looking at RFC versions and history please use the IETF datatracker to help one find history and latest versions: https://datatracker.ietf.org/doc/rfc3493/ https://datatracker.ietf.org/doc/rfc2553/ Says obsolete by rfc3493 https://datatracker.ietf.org/doc/rfc2553bis/ redirects to rfc3493 Sadly goggle often sends one to a html version of a rfc/draft when one searches there for it. The html version does have a link in the banner to the proper datatracker page though. Use of and reference to IETF drafts in comments of the FreeBSD code and implementing them is full of the perils that there is rarely anyone tracking the work and keeping things up to date as the draft evolves and we end up with stale comments, and even stale implementations. rfc3493 still does not define EAI_ADDRFAMILY, one would have to search the mailing list archives to find what the rational for its removal was. Sadly that this is not summarized in section 9 of rfc3493, it should of been. > > I propose re-enabling EAI_ADDRFAMILY and using it for the situation > where a name exists but does not have an address in the requested family. > This would make the error in the example less misleading, and would behave > the same as Linux in this regard. The change to netdb.h is trivial, but > getaddrinfo() needs a little more work because it uses the NS_* errors > from internally and then translates. But it will benefit > from greater accuracy in other cases as well (e.g. "out of memory" > rather than "Name does not resolve"). > > Comments? I have a change in progress, but wanted to float the idea > before I finish it and put it into review. > > Mike > > -- Rod Grimes rgri...@freebsd.org
Re: experimental support for IPv4 unicast extensions
> I have been corresponding with the authors of Internet-Drafts that relax > restrictions on parts of the IPv4 address space to allow normal unicast > use, and I have FreeBSD changes to allow experimentation with these > updates. This message summarizes my changes, and solicits input. > > The changes are all controlled by sysctl, and default to "off". > The parts of the address space in question and the relevant changes: > > 0/8 (network 0) [1]: Restrictions on network 0 are lifted if the sysctl > net.inet.ip.allow_zeronet is set to 1. This applies to packet forwarding > and ICMP echo. > > 224/4 (Experimental/"Class E") [2]: Restrictions on the Experimental > address class are lifted if the sysctl net.inet.ip.allow_experimental > is set to 1. This applies to packet forwarding and ICMP echo. > > 127/8 (loopback net) [3]: The size of the reservation for the loopback > network can be reduced from 127/8 to 127.0/16 using the sysctl > net.int.ip.loopback_mask. My current sysctl sets the mask, but that > is a little cumbersome; I should probably change the sysctl to allow > a mask length to be set. This change is limited to the kernel; the > IN_LOOPBACK macro uses the current mask in the kernel, but the default > mask at user level. Also, some user programs use IN_LOOPBACKNET along > with a Class A shift to crack this by hand. The kernel change affects > IP packet input and output as well as forwarding. > > The changes described above are all included in a single review for now, > although I would probably separate them before pushing them. (They > necessarily collide though.) The review is intended for comments only, > and is https://reviews.freebsd.org/D35741. I think it makes sense to > put these changes in -current in order to enable experimentation, but > I wanted to open the subject for discussion first. Mike, My first cut at this is in review: https://reviews.freebsd.org/D19316 Regards, Rod > > Changes are also being made in Linux, although I don't know their state. > > Note that there is a related proposal and change to allow use of the > lowest host on a network/subnet [4]. This change was essentially a bug > fix for FreeBSD, and is already in -current and 13.1-RELEASE. > > Mike > > [1] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-0/01/ > > [2] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ > > [3] https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-127/ > > [4] > https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-lowest-address/ > > > -- Rod Grimes rgri...@freebsd.org
Re: Netstat -i 5-character interface name length?
[ Charset UTF-8 unsupported, converting... ] > On 6/29/2022 10:56 AM, Chris Ross wrote: > > Hello folks. ?I just noticed something that I?m sure has been true > > forever, but I checked and it?s still true on my 12.3-STABLE system. > > > One of the first local mods I do is alias netstat to netstat -W for this > reason. e.g. > alias netstat?? netstat -W > > in /etc/csh.cshrc That only fixes it for your interactive csh processes, the original poster had specifically mentioned output from periodic scrips, aka daily iirc. One thing that can be done to mitigate the long vlan dev name (imho the vlan driver should of just named itself much short, like "vl", as most network devices are 2 litter names anyway) is to use the "name" option of ifconfig to give them a better name than the default. ifconfig vlan2 create vlandev em0 vlan 2 name v2 -- Rod Grimes rgri...@freebsd.org
Re: Building driver for BCM57504 from Broadcom?
> Hi! > > For more details, see: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263046 > > Problem: Getting a BCM57504 card to work on FreeBSD > > Current state of affairs: > > There's a driver from Broadcom: > > > https://www.broadcom.com/products/ethernet-connectivity/network-adapters/p425g > > as version 222.0.74.0. > > It's source, so I tried to build it on 13.1, after I disabled -Werror in > > share/mk/bsd.sys.mk > sys/conf/kern.pre.mk > > Now it builds, but fails to load, with those error messages: > > link_elf_obj: symbol if_multiaddr_count undefined > linker_load_file: /usr/obj/usr/src/amd64.amd64/sys/modules/bnxt/if_bnxt.ko - > unsupported file type > > I've tried to find that if_multiaddr_count() function in > the source tree (either 13.1 or current), but failed 8-( > > Does anyone have an idea where that function might come from ? > Or should I fake it ? You should start here where a prior similiar event happened: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252642 Then google for "if_multiaddr_count" for other possible hints. > -- > p...@freebsd.org +49 171 3101372 Now what ? -- Rod Grimes rgri...@freebsd.org
Re: Porting OpenBSD MPLS to FreeBSD
> > Hi freebsd-net@, > > > > Long time no see. I've gotten a (Ports) commit bit since then. > > > > I haven't been very active in TCP/IP hacking as of late, as more > > recently I've been more focused on GNOME packages and some GPU drivers. > > > > Going back, I'm thinking about porting OpenBSD's MPLS to FreeBSD. > > I have had similiar thoughts on and off over the years, > and one pretty solid "want" for this. > > > > > I have a two questions: > > > > * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off > > doing a from-scratch implementation based on netgraph? > > Feasible, yes, as to the better off part that probably depends on > who you ask. MPLS is not that complicated to implement, so doing > it either way all depends on weither you want to deal with netgraph, > or the kernel network interface code. Its also probably fairly trivial > to do both with a great deal of shared code. > > > > > * Would some of the other committers here be willing to mentor/help me > > if needed? > > Yes. > > > > > Unlike my old IPFW patches which got nowhere (plus I no longer use > > IPFW), I feel this is more something that could be useful when running > > FreeBSD as a router, but hasn't really been done. > > I can probably arrange a telco size beta tester too... unless > there interested has gone away, which I doubt. > > > -Neel (nc@) Just to follow up, I had a discussion in the weekly Open Source Routing meeting, and have identified the FRR MPLS expert and have help avaliable from that resource for this work. The first order answer on making things FRR compatible is that if you use the OpenBSD API it would be pretty much a drop in function. I have also been asked if there would be a willingness to work with the OSR/FRR folks (netdef.org) in getting the MPLS CI framework working on FreeBSD. They already do CI testing of FRR on FreeBSD, but since there is no MPLS that feature is not tested. I am working out the details on a cross introduction of the FRR MPLS developer and yourself Neel, if you want to travel down that road. This person works cross platform on FRR, iirc mainly BGP, MPLS, and SR on Linux and BSD. -- Rod Grimes rgri...@freebsd.org
Re: why multi-hop icmp redirects to 0.0.0.0 on 13.0 ?
> On Sun, 5 Dec 2021, Lutz Donnerhacke wrote: > > > On Sun, Dec 05, 2021 at 08:20:08PM +0200, John Hay wrote: > >> Something I have observed is that if you use FreeBSD 13 as a router with 2 > >> subnets on the same interface, it will generate redirects when hosts send > >> packets to the other subnet via the FreeBSD router. I think it is wrong. > > > > No, it's correct. > > > >> The host does not have a more direct way to get to the other subnet. > > > > The other host can arp for an address in a non-connected network on the > > interface because it's the same L2 domain. Hence the ICMP redirect is send > > out to provide the shortcut (skipping the router). > > That has always be a very Linux-y approach; FreeBSD should not ARP > for any subnet it is not connected to (at least it didn't use to). > > I think you could add a host route in the past and then it would but > with the current IPv4 I couldn't even say from quickly looking what it > would do. route add foo -direct > > > >> RFC792 > >> on page 13 does not talk about interfaces, but networks, "If G2 and the > >> host identified by the internet source address of the datagram are on the > >> same network...". > > > > "network" == "layer 2 domain". > > No, no in this context; it talks about about the "internet source > address of a datagram" and hence network == Layer 3 as that is where > internet addresses belong. No one would phrase it anymore like this > these days but in those days ... Concur, in RFC's "network" almost always refers to a layer 2 domain, the word "link" is use refers to a layer 2 domain. > Bjoern A. Zeeb r15:7 -- Rod Grimes rgri...@freebsd.org
Re: Porting OpenBSD MPLS to FreeBSD
[ Charset UTF-8 unsupported, converting... ] > Hi Alexander, > > On 2021-12-04 10:42, Alexander V. Chernikov wrote: > >> * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off > >> doing a from-scratch implementation based on netgraph? > > It depends. MPLS implementaiton can be splitted into multiple logical > > parts - dataplane (input, control, output, forward) and control plane > > (programming ip routes+mpls and mpls-only fowarding state). Some parts > > of the former can indeed be imported from OpenBSD. However, most of > > the control plane part have to be written from scratch. Finally, it > > may be desired to maintain an programming interface close to the one > > already implemented in major routing SW (frr, bird) - I guess that > > would be simpler to achieve with native, non-netgraph implementation. > > Thanks for your description. I haven't started work yet, but I'd > probably import the dataplane from OpenBSD where I can and do a new > control plane, maybe that with a FRR/Bird-compatible API. When you get to working with FRR let me know, I am a member of the CI infustructure team there and can hook you up directly with very knowledgeable FRR developers. > > I wasn't too keen on using netgraph anyways, I felt it was unnecessary > complexity. True, but with that complexity comes an ulmost unlimited flexiablity. > If I were to work on this, would I be better off starting with the > dataplane or control plane? I concur with Alexander on this, dataplace first, with an eye on how FRR/Bird interact with the dataplane. > > >> * Would some of the other committers here be willing to mentor/help me > >> if needed? > > I?d love to. Most of my the routing-related stack changes (modular > > lookup framework, nexthops, rtsock cleanups) were done to enable > > efficient kernel-based MPLS implementation. > > Thanks! > > -Neel (nc@) > > -- Rod Grimes rgri...@freebsd.org
Re: Porting OpenBSD MPLS to FreeBSD
> Hi freebsd-net@, > > Long time no see. I've gotten a (Ports) commit bit since then. > > I haven't been very active in TCP/IP hacking as of late, as more > recently I've been more focused on GNOME packages and some GPU drivers. > > Going back, I'm thinking about porting OpenBSD's MPLS to FreeBSD. I have had similiar thoughts on and off over the years, and one pretty solid "want" for this. > > I have a two questions: > > * Is porting OpenBSD MPLS to FreeBSD feasible, or are we better off > doing a from-scratch implementation based on netgraph? Feasible, yes, as to the better off part that probably depends on who you ask. MPLS is not that complicated to implement, so doing it either way all depends on weither you want to deal with netgraph, or the kernel network interface code. Its also probably fairly trivial to do both with a great deal of shared code. > > * Would some of the other committers here be willing to mentor/help me > if needed? Yes. > > Unlike my old IPFW patches which got nowhere (plus I no longer use > IPFW), I feel this is more something that could be useful when running > FreeBSD as a router, but hasn't really been done. I can probably arrange a telco size beta tester too... unless there interested has gone away, which I doubt. > -Neel (nc@) -- Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
> Jamie wrote:
>
> > Oleksandr Kryvulia wrote:
>
> > > 04.11.21 01:01, Mike Karels wrote:
> > > > I have a pending change to stop using class A/B/C netmasks when setting
> > > > an interface address without an explicit mask, and instead to use a
> > > > default
> > > > mask (24 bits). A question has arisen as to what the default mask
> > > > should
> > > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8
> > > > bit
> > > > mask currently, but additions without a mask would default to 24 bits.
> > > > There is no warning for missing masks for loopback in the current code.
> > > > I'm not convinced that the mask has any meaning here; only a host route
> > > > to the assigned address is created. Does anyone know of any meaning or
> > > > use of the mask on a loopback address?
> > > >
> > > > Thanks,
> > > > Mike
> > > >
> > >
> > > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> > >
> > > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > > [2] https://datatracker.ietf.org/doc/html/rfc1122
>
> It's true that 127/8 is currently reserved, but that isn't enforced
> by FreeBSD using the mask on the interface. Such packets are prevented
> from forwarding by in_canforward(), which in turn uses IN_LOOPBACK().
> The latter uses a compiled-in 8-bit mask.
I have a review up that "relaxes" the restrictions on this (127/8)
and other ranges.
https://reviews.freebsd.org/D19316
>
> > There is a push by some people to release 127.0.0.0/8 address space,
> > leaving only 127.0.0.0/16 as reserved for localhost.
>
> > https://www.spinics.net/lists/netdev/msg598545.html
>
> > https://github.com/schoen/unicast-extensions/blob/master/127.md
>
> > https://github.com/schoen/unicast-extensions/
>
> > I make no comment on the feasability of doing this!
>
> > However, that aside, aren't you just confusing the mask with routing?
>
> The two masks (interface and route) are separate, but the routing mask
> is set from the interface mask for most interfaces (broadcast or NBMA,
> but not loopback or point-to-point). The interface mask is visible to
> user level, including routing daemons. But I think it would be wrong
> for a routing daemon to infer anything from the mask on a loopback
> route. But the reason for my question was to find out if there is
^ I think you meant interface here?
> anything that uses the interface mask in this case, and thus whether
> a change in the default matters.
I actually do believe routing daemons pay very close attention to
the netmask on and interfaces. It is how CIDR routes to interfaces
are created and maintained by most of them. Even ancient gated
used this information.
>
> > I think the mask on any IP on a loopback interface should be /32
> > (if you want to add a "127.0.0.0/8 -local" route even if done
> > automatically", then so be it)
>
> Using /32 on loopback is not a bad idea. /etc/network.subr is wired
> to 127.0.0.1/8 currently. I don't think I'll change it in this pass
> though.
>
> > Note, the default FreeBSD firewall rules already have:
>
> > ${fwcmd} add 100 pass all from any to any via lo0
> > ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> > ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
>
> If you use the default rules...
The default rules should work with a fresh install that
is left with defaults in place. Due to loss of 127/8
routes the firewall code is borked and we only do not
leak 127/8 packets because of other code in the kernel
that prevents them from leaking.
> Mike
--
Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
> Oleksandr Kryvulia wrote:
>
> > 04.11.21 01:01, Mike Karels ?:
> > > I have a pending change to stop using class A/B/C netmasks when setting
> > > an interface address without an explicit mask, and instead to use a
> > > default
> > > mask (24 bits). A question has arisen as to what the default mask should
> > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit
> > > mask currently, but additions without a mask would default to 24 bits.
> > > There is no warning for missing masks for loopback in the current code.
> > > I'm not convinced that the mask has any meaning here; only a host route
> > > to the assigned address is created. Does anyone know of any meaning or
> > > use of the mask on a loopback address?
> > >
> > > Thanks,
> > > Mike
> > >
> >
> > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere
> > outside of the localhost. This described in RFC 5735 [1] and 1122 [2]
> >
> > [1] https://datatracker.ietf.org/doc/html/rfc5735
> > [2] https://datatracker.ietf.org/doc/html/rfc1122
>
> There is a push by some people to release 127.0.0.0/8 address space,
> leaving only 127.0.0.0/16 as reserved for localhost.
>
> https://www.spinics.net/lists/netdev/msg598545.html
>
> https://github.com/schoen/unicast-extensions/blob/master/127.md
>
> https://github.com/schoen/unicast-extensions/
>
> I make no comment on the feasability of doing this!
>
> However, that aside, aren't you just confusing the mask with routing?
>
> I think the mask on any IP on a loopback interface should be /32
> (if you want to add a "127.0.0.0/8 -local" route even if done
> automatically", then so be it)
>
> Note, the default FreeBSD firewall rules already have:
>
> ${fwcmd} add 100 pass all from any to any via lo0
> ${fwcmd} add 200 deny all from any to 127.0.0.0/8
> ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any
Which no longer work correctly since the "to 127.0.0.0/8"
packets SHALL go out what ever interface the route table
tells them to (often the default route), AND NOT lo0.
oot {1003}# route -n get 127.1.1.1
route to: 127.1.1.1
destination: 0.0.0.0
mask: 0.0.0.0
gateway: 192.168.32.8
fib: 0
interface: em0
flags:
recvpipe sendpipe ssthresh rtt,msecmtuweightexpire
0 0 0 0 1500 1 0
> Cheers, Jamie
--
Rod Grimes rgri...@freebsd.org
Re: netmask for loopback interfaces
> 04.11.21 01:01, Mike Karels ?: > > I have a pending change to stop using class A/B/C netmasks when setting > > an interface address without an explicit mask, and instead to use a default > > mask (24 bits). A question has arisen as to what the default mask should > > be for loopback interfaces. The standard 127.0.0.1 is added with an 8 bit > > mask currently, but additions without a mask would default to 24 bits. > > There is no warning for missing masks for loopback in the current code. > > I'm not convinced that the mask has any meaning here; only a host route > > to the assigned address is created. Does anyone know of any meaning or > > use of the mask on a loopback address? > > > > Thanks, > > Mike > > > > /8 mask on loopback prevetnts using of 127.x.x.x network anywhere > outside of the localhost. This described in RFC 5735 [1] and 1122 [2] > > [1] https://datatracker.ietf.org/doc/html/rfc5735 > [2] https://datatracker.ietf.org/doc/html/rfc1122 Saddly that no longer works correctly since there is no longer a 127/8 route in the table. Which, IMHO, is a mistake. -- Rod Grimes rgri...@freebsd.org
Re: cleaning up INET: deprecating network class A/B/C
> Rod wrote:
>
> > > I plan to do some cleanup of the residual code defining and using the
> > > old Internet network classes (A/B/C), which have been obsolete since
> > > CIDR took hold. This is an outline of what I plan, as it will happen
> > > in a number of steps and reviews, and I would like feedback on some
> > > of it.
> > >
> > > I want to reduce the use of the obsolete definitions and interfaces,
> > > and make it less likely for them to be used going forward. I plan
> > > to hide the Class A/B/C bit definitions unless a feature test macro
> > > is defined; that will be the default for user code for the moment.
> > > A few files in the kernel will need to define the feature test macro
> > > for now (but see the next two paragraphs).
>
> > Sounds good.
>
> > >
> > > Several of the uses of the historical network class macros have to
> > > do with generating a default network mask when none is provided.
> > > The worst of these is in the code for SIOCAIFADDR (add interface
> > > address). I want to have ifconfig and/or the kernel warn about this;
> > > the default is most likely wrong. After some time with a warning,
> > > it should become an error to set an Internet interface address
> > > without a mask (except for loopback and point-to-point interfaces,
> > > where the mask is meaningless).
>
> > Sounds good except that last bit, mask on loopback is
> > meaningful, especially for people like me that alrady
> > have modified systems that change loopback from 127/8
> > to 127/16.
>
> I'm not aware of anything that uses the mask on a loopback interface;
> are you? There is no network route installed when the loopback address
> is set. I think it's similar for point-to-point interfaces, where only
> the host route for the destination is added.
This is a regression in FreeBSD. Case in point:
x230a.dnsmgr.net:root {1003}# route -n get 127.1.1.1
route to: 127.1.1.1
destination: 0.0.0.0
mask: 0.0.0.0
gateway: 192.168.32.8
fib: 0
interface: em0
flags:
recvpipe sendpipe ssthresh rtt,msecmtuweightexpire
So if I try to send packets to 127.1.1.1 they are going to attempt
to go out em0, simply WRONG as the netmask on lo0 CLEARLY states
they should be via that interface:
x230a.dnsmgr.net:root {1004}# ifconfig lo0
lo0: flags=8049 metric 0 mtu 16384
options=680003
inet 127.0.0.1 netmask 0xff00
ping 127.1.1.1
PING 127.1.1.1 (127.1.1.1): 56 data bytes
ping: sendto: Can't assign requested address
this should actually be silent with no response
I would say that FreeBSD is broken here with respect to the
loss of the 127.0.0.0/8 via lo0 route.
>
> > Also care should be taken on point to point,
> > I think there is probably a fair bit of code/systems
> > out there that MAY still assume /30 or require /30 to
> > be set on these, it MAY be an interropt issue to force
> > the FreeBSD end to /32.
>
> Where is the mask ever used on a point-to-point interface? There is
> no broadcast address. However, my changes wouldn't break anything
> that isn't already broken.
This is P2P implementation dependent, iirc both ppp and tun and slip
all use to need a /30 and packets sent to the 0 host was discarded,
and packets sent to the broadcast address was sent to the far end.
Your only looking at current FreeBSD behavior, and I would suggest
that a larger sweep be made in the name of interoperability. Also
your forcing a POLICY and not simply providing a METHOD. If I want
to run a /24 on a p2p link I should be allowed to.
>
> > > I am tempted to define a new default mask, e.g. 24 bits, for those
> > > places that must be able to generate one. An example is NFS BOOTP
> > > code. I am interested in feedback on this idea. It would help to
> > > reduce use of the old masks, and 8- or 16-bit prefixes are highly
> > > unlikely to be correct. Comments on adding a default mask? This
> > > would eliminate the use of the old class macros in the kernel.
>
> > I am not keen on the idea of a default mask at all. I believe
> > every place that an IP address -is- used also has the ability
> > to specify a netmask.
>
> The cases that I'm talking about, like the NFS BOOTP code, have two
> choices: use a default, or fail (to boot, in this case). I'm not talking
> about adding a default anywhere, just changing it to ignore the "class"
> of the address. This would also be true when setting a local address
> with ifconfig, but that would only be temporary until it starts to return
> an error.
Can you point specifically at this code so I can get a better
understanding of what it is doing? I dont use BOOTP,
I use iPXE so I am unfamiliar with this code.
>
> > > The C library routines inet_netof() and inet_lnaof() should be
> > > deprecated, as they use the historical masks. inet_makeaddr() is
> > > almost as bad; it works almost by accident as long as a mask is a
> > > multiple of 8 bits. I'd like to remove their use from the base
> > >
Re: cleaning up INET: deprecating network class A/B/C
> I plan to do some cleanup of the residual code defining and using the > old Internet network classes (A/B/C), which have been obsolete since > CIDR took hold. This is an outline of what I plan, as it will happen > in a number of steps and reviews, and I would like feedback on some > of it. > > I want to reduce the use of the obsolete definitions and interfaces, > and make it less likely for them to be used going forward. I plan > to hide the Class A/B/C bit definitions unless a feature test macro > is defined; that will be the default for user code for the moment. > A few files in the kernel will need to define the feature test macro > for now (but see the next two paragraphs). Sounds good. > > Several of the uses of the historical network class macros have to > do with generating a default network mask when none is provided. > The worst of these is in the code for SIOCAIFADDR (add interface > address). I want to have ifconfig and/or the kernel warn about this; > the default is most likely wrong. After some time with a warning, > it should become an error to set an Internet interface address > without a mask (except for loopback and point-to-point interfaces, > where the mask is meaningless). Sounds good except that last bit, mask on loopback is meaningful, especially for people like me that alrady have modified systems that change loopback from 127/8 to 127/16. Also care should be taken on point to point, I think there is probably a fair bit of code/systems out there that MAY still assume /30 or require /30 to be set on these, it MAY be an interropt issue to force the FreeBSD end to /32. > > I am tempted to define a new default mask, e.g. 24 bits, for those > places that must be able to generate one. An example is NFS BOOTP > code. I am interested in feedback on this idea. It would help to > reduce use of the old masks, and 8- or 16-bit prefixes are highly > unlikely to be correct. Comments on adding a default mask? This > would eliminate the use of the old class macros in the kernel. I am not keen on the idea of a default mask at all. I believe every place that an IP address -is- used also has the ability to specify a netmask. > > The C library routines inet_netof() and inet_lnaof() should be > deprecated, as they use the historical masks. inet_makeaddr() is > almost as bad; it works almost by accident as long as a mask is a > multiple of 8 bits. I'd like to remove their use from the base > system. Unfortunately, I have no idea how much other software uses > them. We can at least document them as deprecated and unsafe. Wrap them in a depricating macro, the do a EXP-RUN with that macro defined, should get a good idea of that fallout from that. I do believe Linux still defines the CLASS macros. > Mike -- Rod Grimes rgri...@freebsd.org
Re: change to deprecate broadcast on host 0 of a subnet
> Bjoern wrote: > > > On 12 Sep 2021, at 15:25, Mike Karels wrote: > > > > Long ago (4.2BSD), the IP broadcast address was the lowest address on > > > a > > > network, the one with a host part of 0. In RFC1122, the broadcast > > > address > > > was standardized using a host part of all ones. 4.3BSD changed its > > > default, and made the broadcast address settable with ifconfig. > > > However, > > > FreeBSD *still* broadcasts packets sent to the lowest address on a > > > subnet. > > > > > > I have a change in review to stop broadcasting the lowest address on a > > > subnet by default, but added a sysctl to revert to the current > > > behavior. > > > I really doubt that anyone is still using a 0-based broadcast address. > > > This change allows host 0 on a subnet to be used as an assigned host > > > address, as long as the systems on that network support it (including > > > routers). Linux already has this change. > > > > > > The review is https://reviews.freebsd.org/D31861. See also > > > https:/datatracker.ietf.org/draft-schoen-intarea-lowest-address/ and > > > I think it is: > > > https://datatracker.ietf.org/doc/draft-schoen-intarea-lowest-address/ > > Thanks for the correction, I think I had to type this rather than pasting. > > > > some of the discussion in https://reviews.freebsd.org/D19316. > > > > > > Comments are welcome on the review. I will wait a couple of days > > > for comments before proceeding. I am also interested in comments on > > > whether this should be MFC'ed to 13-stable after a suitable delay. > > > I would have even gone one further step back and put this under > > EXPERIMENTAL > > in HEAD and wait until this draft has gone anywhere but with your sysctl > > I think > > it is fine (from reading the email not the recent review). > > > I would prefer if the current behaviour stayed default (would also MFC > > better) > > and then flip if this will indeed go anywhere. > > I considered that, but I think that the current behavior is simply > wrong. We broadcast packets to the lowest address on the net, but > we don't receive these broadcasts as such. I was surprised to find > that we were still broadcasting these packets. I can't think of any > reason we should do that. I agree with Mike here, though the IETF/RFC process is lacking, the use of all 0 host as a broadcast address is dead and has been dead for decades. If anyone anyplace can point me to a piece of equipment or software that can even recieve these without special configuration I would gladly recant my possition. > > Any other opinions on the default setting of the sysctl? > > > > My personal note on this is: it is riding a dead horse, driven by > > economics, > > and it feels 30 year too late to still do this and change this historic > > behaviour. > > 30 years ago, one might have been able to find a Vax running 4.2BSD to > send these packets to. I agree that this change should have been made > earlier, but that's not a good reason not to do it now. Whether or not > the change has economic benefit, it may allow people to use an additional > host on small networks. But I look at this primarily as a cleanup. There has been nothing pushing for a change here, the thinking in the network community has been that you can not use a host of 0 on a subnet, and left at that. Again, the process to correct the RFC's has been lacking. > Mike -- Rod Grimes rgri...@freebsd.org
Re: TCP Connection hang - MSS again
> 06.04.2021 19:54, Rodney W. Grimes wrote: > >> 05.04.2021 19:44, Rozhuk Ivan wrote: > >> > >>>>> As I understand, in some cases remote host does not reply with MSS > >>>>> option, and host behind router continue use mss 8960, that dropped > >>>>> by router. > >>>> If the peer does not provide an MSS option, your local FreeBSD based > >>>> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is > >>>> 536. So I don't think this should be a problem. > >>> > >>> Thats it! > >>> Thanks, it was ~64k in mine config. > >> > >> This is also per-host setting, you know :-) > >> > >> It is generally bad idea using MTU over 1500 for an interface facing > >> public network > >> without -mtu 1500. You see, because TCP MSS affects only TCP and there is > >> also UDP > >> that happily produces oversized datagramms for DNS or RTP or NFS or > >> tunneling like L2TP or OpenVPN etc. > >> relying on IP fragmentation. > >> > >> I still recommend using -mtu 1500 in addition to mssdflt in your case. > > > > I do not recommend such a setting. That would defeat any jumbo frame usage > > locally! > > Why? Default route should not be used for local delivery. Your right, but we are both making assumptions, I assumed that most likely the only route on the system is the default route, and your assuming that they are running with something more than a default route. > > The gateway/router that is forwarding packets to the internet connection > > needs its upstream interface mtu set properly, and configured to properly > > return icmp need fragement messages on the interfaces towards the > > internal network. > > This results in extra delays and retransmission during outgoing data > transfer, not good. > The mechanics is much more fragile than default route's mtu attribute. The delay should be pretty slight, the router is going to return an icmp message, and if configured to do so frag the packets and forward them on, no retransmission would occur as the DF flag is not normally set unless explicitly requested. It still makes no since to me to increase the interface MTU and then crank it back down by using a route MTU. You might as well just leave the MTU alone and not have 2 configurations items more or less doing nothing. -- Rod Grimes rgri...@freebsd.org ___ 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: TCP Connection hang - MSS again
> 05.04.2021 19:44, Rozhuk Ivan wrote: > > >>> As I understand, in some cases remote host does not reply with MSS > >>> option, and host behind router continue use mss 8960, that dropped > >>> by router. > >> If the peer does not provide an MSS option, your local FreeBSD based > >> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is > >> 536. So I don't think this should be a problem. > > > > Thats it! > > Thanks, it was ~64k in mine config. > > This is also per-host setting, you know :-) > > It is generally bad idea using MTU over 1500 for an interface facing public > network > without -mtu 1500. You see, because TCP MSS affects only TCP and there is > also UDP > that happily produces oversized datagramms for DNS or RTP or NFS or tunneling > like L2TP or OpenVPN etc. > relying on IP fragmentation. > > I still recommend using -mtu 1500 in addition to mssdflt in your case. I do not recommend such a setting. That would defeat any jumbo frame usage locally! The gateway/router that is forwarding packets to the internet connection needs its upstream interface mtu set properly, and configured to properly return icmp need fragement messages on the interfaces towards the internal network. This leaking of jumbo frames to the Internet is almost always caused by blockage of icmp packets internal to a network, and doing that forces one to run on an mtu that is acceptable to the global Internet, a far from optimal situation. -- Rod Grimes rgri...@freebsd.org ___ 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: NFS Mount Hangs
And I'll follow the lead to top post, as I have been quietly following this thread, trying to only add when I think I have relevant input, and I think I do on a small point... Rick, Your "unplugging" a cable to simulate network partitioning, in my experience this is a bad way to do that, as the host gets to see the link layer go down and knows it can not send. I am actually puzzled that you see arp packets, but I guess those are getting picked off before the interface layer silently tosses them on the ground. IIRC due to this loss of link layer you may be masking some things that would occur in other situations as often an error is returned to the application layer. IE the ONLY packet your likely to see into an unplugged cable is "arp". I can suggest other means to partition, such as configuring a switch port in and out of the correct LAN/VLAN, a physical switch in the TX pair to open it, but leave RX pair intact so carrier is not lost. Both of these simulate partitioning that is more realistic, AND does not have the side effect of allowing upper layers to eat the packets before bpf can grab them, or be told that partitioning has occured. Another side effect of unplugging a cable is that a host should immediately invalidate all ARP entries on that interface... hence your getting into an arp who has situation that should not even start for 5 minutes in the other failure modes. Regards, Rod > Well, I'm going to cheat and top post, since this is elated info. and > not really part of the discussion... > > I've been testing network partitioning between a Linux client (5.2 kernel) > and a FreeBSD-current NFS server. I have not gotten a solid hang, but > I have had the Linux client doing "battle" with the FreeBSD server for > several minutes after un-partitioning the connection. > > The battle basically consists of the Linux client sending an RST, followed > by a SYN. > The FreeBSD server ignores the RST and just replies with the same old ack. > --> This varies from "just a SYN" that succeeds to 100+ cycles of the above >over several minutes. > > I had thought that an RST was a "pretty heavy hammer", but FreeBSD seems > pretty good at ignoring it. > > A full packet capture of one of these is in /home/rmacklem/linuxtofreenfs.pcap > in case anyone wants to look at it. > > Here's a tcpdump snippet of the interesting part (see the *** comments): > 19:10:09.305775 IP nfsv4-new3.home.rick.nfsd > > nfsv4-linux.home.rick.apex-mesh: Flags [P.], seq 202585:202749, ack 212293, > win 29128, options [nop,nop,TS val 2073636037 ecr 2671204825], length 164: > NFS reply xid 613153685 reply ok 160 getattr NON 4 ids 0/33554432 sz 0 > 19:10:09.305850 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [.], ack 202749, win 501, options > [nop,nop,TS val 2671204825 ecr 2073636037], length 0 > *** Network is now partitioned... > > 19:10:09.407840 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [P.], seq 212293:212525, ack 202749, win > 501, options [nop,nop,TS val 2671204927 ecr 2073636037], length 232: NFS > request xid 629930901 228 getattr fh 0,1/53 > 19:10:09.615779 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [P.], seq 212293:212525, ack 202749, win > 501, options [nop,nop,TS val 2671205135 ecr 2073636037], length 232: NFS > request xid 629930901 228 getattr fh 0,1/53 > 19:10:09.823780 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [P.], seq 212293:212525, ack 202749, win > 501, options [nop,nop,TS val 2671205343 ecr 2073636037], length 232: NFS > request xid 629930901 228 getattr fh 0,1/53 > *** Lots of lines snipped. > > > 19:13:41.295783 ARP, Request who-has nfsv4-new3.home.rick tell > nfsv4-linux.home.rick, length 28 > 19:13:42.319767 ARP, Request who-has nfsv4-new3.home.rick tell > nfsv4-linux.home.rick, length 28 > 19:13:46.351966 ARP, Request who-has nfsv4-new3.home.rick tell > nfsv4-linux.home.rick, length 28 > 19:13:47.375790 ARP, Request who-has nfsv4-new3.home.rick tell > nfsv4-linux.home.rick, length 28 > 19:13:48.399786 ARP, Request who-has nfsv4-new3.home.rick tell > nfsv4-linux.home.rick, length 28 > *** Network is now unpartitioned... > > 19:13:48.30 ARP, Reply nfsv4-new3.home.rick is-at d4:be:d9:07:81:72 (oui > Unknown), length 46 > 19:13:48.42 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [S], seq 416692300, win 64240, options [mss > 1460,sackOK,TS val 2671421871 ecr 0,nop,wscale 7], length 0 > 19:13:48.400185 IP nfsv4-new3.home.rick.nfsd > > nfsv4-linux.home.rick.apex-mesh: Flags [.], ack 212293, win 29127, options > [nop,nop,TS val 2073855137 ecr 2671204825], length 0 > 19:13:48.400273 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [R], seq 964161458, win 0, length 0 > 19:13:49.423833 IP nfsv4-linux.home.rick.apex-mesh > > nfsv4-new3.home.rick.nfsd: Flags [S], seq 416692300, win 64240, options [mss
Re: Which cpu/mainboard for fast routing (bgp, full tables) ?
> Hi! > > > That class of processor has fairly limited memory bandwidth. An E5 v3 or > > greater should get you what you want, although finding a system that makes > > good use of available PCIe lanes with a single socket configuration can > > sometimes be maddening. AMD may have a variety of nice parts for this > > application, although I don?t have any personal experience with routing on > > such hardware. > > Thanks -- I searched for a pair of boxes in my infra with those > specs, found them: > > Intel(R) Xeon(R) CPU E5-1620 v3 @ 3.50GHz > 82599ES 10-Gigabit SFI/SFP+ Network Connection > and > Intel(R) Xeon(R) CPU E5-1620 v4 @ 3.50GHz > 82599ES 10-Gigabit SFI/SFP+ Network Connection > > and tested. Roughly the same performance, if we use only one > connection. These CPU's have a quad channel memory controller, to achive anything close to the maximal memory bandwidth of 68BG/s you need to have all 4 banks of the memory occupied with identical DIMM's, and preferable DDR4 2133 or DDR4 2400. Also iirc the 82599ES uses the iflib driver code, and I am not sure how performant that is. The Mellanox and Chelsio cards are preferable in places that high speed is needed. > > iperf3 -c > > The boxes were able to reach 10gbit, if we run 3 threads in parallel: > > iperf3 -c -P 3 > > So I have some area where I can investigate further. I am not sure if hyperthreading has any effect on this type setup, I usually disable it on anything I want to be "performant" unless I see some great need for more threads. > p...@freebsd.org +49 171 3101372 Now what ? -- Rod Grimes rgri...@freebsd.org ___ 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: AW: NFS Mount Hangs
> >>Output from the NFS Client when the issue occurs # netstat -an | grep > >>NFS.Server.IP.X > >>tcp0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049 > >>FIN_WAIT2 > >I'm no TCP guy. Hopefully others might know why the client would be stuck in > >FIN_WAIT2 (I vaguely recall this means it is waiting for a fin/ack, but > >could be wrong?) > > When the client is in Fin-Wait2 this is the state you end up when the Client > side actively close() the tcp session, and then the server also ACKed the > FIN. > This will last for ~2 min or so, but is asynchronous. However, the same > 4-tuple can not be reused during this time. I do not think this is the full story. If infact the Client did call close() you are correct, you would end up in FIN_WAIT2 for upto what ever the timeout is set to, IIRC default on that is 60 seconds, further in this case the socket is disconnected from the application and only the kernel has knowledge of it. The socket can stay in FIN_WAIT2 indefanitly if the application calls shutdown(2) on it, and never follows up with a close(2). Which situation exists can be determined by looking at fstat to see if the socket has an associted PID or not, not sure if that works on Linux though. > > With other words, from the socket / TCP, a properly executed active close() > will end up in this state. (If the other side initiated the close, a passive > close, will not end in this state) But only for a brief period. Stuck in this state indicates close(2) was not called, but shutdown(2) was. I believe it is also possible to get sockets stuck in this state when a client side port number reuse colides with a server side socket that is still in s CLOSE_WAIT state, oh wait, that ends up in no response to the SYN, hu... > freebsd-net@freebsd.org mailing list -- Rod Grimes rgri...@freebsd.org ___ 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: NFS Mount Hangs
Note I am NOT a TCP expert, but know enough about it to add a comment... > Alan Somers wrote: > [stuff snipped] > >Is the 128K limit related to MAXPHYS? If so, it should be greater in 13.0. > For the client, yes. For the server, no. > For the server, it is just a compile time constant NFS_SRVMAXIO. > > It's mainly related to the fact that I haven't gotten around to testing larger > sizes yet. > - kern.ipc.maxsockbuf needs to be several times the limit, which means it > would >have to increase for 1Mbyte. > - The session code must negotiate a maximum RPC size > 1 Mbyte. >(I think the server code does do this, but it needs to be tested.) > And, yes, the client is limited to MAXPHYS. > > Doing this is on my todo list, rick > > The client should acquire the attributes that indicate that and set > rsize/wsize > to that. "# nfsstat -m" on the client should show you what the client > is actually using. If it is larger than 128K, set both rsize and wsize to > 128K. > > >Output from the NFS Client when the issue occurs > ># netstat -an | grep NFS.Server.IP.X > >tcp0 0 NFS.Client.IP.X:46896 NFS.Server.IP.X:2049 > >FIN_WAIT2 > I'm no TCP guy. Hopefully others might know why the client would be > stuck in FIN_WAIT2 (I vaguely recall this means it is waiting for a fin/ack, > but could be wrong?) The most common way to get stuck in FIN_WAIT2 is to call shutdown(2) on a socket, but never following up with a close(2) after some timeout period. The "client" is still connected to the socket and can stay in this shutdown state for ever, the kernel well not reap the socket as it is associated with a processes, aka not orphaned. I suspect that the Linux client has a corner condition that is leading to this socket leak. If on the Linux client you can look at the sockets to see if these are still associated with a process, ala fstat or what ever Linux tool does this that would be helpfull. If they are infact connected to a process it is that process that must call close(2) to clean these up. IIRC the server side socket would be gone at this point and there is nothing the server can do that would allow a FIN_WAIT2 to close down. The real TCP experts can now correct my 30 year old TCP stack understanding... > > ># cat /sys/kernel/debug/sunrpc/rpc_xprt/*/info > >netid: tcp > >addr: NFS.Server.IP.X > >port: 2049 > >state: 0x51 > > > >syslog > >Mar 4 10:29:27 hostname kernel: [437414.131978] -pid- flgs status -client- > >--rqstp- ->timeout ---ops-- > >Mar 4 10:29:27 hostname kernel: [437414.133158] 57419 40a1 0 9b723c73 > >>143cfadf3 4ca953b5 nfsv4 OPEN_NOATTR a:call_connect_status [sunrpc] > >>q:xprt_pending > I don't know what OPEN_NOATTR means, but I assume it is some variant > of NFSv4 Open operation. > [stuff snipped] > >Mar 4 10:29:30 hostname kernel: [437417.110517] RPC: 57419 > >xprt_connect_status: >connect attempt timed out > >Mar 4 10:29:30 hostname kernel: [437417.112172] RPC: 57419 > >call_connect_status > >(status -110) > I have no idea what status -110 means? > >Mar 4 10:29:30 hostname kernel: [437417.113337] RPC: 57419 call_timeout > >(major) > >Mar 4 10:29:30 hostname kernel: [437417.114385] RPC: 57419 call_bind > >(status 0) > >Mar 4 10:29:30 hostname kernel: [437417.115402] RPC: 57419 call_connect > >xprt >e061831b is not connected > >Mar 4 10:29:30 hostname kernel: [437417.116547] RPC: 57419 xprt_connect > >xprt >e061831b is not connected > >Mar 4 10:30:31 hostname kernel: [437478.551090] RPC: 57419 > >xprt_connect_status: >connect attempt timed out > >Mar 4 10:30:31 hostname kernel: [437478.552396] RPC: 57419 > >call_connect_status >(status -110) > >Mar 4 10:30:31 hostname kernel: [437478.553417] RPC: 57419 call_timeout > >(minor) > >Mar 4 10:30:31 hostname kernel: [437478.554327] RPC: 57419 call_bind > >(status 0) > >Mar 4 10:30:31 hostname kernel: [437478.555220] RPC: 57419 call_connect > >xprt >e061831b is not connected > >Mar 4 10:30:31 hostname kernel: [437478.556254] RPC: 57419 xprt_connect > >xprt >e061831b is not connected > Is it possible that the client is trying to (re)connect using the same client > port#? > I would normally expect the client to create a new TCP connection using a > different client port# and then retry the outstanding RPCs. > --> Capturing packets when this happens would show us what is going on. > > If there is a problem on the FreeBSD end, it is most likely a broken > network device driver. > --> Try disabling TSO , LRO. > --> Try a different driver for the net hardware on the server. > --> Try a different net chip on the server. > If you can capture packets when (not after) the hang > occurs, then you can look at them in wireshark and see > what is actually happening. (Ideally on both client and > server, to check that your network hasn't dropped anything.) > --> I know, if the hangs aren't easily reproducible, this isn't > easily done. > --> Try a
Re: Is anybody using ng_pipe?
> On Tue, Aug 18, 2020 at 2:43 PM Eugene Grosbein wrote: > > Sorry, missed that. But why wasn't possible? > > There's a daemon running on the system that handles most network > configuration. It's quite inflexible and will override any manual > configuration changes. It manages firewall rules but is ignorant of > netgraph, so it will remove any dummynet rules but leave netgraph > configuration alone. It was significantly easier to just use ng_pipe, > even after having to fix or work around the bugs, than it was to fight > the daemon. > > On Tue, Aug 18, 2020 at 2:56 PM Marko Zec wrote: > > The probability that a frame is completely unaffected by BER events, > > and thus shouldn't be dropped, is currently computed as > > > > Ppass(BER, plen) = Psingle_bit_unaffected(BER) ^ Nbits(plen) > > The problem is in its calculation of Psingle_bit_unaffected(BER). The > BER is the fraction of bits that are affected, therefore it is the > probability that a bit is affected. But for some reason, > Psingle_bit_unaffected(BER) is calculated as 1 - 1/BER rather than 1 - > BER. This leads to the probability table being wrong. For example, > given a BER of 2350, the probability that a 1500-byte packet is > not dropped is: Is this a confusion over Bit Error Rate vis Bit Error Ratio? A BER of 2350 I must assume is 1 bit in 2350 bits. 1 - 1/BER looks correct to me for a Bit Error Rate 1 - BER looks correct to me for a Bit Error Ratio (usually a percentage) > > (1 - 2350/2**48)**(1500 * 8), which is approximately 99.00%. > > However, ng_pipe calculates a fixed-point probability value of > 281460603879001. To calculate whether a frame should be dropped, > ng_pipe takes this probability value and shifts it right by 17, > yielding 2147373991. It then calls rand() to generate a random number > in the range [0,2**31-1]; if the random number is larger than the > probability value than it is dropped, otherwise it is kept. The > chances that a packet is kept is therefore 2147373991/(2**31 - 1), or > about 99.99%. This looks like optimization to reduce calculation as it is done for every packet, why not do the calculation more accurately and only for each "error", see below. > It's easy enough to fix this one, but I wasn't sure that it would be > so easy to fix the TSO/LRO issue without significantly increasing the > memory usage, so I wanted to gauge whether it was worth pursuing that > avenue or if a simpler model would be a better use of my time. The > feedback is definitely that a simpler model is *not* warranted, so > let's talk about fixing TSO/LRO. I am not even sure how to deal with TSO/LRO and BER. Your not going to discard the whole segment are you? Are you going to try and packetize it, drop the packet(s) with errors, reassmble it? My method of calculating the future error point would at least allow you to just pass a whole segment without any of that hassle and only have to do that when an error is within some segment. > > On Tue, Aug 18, 2020 at 1:47 PM Rodney W. Grimes > wrote: > > Hum, that sounds like a poor implementation indeed. It seems > > like it would be easy to convert a BER into a packet drop > > probability based on bytes that have passed through the pipe. > > I'm not quite following you; can you elaborate? Would this solution > require us to update some shared state between each packet? One > advantage of the current approach is that there is no mutable state > (except, of course, when configuration changes). You would use the bytes transfered state that is already stored, and compute a "next error" point based on BER and some randomness such that your errors are not clocked at exact BER intervals. Compare the next error point to the bytes transfered + size of this packet/segment to decide if it needs dropped, if you drop then you must calculate a new "next error" point. This should considerable reduce the overhead for error rates that effect less than 50% of packets, and would be the same overhead for BER that effect every packet. And 100x more efficient for things that effect 1% of packets. -- Rod Grimes rgri...@freebsd.org ___ 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: Is anybody using ng_pipe?
> I recently needed to be able to simulate a lossy, high-latency network > in an environment where dummynet wasn't possible. I gave ng_pipe a > try, and hit some major issues > > 1. Instead of configuring a packet drop rate, you configure a bit > error rate, which I found significantly less intuitive >From your background being packet network centric perhaps? Those of us who have line oriented, aka telecom, centric backgrounds BER is a very meaningful and useful metric. > 2. The use of BER makes for a very inconvenient implementation, as > ng_pipe has to maintain a table of packet drop rates for every > possible packet size Hum, that sounds like a poor implementation indeed. It seems like it would be easy to convert a BER into a packet drop probability based on bytes that have passed through the pipe. It should be easy to covert a BER into a packet drop rate, but doing the converse leads to quantization errors. I would rather see us keep the BER as the metric and fix what is broken rather than convert this to a packet drop rate.. > 3. The table implementation isn't sized right for LRO or TSO, leading > to ng_pipe going out of bounds of the array and panicking the system Code predates LRO and TSO, so not unexpected. > 4. The table calculation had two integer truncation bugs and used the > wrong formula. I'm reasonably sure it would never calculate a > probability other than 0 due a 64-bit constant being truncated to > 32-bits. You retracted this. > I'd like to dump all of this and just implement a packet loss rate, > which would simplify all this immensely. Is anybody using ng_pipe > with a non-zero BER who would object to this? Given this litany of > issues I doubt it, but I thought that I'd be sure. My gut instinc is that statistically BER leads to a more realistic model. -- Rod Grimes rgri...@freebsd.org ___ 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: ip(8) in base
> > From: "Alexander V. Chernikov" > > To: net , freebsd-hackers > > Subject: ip(8) in base > > Date: Sun, 16 Aug 2020 10:11:11 +0100 > > > I want to introduce ip(8) or something similar in base. > > Basically, I need some userland tool to explicitly operates on nexthops, > > nexthop groups and fib lookup algorithms. > > > The existing tools are not well suited for the job: route(8) may be a > > candidate, but (a) it would either add another bunch of options or > > drastically change the tool by introducing [route nhop add], [route nhgroup > > add] and (b) listing is traditionally done by netstat(8). > > I agree with the others who said not to use ip(8) if the tool is not > compatible with the Linux ip. Also, routing is (at least in theory) > independent of address family, and that makes the name "ip" too specific. I strongly agree with this. > However, I think that route and netstat are sufficiently extensible to > add additional facilities, as they have been so far. One suggestion, > though, would be to preserve the general strategy of using "route verb ...", > e.g. "route add nhop ..." rather than "route nhop add ...". These seem > sufficiently similar to existing functionality to share a tool. Again, I agree with the above statement by Mike. The proposed commands are all in support of "route" features, and in BSD it is the route command that is used to maniplate these, please do not deviate from that. I have seen no strong reason given that route(8) and netstat(1) can not be extended to add the desired functionality. > Similarly, if possible I would prefer to see --libxo json rather than -j. I have no skin in this one, other than to state that iirc the route(8) command is currently without any long options so adding this --libxo would require adding long option support, which is probably not justifiable for 1 option. > Mike > > > I feel like there is a need of some cli tool that provides the ability to > > easily extend it by having separate namespaces for each sub-command (hello, > > ifconfig). > > > Naming is hard. I can, for example, use "rt" as a name to address my use > > cases. > > However, given the kernel interfaces for managing nexthops/nexhop groups > > are the same as with routes/arp/ndp, why not spending some additional time > > and support operating on routes and neighbors and name it ip? > > > Though, that arises multiple questions. > > Are we comfortable with ip(8) as a name in general? > > If we are, what's our take on having the compatible interface with Linux > > ip(8)? > > > Any comments/feedback is welcome :-) > > > > Appendix > > List of commands I need implemented > > > cmd [-46m] nhop create [gw XX] [iface YYY] [mtu YYY] [reject] [proxyfib Y] > > [fib X][ipv4] [ipv6] > > cmd [-46m] nhop delete nhop_id > > cmd -46m nhop list > > cmd -j nhop list # json What is special about these nhop routes that this is not just a route add? Could that not be handled as either a route flag ala -iface/-static/-reject/-blackhole or via a route modifier ala -osi/-xns/-inet/-inet6? I am actually a bit confused in that all routes are really just an expression of the "next hop" as far as the kernel goes, or are we now doing lsdb type routing in the kernel? > > > cmd -46m nhgroup create nhops 1,2,3,4,5,6 [fib X] > > cmd -46 nhgroup create nhops 1=100,2=100,3=200,4=100 [proxyfib Y][fib X] > > cmd -46 nhroup list ^ nhgroup? > > cmd -46 nhgroup delete nhgroup_id > > > cmd -46 fib algo list > > cmd -46 fib algo set algo dpdk_lpm6 fib 0 > > cmd -46 fib algo set algo auto fib 0 > > > > /Alexander -- Rod Grimes rgri...@freebsd.org ___ 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: No connection between jails
> I have two jails in the same subnet on two different hosts: > > > HOST1 -- jail1 > > | > > | > > HOST2 - jail2 > > > HOST1: 10.70.7.13/16 > HOST2: 10.70.70.2/16 > jail1: 10.70.5.2/32 > jail2: 10.70.7.50/32 > > Default gateway in the network is 10.70.70.1 but I don't think it > matters in this issue. > > > There is network connection between HOST1 and jail2, or HOST 2 and > jail1, or between any other host in the network and either jail1 or > jail2, however there is no network connection between jail1 and jail2. > By network connection I mean exchange of packets, e.g. "telnet > destination port". Both hosts and the default gateway are connected to > the same psychical switch. > > There is actually more jails on HOST1 but the situation is analogous - > no connection between jails on HOST1 and any jails on HOST2. > > What am I missing? > > > Both hosts have gateway_enable="YES" in rc.conf (net.inet.ip.forwarding: > 1). I am not using VNET, jails are aliased directly in host's network > interfaces (lagg0 for HOST1 and em0 for HOST2). Let me guess, lagg0 includes a wireless device? I think you may have the issue that you can not run multiple MAC addresses on a wireless device, and each of your jails on this node are going to have a unique MAC. > Thanks > GrzegorzJ > > ___ > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: How to increase the size of the MAC address caching table?
> 18.07.2020 16:16, Alexander V. Chernikov ?: > > 18.07.2020, 13:56, "Alexandr Baryshnyev" : > > > > Hello everybody. > > > > ???I have about 1,500 devices on the network, but in fact the MAC > > address table on the central router running Freebsd > > 12.0 never contains more than 1000 with small cached records. In the > > network, there are short-term random interruptions > > between different hosts and the router. The connection to the Internet > > on different computers in the network is lost for > > a short time. No apparent cause of these breaks was found. > > > > How often does this happens and what is the average "short-term" duration? > > I'd look into route -n monitor (don't remember if arp state reporting was > > merged into 12.0) and try to tcpdump arp > > traffic to get understanding what's happening here. > > Also: does this router perform TCP termination of the flows toward Internet? > > Breaks occur for no apparent reason. If you take one computer on the network, > it first works without problems for a long > time, then it suddenly starts breaks: one minute there is no connection, then > there are a few minutes and so on in a > circle. After a while (sometimes from one to three days) normal operation on > this computer resumes, but the problem goes > to another computer on the network and there is the same thing that happened > on the previous computer. Since we are talking arp I am going to assume no routing protocol is active on this collision domain. Please correct me if I am wrong about this. What is the switching topology of this 1500 node collision domain? Is it possible leaf switches are occasionally experiencing a MAC table overflow? How are IP addresses assigned, if by DHCP what are the lease lengths? Is it possible an IP is getting recycled while the node still thinks it has a valid lease? > > > ???There is a suspicion that the MAC address table on the FreeBSD > > router has a limited size, about 1000 with a small > > record maximum. Is that so? Is it possible to increase the size of this > > table if it is limited? An internet search was > > not successful. > > > > It's not limited. > > OK, thank you. So we have another cause for our problem. > > > ??Help me, please. > > > > ?> arp -an | grep -ve incomplete | wc -l What are these incomplete entries you filtered out? How many are there and why are the occuring? > > ?1055 > > > > "Incomplete" are still entries in the per-interface mac address table. > > What's the size with incomplete ones? > > > arp -an | wc -l > 1183 > > ifconfig bridge0 addr | wc -l > 1214 You are using FreeBSD as a transparent bridge for 1214 nodes? I know I only asked a lot of questions but hopefully some of the answers might provide an insight into what is going wrong. > ? Thank you. > -- > Best regards, > Alexandr B. Baryshnyev, e-mail: a...@abbon.net -- Rod Grimes rgri...@freebsd.org ___ 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: [Bug 248002] ping(8): TTL DETAILS update
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248002 > > Bug ID: 248002 >Summary: ping(8): TTL DETAILS update >Product: Documentation >Version: Latest > Hardware: Any > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: Manual Pages > Assignee: b...@freebsd.org > Reporter: jldu...@gmail.com > CC: d...@freebsd.org, n...@freebsd.org > > Reading ping(8), section "TTL DETAILS", I have seen a number of > inconsistencies regarding this value in FreeBSD. This section of the man page > has not been updated to reflect the current state. For instance: > > > Not change it; this is what BSD systems did before the 4.3BSD-Tahoe release. > > In this case the TTL value in the received packet will be 255 minus the > > number of routers in the round-trip path. > > This paragraph implies that FreeBSD is still using 255 as its default TTL, > it should be updated to reflect the current value (64) [1], perhaps: > > Not change it; this is what BSD systems did before the 4.3BSD-Tahoe release. > In this case the TTL value in the received packet will be 64 minus the number > of routers in the round-trip path. Why hard code another constant? Refer to net.inet.ip.ttl. > > Other paragraphs could also be updated, for example: > > > The TCP/IP specification recommends setting the TTL field for IP packets to > > 64, but many systems use smaller values (4.3BSD uses 30, 4.2BSD used 15). > > The TCP/IP specification recommends setting the TTL field for IP packets to > 64, FreeBSD uses this value... > > The DESCRIPTION mentions that the sysctl net.inet.ip.ttl is used, but > it does not say that this value is 64 by default. And it probably shouldnt, sticking hard constants in man pages leads to out of date information any time that constant evolves. > > Maybe also include some current OSs? I have compiled a quick list that can be > easily verified pinging the hosts inside the brackets, this should give you > the TTL (plus the number of hops): > > Windows: 128 [live.com] > BSDs (NetBSD and OpenBSD): 255 [netbsd.org, openbsd.org] > Linux: 64 [linux.org] > > FreeBSD, macOS: 64 FreeBSD should not document what other OS's do. > > > Set it to 255; this is what current BSD systems do. In this case the TTL > > value in the received packet will be 255 minus the number of routers in the > > path from the remote system to the pinging host. > > Set it to 255; this is what some BSD systems do... > > Some current BSD systems do use 255 (at least NetBSD and OpenBSD); however, > FreeBSD uses the IANA-recommended value of 64 [2]. > > References: > > [1] > https://github.com/freebsd/freebsd/blob/3f4da6d3e7a2a8cc34a94938bd1c4f80c8d1d449/sys/netinet/ip.h#L212 > [2] > https://www.iana.org/assignments/ip-parameters/ip-parameters.xhtml#ip-parameters-2 > > -- > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: routed && route6d removal proposal
> 23.06.2020 2:26, Rodney W. Grimes wrote: > > >> 22.06.2020 19:49, Rodney W. Grimes wrote: > >>> Whats unmaintained about code that has no need to change cause it just > >>> pretty much works? > >> Have you actually tried running routed(8) as base for real network with > >> loops, > >> mix of p2p and ethernet-like interfaces, IPv4 aliases, need of > >> offset-lists and > >> with diameter about 6 hops? > > > > As I said I know of people that are running and it is working, and > > Hiroko's post clearly establishes that as fact in evidence. > > > > I am not even sure that RIP* has loop detection in the protocol, > > It has, of course. Slight miss communications, there really isnt a loop detection in the on wire protocol, or multipath support, it simply excludes certain routes that end up excluded by counting to infinity to stop the loop (inifinity is usually 16 for this solution). Its not like OSPF or BGP where you can calculate loops and mulipath effects. Bottom line, RipV2 is not healthy on a network when loops exist, though it should not lead to failure. > > > as the prefered routing protocol for anything multipath (which > > is what loops are in effect) is OSPF. > > RIPv2 may be used for failover, not for multipath. Any redundant route > creates L3 "multipath". Yes. > >> I'm not talking about RIPv2 inherent deficiencies. > >> Our routed just glitches where quagga's ripd just works. > > > > And your PR# for reporting the bug is? > > Was. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=51927 > Never had a chance to verify if it was really fixed in HEAD because it was > not for RELENG_4, > so I moved to ripd. As you may remeber, RELENG_5 needed much time to become > ready for production. I can not find any commit linked to that bug, but this is probalby before the system to do that existed. Unless we can confirm the bug still exists I think it would be predunt to assume it is fixed based on what I read in the PR, so dismissing the claim that the inbase routed "just glitches." Can you agree with that logic Eugene? Regards, -- Rod Grimes rgri...@freebsd.org ___ 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: Committing a few ipfw(8) patches
> Hi freebsd-net@,
>
> I'm really sorry if I'm bothering you with emails like this.
>
> If there are any committers here, I have two patches for the ipfw(8)
> subsystem.
>
> The patches (w/ description & URL) are:
>
> ===
> ipfw(8): In fill_ip6(), use a single statement for both "me" and "me6".
> This prevents unneeded code duplication.
>
> URL: https://reviews.freebsd.org/D24403
> ===
> ipfw: Support {w:x:y::z}:port (bracketed) IPv6 addresses in the fwd
> command.
>
> While we're doing this, optimize by not attempting to parse addresses if
> we're using tableargs.
>
> URL: https://reviews.freebsd.org/D24011
> ===
>
> Both patches have been accepted by rgrimes@, but neither are committed
> yet.
Since I am not an "area expert" on ipfw I do not feel comfortable
in commiting these patches without additional review.
If they can get some more review I would be fine with committing them.
> Could one of you committers please commit the above two patches? If so,
> I would love that.
>
> Unfortunately, I am not a committer. I just happen to share a first name
> (not last) with one, don't get confused.
>
> Best,
>
> Neel Chauhan
>
> ===
>
> https://www.neelc.org/
> ___
> 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"
>
--
Rod Grimes rgri...@freebsd.org
___
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: routed && route6d removal proposal
> 22.06.2020 19:49, Rodney W. Grimes wrote: > > > Whats unmaintained about code that has no need to change cause it just > > pretty much works? > > Have you actually tried running routed(8) as base for real network with loops, > mix of p2p and ethernet-like interfaces, IPv4 aliases, need of offset-lists > and > with diameter about 6 hops? As I said I know of people that are running and it is working, and Hiroko's post clearly establishes that as fact in evidence. I am not even sure that RIP* has loop detection in the protocol, as the prefered routing protocol for anything multipath (which is what loops are in effect) is OSPF. > > I'm not talking about RIPv2 inherent deficiencies. > Our routed just glitches where quagga's ripd just works. And your PR# for reporting the bug is? -- Rod Grimes rgri...@freebsd.org ___ 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: routed && route6d removal proposal
> Hey, > > I would like to propose removal of sbin/routed and usr.sbin/route6d. I disagree with removal, as your analysis is flawed. > routed(8) is the daemon implementing RIPv2 routing protocol. > route6d(8) is the daemon implementing RIPng routing protocol for IPv6. > > RIP [1] was one of the first protocols used in the networking. The first > version was implemented back in 1982. RIPv1 was implemented in 1982, RIPv2 became RFC2453 in November 1998, and is a current and valid IETF standard, STD56. It was updated by RFC4822 in February 2007. > > 1. Network landscape has changed since then. BGP, OSPF, IS-ISIS and other > routing protocols have been created and greatly improved over years. People > have created and adopted numerous designs leveraging OSPF/ISIS or BGP. > RIP became obsolete a while ago as there were no competitive advantage it can > offer. > "It is the oldest routing protocol used by the network industry and is > considered by many to be inefficient or border-line obsolete." ? [2], 2009 RIPv2 is not obosolete, and your reference is not authoritave on what is or is not an obsolete network protocol. I know of people using RIPv2 in networks. > "Today, the only reason you might run across a network running RIPv2 is > either that the network is very old and in serious need of an upgrade or the > network is running cheaper, consumer-grade routing hardware that can only > support RIP" ? [3], 2016. Or there simply is no need for anything more complicated. RipV2 is a very simple protocol and works fine for small networks in many settings. > > 1.1. Nowadays the daemon name is simply misleading. Given situation described > above, one does expect far wider functionality from the program named > "route[6]d" than just RIP implementation. I'll agree the name is missleading, so change it, but removal on your false basis is not. > > 2. Multiple routing stacks supporting all major routing protocol including > RIP exists these days: bird, frr, quagga. Many BGP-only designs in are > gaining popularity, so do bgp speakers such as exabgp or gobgp. Nowadays, if > one needs dynamic routing on the host, OSPF or BGP speaker is the choice. > FreeBSD packages contains well-maintained ports for these. Having RIP[ng] > speakers in base offers no advantage. Routing stacks? You mean routing daemons? Forcing users to install bir, frr or quagga when all they need, or have been using for a long time is in base ripv2 is not good for users. > 3. Both routed/route6d are largely unmaintained [4] and presents an > additional attack vector. Here is the list of last non-trivial commits to > routed/route6d: Whats unmaintained about code that has no need to change cause it just pretty much works? > > sbin/routed: > r327276 - coverity > r317035 - rtsock fix > r299825 - coverity > r299822 - coverity, from netbsd > r299821 - coverity, from netbsd > r299784 - coverity, from netbsd > r299771 - coverify, from netbsd > r286347 - bugfix > r276602 - SA14:21 patch > r271919 - SA14:21 fix > r215702 - logic fix, 2010 > > usr.sbin/route6d: > r337500 - functional fix, 2018 > r317035 - rtsock fix > r311994 - coverity > r311985 - coverity > r299869 - coverity > r299491 - coverity > r270234 - link-local fix > r243233 - functionality improvement, 2012 > > To summarise: RIP protocol is obsolete, implementations for newer protocols > exists in ports, implementation in base is unmaintained. > > With all that in mind I propose to remove routed and route6d from base in > FreeBSD 13. > Timeline: > June 5 - feedback aggregation and decision point > July 19 - removal (proposed) > > > [1] https://en.wikipedia.org/wiki/Routing_Information_Protocol > [2] > https://www.globalknowledge.com/ca-en/resources/resource-library/articles/basics-of-understanding-rip/ > [3] > https://www.networkcomputing.com/data-centers/comparing-dynamic-routing-protocols > [4] > https://bugs.freebsd.org/bugzilla/buglist.cgi?cmdtype=runnamed_id=361897=routed_prs > > /Alexander > ___ > 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" > > -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> On Wed, 17 Jun 2020 10:33:59 -0700 (PDT) Rodney W. Grimes > freebsd-...@gndrsh.dnsmgr.net said > > > > > > > On (06/16/20 08:14), Rodney W. Grimes wrote: > > >>Ok, well, I just thought of one and not sure if it is an issue or not, > > >>doesng unbound have the ability to specify interfaces? If so those > > >>may not exist until NETWORKING has run? > > > > > > > > > > Unbound isn't really going to do anything useful without the network. I > > > don't think it is unreasonable that it should depend on NETWORKING. > > > > Well then the current setup for local_unbound is counter to that, > > as it is BEFORE: NETWORKING > > > > > I think we're in an edge case here and, perhaps, a better solution might > > > be to have someone(tm) add in support in rc.conf to specify dependency > > > overrides. > > > > dns and configuration are a chicken/egg problem, not really an edge > > case, and a person must make a decision as to how to deal with that. > > > > > > > > So, perhaps you could set: > > > > > > dhcpd_after="unbound" > > > > > > Which would factor into the rcorder processing and make sure that dhcpd > > > starts after unbound. > > > > > > This would allow people to fine-tune things when they run into cases > > > like this. > > > > Even beside the unbound problem, this is a good idea. It would > > fix my "I need ipfw before routing as without ipfw my ospf packets > > get blocked and things take much longer to come up problem." > Honestly. I'm really inclined to agree with Rodney. rcorder should > really be a more fine-grained utility. > What about something like: > BEFORE: NETWORKING: pf > or > BEFORE: NETWORKING: ipfw > or > BEFORE: NETWORKING: unbound > etc, etc... > I think there *may* be a better direction. *But* this, at least > should be an easy direction to add with few repercussions. Yes? I do not see your fine graining, the above can be expressed already with just the pf, ipfw or unbound keyword can't they? Though I do think we need to maybe find ways to alter what the default values for BEFORE: and REQUIRE: are in the /etc/rc.d files. As my example I use the fact I have to add ipfw to rc.d/routing as it is problematic getting a routing protocol (ospf, bgp, ripv2) to come up when the firewall is blocking all the packets. It eventuly sorts itself out, but its ugly on the console and on the wire. > > > > > > > -r > > > > > > The idea that a daemon that depends on the network being functional > > > >> > > >> On a related note, unbound rc script provides "unbound" > > > >> service. > > > >> > > >> I think that maybe it should provide something more generic > > > >> such > > > as "nameserver" > > > >> > > >> or "dns-server" (not sure if there is an established name for > > > that). > > > >> > > >> The reason I am saying this is that, IMO, if unbound is > > > >> replaced > > > with some other > > > >> > > >> name server implementation the rc dependency chains should stay > > > the same. > > > >> > > > > > > >> > > > I do not see anything in the base system that uses unbound or > > > local_unbound > > > >> > > > service name, so this looks like it could be straightforward, > > > though there > > > >> > > > may be some ports that have use of this token. > > > >> > > > > > > >> > > > For the blue bikeshed I find that "server" is just noise in the > > > token > > > >> > > > and that "dns" already has "s" for system, so just "dns" is good > > > with me :-) > > > >> > > > > > >> > > That's a good point. > > > >> > > > >> I don't agree. The term dns is too generic. People are often running > > > >> dfferent nameservers on the same machine, as example: authoritative > > > >> and nonauthoritative (e.g. nsd & unbound). > > > > > > >>Given examples by others your right, we can not put all of these > > >>behind the knob "dns". > > > > > > > >> Regards, > > > >>jaap > > >>-- > > >>Rod Grimes > > >rgri...@freebsd.org > > > > > > -- > > > Ryan Steinmetz > > > PGP: 9079 51A3 34EF 0CD4 F228 EDC6 1EF8 BA6B D028 46D7 > > > > > > > -- > > Rod Grimes > > rgri...@freebsd.org > > --Chris > > > > -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> On Tue, Jun 16, 2020 at 08:18:59AM -0700, Rodney W. Grimes wrote: > > ... Sometimes > > that leads to duplicate IP information stored in various config files. > > > > When possible managing those configuraitons via ansible or other CM > > system that can pull the data from dns and build the config files > > minimizes the work to keep it all up to date. > > Would defining a variable in /etc/rc.conf help? Don't most/all rc.d scripts > end up sourcing it? Works for me in my local startups. No as it is usually .conf files that need this info, and those do not source rc.conf. Almost any routing protocol configuration needs access to this data, dhcpd.conf is another one. This particular one, wanting to use names in a name service itself is particularly hard to deal with. -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> > On (06/16/20 08:14), Rodney W. Grimes wrote: > >Ok, well, I just thought of one and not sure if it is an issue or not, > >doesng unbound have the ability to specify interfaces? If so those > >may not exist until NETWORKING has run? > > > > Unbound isn't really going to do anything useful without the network. I > don't think it is unreasonable that it should depend on NETWORKING. Well then the current setup for local_unbound is counter to that, as it is BEFORE: NETWORKING > I think we're in an edge case here and, perhaps, a better solution might > be to have someone(tm) add in support in rc.conf to specify dependency > overrides. dns and configuration are a chicken/egg problem, not really an edge case, and a person must make a decision as to how to deal with that. > > So, perhaps you could set: > > dhcpd_after="unbound" > > Which would factor into the rcorder processing and make sure that dhcpd > starts after unbound. > > This would allow people to fine-tune things when they run into cases > like this. Even beside the unbound problem, this is a good idea. It would fix my "I need ipfw before routing as without ipfw my ospf packets get blocked and things take much longer to come up problem." > -r > > The idea that a daemon that depends on the network being functional > >> > > >> On a related note, unbound rc script provides "unbound" service. > >> > > >> I think that maybe it should provide something more generic such > >> as "nameserver" > >> > > >> or "dns-server" (not sure if there is an established name for > >> that). > >> > > >> The reason I am saying this is that, IMO, if unbound is replaced > >> with some other > >> > > >> name server implementation the rc dependency chains should stay > >> the same. > >> > > > > >> > > > I do not see anything in the base system that uses unbound or > >> local_unbound > >> > > > service name, so this looks like it could be straightforward, > >> though there > >> > > > may be some ports that have use of this token. > >> > > > > >> > > > For the blue bikeshed I find that "server" is just noise in the > >> token > >> > > > and that "dns" already has "s" for system, so just "dns" is good > >> with me :-) > >> > > > >> > > That's a good point. > >> > >> I don't agree. The term dns is too generic. People are often running > >> dfferent nameservers on the same machine, as example: authoritative > >> and nonauthoritative (e.g. nsd & unbound). > > > >Given examples by others your right, we can not put all of these > >behind the knob "dns". > > > >> Regards, > >>jaap > >-- > >Rod Grimes > >rgri...@freebsd.org > > -- > Ryan Steinmetz > PGP: 9079 51A3 34EF 0CD4 F228 EDC6 1EF8 BA6B D028 46D7 > -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> On 15/06/20 14:47, Andriy Gapon wrote: > > On 15/06/2020 14:48, Eugene Grosbein wrote: > >> 15.06.2020 13:10, Andriy Gapon wrote: > >> > >>> I am configuring a small LAN -- mostly a gateway / router for it -- and I > >>> am > >>> using unbound for a local DNS and isc-dhcp44-server for DHCP. > >>> I have a few hosts with static IP addresses (for various reasons). > >>> So, in unbound.conf I have an entry like > >>> local-data: "hipster.home.arpa. IN A 192.168.0.222" > >> > >> Consider using /etc/hosts in addition to DNS to solve chicken/egg problem. > >> > >> > > > > Having the same IP in more than one place (on the router) is the thing that > > I'd > > like to avoid in the first place. Otherwise, there is no problem putting > > it in > > hdcpd.conf. > > > > A secondary DNS server could also help, unless both are rebooted at the > same time. Defanitly, that is one solution, but it also has issues like now I need NETWORKING and ROUTING and FIREWALL code all working before I might be able to access that "remote" DNS server. This is one of the things that has lead me to manage systems in a way that I can almost always boot anything with the network disconected and it still comes up with a valid and operation state. Sometimes that leads to duplicate IP information stored in various config files. When possible managing those configuraitons via ansible or other CM system that can pull the data from dns and build the config files minimizes the work to keep it all up to date. > -- > Guido Falsi -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> "Rodney W. Grimes" writes: > > > Um, yea, I guess the bigger question is why is the port different > > than the base system in this respect? > > The the unbound port existed years before it was decided that unbound > should replace bind in the base system. > > If you want the port to change, send a PR for the port so I won't forget this. > > > > > I would expect unbound to be the same, as unbound_local in almost > > every respect, especially with respect to its startup sequencing, > > providers and requires. > > Not really. For a start, the port has a different default configuration > then the one in base. Why does that change the startup order, required and providers? If the rc system is so sensative as to the configuration of daemons/servers we need to add a way to alter these better than editing /etc/rc.d/* files. (Which I present I do only as a last resort and last time I checked I had 2 local mods in there, one mostly case bird takes to long to get going during the routing startup, and one to cause ipfw loading earlier. > > > > > > I seen no problem in adding a BEFORE: NETWORKING to the port, covering > > > > a larger number of casses than your narrow BEFORE: dhcpd. > > I don't see a problem either. Ok, well, I just thought of one and not sure if it is an issue or not, doesng unbound have the ability to specify interfaces? If so those may not exist until NETWORKING has run? > > > >> On a related note, unbound rc script provides "unbound" service. > > > >> I think that maybe it should provide something more generic such as > "nameserver" > > > >> or "dns-server" (not sure if there is an established name for that). > > > >> The reason I am saying this is that, IMO, if unbound is replaced with > some other > > > >> name server implementation the rc dependency chains should stay the > same. > > > > > > > > I do not see anything in the base system that uses unbound or > local_unbound > > > > service name, so this looks like it could be straightforward, though > there > > > > may be some ports that have use of this token. > > > > > > > > For the blue bikeshed I find that "server" is just noise in the token > > > > and that "dns" already has "s" for system, so just "dns" is good with > me :-) > > > > > > That's a good point. > > I don't agree. The term dns is too generic. People are often running > dfferent nameservers on the same machine, as example: authoritative > and nonauthoritative (e.g. nsd & unbound). Given examples by others your right, we can not put all of these behind the knob "dns". > Regards, > jaap -- Rod Grimes rgri...@freebsd.org ___ 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: unbound and (isc) dhcpd startup order
> On 15/06/2020 15:57, Rodney W. Grimes wrote:
> >>
> >> I am configuring a small LAN -- mostly a gateway / router for it -- and I
> >> am
> >> using unbound for a local DNS and isc-dhcp44-server for DHCP.
> >> I have a few hosts with static IP addresses (for various reasons).
> >> So, in unbound.conf I have an entry like
> >> local-data: "hipster.home.arpa. IN A 192.168.0.222"
> >> and in dhcpd.conf have:
> >> host hipster {
> >>
> >>
> >> hardware ethernet 40:74:e0:xx:xx:xx;
> >>
> >>
> >> fixed-address hipster.home.arpa;
> >>
> >>
> >> }
> >>
> >> I am using a DNS name to avoid hardcoding the same IP address twice.
> >> But obviously this depends on the local DNS server starting before the HDCP
> >> server if they are on the same host / router.
> >> It seems that at the moment there is nothing to ensure that order.
> >>
> >> For the moment I modified rc.d/unbound to add this line:
> >> # BEFORE: dhcpd
> >
> >>From looking at /etc/rc.d/local_unbound we see:
> > # PROVIDE: local_unbound
> > # REQUIRE: FILESYSTEMS defaultroute netwait resolv
> > # BEFORE: NETWORKING
> > # KEYWORD: shutdown
> >
> > What makes it work for that case is the BEFORE: NETWORKING is that
> > line missing for the port version?
>
> Yes, it is:
> # PROVIDE: unbound
> # REQUIRE: SERVERS cleanvar
> # KEYWORD: shutdown
>
> If we add BEFORE: NETWORKING then REQUIRE will also have to be adjusted as
> it's
> impossible to be before NETWORKING and after SERVERS.
Um, yea, I guess the bigger question is why is the port different
than the base system in this respect?
I would expect unbound to be the same, as unbound_local in almost
every respect, especially with respect to its startup sequencing,
providers and requires.
> >> I am not sure if this is the best solution and it's something that can be
> >> included into the port.
> >
> > I think that DNS needs to be started before more than just dhcpd,
> > so this is just 1 of many possible cases. This can also be issues
> > with almost any network stuff that wants to do stuff by DNS value,
> > including the networkself. DNS creates a chicken/egg problem in
> > that you may, or may not need the network to resolve names, I have
> > always hated that aspect of it. Modern tooling can help, you use
> > stuff to build your /etc/rc config files that can me run while the
> > network is up and functional so that this entering IP addresses in
> > N places is less painful.
> >
> > I seen no problem in adding a BEFORE: NETWORKING to the port, covering
> > a larger number of casses than your narrow BEFORE: dhcpd.
>
> I agree.
> I hope it doesn't break any currently working configurations too.
I have no idea how to hunt through ports looking for this. I
suppose find all ports that need unbound and see what there startup
scripts look like.
> >> On a related note, unbound rc script provides "unbound" service.
> >> I think that maybe it should provide something more generic such as
> >> "nameserver"
> >> or "dns-server" (not sure if there is an established name for that).
> >> The reason I am saying this is that, IMO, if unbound is replaced with some
> >> other
> >> name server implementation the rc dependency chains should stay the same.
> >
> > I do not see anything in the base system that uses unbound or local_unbound
> > service name, so this looks like it could be straightforward, though there
> > may be some ports that have use of this token.
> >
> > For the blue bikeshed I find that "server" is just noise in the token
> > and that "dns" already has "s" for system, so just "dns" is good with me :-)
>
> That's a good point.
> I've just checked bind ports and they use PROVIDE: named
> Not sure if "named" here is a bind specific name or a generic one.
named is specifically the name of the binary included in the bind
product, which included the resolver stub, named, and some other
support utilities like rndc and nslookup.
It would make since to unify these, though that is going to take
some cafeful thought and co-ordination as to not break peoples
running systems. I suspect the ports conflict stuff is keeping
one from installing unbound, and bind at the same time, arguable
wrong as one should be able to install both, but only run one
at a time, or even run both on different ports.
> --
> Andriy Gapon
--
Rod Grimes rgri...@freebsd.org
___
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: unbound and (isc) dhcpd startup order
>
> I am configuring a small LAN -- mostly a gateway / router for it -- and I am
> using unbound for a local DNS and isc-dhcp44-server for DHCP.
> I have a few hosts with static IP addresses (for various reasons).
> So, in unbound.conf I have an entry like
> local-data: "hipster.home.arpa. IN A 192.168.0.222"
> and in dhcpd.conf have:
> host hipster {
>
>
> hardware ethernet 40:74:e0:xx:xx:xx;
>
>
> fixed-address hipster.home.arpa;
>
>
> }
>
> I am using a DNS name to avoid hardcoding the same IP address twice.
> But obviously this depends on the local DNS server starting before the HDCP
> server if they are on the same host / router.
> It seems that at the moment there is nothing to ensure that order.
>
> For the moment I modified rc.d/unbound to add this line:
> # BEFORE: dhcpd
>From looking at /etc/rc.d/local_unbound we see:
# PROVIDE: local_unbound
# REQUIRE: FILESYSTEMS defaultroute netwait resolv
# BEFORE: NETWORKING
# KEYWORD: shutdown
What makes it work for that case is the BEFORE: NETWORKING is that
line missing for the port version?
> I am not sure if this is the best solution and it's something that can be
> included into the port.
I think that DNS needs to be started before more than just dhcpd,
so this is just 1 of many possible cases. This can also be issues
with almost any network stuff that wants to do stuff by DNS value,
including the networkself. DNS creates a chicken/egg problem in
that you may, or may not need the network to resolve names, I have
always hated that aspect of it. Modern tooling can help, you use
stuff to build your /etc/rc config files that can me run while the
network is up and functional so that this entering IP addresses in
N places is less painful.
I seen no problem in adding a BEFORE: NETWORKING to the port, covering
a larger number of casses than your narrow BEFORE: dhcpd.
>
> On a related note, unbound rc script provides "unbound" service.
> I think that maybe it should provide something more generic such as
> "nameserver"
> or "dns-server" (not sure if there is an established name for that).
> The reason I am saying this is that, IMO, if unbound is replaced with some
> other
> name server implementation the rc dependency chains should stay the same.
I do not see anything in the base system that uses unbound or local_unbound
service name, so this looks like it could be straightforward, though there
may be some ports that have use of this token.
For the blue bikeshed I find that "server" is just noise in the token
and that "dns" already has "s" for system, so just "dns" is good with me :-)
> Thanks!
> --
> Andriy Gapon
--
Rod Grimes rgri...@freebsd.org
___
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: how to fix an interesting issue with mountd?
> Hi, > > I'm posting this one to freebsd-net@ since it seems vaguely similar > to a network congestion problem and thought that network types > might have some ideas w.r.t. fixing it? > > PR#246597 - Reports a problem (which if I understand it is) where a sighup >is posted to mountd and then another sighup is posted to mountd while >it is reloading exports and the exports are not reloaded again. >--> The simple patch in the PR fixes the above problem, but I think will > aggravate another one. > For some NFS servers, it can take minutes to reload the exports file(s). > (I believe Peter Erriksonn has a server with 8+ file systems exported.) > r348590 reduced the time taken, but it is still minutes, if I recall > correctly. > --> If you apply the patch in the PR and sighups are posted to mountd as >often as it takes to reload the exports file(s), it will simply reload > the >exports file(s) over and over and over again, instead of processing >Mount RPC requests. > > So, finally to the interesting part... > - It seems that the code needs to be changed so that it won't "forget" > sighup(s) posted to it, but it should not reload the exports file(s) too > frequently. > --> My thoughts are something like: > - Note that sighup(s) were posted while reloading the exports file(s) and > do the reload again, after some minimum delay. > --> The minimum delay might only need to be 1second to allow some >RPCs to be processed before reload happens again. > Or > --> The minimum delay could be some fraction of how long a reload takes. > (The code could time the reload and use that to calculate how long > to >delay before doing the reload again.) > > Any ideas or suggestions? rick > ps: I've actually known about this for some time, but since I didn't have a > good > solution... Build a system that allows adding and removing entries from the in mountd exports data so that you do not have to do a full reload every time one is added or removed? Build a system that used 2 exports tables, the active one, and the one that was being loaded, so that you can process RPC's and reloads at the same time. > ___ > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: SRv6 in FreeBSD
> Hi Rodney, > > I haven't said that is not approved or an RFC exist (there are many and some > interesting use cases) , but can you tell me of any in production deployments? I can not, though for the SRH to be in its current state as a "Standards Track" document there must be running code someplace... and that usually implies production deployments as well, or atleast not small scale tests. > > The conservatory still there, if you check with your customer, how many are > willing to deploy it? I did not mention any customer(s) at all, I stated I was interested in any use case. > > Open for an offline talk about it as i really like to know if you are seeing > other thing.. I do not know that there is much to talk about. > Best regards. > > Santiago > > > > On 2019-11-26 11:33, Rodney W. Grimes wrote: > > >> Hi Alex, > >> > >> While I'm not a BSD developer, i really doubt it, considering that the > >> building blocks for SR are not there ( mpls support or just label > >> push/pop/swap). > > He specifically stated SRv6 which is not MPLS based. > > The building blocsk if one was to need this in a BSD are in > > OpenBSD which has an MPLS implementation. > > > >> On the other hand, on SRv6 as you mentioned you rely on IPv6 headers and > >> there is a lot of conservatory about it ( unless you are a Cisco fan!) > > :-) The SRH is 5 years and 26 revisions into the process and has > > been "Submitted to IESG for Publication" per: > > https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ > > so it should be possible for someone to do an implementation in FreeBSD > > > >> I'm interesting on the use case, if you don't mind... is it just service > >> chaining you application ? Usually servers are just part of an overlay ( > >> call it VXLAN,? MPLS? or something over something else...) > > I would be interested to here the use cases as well. > > > >> Best regards. > >> > >> Santiago > >> > >> > >> On 2019-11-25 03:43, madhava gaikwad via freebsd-net wrote: > >>> Hello Experts, > >>> I want to know if there is any effort/planning going on to implement > >>> Segment Routing (RFC 8402?https://tools.ietf.org/html/rfc8402). I see > >>> Linux supporting it. Wondering if there is something planned on FreeBSD > >>> too.My app runs on FreeBSD and I have a use case to share information > >>> from one application gateway to another about connection identity. I > >>> thought SRv6 header can help me here. > >>> Thank you.Alex. > >>> ___ > >>> 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" > >> ___ > >> 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" > >> > >> > ___ > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: SRv6 in FreeBSD
> Hi Alex, > > While I'm not a BSD developer, i really doubt it, considering that the > building blocks for SR are not there ( mpls support or just label > push/pop/swap). He specifically stated SRv6 which is not MPLS based. The building blocsk if one was to need this in a BSD are in OpenBSD which has an MPLS implementation. > > On the other hand, on SRv6 as you mentioned you rely on IPv6 headers and > there is a lot of conservatory about it ( unless you are a Cisco fan!) :-) The SRH is 5 years and 26 revisions into the process and has been "Submitted to IESG for Publication" per: https://datatracker.ietf.org/doc/draft-ietf-6man-segment-routing-header/ so it should be possible for someone to do an implementation in FreeBSD > > I'm interesting on the use case, if you don't mind... is it just service > chaining you application ? Usually servers are just part of an overlay ( > call it VXLAN,? MPLS? or something over something else...) I would be interested to here the use cases as well. > > Best regards. > > Santiago > > > On 2019-11-25 03:43, madhava gaikwad via freebsd-net wrote: > > Hello Experts, > > I want to know if there is any effort/planning going on to implement > > Segment Routing (RFC 8402?https://tools.ietf.org/html/rfc8402). I see Linux > > supporting it. Wondering if there is something planned on FreeBSD too.My > > app runs on FreeBSD and I have a use case to share information from one > > application gateway to another about connection identity. I thought SRv6 > > header can help me here. > > Thank you.Alex. > > ___ > > 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" > ___ > 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" > > -- Rod Grimes rgri...@freebsd.org ___ 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: FreeBSD as multicast router
> > > Hi All > > > > > > I have (noob) questions about multicast routing under FreeBSD. > > > > > > I have FreeBSD box with two (or more) multicast enabled interfaces (e.x. > > > vlan750 and vlan299). vlan750 connected to multicast source. > > > > > > Then pimd installed and only this two interfaces enabled in pimd config. > > > Multicast routes successfully installed by pimd and listed by `netstat > > > -g -f inet` > > > > > > Then client on vlan299 send IGMP-Join (this Join received by FreeBSD on > > > vlan299) > > > > > > The question is: who will forward muilticast from one interface > > > (vlan750) to another (vlan299)? Is it kernel specific job or I need > > > additional software? > > > Please read the manpage multicast(4) "man 4 multicast", > > you should need to build a custom kernel with the "options MROUTING" > > to enable the multicast forwarding in the kernel. > > If "netstat -g" shows routes, the kernel must have been built with "options > MROUTING". Indeed. > > The kernel does the forwarding, according to those routing tables installed > by pimd or another multicast routing program. Is it not working? It sounds > like you are very close. Could it be sysctl net.inet.ip.forwarding? Does that still apply to mroutes? > > > > Victor Gamov > > > -- > > Rod Grimes > > rgri...@freebsd.org > > Mike > ___ > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: FreeBSD as multicast router
> Hi All > > I have (noob) questions about multicast routing under FreeBSD. > > I have FreeBSD box with two (or more) multicast enabled interfaces (e.x. > vlan750 and vlan299). vlan750 connected to multicast source. > > Then pimd installed and only this two interfaces enabled in pimd config. > Multicast routes successfully installed by pimd and listed by `netstat > -g -f inet` > > Then client on vlan299 send IGMP-Join (this Join received by FreeBSD on > vlan299) > > The question is: who will forward muilticast from one interface > (vlan750) to another (vlan299)? Is it kernel specific job or I need > additional software? Please read the manpage multicast(4) "man 4 multicast", you should need to build a custom kernel with the "options MROUTING" to enable the multicast forwarding in the kernel. > Victor Gamov -- Rod Grimes rgri...@freebsd.org ___ 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: [SOLVED] Re: FRR on FreeBSD 12 - problems with OSPFv3
> > > > On 10/11/19 4:14 PM, BulkMailForRudy wrote: > > > > Thanks for the questions, good for me to think about it some more.? > > Short response: > > > > ?I don't think it is the FRR config, but the routes received that are > > crashing it or ospf6d has some other issue. > > > > > Got it running!? I tested the theory that 'bad routes' were crashing > ospf6d.? This did it.? I have some odd,legacy,test /124 blocks in the > network (will ferret them out), but filtering the routes fixes this. > > router ospf6 > ?auto-cost reference-bandwidth 1 > ?area 0.0.0.0 filter-list prefix IN-OSPF6 in > ?interface cxl1 area 0.0.0.0 > ?interface cxl2 area 0.0.0.0 > ?interface cxl3 area 0.0.0.0 > ! > ipv6 prefix-list IN-OSPF6 seq 3 permit 2607:f598::/32 le 64 > ipv6 prefix-list IN-OSPF6 seq 99 deny ::/0 le 128 > > > Rudy Great, Would you still please open an issue as pointed out in another email at the FRR site, this helps them track and close the underlying problem. No route received from any peer should *crash* a daemon. Including this additional data may help them to identify the problem. Regards, -- Rod Grimes rgri...@freebsd.org ___ 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: FRR on FreeBSD 12 - problems with OSPFv3
> > Thanks for the questions, good for me to think about it some more.? > Short response: > > ?I don't think it is the FRR config, but the routes received that are > crashing it or ospf6d has some other issue. > > > On 10/11/19 2:12 PM, Rodney W. Grimes wrote: > >> I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > >> the same time. I've tried frr6 and frr7 and get the same errors. > >> > >> bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm > >> going wrong. > >> > >> If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. > > What if you comment out just lo0? Running OSPF on a loopback > > interface makes no since, your not going to be able to establish > > a DR/BDR pair so OSPF can never really come up on that interface, > > and if it did injecting any route from 127/8 into the OSPF lsdb > > would be very bad! > > > > Though I doubt this is the source of the illegal instuction trap > > it is none the less a configuration issue. > > > Personally, I always put a 172.17.x.x IP on my lo0 and then advertise > that into my network.? I don't make it part of the router config, but I > wanted a 'test device' to boot ospf6d and see it crash.? Also, the docs > on FRR have an lo0. Putting an IP on lo0 and injecting it into OSPF via a redistribution is quiet normal, but actually RUNNING ospf on lo0 is not needed, nor even functional as you have no peer to speak to on that interface and ospf can never form an adjacency. I'll ask the FRR folks about why they are showing ospf on lo0, unless I am missing some this makes no since to me at all. > I do advertise my 172.17.x.x IP on the loobpback:? This is how I verify > OSPF is up -- the IPwill ping from other devices on the network when > OSPF is up.? For IPv6, I put a whole /64 on the lo0. So many IPs in v6.? :) Again, valid, but that does not require the ospf link layer protocol to actually be running on lo0, just a redistribute of a static into ospf as an Type 1 or 2 ASE route. > >> *** LOGS *** > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 5 usec, Reason: L+ > >> > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec > >> 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 109 usec, Reason: R+, R-, L+ > >> > >> 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec > >> 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 116 usec, Reason: R+, N+, L+ > >> > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Down]->[Init] (HelloReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [Init]->[ExStart] (2-WayReceived) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExStart]->[ExChange] (NegotiationDone) > >> 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > >> [ExChange]->[Loading] (ExchangeDone) > >> 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > >> sec 99 usec, Reason: R+, R- > >> > >> 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: > >> [Loading]->[Full] (LoadingDone) > >> 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec > >> 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to > >> announce only ospf6 routes vrf=0 > >> 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an > >> error and is shutting down. > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table > >> chunks > >> 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label > >
Re: FRR on FreeBSD 12 - problems with OSPFv3
> I just upgraded from FreeBSD 11 to 12 and upgrade from quagga to FRR at > the same time. I've tried frr6 and frr7 and get the same errors. > > bgpd and ospfd work fine, but ospf6 doesn't work.? Not sure what I'm > going wrong. > > If I commend out all the interfaces EXCEPT lo0, ospf6d does not crash. What if you comment out just lo0? Running OSPF on a loopback interface makes no since, your not going to be able to establish a DR/BDR pair so OSPF can never really come up on that interface, and if it did injecting any route from 127/8 into the OSPF lsdb would be very bad! Though I doubt this is the source of the illegal instuction trap it is none the less a configuration issue. > router ospf6 > ?ospf6 router-id 172.17.18.98 > ?redistribute connected route-map MONKEY-ospf6 > ?redistribute static route-map MONKEY-AND-MORE-ospf6 > ?!interface cxl1 area 0.0.0.0 > ?!interface cxl2 area 0.0.0.0 > ?!interface cxl3 area 0.0.0.0 > ?interface lo0 area 0.0.0.0 > > As soon as I get routes from my network, ospf6d tanks. By tanks I take it you mean gets the trap you show below? > Any thoughts? > > > Here is the output from zebra and ospf6. > > *** LOGS *** > > 2019/10/10 23:19:31 OSPF6: Scheduling cxl1 for sso > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 5 usec, Reason: L+ > > 2019/10/10 23:19:31 OSPF6: Scheduling cxl2 for sso > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 50 msec > 2019/10/10 23:19:31 OSPF6: Scheduling cxl3 for sso > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Down]->[Init] (HelloReceived) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Init]->[ExStart] (2-WayReceived) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [ExStart]->[ExChange] (NegotiationDone) > 2019/10/10 23:19:31 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [ExChange]->[Loading] (ExchangeDone) > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 109 usec, Reason: R+, R-, L+ > > 2019/10/10 23:19:31 OSPF6: SPF: Scheduled in 83 msec > 2019/10/10 23:19:31 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 116 usec, Reason: R+, N+, L+ > > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [Down]->[Init] (HelloReceived) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [Init]->[ExStart] (2-WayReceived) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [ExStart]->[ExChange] (NegotiationDone) > 2019/10/10 23:19:33 OSPF6: Neighbor state change 10.8.254.122%cxl1: > [ExChange]->[Loading] (ExchangeDone) > 2019/10/10 23:19:33 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:33 OSPF6: SPF processing: # Areas: 1, SPF runtime: 0 > sec 99 usec, Reason: R+, R- > > 2019/10/10 23:19:36 OSPF6: Neighbor state change 172.17.24.25%cxl3: > [Loading]->[Full] (LoadingDone) > 2019/10/10 23:19:36 OSPF6: SPF: Scheduled in 0 msec > 2019/10/10 23:19:31 ZEBRA: client 32 says hello and bids fair to > announce only ospf6 routes vrf=0 > 2019/10/10 23:19:38 ZEBRA: [EC 4043309117] Client 'ospf6' encountered an > error and is shutting down. > 2019/10/10 23:19:38 ZEBRA: release_daemon_table_chunks: Released 0 table > chunks > 2019/10/10 23:19:38 ZEBRA: release_daemon_label_chunks: Released 0 label > chunks > 2019/10/10 23:19:39 ZEBRA: client 32 disconnected. 100 ospf6 routes > removed from the rib > > *** CRASH *** Zebra process crashes after the ospf6 process has encountered some error and shut down or are you indicatong that the OSPF6D process has crashed? > If I run on the command line and don't background, it bombs after 7 > seconds: > # ospf6d > Illegal instruction > > > Here is the end of truss: > # truss ospf6d > ... > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863378432 (0x81e04f000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863382528 (0x81e05) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863386624 (0x81e051000) > mmap(0x0,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = > 34863390720 (0x81e052000) > SIGNAL 11 (SIGSEGV) code=SEGV_ACCERR trapno=12 addr=0x7fffdff8 > process killed, signal = 4 > > I wasn't seeing any CORE files when the process dumped, so I turned this > knob: > sysctl kern.sugid_coredump=1 > > Now there is a 1 GByte core file! > > # /usr/obj/usr/src/amd64.amd64/gnu/usr.bin/gdb/gdb/gdb > /usr/local/sbin/ospf6d ospf6d.core > > (gdb) bt > #0? 0x00080030678c in hash_get () from /usr/local/lib/libfrr.so.0 > #1? 0x00080033a9b2 in route_node_lookup () from > /usr/local/lib/libfrr.so.0 > #2? 0x00241345 in ospf6_route_lookup () > #3? 0x0022e718 in ospf6_abr_examin_summary () > #4? 0x0022f13b in ospf6_abr_examin_brouter () > #5? 0x002473ad in ospf6_top_init () > #6? 0x0022efda in
Re: dummynet: bandwidth is limited to 2 Gbit/s ?
> On 24.09.2019 12:42, Andriy Gapon wrote: > > > It seems that the userland component of ipfw/dummynet uses int for the > > bandwidth > > represented in bit/s. Also, int is used for passing that value from the > > userland to the kernel. > > > > What would be the best way to extend this? > > Just use a larger type? > > Or maybe add another field to try to preserve KBI backward compatibility? > > > > Thank you. > > AFAIK, we never had any public ABI or stable KBI interface announced to > userland or in-kernel consumers > and had no consumers of dummynet other than ipfw(8) binary. Just increase > type. Any attempt to mfc this would break KABI/userland and that is never a good thing to do. It may not be a public ABI, but it is an ABI, and stability of that and backwards compatibility are always a good thing to strive for. -- Rod Grimes rgri...@freebsd.org ___ 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: Is there an way for a program to know when the list of network interfaces has changed (without rescanning them)?
> I am asking because wireshark doesn't sense the interface list changes, > and it just always shows the list from the time it was launched . I am cc'ing Michael Tuexen , both a FreeBSD and long time wireshare developer. I see there has been at least 2 ways proposed to you for doing this, I would suggest using the route socket as the prefered method as that should be some what portable accross all the BSD type platforms, a devd solution would be FreeBSD specific. > Yuri -- Rod Grimes rgri...@freebsd.org ___ 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: Can Ethernet and wi-fi be used concurrently?
> 25.06.2019 3:16, Rodney W. Grimes wrote:
>
> >> from Nick Wolff:
> >>
> >>> Yes this is no issue just need to make sure you don't have an default
> >>> route
> >>> on your Ethernet interface(May need to set a static) and that the hotspot
> >>> network and intranet network doesn't overlap.
> >>
> >> To use the ethernet, I believe I need
> >>
> >> route add default 192.168.0.1
> >>
> >> if I don't use dhclient.
> >>
> >> How do I avoid this, and then how would I add route for the hotspot
> >> network?
> >
> > One of the night mares of trying to get 2 interfaces that
> > either one is using DHCP to play nice togeather is
> > a royal PITA as we have no way to ignore a default route
> > from a DHCP server.
> >
> > Our (the freebsd) dhclient is lacking in this area, this problem has
> > been solved in several other implementations.
>
> In fact, we have the they to ignore a default route from a DHCP server.
> Our DHCP client does NOT install any routes by itself. It merely passes
> routing info
> to shell script /sbin/dhclient-script that contains many distinct shell
> functions
> and allows user to override any function such as one rewriting
> /etc/resolv.conf
> or another adding routes including default one.
>
> One may create /etc/dhclient-enter-hooks script overriding some of noted
> functions.
> For example, to prevent DHCP client from touching /etc/resolv.conf
> in case you run your own DNS recursor at localhost:
>
> add_new_resolv_conf() {
> return 0
> }
>
> Same way one may override following function that is called with "new_routers"
> variable to NOT change default route or change it conditionally etc.
>
> This feature is documented within dhclient-script(8) manual page liked with
> dhclient(8).
> I use this in production without any problem.
Thank you Eugene, this is very informative, I'll have to take
a closer look at this as a solution, but I did not find it when
I was reading the man pages and such. What I see in other implementations
is the ability to supersede or ignore the default route directly
by configuration entires in /etc/dhclient.conf.
Again, thank you,
--
Rod Grimes rgri...@freebsd.org
___
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: Can Ethernet and wi-fi be used concurrently?
> from Nick Wolff: > > > Yes this is no issue just need to make sure you don't have an default route > > on your Ethernet interface(May need to set a static) and that the hotspot > > network and intranet network doesn't overlap. > > To use the ethernet, I believe I need > > route add default 192.168.0.1 > > if I don't use dhclient. > > How do I avoid this, and then how would I add route for the hotspot network? One of the night mares of trying to get 2 interfaces that either one is using DHCP to play nice togeather is a royal PITA as we have no way to ignore a default route from a DHCP server. Our (the freebsd) dhclient is lacking in this area, this problem has been solved in several other implementations. > Tom -- Rod Grimes rgri...@freebsd.org ___ 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: Odd TCP ECN related bahavior
> > Hi all, > > I am not on this mailing list. So, all responses should be sent > to my personal address. > > I just noticed somewhat confusing network behavior when I was > using wireshark to understand why certain connections have been > unexpectedly slow. > > My 11.3 stable (latest update 2019-06-23) seems to do this > according to wireshark... > > ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) You only show 1 packet, and without the type of that packet I can not tell if this is an error in the code or simply that you captured one of the packets that does not marked with ECN bits even in an ECN flow Note also that ECN is negotiated on a per TCP connection, not on every single packet. > > My system has this set, though... > > net.inet.tcp.ecn.enable: 1 So ecn should be negotiated in both directions. > > At the same time the peer system was reporting ECN capability... > > ..10 = Explicit Congestion Notification: ECN-Capable Transport > codepoint '10' (2) > > Apparently increasing the value in... > > net.inet.tcp.ecn.maxretries > > doesn't help. > > What should I make of this? Is the ECN implementation in 11.3 somehow > faulty or is this something more down to earth? If it is I would certainly like to now asap, > --jau -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
[ Charset windows-1252 unsupported, converting... ] > 19.06.2019 22:42, Rodney W. Grimes wrote: > > >> 18.06.2019 10:10, Ronald F. Guilmette wrote: > >>> How can I turn off IPv6 entirely without rebuilding the kernel? > >> You cannot. GENERIC kernel specifically enables IPv6 support and you need > >> to disable it at compile time. > >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in > >> the /etc/src.conf > >> or else some utilities compiled with INET6 by default will query kernel > >> for IPv6-specific data (like routing entries) and complain that your > >> kernel does not know about it. > > I have not seen these issues, can you give a specific example that fails? > > Other than kernel/userland interaction (that may be not relevant anymore for > modern FreeBSD), > that's basically about making network connections (such as telnet etc.) > to FQDNs resolved to IPv6 addresses supported by binaries (and resolver being > userland beast) > but not kernel/routing table. > > > A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a > > netstat -rn6 returns a "Protocol not supported error" as should all other > > things. > >> World built WITHOUT_INET6 has no such rough edges. > > I find that actually causes me more issues, as then my > > netstat -rn6 returns a hard error due to: > > case '6': > > #ifdef INET6 > > af = AF_INET6; > > #else > > errx(1, "IPv6 support is not compiled in"); > > #endif > > Seems very logical to me. Do we have a script in base running "netstat -rn6" > and breaking on this? Actually that would be more proper as: #ifdef INET6 case '6': af = AF_INET6; #endif With similiar adjustments to the usage message, if needed. -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> In message > > Andreas Nilsson wrote: > > >> That is *not* what the Handbook says. Please read it. > >> https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/firewalls-ipfw.html > >> > >Ok, so the handbook is wrong. It's a bug in the documentation. > > ACK Probably should just eliminate the firewall_type="/path/to/rules" thing, as that can be done with firewall_script and that does the right thing here. > >As soon as set firewall_script instead of firewall_type your problems will > >be solved. Just try it. The man page for rc.conf will tell you the same > >thing. > > ACK. Thank you for setting me straight. Your not wrong either. There are bugs here. > Regards, > rfg -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> 19.06.2019 22:42, Rodney W. Grimes wrote: > > >> 18.06.2019 10:10, Ronald F. Guilmette wrote: > >>> How can I turn off IPv6 entirely without rebuilding the kernel? > >> You cannot. GENERIC kernel specifically enables IPv6 support and you need > >> to disable it at compile time. > >> And if you do, you better rebuild the world too using WITHOUT_INET6=yes in > >> the /etc/src.conf > >> or else some utilities compiled with INET6 by default will query kernel > >> for IPv6-specific data (like routing entries) and complain that your > >> kernel does not know about it. > > I have not seen these issues, can you give a specific example that fails? > > Other than kernel/userland interaction (that may be not relevant anymore for > modern FreeBSD), > that's basically about making network connections (such as telnet etc.) > to FQDNs resolved to IPv6 addresses supported by binaries (and resolver being > userland beast) > but not kernel/routing table. > > > A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a > > netstat -rn6 returns a "Protocol not supported error" as should all other > > things. > >> World built WITHOUT_INET6 has no such rough edges. > > I find that actually causes me more issues, as then my > > netstat -rn6 returns a hard error due to: > > case '6': > > #ifdef INET6 > > af = AF_INET6; > > #else > > errx(1, "IPv6 support is not compiled in"); > > #endif > > Seems very logical to me. Do we have a script in base running "netstat -rn6" > and breaking on this? Again, why does it need to be in base? Since when was that the standard by which we measure proper function? Basically the above #else is probably not the best of ideas... silently ignoring the -6 would of been a more gracefull solution possibly. -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> 19.06.2019 23:18, Rodney W. Grimes wrote: > > >> 19.06.2019 3:57, Ronald F. Guilmette wrote: > >> > >>> And god only knows how much will break once I've done that. > >> > >> IPv6 will break only. > > > > That is incorrect, scripts that would silently do nothing can > > now infact fail, trust me, first hand experience. This can > > have consequences beyong "IPv6 will break only". > > > >>> How many other > >>> people have tested -all- of the resulting binaries, seriously, on actual > >>> production systems? (I may be the first one ever, at least for 12.0.) > >> > >> I ran plenty of hosts with IPv6 disabled this way and no problems > >> observed, but this pre-dates 12.0. > > > > I've not run a userland without V6 in a long time once I started to have > > issues with some things. > > Can you give an example of such script in base system, please? > > If you have such script or binary not in our base, it's not our fault :-) That is an extremly aragant position to take. Your basically saying that only the base system scripts have to function correctly and that any script not part of the base system has no need to be supported. Go tell this to the ports people... *sigh* -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> Rodney W. Grimes writes: > > > > And god only knows how much will break once I've done that. How many > > other > > > people have tested -all- of the resulting binaries, seriously, on actual > > > production systems? (I may be the first one ever, at least for 12.0.) > > > > I also agree here, running a WITHOUT_IPV6 userland is both very > > painful to get built AND has issues that one does not need to face, > > like I showed in another thread about netstat -6. > > Wider question: > Say I'm running a system with both IPv4 and IPv6 enabled. > Stuff Happens(tm) and I want to completely disable IPv6 for some > indefinite but temporary period - not chamge any configuration > settings or firewall rules, but just have the code finish processing > current packets (or not) and then ignore further traffic. There will > be consequences; I'm prepared to accept them. > Is there a single master switch - a sysctl, perhaps, or something > in /etc/rc.d - that lets me do that? You do raise a very valid point. ipfw add 1 deny ipv6 from any to any That is about the only "master" switch I can think of that would be very effective. > Robert Huff -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> In message > > Freddie Cash wrote: > > >For someone who doesn't want to be preached to about the benefits of IPv6, > >you certainly do a lot of preaching about not wanting IPv6. :) > > Guilty as charged. > > >You've been given the tools to do exactly what you want: > > - comment out IPv6 support in the kernel config file > > - add WITHOUT_IPV6=yes to /etc/src.conf > > - rebuild the world and kernel > > > >Voila! A version of FreeBSD made especially for you, without any traces of > >IPv6. Does exactly what you want. Why the long diatribe asking for > >something else once you've been shown how to do what you want? > > Rebuild kernel+world is not exactly a quick solution. Agreed. And I only recommend rebuilding the kernel, one of my motivations for that is besides not needing the v6 on a log of stuff is it reduces both wasted code size, and some security concerns. > And god only knows how much will break once I've done that. How many other > people have tested -all- of the resulting binaries, seriously, on actual > production systems? (I may be the first one ever, at least for 12.0.) I also agree here, running a WITHOUT_IPV6 userland is both very painful to get built AND has issues that one does not need to face, like I showed in another thread about netstat -6. > But this is all besides the point anyway. I am now resigned to my fate, > and I am already up to the fifth stage of grief with respect to this issue. > > https://en.wikipedia.org/wiki/K%C3%BCbler-Ross_model > > > Regards, > rfg -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> 19.06.2019 3:57, Ronald F. Guilmette wrote: > > > And god only knows how much will break once I've done that. > > IPv6 will break only. That is incorrect, scripts that would silently do nothing can now infact fail, trust me, first hand experience. This can have consequences beyong "IPv6 will break only". > > How many other > > people have tested -all- of the resulting binaries, seriously, on actual > > production systems? (I may be the first one ever, at least for 12.0.) > > I ran plenty of hosts with IPv6 disabled this way and no problems observed, > but this pre-dates 12.0. I've not run a userland without V6 in a long time once I started to have issues with some things. -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> In message <23816.53518.998090.665...@jerusalem.litteratus.org>, > Robert Huff wrote: > > >> Actually, no, that's not how one is supposed to enable one's own set > >> of ipfw ules. To do that, the Handbook (Sec. 30.4.1) says very clearly > >> that one should do: > >> > >> firewall_enable="YES" > >> firewall_type="path-to-my-rules-file" > >> > >> But I'm glad you brought it up. The funny thing is that even that > >> doesn't work properly nowadays *or* like it used to in the past. > > > > If this is true - haven't checked personally - then it's a bug. > >(And a non-trivial one, the fact you're the first to report it > >notwithstanding.) > > Can you please open a bug report? > > I aim to please. As requested: > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238694 Thank you. -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> 18.06.2019 10:10, Ronald F. Guilmette wrote: > > > How can I turn off IPv6 entirely without rebuilding the kernel? > > You cannot. GENERIC kernel specifically enables IPv6 support and you need to > disable it at compile time. > And if you do, you better rebuild the world too using WITHOUT_INET6=yes in > the /etc/src.conf > or else some utilities compiled with INET6 by default will query kernel > for IPv6-specific data (like routing entries) and complain that your kernel > does not know about it. I have not seen these issues, can you give a specific example that fails? A netstat -rn on a v4 only kernel simple reports the v4 table, and iirc a netstat -rn6 returns a "Protocol not supported error" as should all other things. > World built WITHOUT_INET6 has no such rough edges. I find that actually causes me more issues, as then my netstat -rn6 returns a hard error due to: case '6': #ifdef INET6 af = AF_INET6; #else errx(1, "IPv6 support is not compiled in"); #endif -- Rod Grimes rgri...@freebsd.org ___ 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: Eliminating IPv6 (?)
> I do not wish to begin any religious war here. I understand that IPv6 > can be a sensitive and sometimes even emotional issue for many people. > Speaking only for myself, and only for the present moment, I can say > that for me, IPv6 represents only an annoyance and a very sizable > distraction. At present, I don't use it and have absolutely no need > to do so. I would thus like to simplify my life by eliminating it from > my (12.0-RELEASE) system, so that I won't even have to think about it, > or wonder about it, e.g. when I am configuring my firewall, my daemons, > etc. > > I have tried searching for instructions on how to do this online, but > the suggestions and recommendations for how to do this vary widely. > There does not seem to be any "standard" set of recommendations for > how to simply turn off all IPv6 for a given system, short of rebuilding > the kernel, from scratch, with proper options to eliminate IPv6 support > in the kernel entirely. > > I finally settled on trying to add the following options to my /etc/rc.conf > file: > > ipv6_network_interfaces="none" > ip6addrctl_enable="NO" > ip6addrctl_policy="ipv4_prefer" > ipv6_activate_all_interfaces="NO" > > These seem to have worked only marginally. > > After a fresh reboot, my loopback interface (lo0) for example is still > configured to have -both- IPv4 -and- IPv6 addresses... and routes... > associated with it. > > How can I turn off IPv6 entirely without rebuilding the kernel? I too do not need IPv6 in many many many places, and this is the option I choose to disable it, a kernel recompile is the only complete and effective "knob" to get IPV6 out of your system. Once it is gone from the kernel all the other stuff recognises this and just deals with it without any other tweaking. > Regards, > rfg > > > P.S. Please, please, please, refrain from giving me a sermon about how > I am an idiot and/or about how IPv6 is going to save mankind and/or the > galaxy as we know it. I am pro choice, and I don't really wish to have > IPv6 rammed down my throat before I am ready to swallow. I don't need it, > don't use it, and for me, life is much simpler without it for now. No sermon here, I fully support your position, and am very glad to see that bz@ continues to assert that we need to maintain the INET and INET6 compile options (for some day we may be able to remove V4, but it also has the added benifit in that we can build V4 only, v6 only, or (insert your prefered higher power) forbid, no INET at all! -- Rod Grimes rgri...@freebsd.org ___ 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: localhost woes -- help requested
> > In message <201906190617.x5j6hqma016...@gndrsh.dnsmgr.net>, > > Rodney W. Grimes" wrote: > > > > >> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, > > >> "Rodney W. Grimes" wrote: > > >> > > >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > > >> > > >> > > >> 1) https://pastebin.com/raw/wXTTgd9R > > >This is /etc/hosts, not /etc/host.conf > > ># cat /etc/host.conf > > ># Auto-generated from nsswitch.conf > > >hosts > > >dns > > > > > >> 2) https://pastebin.com/raw/PiGpN0LU > > >> > > >> 3) Yes, local-unbound > > > > > >Ok, if you comment out ::1 from /etc/hosts then the lookup is > > >going to fall through to DNS with the default /etc/host.conf file > > >and you'll get what ever your dns is configured to return, which > > >is usually the exact some thing as /etc/hosts has. > > > > So basically you're telling me that local-unbound has taken it upon > > itself to decide for me, regardless of what is or isn't in my /etc/hosts > > file, what addresses "localhost" should resolve to?? > > Yes, dns resolvers shipping for the last 5 decades have all shipped Ooppps.. off by one calculation "near 4 decades" > with default "localhost" values. Both "localhost" and 127.in-addr.arpa > zones existed iirc in the very first version of bind. > > > > > If so, that really is rather presumptive on its part. > > No, well defined by RFC. > I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost > > Specifically this detail: > In the Domain Name System, the name localhost is reserved as a > top-level domain name, originally set aside to avoid confusion > with the hostname used for loopback purposes.[3] IETF standards > prohibit domain name registrars from assigning the name localhost. > > > And finally: > https://tools.ietf.org/html/rfc2606#section-2 > at > The ".localhost" TLD has traditionally been statically defined in > host DNS implementations as having an A record pointing to the > loop back IP address and is reserved for such use. Any other use > would conflict with widely deployed code which assumes this use. > > Regards, > -- > Rod Grimes rgri...@freebsd.org > ___ > 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" > -- Rod Grimes rgri...@freebsd.org ___ 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: localhost woes -- help requested
> In message <201906190617.x5j6hqma016...@gndrsh.dnsmgr.net>, > Rodney W. Grimes" wrote: > > >> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, > >> "Rodney W. Grimes" wrote: > >> > >> >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > >> > >> > >> 1) https://pastebin.com/raw/wXTTgd9R > >This is /etc/hosts, not /etc/host.conf > ># cat /etc/host.conf > ># Auto-generated from nsswitch.conf > >hosts > >dns > > > >> 2) https://pastebin.com/raw/PiGpN0LU > >> > >> 3) Yes, local-unbound > > > >Ok, if you comment out ::1 from /etc/hosts then the lookup is > >going to fall through to DNS with the default /etc/host.conf file > >and you'll get what ever your dns is configured to return, which > >is usually the exact some thing as /etc/hosts has. > > So basically you're telling me that local-unbound has taken it upon > itself to decide for me, regardless of what is or isn't in my /etc/hosts > file, what addresses "localhost" should resolve to?? Yes, dns resolvers shipping for the last 5 decades have all shipped with default "localhost" values. Both "localhost" and 127.in-addr.arpa zones existed iirc in the very first version of bind. > > If so, that really is rather presumptive on its part. No, well defined by RFC. I would suggest a starting read at https://en.wikipedia.org/wiki/Localhost Specifically this detail: In the Domain Name System, the name localhost is reserved as a top-level domain name, originally set aside to avoid confusion with the hostname used for loopback purposes.[3] IETF standards prohibit domain name registrars from assigning the name localhost. And finally: https://tools.ietf.org/html/rfc2606#section-2 at The ".localhost" TLD has traditionally been statically defined in host DNS implementations as having an A record pointing to the loop back IP address and is reserved for such use. Any other use would conflict with widely deployed code which assumes this use. Regards, -- Rod Grimes rgri...@freebsd.org ___ 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: localhost woes -- help requested
> In message <201906181719.x5ihj8g0014...@gndrsh.dnsmgr.net>, > "Rodney W. Grimes" wrote: > > >What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? > > > 1) https://pastebin.com/raw/wXTTgd9R This is /etc/hosts, not /etc/host.conf # cat /etc/host.conf # Auto-generated from nsswitch.conf hosts dns > 2) https://pastebin.com/raw/PiGpN0LU > > 3) Yes, local-unbound Ok, if you comment out ::1 from /etc/hosts then the lookup is going to fall through to DNS with the default /etc/host.conf file and you'll get what ever your dns is configured to return, which is usually the exact some thing as /etc/hosts has. -- Rod Grimes rgri...@freebsd.org ___ 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: localhost woes -- help requested
> In message > , > Adam wrote: > > >On Sat, Jun 15, 2019 at 12:54 AM Ronald F. Guilmette > >wrote: > >> ... except for the browsers, and also one other thing (nmh outbound > >> email handling). Now, both Firefox and Opera crash and burn, right > >> out of the gate, when started from the command line. In both cases > >> thet do so both with entirely cryptic failure messages. > >> > >> But here's the kicker... I futzed around with this awhile and found > >> out that if I just change the default value of the DISPLAY environment > >> variable from "localhost:0.0" to ":0.0" then both browsers *do* then > >> start up successfully from the command line. > >> > >> So, um, what the bleep did I do wrong? > >> > >> Here's the output of the command "getent hosts localhost": > >> > >> ::1 localhost > >> 127.0.0.1 localhost localhost.tristatelogic.com > >> > >> > >> Any hints for how I can debug this mess would be appreciated. > >> > > > >Do you have local_unbound running? It's probably caching the result. > > > >/etc/rc.d/local_unbound stop > > > >Then try your changes to /etc/hosts > > I have now rebooted the system multiple times, from a cold start, and > this has had *no* effect on the output generated by "getent hosts localhost". > > That is *still* showing me that there exists a mapping from "localhost" > to an IPv6 address, even though I commented that out in my /etc/hosts > file. > > I really would like to understand why manual edits to /etc/hosts seem > to have no effect whatosoever. And more importantly, I'd really still > like to know whey X applications cannot seem to connect to the X server > when and if DISPLAY is set to localhost:0.0 while they have no problem > doing so when DISPLAY is instead set to :0.0 What is in /etc/host.conf, /etc/resolv.conf, do you have DNS running? -- Rod Grimes rgri...@freebsd.org ___ 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: Bridges on VLAN-tagged interfaces.
> [I cast level 3 necromancy and revive this thread from the dead] But this is all layer 2 stuff :-) > > On Tue, Mar 19, 2019 at 4:02 AM Eric Bautsch wrote: > > > > Hi Patrick. > > > > > > I get that point, but then I have two options only: I somehow convince the > > BIOS > > to do a network boot over a VLAN for installation - not a capability this > > BIOS > > appears to have, or I end up creating a whole new VLAN that's either routed > > or > > has YP, DNS, time and installation servers on it. That's a massive > > headache > > > > It'd be much neater if FreeBSD could handle the tagged/untagged traffic. It > > just > > works (TM) on Solaris and Linux, so I expected it to do the same on > > FreeBSD... :-( > > > > Surely, there must be a way > > > > This is a product of how vlans and bridges work on FreeBSD, but I > think it doesn't have to be this way. Let's break it down: re0.33 is a > vlan(4) attached to re0. Ordinary traffic coming in on vlan 33 does > this little dance number: > > incoming -> re0:ether_input -> ether_demux -> vlan_input -> re0.33:ether_input > > Let's mix it up: add re0.33 to a bridge0. Traffic is passed to > potential bridge for processing in ether_input_internal prior to > ether_demux, so you end up with this setup: > > incoming -> re0:ether_input -> ether_demux -> vlan_input -> > re0.33:ether_input -> bridge0:bridge_input -> ether_demux > > Now let's evolve into our final form. add re0 to bridge1; this is what > I'm most certain is happening > > incoming -> re0:ether_input -> bridge1:bridge_input -> bridge_forward > > oops. bridge1 grabs the re0 packet before we have a chance to do any > vlan processing. Traffic isn't bound for *this* bridge or any of the > other interfaces, so it will perform the bridge forwarding function > and everything goes off the rails. That makes sense as to what I saw happening last time I had issues with this. > > This is not an unsolvable problem, though, from a developer > perspective. I think if_bridge(4) simply needs to be taught a little > about if_vlan(4) (needs more hooks...) so that traffic coming in on > re0 with a vlan that matches an if_vlan(4) interface doesn't get > snagged in the wrong bridge too early. Sounds reasonable, both vlan and bridge/switch are layer 2 functionality and should fully co-operate. One thing to note if you are going to dig around in this code it is known to have poor performance and is one of the bottleneck areas for getting packets in and out of a bhyve vm via the tap to bridge path. I defanitly would enjoying having the configuration and performance of the ESXi vswitch paradigm in FreeBSD if we can implement it with this code in a reasonable fasion. I can provide some sample config files if desired. > Thanks, > Kyle Evans -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-101: obsolete driver removal planned for 2019-05-18
> Eugene Grosbein wrote: > > 11.05.2019 22:59, Julian H. Stacey wrote: > > > > >> 11.05.2019 21:32, Julian H. Stacey wrote: > > >> > > I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > > as previous approved in FCP-101. > > The following drivers are slated for > > removal from FreeBSD-HEAD (to be FreeBSD-13): > > > > ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > >>> > > >>> OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > >>> spare) that will never be able to upgrade. > > >> > > >> Do those boxes have 10M-only or 100Mbps variants of ed(4)? > > >> What kind of hardware do they have (CPU and memory-wise)? > > > > > > Thanks for question. I ran a quick check: > > > cd /usr/src; > > > # Apply my patches: > > > # customise `pwd` > > > # http://www.berklix.com/~jhs/bin/.csh/customise > > > cd /sys/amd64/conf > > > grep device [A-Z][A-Z][A-Z][A-Z].small | grep ed > > > DUAL.small:device ed > > > FILM.small:device ed > > > KING.small:device ed > > > LAPA.small:device ed > > > LAPD.small:device ed > > > LAPL.small:device ed > > > LAPN.small:device ed > > > LOFT.small:device ed > > > MINI.small:device ed > > > SCAN.small:device ed0 at isa? port 0x280 irq 15 iomem 0xd iosiz > > > 0x1 > > > SLIM.small:device ed > > > SNOW.small:device ed0 at isa? port 0x280 irq 5 iomem 0xc8000 > > > WIND.small:device ed > > > > I've asked not for configuration files but for description of hardware. > > ed(4) supports many different models. Some of them do 10Mbps only > > but some are 100M-capable including PCI-connected. > > > > And it's interesting to know what is CPU and memory type/amount of boxes. > > Info I had long pre saved, exported here: > http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/ > Many boxes run newer releases than logs show, but eg dmesg shows memory etc. It would help if you could run this from the hosts directory above and post the output here, I doubt anyone besides me well bother looking any further than this email at this data, but they well if you post this output: find . -type f | grep /dmesg | xargs egrep 'CPU:|real memory|Ethernet' That should give us machine name by file path, CPU type, memory and what ethernet cards are in it. I found one box, the second one I looked at, http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/logs/blak/dmesg0 that clearly has enough CPU and memory to run 13: CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) real memory = 536858624 (511 MB) ed0: at port 0x240-0x25f iomem 0xcc000-0xc irq 5 pnpid EDI0119 on isa0 ed0: [ITHREAD] ed0: WARNING: using obsoleted if_watchdog interface ed0: Ethernet address: 00:00:b4:36:a5:04 > Re Gary's: > > 2) what versions of FBSD is Julian now running on his hardware? > > 3) does he ever plan to upgrade this hardware to >= FBSD 13? > > Not many, if any of them; I should idealy find time to purge some, > but I also have sundry newer PCs, & spare ed etc cards, so a pity to loose ed. > > > More generaly It won't be just me with ed. With 13 I can power up any time, > (+ other pcmcia & PCI & ISA cards in boxes) there's probably many more > globaly. > > But sys admins often don't have time to read developer lists like > current@ & arch@. So developer considering zapping things, will > not be seen by users it will hit later. > > First many will know is seeing in a RELNOTES "XYZ will be removed > in release [0-9].[0-9]" No chance to answer an earlier "Are many > still using XYZ, we're thinking of deleting it ?" I believe all of the proposed cards have been announcing they are gone in FreeBSD 13 starting at FreeBSD 12. I am NOT clear if these gonein notices got backported to 11, if not they should be ASAP as getting notice out to the 11.3 users is important too. > If ed is the biggest legacy NIC, best be cautious ? I agree to some extent, but have no hard use evedence. > (BTW I also have 2 boxes running today's current, not just old Rels here.) > > Cheers, > Julian > -- > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich Aachen Kent > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in EU. > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers died. > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-101: obsolete driver removal planned for 2019-05-18
> 12.05.2019 8:21, Warner Losh wrote: > > > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet > > drivers > > >> as previous approved in FCP-101. > > >> The following drivers are slated for > > >> removal from FreeBSD-HEAD (to be FreeBSD-13): > > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > > spare) that will never be able to upgrade. > > Do those boxes have 10M-only or 100Mbps variants of ed(4)? > > What kind of hardware do they have (CPU and memory-wise)? > > > > There are no 100M ed variants. There are some PC Card variants that have > > 100M MII connections, but they are limited to about 12Mbps due to bus > > limits. Even the PCI ones didn't have 100M mii connections. > > There was RTL8029AS "NE2000-compatible" 100M 32 bit PCI 2.1 adapter. > Not sure if ed(4) supports RTL8029AS. That is what I was hunting for, but I can not seem to locate a data sheet on that. I also thought there was a 100mb version of the DP83905, but can not seem to locate any data thier either. Given this lack of findable data I shall continue to support the ed removal, unless Julian comes up with the needed criteria, and with holding my own fact that I do have a pile of these around, but they are not in use and are only retained for testing and resurection of ancient things. -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-101: obsolete driver removal planned for 2019-05-18
> > I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > > as previous approved in FCP-101. > > The following drivers are slated for > > removal from FreeBSD-HEAD (to be FreeBSD-13): > > > > ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > spare) that will never be able to upgrade. I thought ed was already saved from this process, as that is the NE2000 driver, probably the most cloned network device on the planet. -- Rod Grimes rgri...@freebsd.org ___ 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: In freshly installed 12i386 VM dhclient printed "No buffer space available"
> I just took the latest 12i386 ISO image, installed into a VM with 2GB > memory, and got the "No buffer space available" from dhclient during the > initial IPv4 network setup. > > This should never happen, IMO. The i386 tuneparameters have seriuosly degraded due to lack of love by the developers. > Yuri -- Rod Grimes rgri...@freebsd.org ___ 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: Bridges on VLAN-tagged interfaces.
> Am 11.03.2019 um 11:48 schrieb Eric Bautsch: > ? > > |ifconfig bridge create ifconfig bridge1 addm re0.33| > > > > If I now put an IP on that bridge instead of re0.33, it does not ping. > > > > If I do a broadcast ping from another host on that network thus > > (Solaris system issuing the ping): > > ping -sn 192.168.33.255 > > > > I can see packets arriving if I |tcpdump -i re0.33| and if I |tcpdump > > -i bridge1| > > However, on neither interface do I see any pings coming in when I ping > > it's own address (in this case 192.168.33.20). > > IP stack processes them without passing it to the interface(s), so > that's not unusual. > > > > The Solaris system issuing the pings has learned the arp address of > > the bridge though: > > Code: > > > > |root@gaspra # arp -an | grep 192.168.33.20 net1 192.168.33.20 > > 255.255.255.255 02:a7:91:b6:3a:01| > > > > If I |tcpdump -i bridge1|, I do get some packets, but not any echo > > requests: > > Code: > > > > |root@bianca # tcpdump -i bridge1 tcpdump: verbose output suppressed, > > use -v or -vv for full protocol decode listening on bridge1, link-type > > EN10MB (Ethernet), capture size 262144 bytes 11:05:26.081185 ARP, > > Request who-has 192.168.33.20 (Broadcast) tell > > juliet-punchin.swangage.co.uk, length 46 11:05:26.081197 ARP, Reply > > 192.168.33.20 is-at 02:a7:91:b6:3a:01 (oui Unknown), length 28 > > 11:05:38.201079 IP6 fe80::7285:c2ff:fea6:583c > ff02::2: ICMP6, router > > solicitation, length 16 11:06:04.079441 ARP, Request who-has > > 192.168.33.20 (Broadcast) tell juliet-punchin.swangage.co.uk, length > > 46 11:06:04.079464 ARP, Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 > > (oui Unknown), length 28 11:06:17.588644 ARP, Request who-has > > 192.168.33.20 (Broadcast) tell gaspra-punchin.swangage.co.uk, length > > 46 11:06:17.588665 ARP, Reply 192.168.33.20 is-at 02:a7:91:b6:3a:01 > > (oui Unknown), length 28| > > If I read it corretcly, all you get are ethernet broadcast frames. > (Hard) Reading next: > ? > > |root@bianca # ifconfig -a re0: > > flags=8943 metric 0 > > mtu 1500 > > options=8209b > > > > ether 80> > ) status: active nd6 > > options=29 lo0: > > flags=8049 metric 0 mtu 16384 > > options=680003 inet6 > > ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet > > 127.0.0.1 netmask 0xff00 groups: lo nd6 > > options=21 bridge0: > > flags=8843 metric 0 mtu 1500 > > ether 02:a7:91:b6:3a:00 inet 192.168.140.85 netmask 0xff00 > > broadcast 192.168.140.255 id 00:00:00:00:00:00 priority 32768 > > hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 > > timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > > member: re0 flags=143 ifmaxaddr 0 > > port 1 priority 128 path cost 55 groups: bridge nd6 > > options=9 re0.33: > > flags=8943 metric 0 > > mtu 1500 options=80003 ether > > 80> > scopeid 0x4 groups: vlan vlan: 33 vlanpcp: 0 parent interface: re0 > > media: Ethernet autoselect (1000baseT ) status: > > active nd6 options=21 bridge1: > > flags=8843 metric 0 mtu 1500 > > ether 02:a7:91:b6:3a:01 inet 192.168.33.20 netmask 0xff00 > > broadcast 192.168.33.255 id 00:00:00:00:00:00 priority 32768 hellotime > > 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 > > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: > > re0.33 flags=143 ifmaxaddr 0 port > > 4 priority 128 path cost 2 groups: bridge nd6 > > options=9 root@bianca #| > > Here you have a universally administered addresses (UAA) on the parent > interface re0, which is the same for the vlan clone re0.33, and a > locally administered addresses (LAA) on if_bridge(4), which was verified > to be announced. > In order to get through the MAC filter of the ethernet interface, re0.33 > must be in PROMISC mode. > I remember having seen two different PROMISC interface status ? never > tracked it down.? But issuing 'ifconfig re0.33 promisc' might result in > a second PROMISC status report on re0.33 and a working setup... > If so, one has to discover the mystery of the 1st PROMISC status report, > and file a bug reports probably. Oh, I think you just tickled a brain cell on another problem I was seeing in another place with bhyve, bridges and taps. I need to recreate that configuration and see if infact it is a missing promisc on an interface. Thank YOU! > Best, > -harry -- Rod Grimes rgri...@freebsd.org ___ 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: use of #ifdef INET and #ifdef INET6 in the kernel sources
> Bjoern A. Zeeb wrote:
> [stuff snipped]
> I wrote:
> >> So, is this still recommended for blocks of code that only execute for
> >> the version
> >> of IP, but will build for kernels that do not have the particular
> >> "options INET{6}"
> >> in the kernel config?
> >
> >Yes.
> Ok, I'll do it.
Thank you
> >> If it is still recommended, I will do it, but I'll admit I don't
> >> understand why it should
> >> be done? (All it does is reduce the size of the executable by a small
> >> amount and
> >> that doesn't seem significant to me.)
> >
> >That small amount is still relevant on some devices where people go to
> >great lengths to fit our constantly growing base into a tiny small
> >thingy.
> I doubt NFS gets squeezed into such devices and, yes, it is a small amount.
> Using source line counts via "wc" (ir includes comments, etc):
> - This will reduce the # of lines by about 6 for a module of about 7700 lines
>which is loaded when either the nfscl or nfsserver modules are loaded.
>(These are both about 25000 lines and require the krpc, which is another
> 1.
> I haven't included the Kerberos stuff, because I can't remember if that
> gets loaded
> unless Kerberos mounts get used.)
> --> A savings of 6 lines in something like 43000.
That means that nfsusrd is an extremly well behaved ipv4/ipv6
agnostic deamon that only takes a small change to make it able
to run as either v4/v6 as a single stack or dual stacked, at a cost
that also sounds minial, even if it took an #ifdef for each of these
lines that is only 6 in 43000 lines of code, which is a small cost.
The same analysis on other code probably comes out no place near
this.
Also didnt this use to use a unix domain? Could the unix domain
be put back and knobbed so that I could actually run this without
it doing the localnet thing at all? I know that it had issues
as the socket is in /tmp and if /tmp isnt a right type file system,
etc... But some of us do know that and do run with a /tmp that
would support AF_UNIX type nfsusrd.
If it takes 6 lines of ifdef to do v4 vs v6, how many lines of
ifdef is it to add AF_UNIX back and make it run time choice?
(Goes looking for more Nomex clothing :-)
> >And it allows you to lose code from your kernel that you don?t
> >need/want, such as if you?d want to rip out all INET sources from a
> >tree.
> Ok, I can buy into this argument. I doubt I'll see IPv4 removed in my
> lifetime, but
> it does document where the code is.
> (In Canada, network providers only give out IPv4 addresses to end users, from
> what I've seen.)
>
> >I know both of these groups still do exist.
> >
> >Also every code not compiled in is not an attack surface, where you
> >think it?s executed or not.
>
> rick
--
Rod Grimes rgri...@freebsd.org
___
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: use of #ifdef INET and #ifdef INET6 in the kernel sources
> On 28 Feb 2019, at 1:11, Rick Macklem wrote:
>
> > I thought (can't remember when/how I was told) that it was no longer
> > recommended to add
> > #ifdef INET
> > or
> > #ifdef INET6
> > to the kernel sources.
>
> Not sure who said this.
>
> > I'll admit I think #ifdef'ng code when it isn't necessary to get it to
> > build makes the
> > code less readable and, as such, I prefer not to do this.
>
> We all agree on this.
>
>
> > So, is this still recommended for blocks of code that only execute for
> > the version
> > of IP, but will build for kernels that do not have the particular
> > "options INET{6}"
> > in the kernel config?
>
> Yes.
>
>
> > If it is still recommended, I will do it, but I'll admit I don't
> > understand why it should
> > be done? (All it does is reduce the size of the executable by a small
> > amount and
> > that doesn't seem significant to me.)
>
> That small amount is still relevant on some devices where people go to
> great lengths to fit our constantly growing base into a tiny small
> thingy.
Yep Most ISP's are still not delivering ipv6 to the home in
the USA. Using a tunnel protocol instead.
> And it allows you to lose code from your kernel that you don?t
> need/want, such as if you?d want to rip out all INET sources from a
> tree.
I buildworld, not just the kernel, without INET6 for all of
my ipv4 only node areas. I know I am a mintory there, but
there are probably others.
>
> I know both of these groups still do exist.
>
> Also every code not compiled in is not an attack surface, where you
> think it?s executed or not.
This last reason is/was a prevelent one for me for a long time,
diven ipv6 is trying to autoconfigure stuff and interfaces
just get a link local address that is reachable that I would
have to secure. Its was/is a royal pita to do that for lots of
machines.
Am I missing something in there is just some way to turn off the
link local ipv6 address?
For people in the ipv6 only world disabling the ipv4 code is
the right thing to do as well. In the future this would become
the default and the ipv4 bits shall rot, break and then be
removed.
> /bz
--
Rod Grimes rgri...@freebsd.org
___
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: 240/4
> Taking this off list
This thread would be better served on n...@freebsd.org,
what do you think cem?
After getting to the end of this I decided I am going to
add n...@freebsd.org, and woll...@freebsd.org just in case
he is not on that list.
To those first seeing any of this, it is a thread that kinda
started in a PR:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235927
you may wish to read that before repling here.
> there is a internet draft cooking in the ipv4-cleanup repository on
> github. At the moment the history section is well worth reading, but
> we may end up splitting it into separate drafts and don't currently
> plan to submit it at the march ietf, but to gauge response at
> netdevconf and then on the hallway track at the ietf.
Thats good, as far as getting the process moving forward.
> The last attempt to open up 240/4 died in bickering over how they
> would be used rather than making them work,
And I suspect what caused that has probably not changed,
hence my hesitation on immeditate action.
> so we've been patching
> everything, testing with a couple testbeds, identifying what else is
> broken, and planning a public experiment to take place over the next
> 2-3 years. We've had more than a few convos at high levels at icann,
> tacit support from folk like vint and so forth (see relevant
> discussion on the internet history mailing list), etc.
Also good.
> Also what we're up to overall is actually a great deal more ambitious
> ("a moonshot"). based on my experience on my prior rfcs (like
> rfc8290), navigating ietf processes is somewhat easier with lots of
> running code to point to.
The moonshot on 240/0 would be getting Microsoft to fix there stuff.
The OSS arena is trivial once a draft exists. I have backed off
more than anything because there is infact, though maybe old, a
draft submitted by Cisco.
> Actually I regard fixing "zeroth" networking
> and making sure https://tools.ietf.org/html/rfc3021 works in more
> places as the best short term focus of the project - 240/4 is a
> lightning rod for some people, but fixing 0/8 finally (john gilmore
> fixed that in 1985 and is kind of bugged about it now), and
> reallocating formerly reserved multicast spaces as unicast are also on
> that long term agenda.
>
> (for the record, fixing 0/8 is merely changing the is_zeronet macro -
> change that to 0 and 0/8 works. Should have been fixed when bsd 4.2
> finally retired damn it)
One of the problems with fixing any of 240/4 or 0/8 is that these
address are almost always used in foolishly crafted DDOS attacks
so are heavily filtered as both source and destination addresses.
> It's only been 10 years since 240/4 sort of started to work. I do
> think that this time around with enough support from the open source
> community we can make a dent in things in under 5; it would be great
> to have a few freebsd folk along for the ride.
I have sent a private email to Garratt Wollman asking him to take
a look at the PR. If your concerned about my relactance to just
go commit the 1 liner, do not let that worry you too much.
We do need to do due dillegence, and for me the only real
remaing question is does this in any way cause FreeBSD to
be out of conformance with either host requirements or
router requirements, or FIPS or other standards, as we do
have downstreams who have strict requirements in these areas.
> Dave T?ht
> CTO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-831-205-9740
--
Rod Grimes rgri...@freebsd.org
___
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: correct IP# for NFS kernel upcall to userland daemon
> Hi, > > I have been in a recent discussion about what the correct IP address to use > for > an upcall from the kernel to the NFS daemon nfsuserd (which maps between > uids<->usernames and gids<->group names). > > The code uses UDP for the upcall (I once committed a patch changing that to > an AF_LOCAL socket, but it broke certain sites where the directory the socket > was being created in was NFS mounted). > > Currently the code uses a hardwired "127.0.0.1". > Rodney Grimes feels that it would be better to do a name lookup on "localhost" > to get the address to use. > > In this case, I am concerned that the daemon will not be able to start up > under > conditions where the DNS service isn't yet functional. (This problem can > mostly > be avoided by specifying "localhost" in /etc/hosts and configuring the system > to > use that file before DNS, but I still don't like having this dependency on > DNS for > the daemon starting up.) > Note that the upcall will work for any IP# that refers to the local machine > and it > does not need to be the one specified for "localhost" in the DNS. > > So, do you think I should do a lookup for "localhost" at daemon startup or use > a hardwired "127.0.0.1/::1"? > > Thanks in advance for any comments, rick Note that my main issue with this is hardcoding of a value in the kernel that can not be changed, thus if I either have no lo0 or have configured lo0 to be something other than 127.0.0.1 this hard coded use by the kernel of 127.0.0.1 would fail and there would be no way around it short of a recompile. I see a few other hard coded localhost values in the kernel and minimally these should be garbage collected into #define LOCALHOST 0x7f01 and much beter would be to put these into a tunable, and finally best of all would be to find ways to not be depending on "optional lo0 && lo0 == 7f01" in the kernel or userland code. I do believe that the some of the test software used for CI is also having similiar issues, and suspect that hard coding these values in places is eventually going to lead to testability issues. -- Rod Grimes rgri...@freebsd.org ___ 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: bhyve, nat, lagg failover problems
> On 2/15/19 5:28 PM, Johannes Lundberg wrote: > > Hey! > > > > I have a setup like described here: > > https://github.com/churchers/vm-bhyve/wiki/NAT-Configuration > > Bhyve guests use static IP addresses and everything works fine (i.e. > > guest can access host and internet). > > > > However, if I use lagg with failover for em0 and wlan0, and replace em0 > > with lagg0 in pf.conf the guests can not communicate with the host, or > > internet. The failover works fine for the host. I'm sure there has to be > > a way to get this to work... > > > > Is there anyone that can help? > > Found the problem! The command > > |# vm switch address public 192.168.8.1/24| > > |fixed it. vm-bhyve's command 'vm's help did not list this option as > available and therefor the confusion. It turns out the "vm" command's > help was outdated, not the wiki. Now my bhyve guests also work properly > during failover from ethernet to wifi :D I only setup the lagg in > rc.conf and let vm-bhyve handle all settings regarding the bridge, as > described in their wiki. > | Would you be willing to either put up a wiki article on this, or work with Michael Dexter who would love to have this well documented in the wiki as it is a frequently asked for feature/setup. I have added him to the cc, dex...@freebsd.org. Thanks, -- Rod Grimes rgri...@freebsd.org ___ 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: Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers
> On Thu, Jan 31, 2019 at 11:43:44PM +, Brooks Davis wrote: > > We are currently planning to remove the following less-popular 10/100 > > Ethernet drivers in the March/April timeframe: > > > > ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > > > All of these drivers generate warnings in FreeBSD 12 and to the best of > > my knowledge, none have cleared the bar specified in the FCP[0]: > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > Hi, > > The above document states that the support lifetime for FreeBSD 12 is 2023. > > The expected EOL (but not decided) for 12 is June 30, 2020 however, according > to Can someone please go revise where ever this is posted based on the 18 month minima that was set to simply state "undetermined", people are reading too much into the date posted there. > https://www.freebsd.org/security/security.html#sup > > So, hardware in some of my machines will only be supported until sometime next > year. Brooks, Given that at the time FCP-101 was written part of it was based on the assumption of a 5 year life time for 12.0. Since that assumption is now invalid, and worse, unknown, I would ask that until a decision about the life of 12.0 is made we back off on the FCP-101 process and not do anything about removing drivers until that support model adjustment is finalized and we can evaluate the impact on FCP-101's assumption. Regards, -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> Rodney W. Grimes wrote this message on Wed, Oct 24, 2018 at 05:19 -0700: > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > For those currious about this case: > https://www.bostonglobe.com/business/2017/03/16/lack-oxford-comma-costs-maine-company-millions-overtime-dispute/BIxK837fA2C06qavQMDs5J/story.html For those more interested: https://law.justia.com/cases/federal/appellate-courts/ca1/16-1901/16-1901-2017-03-13.html And I was wrong, it is a US case, though I am sure there is other similiar case law on other books. -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> "Rodney W. Grimes" wrote: > > We could add that once the document is submitted to core > > any change to it between submitting and vote by core requires > > core to be involved, even if it is simply an ack of a change > > has been made to what was submitted. > > Yes ! And to expand on that further since core is under a 2 week timeline to complete this process any submitted change acceptable to core resets the 2 week timer, if core rejects the change the timer continues as original. -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> On Wed, Oct 24, 2018 at 05:19:33AM -0700, Rodney W. Grimes wrote: > > And I have read case law that boiled down to the presents vs absence > > of a comma > > If we are now going to evaluate all proposed changes to FreeBSD on the > same rigid principles as the US legal system, I'm done. I do not think "all" is in scope here, but I do feel should excercise care about procedure. And FYI, the case law above I am pretty sure was not US. I also believe that what is at issue here can be fixed rather easily without ever going down the minor vs major slippery slope by some rather simple changes to order of events and careful steps. Warner came very close, I think he just applied his correct "fix" to 1/2 of the problem. There is the stage where the FCP is before core being voted on, and there is the stage that the FCP has been approved. He only addressed 1 of those, and he did so by allowing core to trivially modify the document during the voting process, and I am actually fine with that idea, its good, it is what should be allowed. I trust core to know what is minor vs major. BUTT it still does not cover the issue of the author/submitter modifying the document while it is in core being reviewed and possibly modified. I have issue with that. It is very hard to vote/formally review on something that is fluid. I have not been asked to trust these people with the trust I give core, so I would like to remove that. We could add that once the document is submitted to core any change to it between submitting and vote by core requires core to be involved, even if it is simply an ack of a change has been made to what was submitted. -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
... deleted ... ... cc list trimmed, getting too many recepient gripes from mailman ... > > > > diff --git a/fcp-.md b/fcp-.md > > > > index b4fe0f3..c8cc6f7 100644 > > > > --- a/fcp-.md > > > > +++ b/fcp-.md > > > > @@ -144,7 +144,10 @@ When the discussion of a change has come to a > > suitable > > > > and acceptable close it > > > > SHOULD be updated to the `vote` state. > > > > > > > > At this time the FreeBSD Core Team will vote on the subject of the > > FCP. The > > > > -result of vote moves the FCP into the `accepted` or `rejected` state. > > > > +result of vote moves the FCP into the `accepted` or `rejected` state. > > The > > > > +core team MAY make minor edits to the FCP to correct minor mistakes. > > Core > > > > +MAY return the proposal to the submitter if there are major problems > > that > > > > +need to be addressed. > > > > > > This is a Bad Idea, because it relies on common understanding of what is > > minor. I was once involved with a standards body that had a procedure for > > so-called clerical errors intended to deal with typos, punctuation etc; > > this worked just fine until somebody claimed that the omission of the word > > ?not? in a particular place was clearly a clerical error. > > > > And I have read case law that boiled down to the presents vs absence > > of a comma in an agreement that had results far beyond "minor". > > > > Use of words minor and major should be red flags unless both > > or explicitly defined, and even then those definitions often > > have issues themselves. > > > > I'm not going to define every single word. FCP documents describe process. > They are not legal documents, nor should they be. Major and minor have > common enough meanings, and the basis of bylaws is that we trust core@. The trust isssue is not core (though in this specific case it is a core member submitting the FCP, that is not going to be the case always). The trust issue is do we allow the Author to make this minor/major change decission and how does core get informed that it has happened? -- Rod Grimes rgri...@freebsd.org ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> > On 24 Oct 2018, at 01:23, Warner Losh wrote: > > > > On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> -- Start of PGP signed section. > >>> On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > >>>>> On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > >>>>> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > >>>>> > >>>>>>> On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > >>>>>>>>> I'd also suggest that rl stands in stark contrast to the cs, > >> wb, sn, > >>>>>> smc, > >>>>>>>>> sf, tl, tx and vr drivers, which nobody has mentioned in this > >>>>>> thread, and > >>>>>>>>> which I doubt are in use in any FreeBSD system of any age > >> today. > >>>>>>>> > >>>>>>>> vr is used by my TV driver laptop: > >>>>>>>> http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > >>>>>>>> vr0: flags=8843 metric > >> 0 mtu > >>>>>> 1500 > >>>>>>>>options=82808 > >>>>>>>>ether 00:40:d0:5e:26:38 > >>>>>>>>inet 192.168.91.65 netmask 0xff00 broadcast > >> 192.168.91.255 > >>>>>>>>media: Ethernet autoselect (100baseTX > >>>>>> ) > >>>>>>>>status: active > >>>>>>>> > >>>>>>>> Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > >> soon > >>>>>>>> when I also configure it to receive from a raspberry-pi TV VPN > >> server. > >>>>>>> > >>>>>>> The above was a typo. vr is on the the STAY list. > >>>>>>> > >>>>>>> -- Brooks > >>>>>> Brooks, > >>>>>>Is there a public revised version of FCP-0101 that > >> reflects the > >>>>>> feedback which is what core is voting on? > >>>>>> > >>>>> > >>>>> Its on github, just like it's been the whole time for anybody to see, > >>>>> submit pull requests against and track: > >>>> > >>>> I have no gh account, desires no gh account, so have no way to > >>>> submit a change request other than through direct email to > >>>> brooks or another gh user. This is fundementally flawed. > >>>> > >>>>> https://github.com/freebsd/fcp/blob/master/fcp-0101.md > >>>> > >>>> Thank you for the link, I had looked at it before MeetBSD, > >>>> which did not have most of the recent changes done "a day ago". > >>>> > >>>> Isnt this document now in a frozen state while core reviews/votes? > >>> > >>> I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > >>> to notice a bug in table rendering. I submitted a pull request fix > >>> that and a missing word which was merged since neither was material. I > >>> suppose they could have waited or been skipped, but there's no value in > >>> the FCP process being bound by the sort of pointless rigidity that led > >>> to -DPOSIX_MISTAKE in every libc compile line. > >> > >> The FCP process itself is unclear on this point, > >> I think this should be clarified. > >> > >> It is much more clear on post approval: > >>Changes after acceptance > >> > >>FCPs may need revision after they have been moved into the > >>accepted state. In such cases, the author SHOULD update the > >>FCP to reflect the final conclusions. > >>If the changes are major, the FCP SHOULD be withdrawn > >>and restarted. > >> > > > > Good point Rod. While common sense suggests that trivial changes during the > > voting should be allowed for editorial purposes (eg fix grammar mistakes, > > table rendering etc), it's better to spell that out so there's no confusion. > > > > diff --git a/fcp-.md b/fcp-.md > > index b4fe0f3..c8cc6f7 100644 > > --- a/fcp-.md > > +++ b/fcp-.md > > @@ -144,7 +144,10 @@ When
