Wireshark · Ethereal-dev: Re: [Ethereal-dev] [Patch] Etheral reads from socket

[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

Hi Javier,

I agree with the others that the traffic should not just transported 
via TCP
and therefore this functionality should not be included as is in 
Ethereal.

However, I do understand your problem. So you have already an 
application
which reads SS7 traffic and sends it over an IP network. Why don't you 
just
write another application which reads this traffic and puts it into a 
pipe.
Ethereal can read from that pipe and you have the functionality you want
without touching ethereal. Since you write both the client and the 
server
you can you you own protocol there.

Best regards
Michael

On Jul 4, 2005, at 3:43 Uhr, Javier Acuña wrote:

> Hi, my answers below
>
> > Hi Javier!
> >
> > I had a look at your patch, and must say that IMHO it's not ready for
> > checkin for several reasons (no particular order):
> >
> > - the GUI changes make the capture options dialog box even more
> > "unintuitive" than it already is (e.g. which "IP address" is meant).
> > However, I could fix this if the other problems are solved.
>
> I would appreciate that.
>
> > - I assume the changes won't work with Win32, e.g. the #include's in
> > capture_loop.c will probably won't work on win32 and maybe not on 
> > "other
> > unixes" as well
>
> Hi, I'm a little confused.
>
> I know that pipes and sockets work in Unix, so Unix should be OK
>
> Regarding Windows, in the code to read from a pipe, it says that it 
> won't work on Windows, but in gtk/main.c (a couple of lines above line 
> 2000) you have an '#ifdef _WIN32' to allow reading from some pipe file 
> descriptor.
>
> Since my 'hack' relies on reading from a pipe, I'm not sure if it's 
> going to work in Windows.
>
> Anyhow, adding 'ifdef's' to make my code only visible to unix is a 
> definite possibility.
>
>
>
> > - command line: using two options '-d' and '-e' isn't a good idea, 
> > using
> > one with sub options might be a better idea (like the -a option)
>
> OK.
>
> > - general concerns: you should follow the style of the original files
> > (indentation, curly brackets, ...)
>
> OK, I'll use 'indent' next time.
>
> > In general, most of the things mentioned above are minor points. The
> > major problems are about the general functionality:
> >
> > - security: how do you avoid that someone else is capturing on the
> > server you've provided? That's a serious security problem!!!
>
> I'm going to add username/password support now. I don't think sending 
> the captured info encrypted is necessary,
>
>
> > - As Guy Harris already asked, why not add this feature to libpcap?
>
> Because, as I already said, this is not for capturing. This is used to 
> receive data from another program that does the capturing.
>
> In our case, we use SS7 hardware, and we have stand alone drivers and 
> applications that read data from those interfaces.
>
> This patchs opens the possibility of writing only the driver that 
> interacts with some XXX new hardware, then sends the data to 
> localhost:some_port and with Ethereal you have a new protocol analyzer 
> on top of that new hardware.
>
> > From what I gather, libpcap only reads from Ethernet devices. Adding 
> > this to libpcap limits us to Ethernet hardware.
>
> Regarding WinPcap below,
>
> i) we don't use windows here.
>
> ii) the winpcap approach needs a server and a client. I'm only 
> interested on embedding the client in Ethereal so It can receive from 
> any given source.
>
> > - did you noticed, that Winpcap already has a remote capturing 
> > feature,
> > see: http://www.winpcap.org/docs/docs31beta4/html/group__remote.html 
> > (I
> > don't know if the libpcap team is working on a similar feature, Guy?)
> >
> > - adding a remote capturing feature without providing the 
> > corresponding
> > server might be pretty useless
>
> As I said, this is not bounded to any server. I'm sending a small 
> server to test this patch
>
> > In general, this seems to be a "quick hack" to bring this feature to
> > life. There are some serious questions left open, which should be 
> > solved
> > first before doing further development.
>
> I didn't want to send a full fledged patch until I know you guys are 
> intereted in adding this. Besides, by sending the previos quick hack I 
> learned how to get the GUI thingie to work.
>
> > Regards, ULFL
>
>
>
>
> ________________________________________________________________
>
> Mensaje enviado desde el Servicio Webmail del Dominio sixbell.cl
>
>
>
>
>
>
> _____________________________
> La informacion contenida en esta transmision es confidencial, y no 
> puede ser usada por otras personas que su(s) destinatario(s). El uso 
> no autorizado de la informacion contenida en esta transmision puede 
> ser sancionado. Si ha recibido esta transmision por error, por favor 
> destruyala y notifique al remitente telefonicamente, con cobro 
> revertido o via e-mail.
>
> The information contained in this transmission is privileged, and may 
> not be used by any person other than its addressee(s). Unauthorized 
> use of the information contained in this transmission may be punished  
> by law.  If received in error, please destroy and notify the sender by 
> calling collect or by e-mail.
> _____________________________#include <stdio.h>
> #include <stdlib.h>
> #include <unistd.h>
> #include <strings.h>
> #include <sys/socket.h>
> #include <netinet/in.h>
> #include <sys/types.h>
> #include <sys/socket.h>
> #include <arpa/inet.h>
>
> #define SA struct sockaddr
> #define LISTENQ 100
> /*
>  * gcc server.c -o server
>  * server 'port_no' file.eth
>  * */
>
> void senddata ( int sockfd , char * file);
>
> int main (int argc, char **argv)
> {
> 	int port = (int) strtoul( argv[1], NULL, 10);
> 	char *nameOfFile = argv [2];
> 	
> 	/* Socket */
> 	int listenfd, connfd;
> 	pid_t childpid;
> 	socklen_t clilen;
>
> 	struct sockaddr_in cliaddr, servaddr;
>
> 	listenfd = socket (AF_INET, SOCK_STREAM, 0);
> 	
> 	bzero (&servaddr, sizeof (servaddr) );
> 	servaddr.sin_family = AF_INET;
> 	servaddr.sin_addr.s_addr  = htonl (INADDR_ANY);
> 	servaddr.sin_port = htons ( port );
> 	
> 	bind ( listenfd, (SA *) &servaddr , sizeof(servaddr) );
>
> 	listen ( listenfd, LISTENQ);
>
> 	while (1)
> 	{
> 	  clilen = sizeof (cliaddr);
> 	  connfd = accept (listenfd, (SA *) & cliaddr , &clilen );
>
> 	  if ( (childpid = fork() == 0 ) )
> 	  {
> 		  close (listenfd);
> 		  senddata( connfd, nameOfFile );
> 		  exit ( 0 );
> 	  }
> 	  close (connfd);
> 	}
> }
>
> void senddata ( int sockfd , char * file)
> {
> 	/* Archivo entrada */
> 	FILE *input = fopen(file, "r");
> 	printf("\n");
> 	char *temp = (char *) calloc(1, sizeof(char));
> 	
> 	int re;
> 	while ( (re = fread( (void *) temp, sizeof(char), 1, input) > 0) )
> 	//	fputs(temp, stdout);
> 		write( sockfd , temp, 1);
> 	fclose (input);
> //	write(connfd, buff, strlen(buff));
> }
>
> int Socket(int family, int type, int protocol)
> {
> 	int n;
> 	if ( (n = socket(family, type, protocol)) < 0 )
> 		fprintf (stderr, "Error de Socket(...)\n");
> 	return n;
> }
>
> void Connect(int fd, const struct sockaddr *sa, socklen_t salen)
> {
> 	int n;
>         if ( (n = connect(fd, sa, salen)) < 0)
>                 fprintf(stderr, "Error en Connect(...), %i\n", n);
> }
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev