[1/1] Add support to set the default port for dropbear to listen on

A menu entry has been added to set the port. This menu entry
is processed like entries that were already present and will
rewrite one line of the options.h file that is used by
dropbear during compilation.

Signed-off-by: Jeroen De Wachter <jeroen.de_wachter@alcatel-lucent.com>
---
 package/dropbear/Config.in   |   11 +++++++++++
 package/dropbear/dropbear.mk |    6 ++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

--
1.7.1

Hi Jeroen,

On Fri, Nov 22, 2013 at 7:10 PM,  <jeroen.de.wachter@telenet.be> wrote:
> A menu entry has been added to set the port. This menu entry
> is processed like entries that were already present and will
> rewrite one line of the options.h file that is used by
> dropbear during compilation.
>
> Signed-off-by: Jeroen De Wachter <jeroen.de_wachter@alcatel-lucent.com>
> ---
>  package/dropbear/Config.in   |   11 +++++++++++
>  package/dropbear/dropbear.mk |    6 ++++++
>  2 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/package/dropbear/Config.in b/package/dropbear/Config.in
> index 68c3b71..f266567 100644
> --- a/package/dropbear/Config.in
> +++ b/package/dropbear/Config.in
> @@ -36,4 +36,15 @@ config BR2_PACKAGE_DROPBEAR_LASTLOG
>           Enable logging of dropbear access to lastlog. Notice that
>           Buildroot does not generate lastlog by default.
>
> +config BR2_PACKAGE_DROPBEAR_DEFPORT
> +       int "Default port"
> +       default "22"
> +       depends on BR2_PACKAGE_DROPBEAR

This 'depends on' is no longer needed. There is already a 'if
BR2_PACKAGE_DROPBEAR' around this block.

Best regards
Thomas

On 22/11/13 19:10, jeroen.de.wachter@telenet.be wrote:
> A menu entry has been added to set the port. This menu entry
> is processed like entries that were already present and will
> rewrite one line of the options.h file that is used by
> dropbear during compilation.
>
> Signed-off-by: Jeroen De Wachter<jeroen.de_wachter@alcatel-lucent.com>

  Hi Jeroen,

  Thank you for your patch. However, I don't think we will accept it in 
buildroot. We could make thousands of configuration options that deal 
with all possible fine-grained tweaking. And especially in this 
particular case, the option is quite invasive (requires 5 additional 
lines in the .mk file) and it is possible to achieve the same result by 
adding a command-line option to dropbear, by including a custom 
S50dropbear to your fs-overlay.

  But of course, our friendly maintainer may be of a different opinion.

  The patch itself looks good BTW, except that indentation should be with 
a tab (tab + 2 spaces for the Config.in help text).

  Regards,
  Arnout

[snip]

Jeroen, All,

On 2013-11-22 21:17 +0100, Arnout Vandecappelle spake thusly:
> On 22/11/13 19:10, jeroen.de.wachter@telenet.be wrote:
> >A menu entry has been added to set the port. This menu entry
> >is processed like entries that were already present and will
> >rewrite one line of the options.h file that is used by
> >dropbear during compilation.
> >
> >Signed-off-by: Jeroen De Wachter<jeroen.de_wachter@alcatel-lucent.com>
> 
>  Hi Jeroen,
> 
>  Thank you for your patch. However, I don't think we will accept it in
> buildroot. We could make thousands of configuration options that deal with
> all possible fine-grained tweaking. And especially in this particular case,
> the option is quite invasive (requires 5 additional lines in the .mk file)
> and it is possible to achieve the same result by adding a command-line
> option to dropbear, by including a custom S50dropbear to your fs-overlay.

Agreed. We've already declined to apply such changes in the past, on the
ground that this kind of run-time configuration should be delegated to
either one of:
  - a post-build script (BR2_ROOTFS_POST_BUILD_SCRIPT)
  - a rootfs-overlay (BR2_ROOTFS_OVERLAY)

The basic idea is that Buildroot should install default, sane config
files in /etc, and startup scripts, that provide the standard behaviour
of the package (when that makes sense), and that further project-specific
customisation is out-of-scope for Buildroot (but Buildroot offers the
rootfs-overlay and post-{build,image} scripts for that).

Also, I do not like the way this change tweaks the code between the
extract and patch steps. If that was to be accepted at all, then this
should be done with a real patch file, not a sed expression.

Regards,
Yann E. MORIN.

>>>>> "jeroen" == jeroen de wachter <jeroen.de.wachter@telenet.be> writes:

Hi Jeroen,

 > A menu entry has been added to set the port. This menu entry
 > is processed like entries that were already present and will
 > rewrite one line of the options.h file that is used by
 > dropbear during compilation.

Thanks for the patch, but I'm afraid I agree with Arnout and Yann. The
difference between this option and the others is that there's a runtime
command line option to set the port (-p), whereas that isn't the case
for the others.

Please have a look at changing this with a post build script instead. If
we want to do something to make it a bit easier, then we could change
the init script to source /etc/default/dropbear if available and let if
define E.G. ARGS that we could add to the start-stop-command invocation
-E.G. how we do in S81named for the bind package.

Has anyone happened to work with this Moschip SoC?  I found Linux BSP 
patches for the MCS8140 (OpenWRT 3.3 Kernel plus some initial attempts at 
mainlining around 3.7), however that MCS8140 SoC was a true ARMv5 compared 
to the MCS8142 seems to be based on a Faraday fa526 ARMv4.  Plus I'm not 
to sure if the bus and peripheral architecture are simliar (need to do a 
little more research yet).

Any help is appreciated (reference docs that outline the register 
definition, etc.) .  We're trying to get a 3.x kernel running on this 
target to replace a older 2.6.24 blob that we can't get source for.....

Thanks!

Matthew L Weber / Sr Software Engineer / Platform SW 
mlweber1@rockwellcollins.com

Hi Matthew,

On Mon, Dec 02, 2013 at 10:04:00PM -0600, Matthew Weber wrote:
> Has anyone happened to work with this Moschip SoC?  I found Linux BSP 
> patches for the MCS8140 (OpenWRT 3.3 Kernel plus some initial attempts at 
> mainlining around 3.7), however that MCS8140 SoC was a true ARMv5 compared 
> to the MCS8142 seems to be based on a Faraday fa526 ARMv4.  Plus I'm not 
> to sure if the bus and peripheral architecture are simliar (need to do a 
> little more research yet).
> 
> Any help is appreciated (reference docs that outline the register 
> definition, etc.) .  We're trying to get a 3.x kernel running on this 
> target to replace a older 2.6.24 blob that we can't get source for.....

You have better chances of getting useful answers at the linux-arm-kernel 
mailing list (linux-arm-kernel@lists.infradead.org).

baruch