Re: removing RIP/RIPng (routed/route6d)
FreeBSD (and BSD Unix in general) has a rich history of being a “complete” OS – kernel and userland. If there was really a demand for a minimalist version of FreeBSD, why have people not forked FreeBSD and created it by now? There is also nanobsd, as an option, for those that want minimalist installs (yes, I know it is meant for embedded systems, but it works). I think we need to stop trying to find solutions for non-existent problems. From: owner-freebsd-...@freebsd.org on behalf of Marek Zarychta Date: Wednesday, May 15, 2024 at 11:19 AM To: freebsd-net@freebsd.org Subject: Re: removing RIP/RIPng (routed/route6d) Today Michael Sierchio wrote: There is an argument to be made that all such components of the "base" system should be packages, and managed that way. That would facilitate removal or addition of things like MTAs, Route daemons for various protocols, etc. and permit them to be updated independent of the base system. Too much is included by default in Base. FreeBSD is a comprehensive OS, and most users still do appreciate this feature. I remember that we had also RCS tools in the base system, they got purged (moved to the ports tree really), most users are fine with it, but for managing single config files RCS is still the best-suited versioning system. We still have ftpd(8), but it was almost removed, there was a strong battle on the mailing list to preserve it. FTP protocol is as old as BSD, but it's still valid and, so far not deprecated. A similar story was with smbfs(5). The same probably applies to RIP/RIPng. What if we would better remove LLVM from the base if the system is bloated ? LLVM needs frequent updates and keeping it in base is far more risky in terms of system security than keeping RIP daemons. Why do we still have odd tools like biff(1) in the base ? On the other hand, for a significant share of the user base, the more tiny the OS is, the better. The transition to PkgBase should fulfill user needs, especially those, who want a minimalist OS. So please, go ahead and switch to PgkBase if your FreeBSD system contains undesired software. Cheers Marek On Wed, May 15, 2024 at 1:01 PM John Howie mailto:j...@thehowies.com>> wrote: I use RIP all the time. Removing it would be a pain. What is the justification? Moving it to ports is an option, but now we have to compile, distribute, and install it. Sent from my iPhone > On May 15, 2024, at 07:40, Tomek CEDRO > mailto:to...@cedro.info>> wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott > mailto:uatka3z4z...@thismonkey.com>> wrote: >>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote: >>> (..) >>> i'd like to submit a patch to remove both of these daemons from src. if >>> there's some concern that people still want to use the BSD >>> implementation of routed/route6d, i'm also willing to submit a port such >>> as net/freebsd-routed containing the old code, in a similar way to how >>> the removal of things like window(1) and telnetd(8) were handled. >> >> I use RIPv2 for it's simplicity and small memory and CPU requirements. It >> has its place and shouldn't be considered "legacy" despite its shortcomings. >> It's not uncommon for vendors like Cisco to produce "basic" feature sets of >> IOS that do not include any link-state protocols. >> >> Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to its >> removal from FreeBSD if there were a small footprint alternative. I've used >> FRR and VyOS a bit and they are overkill as replacements. >> >> Your email doesn't justify its removal other than to say you are unconvinced >> of the value of shipping it. As a user I definitely see the value. I >> understand that there is always a cost to providing code, but that wasn't >> suggested as a reason. All APIs, modules, utilities, etc. need to regularly >> justify their presence in the OS. >> >> If it must be removed, is there any way to fork the FreeBSD routed and >> route6d to a port? Or would that defeat the purpose of removing it in the >> first place? > > Yeah, where did that recent trend came to FreeBSD to remove perfectly > working code?? > > There are more and more ideas in recent times like this. > > Architectures removal, drivers removal, backward compatibility > removal. While basic functions become unstable and unreliable. Looks > more like diversion and sabotage than progress. > > If anything is about to be moved out from SRC for a really good reason > it should be available in ports and not in /dev/null. >
Re: removing RIP/RIPng (routed/route6d)
I use RIP all the time. Removing it would be a pain. What is the justification? Moving it to ports is an option, but now we have to compile, distribute, and install it. Sent from my iPhone > On May 15, 2024, at 07:40, Tomek CEDRO wrote: > > On Wed, May 15, 2024 at 4:20 PM Scott wrote: >>> On Mon, Apr 15, 2024 at 09:49:27PM +0100, Lexi Winter wrote: >>> (..) >>> i'd like to submit a patch to remove both of these daemons from src. if >>> there's some concern that people still want to use the BSD >>> implementation of routed/route6d, i'm also willing to submit a port such >>> as net/freebsd-routed containing the old code, in a similar way to how >>> the removal of things like window(1) and telnetd(8) were handled. >> >> I use RIPv2 for it's simplicity and small memory and CPU requirements. It >> has its place and shouldn't be considered "legacy" despite its shortcomings. >> It's not uncommon for vendors like Cisco to produce "basic" feature sets of >> IOS that do not include any link-state protocols. >> >> Anyway, I'm a user, albeit a small user, of RIP and wouldn't object to its >> removal from FreeBSD if there were a small footprint alternative. I've used >> FRR and VyOS a bit and they are overkill as replacements. >> >> Your email doesn't justify its removal other than to say you are unconvinced >> of the value of shipping it. As a user I definitely see the value. I >> understand that there is always a cost to providing code, but that wasn't >> suggested as a reason. All APIs, modules, utilities, etc. need to regularly >> justify their presence in the OS. >> >> If it must be removed, is there any way to fork the FreeBSD routed and >> route6d to a port? Or would that defeat the purpose of removing it in the >> first place? > > Yeah, where did that recent trend came to FreeBSD to remove perfectly > working code?? > > There are more and more ideas in recent times like this. > > Architectures removal, drivers removal, backward compatibility > removal. While basic functions become unstable and unreliable. Looks > more like diversion and sabotage than progress. > > If anything is about to be moved out from SRC for a really good reason > it should be available in ports and not in /dev/null. >
Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address
Hi Yuri,
Is your machine a router or gateway, or have a firewall? Are you trying to
capture all broadcast packets, or just UDP targeted and broadcast packets
to a particular port?
Regards,
John
On 4/8/15, 5:21 PM, Yuri y...@rawbw.com wrote:
On 04/08/2015 05:32, Daniel Corbe wrote:
If nobody answers this question by the time I get home I'll try and
help; however, in the mean time I do have a couple of suggestions.
Have you tried writing the equivalent program in C using the sockets
API? IE is this a python specific problem or a sockets problem in
general?
The second thing is you may just want to try using raw sockets instead.
I verified before with ktrace, and now, following your suggestion,
rewrote it in C, and result is the same.
When I change SOCK_DGRAM-SOCK_RAW it keeps getting some other packets,
sin_port doesn't seem to matter. Also, UDP is the practically important
case.
Unless there is some reasonable explanation why ip source address can
influence reception, I believe this is a bug in kernel. And pretty
important one, because it can hurt DHCP servers.
Yuri
--- C program exhibiting the problem ---
#include sys/types.h
#include sys/socket.h
#include stdio.h
#include stdlib.h
#include netinet/in.h
#define CK(func, call...) if ((call) 0) {perror(#func); exit(1);}
int main() {
int sock, one = 1;
ssize_t count;
struct sockaddr_in sa;
char buffer[4096];
struct sockaddr_storage src_addr;
struct iovec iov[1];
iov[0].iov_base=buffer;
iov[0].iov_len=sizeof(buffer);
struct msghdr msg;
msg.msg_name=src_addr;
msg.msg_namelen=sizeof(src_addr);
msg.msg_iov=iov;
msg.msg_iovlen=1;
msg.msg_control=0;
msg.msg_controllen=0;
CK(socket, sock = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP))
CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, one,
sizeof(one)))
CK(setsockopt, setsockopt(sock, SOL_SOCKET, SO_BROADCAST, one,
sizeof(one)))
sa.sin_family = AF_INET;
sa.sin_addr.s_addr = htonl(INADDR_ANY);
//sa.sin_port = htons(67);
sa.sin_port = htons(1767);
CK(bind, bind(sock, (const struct sockaddr*)sa, sizeof(sa)))
printf(Waiting for broadcast\n);
CK(recvmsg, count = recvmsg(sock, msg, 0))
printf(Received broadcast packet: %zd bytes\n, count);
return 0;
}
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address
Hi Yuri, Have you tried using a static IP address for the host and VM, and disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src port, dst ip, dst prt) must be unique. I am wondering if that is where your problem lies. There might be something that is shortcutting the uniqueness of the tuple and just focusing on IP addresses. I would validate that for you but I am at 35000¹ right now... Regards, John On 4/8/15, 6:42 PM, Yuri y...@rawbw.com wrote: On 04/08/2015 15:31, John Howie wrote: Is your machine a router or gateway, or have a firewall? Are you trying to capture all broadcast packets, or just UDP targeted and broadcast packets to a particular port? No, it isn't a gateway or router, and no firewall. Trying to capture all broadcast UDP to a particular port. Observing this with with virtual machine dhcp client bridged to the host through tapN. Host is otherwise just a plain FreeBSD workstation itself. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Socket bound to 0.0.0.0 never receives broadcasts with non-zero IP source address
Hi Yuri, No need to apologize! Sometimes it takes a dispassionate person to review the problem to help you find the solution. You found it, not me. I just helped you get there… Still at 35000’ (literally), trying to get to where I am going! Regards, John On 4/8/15, 9:43 PM, Yuri y...@rawbw.com wrote: On 04/08/2015 16:07, John Howie wrote: Have you tried using a static IP address for the host and VM, and disabling DHCP? The DHCP client will bind to and use 0.0.0.0 to get an IP address. The SO_REUSEADDR rule is that every tuple (proto, src ip, src port, dst ip, dst prt) must be unique. I am wondering if that is where your problem lies. There might be something that is shortcutting the uniqueness of the tuple and just focusing on IP addresses. I would validate that for you but I am at 35000¹ right now... Hi John, I apologize, I actually did have ipfw rules set, and ipfw is the culprit. Yuri ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Patches for BOOTP/DHCP code to support Windows Server DHCP
Hi Steinar, In short, no, I have no packet traces. Given that the DHCP code in the FreeBSD boot loader and NFS subsystem does not request those options, but that ISC-DHCP does provide them, I will go out on a limb and say that it must be serving them without being asked if they are configured. Regards, John On 6/1/14, 1:24 PM, sth...@nethelp.no sth...@nethelp.no wrote: Section 3.5 of RFC 2131 (the DHCP RFC) states that ...Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested in and ...The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag number. A DHCP Server is not required to return any parameter that a client does not ask for. It appears that the ISC-DHCP server, which is recommended by most, will return configured options regardless of whether or not the client asks for them. As far as I know this is wrong. ISC DHCP does *not* behave this way. Do you have packet sniffer traces to indicate oterwise? In any case - yes, the client should absolutely request all the parameters it wants. Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Patches for BOOTP/DHCP code to support Windows Server DHCP
Hi Steinar, I could ask you to 'prove it', too, but I can easily check when I get back from my current travels :-) It important to note that even if it does (as I think it does) it is NOT in violation of the RFC. The RFC simply says that if a client wants something it should ask for it, and not that a server cannot send the options unsolicited. Best regards, John Sent from my iPhone On Jun 1, 2014, at 19:30, sth...@nethelp.no sth...@nethelp.no wrote: In short, no, I have no packet traces. Given that the DHCP code in the FreeBSD boot loader and NFS subsystem does not request those options, but that ISC-DHCP does provide them, I will go out on a limb and say that it must be serving them without being asked if they are configured. In that case I'm afraid I must stand by my claim that you're wrong and ISC DHCP does *not* provide configured options unless the client asks for them. (And I have copious amounts of packet sniffer traces to prove this.) Not that this is particularly relevant to FreeBSD any more... Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
Re: Patches for BOOTP/DHCP code to support Windows Server DHCP
Hi Rick, That is an excellent point and a good debate to have. I have not looked in detail at how PXEBOOT does it, but I think a clean up of the code to somehow pass arguments to the kernel is preferable to having a diskless client send a slew of needless requests to the DHCP server to request information already requested and obtained in previous stages of the boot process. The number of DHCP requests made by a client when using U-Boot and ubldr is dizzying. The NFS code will look to see if the boot loader configuration file has specified the root filesystem through use of vfs.root.mountfrom, so something should be possible. Another area for possible attention is handling the scenario when there are a number of DHCP servers able to reply to requests. This can happen when you have multiple NICs on segments with DHCP Servers or where you have multiple servers on the same segment. The current code just grabs the first server to reply at each stage (going through each NIC in turn) and has affinity to it for the remainder of that stage but not through the entire boot process. Regards, John Sent from my iPhone On Jun 1, 2014, at 19:01, Rick Macklem rmack...@uoguelph.ca wrote: John Howie wrote: Hi all, I apologize for the cross posting of this email, but I believe it will be of interest to people across all three groups. Please feel free to forward to additional groups if you feel they would benefit. I have seen a few posts on and off over the years about Windows Server DHCP not working with FreeBSD. Specifically, the Windows Server DHCP would not return the boot host name/IP address and the root path. The typical response to ³why won¹t it work has typically been that there is a flaw in Windows Server DHCP code. I did a little digging and found that the problem actually lies in code in FreeBSD. Section 3.5 of RFC 2131 (the DHCP RFC) states that ³...Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested inŠ² and ³...The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag numberŠ². A DHCP Server is not required to return any parameter that a client does not ask for. It appears that the ISC-DHCP server, which is recommended by most, will return configured options regardless of whether or not the client asks for them. There are two places in the FreeBSD codebase that DHCP is used to boot the system over a network. The first is in the boot loader, which uses code in lib/libstand. The second is in the NFS code, in sys/nfs. The code is sys/nfs is not always used if the boot loader sets up the environment for the NFS code, either by passing parameters to the kernel (as PXEBOOT appears to do), or information is configured in the boot loader configuration files, e.g. /boot/loader.rc. I have attached two unified diff files which I ask people to test, before I submit them for inclusion into the codebase as fixes. The first, bootp.c.diff fixes the code in lib/libstand/bootp.c to request the boot host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, aka TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box and ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, fixes code in sys/nfs/bootp_subr.c to request the same options and also to fix bugs that erroneously reported the IP address of the BOOTP/DHCP server. The code assumed that the BOOTP/DHCP server was also the boot host. Please send me all feedback directly. The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but will likely work with 9.0 and also CURRENT and STABLE, including 11.0, as the code is old code that does not appear to have changed in a while. If you want to try it on those systems please, please make sure you have backup copies just in case. If you do not have experience configuring Windows Server DHCP just drop me an email, and I will send you a cheat sheet to get you up and running. I am going to grab the latest ubldr code to see if I can get it to work more like PXEBOOT, that appears to pass parameters to the kernel to avoid the need for the NFS BOOTP/DHCP process. If you test on an ARM system with ubldr in RELEASE you will see a lot of unnecessary network activity going on, that we should be able to fix. Actually, I tend to think that using the code in sys/nfs/bootp_subr.c is preferable to using the NFS stuff in stand that pxeboot does. The only reason I know for pxeboot doing the NFS stuff and filling in the nfsv3_diskless structure is historical. (Or that's what most people use for x86, so it would be a POLA violation if it breaks, if you prefer.) (Basically, the code in sys/nfs/bootp_subr.c is easier to maintain
Patches for BOOTP/DHCP code to support Windows Server DHCP
Hi all, I apologize for the cross posting of this email, but I believe it will be of interest to people across all three groups. Please feel free to forward to additional groups if you feel they would benefit. I have seen a few posts on and off over the years about Windows Server DHCP not working with FreeBSD. Specifically, the Windows Server DHCP would not return the boot host name/IP address and the root path. The typical response to ³why won¹t it work has typically been that there is a flaw in Windows Server DHCP code. I did a little digging and found that the problem actually lies in code in FreeBSD. Section 3.5 of RFC 2131 (the DHCP RFC) states that ³...Second, in its initial DHCPDISCOVER or DHCPREQUEST message, a client may provide the server with a list of specific parameters the client is interested inŠ² and ³...The client can inform the server which configuration parameters the client is interested in by including the 'parameter request list' option. The data portion of this option explicitly lists the options requested by tag numberŠ². A DHCP Server is not required to return any parameter that a client does not ask for. It appears that the ISC-DHCP server, which is recommended by most, will return configured options regardless of whether or not the client asks for them. There are two places in the FreeBSD codebase that DHCP is used to boot the system over a network. The first is in the boot loader, which uses code in lib/libstand. The second is in the NFS code, in sys/nfs. The code is sys/nfs is not always used if the boot loader sets up the environment for the NFS code, either by passing parameters to the kernel (as PXEBOOT appears to do), or information is configured in the boot loader configuration files, e.g. /boot/loader.rc. I have attached two unified diff files which I ask people to test, before I submit them for inclusion into the codebase as fixes. The first, bootp.c.diff fixes the code in lib/libstand/bootp.c to request the boot host (option 12, aka TAG_HOSTNAME) and the NFS root path (option 17, aka TAG_ROOTPATH). This fix has been tested with PXEBOOT on an amd64 box and ubldr on an ARM/RaspberryPI system. The second, bootp_subr.c.diff, fixes code in sys/nfs/bootp_subr.c to request the same options and also to fix bugs that erroneously reported the IP address of the BOOTP/DHCP server. The code assumed that the BOOTP/DHCP server was also the boot host. Please send me all feedback directly. The diff files work with 10.0-RELEASE through 10.0-RELEASE-p3, but will likely work with 9.0 and also CURRENT and STABLE, including 11.0, as the code is old code that does not appear to have changed in a while. If you want to try it on those systems please, please make sure you have backup copies just in case. If you do not have experience configuring Windows Server DHCP just drop me an email, and I will send you a cheat sheet to get you up and running. I am going to grab the latest ubldr code to see if I can get it to work more like PXEBOOT, that appears to pass parameters to the kernel to avoid the need for the NFS BOOTP/DHCP process. If you test on an ARM system with ubldr in RELEASE you will see a lot of unnecessary network activity going on, that we should be able to fix. Regards, John j...@thehowies.com (personal) | jho...@email.arizona.edu (academic) | j.ho...@napier.ac.uk (academic) | jho...@cloudsecurityalliance.org (work) bootp_subr.c.diff Description: bootp_subr.c.diff bootp.c.diff Description: bootp.c.diff ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org
