 | 1 | initial version |
However, it's not clear to me how the underlying mechanism in the GUI route operates as the resulting interface string on remote host looks like "rpcap://host:port/interface-name" regardless of null authentication or authentication in place.
The URL is parsed by libpcap, not by Wireshark/TShark/tcpdump/whatever. It does not have to contain a user name or password - and it's unwise to put the password in the URL on the command-line, especially if somebody else can see the command line you typed.
The rpcap protocol doesn't send the URL over the wire. The initial request from the client to the server is an authentication request that includes credentials, which begin with a credential type (null or username/password) with, for username/password, the username and password, as strings, following the credential type.
Wireshark's "Manage Interfaces" dialog allows you to specify the authentication type and, for username/password authentication, allows you to specify the username and password. TShark has no corresponding mechanism.
Is this limitation because of a limitation or lack of documentation regarding the rpcap protocol for how you handle passing authentication over
No, it's due to a lack of code in TShark to, for example, respond to an "authentication failed" reply from the server, if the reason is "null authentication not permitted", to prompt for a username and password. There's no such code in tcpdump, either.
(There's no documentation for the rpcap protocol at all. I have that as a project, but I have a lot of other things as projects as well, and, sadly, new project keep popping up. It needs to be written, because, at least at not point, there was a non-libpcap rpcap server that wasn't sending correct replies, which broke access from the libpcap client.)
| | 2 | No.2 Revision |
However, it's not clear to me how the underlying mechanism in the GUI route operates as the resulting interface string on remote host looks like "rpcap://host:port/interface-name" regardless of null authentication or authentication in place.
The URL is parsed by libpcap, not by Wireshark/TShark/tcpdump/whatever. It does not have to contain a user name or password - and it's unwise to put the password in the URL on the command-line, especially if somebody else can see the command line you typed.
The rpcap protocol doesn't send the URL over the wire. The initial request from the client to the server is an authentication request that includes credentials, which begin with a credential type (null or username/password) with, for username/password, the username and password, as strings, following the credential type.
Wireshark's "Manage Interfaces" dialog allows you to specify the authentication type and, for username/password authentication, allows you to specify the username and password. TShark has no corresponding mechanism.
Is this limitation because of a limitation or lack of documentation regarding the rpcap protocol for how you handle passing authentication over
No, it's due to a lack of code in TShark to, for example, respond to an "authentication failed" reply from the server, if the reason is "null authentication not permitted", to prompt for a username and password. There's no such code in tcpdump, either.
(There's no documentation for the rpcap protocol at all. I have that as a project, but I have a lot of other things as projects as well, and, sadly, new project keep popping up. It needs to be written, because, at least at not one point, there was a non-libpcap rpcap server that wasn't sending correct replies, which broke access from the libpcap client.)
