estabamos esperando a que aparecieras, hay un par de cosas que podemos
hace r de todas formas asi que digan cuando..(yo no puedo mañana
miercoles) pero si hoy por ejemplo.
estare en el canal pa que caudremos.
/a
he estado mirando un poco como funciona el modulo para perl de kismet,
se resume en que se trata de un wrapper para desarrollar aplis sobre
el tcp, como es obvio a mi esto me queda muy dificil pero como ya lo
instale podriamos mirar un poco y pensar en desarrollar algun par de
lineas que saquen datos intersantes...etc aca les pego el doc del
devel.client. si alguien me puede responder que tan equivocado estoy
pues lo agradesco...sera que es posible usar esto???
Client/Server Protocol
The Kismet client/server protocol has evolved over time, but is finally (as of
this writing) at a stable state. This new method of communication allows a
client to request only the protocols which are of interest, AND to control the
fields and field order that these protocols are sent with. This removes the
disruption the addition of new protocols and new tracking data caused to
independent clients. The basics of the protocol are as follows:
The server->client protocol consists of one-line statements of the format:
*{HEADER}: {Data}
{HEADER} denotes the type of protocol, ie KISMET, NETWORK, TIME, etc.
{Data} denotes the free-form data for this protocol.
Multi-field data is seperated with spaces. Any data field that may contain
spaces is buffered by \001{Field}\001. This buffering is not used for
protocols such as STATUS which return only a single field.
The client->server commands consist of one-line statements of the format:
!{ID} {COMMAND} {Options}
{ID} is a unique numerical identifier (timestamp is often used) which is used
by the server to return an error condition for a specific command.
If {ID} is set to 0, no ACK is returned.
{COMMAND} is the command to be run (ie, ENABLE, REMOVE, CAPABILITY)
{Options} are the options for that command.
Basic client support:
The server expects every client to handle the following basic protocols, and
automatically enables them for that client at connect time. All other
protocols must be specifically request.
*KISMET: {Version} {Start time} {Server name} {Build Revision}
Initial identifier
*ACK: {Command ID}
Acknowledgement that a command was processed. If your client doesn't care
about acknowledgements, this can be ignored or commands can be sent with an
ID of 0.
*ERROR: {String}
Error response for an invalid request. The simplest way to handle this is to
print it as a status message. More advanced handling can be added at your
discretion.
*PROTOCOLS: {Comma-delimited string of supported protocols}
List of protocols this server supports
*CAPABILITY: {Protocol} {Comma-delimited string of fields}
Capability of a specific protocol
*TERMINATE: {String}
Server termination
*TIME: {Current time}
Current server time in seconds since the epoch
The server supports the following commands:
!{ID} CAPABILITY {Protocol}
Request that a *CAPABILITY line be sent for the protocol
!{ID} ENABLE {Protocol} {Comma-delimited string of requested fields}|{*}
Enable sending a protocol with the requested field order. * enables all
fields in the default order.
!{ID} REMOVE {Protocol}
Stop sending a protocol
!{ID} PAUSE
Pause the packet sources
!{ID} RESUME
Resume capturing from the packet sources
!{ID} LISTWEPKEYS
Lists WEP decryption keys if the server allows this.
!{ID} ADDWEPKEY {bssid},{hex key}
Add a WEP decryption key for the given BSSID.
!{ID} DELWEPKEY {bssid}
Remove the WEP key for a give BSSID.
An example session:
Connected to localhost.
Escape character is '^]'.
KISMET: 2.7.1 1038236534 `"Gir"` 20021118101152
*PROTOCOLS:
KISMET,ERROR,PROTOCOLS,CAPABILITY,TERMINATE,TIME,NETWORK,CLIENT,GPS,INFO,REMOVE,STA
TUS,PACKET,ALERT,STRING
!1234 CAPABILITY NETWORK
*ACK: 1234
*CAPABILITY: NETWORK
bssid,type,ssid,beaconinfo,llcpackets,datapackets,cryptpackets,weakpackets
,channel,wep,firsttime,lasttime,atype,rangeip,gpsfixed,minlat,minlon,minalt,minspd,maxlat,maxlo
n,maxalt,maxspd,octets,cloaked,beaconrate,maxrate,manufkey,manufscore,quality,signal,noise,best
quality,bestsignal,bestnoise,bestlat,bestlon,bestalt,agglat,agglon,aggalt,aggpoints
!1235 ENABLE NETWORK bssid,type,ssid
*ACK: 1235
*NETWORK: 00:40:96:55:A2:72 0 [EMAIL PROTECTED]
*NETWORK: 00:A0:F8:41:3C:DD 0 `KrullNet1`
...
PROTOCOL and CAPABILITY processing is left to the discretion of the client
author - they may be ignored with the understanding that a request for an
unknown protocol or an unknown field will result in an error, or they can
be processed to verify that the server accepts all the desired fields.
On Tue, 28 Dec 2004 15:34:47 +0100 (CET), [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Hola señores,
>
> se acerca el final de año y debemos culminar con la concluciones de este
> 2004, creo que debemos hacer una reunion esta semana aunque sea para que
> nos tomemos unas cervezas si no se puede hacer nada mas. que piensan?
>
> Kleper
>
> _______________________________________________
> Altred mailing list
> [email protected]
> http://altred.net/mailman/listinfo/altred_altred.net
>
