To eneable IPfire to deploy routes to (Windows as well as Linux) clients with DHCP i have to add 2 options "rfc3442-classless-static-routes" and "ms-classless-static-routes". To make you able to add the options in the WebUI, it is needed to add the both options to advoptions-list. These options replace "static-routes" which is not intended for classless IP routing - it does not include a subnet mask. Since classless IP routing is now the most widely deployed routing standard, this option is virtually useless, and is not implemented by any of the popular DHCP clients, for example the Microsoft DHCP client. The option "rfc3442-classless-static-routes" is for normal clients, "ms-classless-static-routes" for Microsoft clients. I tested it before opening this issue, it works like a charm.
(In reply to Frickeldave from comment #0) > To eneable IPfire to deploy routes to (Windows as well as Linux) clients > with DHCP i have to add 2 options "rfc3442-classless-static-routes" and > "ms-classless-static-routes". To make you able to add the options in the > WebUI, it is needed to add the both options to advoptions-list. These > options replace "static-routes" which is not intended for classless IP > routing - it does not include a subnet mask. Since classless IP routing is > now the most widely deployed routing standard, this option is virtually > useless, and is not implemented by any of the popular DHCP clients, for > example the Microsoft DHCP client. > The option "rfc3442-classless-static-routes" is for normal clients, > "ms-classless-static-routes" for Microsoft clients. > I tested it before opening this issue, it works like a charm. This last bit seems to be saying that by adding these two options to the Advanced Options list you are able to achieve what you want. Therefore I don't really understand what you are saying is the bug? Could you please provide more information on the issue you are experiencing?
Note that there's already a pull request that solves this issue: https://github.com/ipfire/ipfire-2.x/pull/67
So the pull request was put into github but IPFire does not do pull requests from github. See the wiki:- https://wiki.ipfire.org/devel/sources#github-mirror The request was made in github to submit the patch in the IPFire Development mailing list which would automatically put it into the IPFire Patchwork system. The pull request in github was closed at that point. So if someone wants to submit this patch via the Development Mailing List https://wiki.ipfire.org/devel/submit-patches they would be welcomed in doing it.
I'm sorry, but I don't get the point here. There obviously *IS* a patch present for this issue and I yet gave you the hint where it can be found. Why do you still persist in that someone still shall re-submit if via the mailing-list? Arne complained (which is fully justifiable) that the IPFire-team is underpowered at the moment, so why not using all sources of support from the community? What's so bad about using Github's pull request system? You still could discuss the patches in your mailinglist if you like to. But ignoring any patches submitted there is couterproductive IMHO.
I can not help you. I have no access to github for taking pull requests and no access to the IPFire git system to push changes into it. All my package update patches and bug fixes are submitted via git format-patch and then git send-email to the dev ML and that makes them automatically appear in patchwork where they are reviewed and tracked through the whole process of getting into a Core Update by the developers. What I have explained is the system as I know it as and as I use.
(In reply to Christian Keck from comment #4) > I'm sorry, but I don't get the point here. > > There obviously *IS* a patch present for this issue and I yet gave you the > hint where it can be found. Why do you still persist in that someone still > shall re-submit if via the mailing-list? Yes. There is a process for these things. Every change that is going into IPFire is peer-reviewed and it should be exactly like that. > Arne complained (which is fully justifiable) that the IPFire-team is > underpowered at the moment, so why not using all sources of support from the > community? We do that, but we expect those patches to be sent to us through the correct channels. We cannot look around and see where people might have dropped something and if that is just an RFC or a patch being submitted for inclusion. > What's so bad about using Github's pull request system? You still could > discuss the patches in your mailinglist if you like to. But ignoring any > patches submitted there is couterproductive IMHO. GitHub is horrible. There is no chance to peer-review stuff. It would be great it GH would allow disabling pull requests, but unfortunately they don't do that. We cannot work with a "drop and forget" mentality that some people have on there. Sending an email with a patch is absolutely not too much to ask. Git has tools that do it for you.
Ah, okay, that explains why. Thanks for the clarification.
As here has been no further response regarding the submission of a patch via the approved route, I have picked this bug up to provide it.
Created attachment 970 [details] attachment-621010-0.html Sehr geehrte Damen und Herren, in der Zeit vom 24.12.2021 bis einschließlich 09.01.2022 bin ich nicht im Hause erreichbar. Bei Anliegen bezüglich der macio IT-Administration wenden Sie sich bitte an it-support@macio.de. Bitte beachten Sie, dass die Nachrichten nicht automatisch weitergeleitet werden. Vielen Dank. Mit freundlichen Grüßen Christian Keck Fon: +49 431 67072-0 Fax: +49 431 67072-29 Mail: it-support@macio.de<mailto:it-support@macio.de> macio GmbH | Kiel Am Kiel-Kanal 1 D-24106 Kiel www.macio.de<http://www.macio.de> macio | software engineering & user interface design Geschäftsführer: Joern Kowalewski, Alexander Friedel, Sven Schreier Amtsgericht Kiel, HRB 5832
Patch submitted to the development mailing list and to patchwork https://patchwork.ipfire.org/project/ipfire/patch/20211226215512.3525919-1-adolf.belka@ipfire.org/
patch merged into Core Update 163 https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=4df6daf381223ecc040df3c1baed246782fd9cd2
Core Update 163 released. Additional options confirmed to be listed in options. https://blog.ipfire.org/post/ipfire-2-27-core-update-163-released