[feature request] Bintec Be.IP Plus

[MakiKyouko]

Great project have used it so far with a Vigor 130. But has now been replaced by a Bintec Be.IP Plus. Are there any plans to support this? The manufacturer has an example incl. description here: https://knowledgebase.bintec-elmeg.com/knowledgebase/dsl-ermitteln-der-leitungsqualitaet/ I could also provide my own logs retrieved via telnet and ssh.

[janh]

This looks like it should be possible to support. I also found another example with full output here: https://faq.bintec-elmeg.com/index.php?title=Analyse_-_DSL_status

It would be good to have a capture of a successful Telnet connection including the command in order to implement the login prompts, as well as for testing. The payload data should be sufficient, so if you use Wireshark for a capture, you can follow the TCP stream and choose "Show data as: Hexdump" to get the necessary information.

[MakiKyouko]

That sounds great. Is this capture sufficient? hexdump_be_ip_plus.txt

[janh]

I added support in the bintec-elmeg branch. If you can confirm that it actually works with the real device (using both Telnet and SSH), I'll merge the code into the master branch.

To test the code, you would need to build it yourself, as described in the documentation. If you need any help with that, please ask!

[MakiKyouko]

Great. The access via Telnet works without any problems. Over SSH there is a small problem with cipher selection. From the shell I have to call ssh with the parameter "-c aes128-cbc", then it works. How can I configure something similar for go-dsl?

Polling with telnet:

Connecting… done
Loading data… done

           State:    Showtime
            Mode:    ADSL2+ Annex J
          Uptime:    21 days, 21 hours, 10 minutes

          Remote:    Infineon 8.2.11.9 (130.185)
           Modem:    Infineon 574C02 VRX288

     Actual rate:       10020 kbit/s       2394 kbit/s
 Attainable rate:       11204 kbit/s       2380 kbit/s
         MINEFTR:           - kbit/s          - kbit/s

         Bitswap:    on (8395)           on (77)
 Rate adaptation:           -                 -

    Interleaving:          12 ms              6 ms
             INP:         4.0 symbols       1.1 symbols
  Retransmission:           -                 -

       Vectoring:           -                 -

     Attenuation:        38.3 dB           20.5 dB
      SNR margin:         6.0 dB            6.6 dB
  Transmit power:        19.3 dBm          13.1 dBm

    RTX TX Count:           -                 -
     RTX C Count:           -                 -
    RTX UC Count:           -                 -

       FEC Count:    23960341              2023
       CRC Count:       38457                 1

        ES Count:           -                 -
       SES Count:           -                 -

Polling with ssh:

Connecting… failed: ssh: handshake failed: ssh: no common algorithm for client to server cipher; client offered: [aes128-gcm@openssh.com chacha20-poly1305@openssh.com aes128-ctr aes192-ctr aes256-ctr], server offered: [aes128-cbc 3des-cbc blowfish-cbc cast128-cbc arcfour aes192-cbc aes256-cbc]

[janh]

Thank you!

About the SSH issue: Adding support for legacy ciphers would be possible (I even created a draft for that some time ago). However, I would really like to avoid that, if it is possible to make the device use a more modern cipher.

While the documentation of the device does not mention any modern ciphers, the actual firmware contains references to the ciphers aes128-ctr, aes192-ctr, aes256-ctr, and chacha20-poly1305@openssh.com, which are supported even by the ancient OpenSSH 7.1p2 from 2016.

Could you check if the device offers a way to enable one of these ciphers? If they are not available to choose from the UI, it might be possible to edit the option sshdCfgCiphers directly, similarly as described here for sshdCfgMaxClients: https://knowledgebase.bintec-elmeg.com/knowledgebase/anzahl-der-aktiven-ssh-sessions-erhoehen/

[MakiKyouko]

Editing via UI is not possible for the ciphers. I can change other values but not the ciphers. But I could adjust the ciphers via the console. Currently I have entered these: sshdCfgCiphers="3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,aes128-ctr".

A connection via ssh works now without problems. But the program does not work properly yet. I will try to find out later what is going wrong.

A manual call from the console: ssh admin@ip and then "dsl -v status" works without problems.

The program reports:

Connecting… done
Loading data… failed: Process exited with status 129 from signal HUP

[janh]

Does ssh admin@ip dsl -v status work? If that also fails, it would explain the issue: The SSH protocol has different commands for opening an interactive shell and for executing a command directly. The client currently only implements running a command, but it is possible that the device doesn't support that properly.

[MakiKyouko]

I think I have the thinking error.... SSH does not work with password but only with public key authentication right? Currently I can't find a solution to store my key in authorized_keys or something similar on the router.

[janh]

SSH also supports other authentication methods including password authentication.

But if the confusion is about my last comment, that doesn't matter. That is only about what happens after the authentication was successful.

RFC 4254 section 6.5 has details about what I meant. If you use a regular SSH client, it will usually send a "shell" request after authentication, and you'll get an interactive shell. If you pass it an command as an argument (as in the example from my previous comment), then it will send an "exec" request instead and run just the specified command. This is also what the client of my library does currently.

So, trying to use a SSH client like that would be a way to verify that the issue is that "exec" requests over SSH are broken for this device. In that case, it might be possible to work around this by using a "shell" request instead. (The question would then be if it is worth it to implement that.)

[MakiKyouko]

Ok it looks broken to me. In my humble opinion it is not worth the effort as other devices only support telnet.

ssh admin@192.168.0.251 dsl -v status
admin@192.168.0.251's password:

Welcome to be.IP plus version V.10.2.12.102 IPv6, IPSec, PBX from 2023/02/17 00:00:00
systemname is be.ip_plus, location

be.ip_plus:> 

[janh]

Yes, this seems to match with the error you saw before (since the device for some reason runs the shell despite the "exec" request, I think the process exits because stdin is not connected).

For now, I merged Telnet support to the master branch, but I'll still try if the workaround would be easy to implement.

(So far the only other client that supports only Telnet is the one for DrayTek devices, because SSH is really terribly broken on these: For older devices, no connection is possible at all, as the Go SSH package doesn't support the DES host key length, and others are known to crash when a command that is run via SSH has a long output.)

[janh]

After thinking about it again, I decided to keep support for these devices Telnet-only for now (but I extended the documentation to mention that SSH is not supported).