Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissectors/: Makefile.nmake packet-ieee80211.c /trunk/epan/: libwireshark.def /trunk/gtk/: Makefile.nmake airpcap_dlg.c airpcap_d

2006-12-07 Thread Guy Harris
Gerald Combs wrote:

 As far as the Airpcap code being Windows-specific: we've tried to
 generalize it so that it can be adapted to other platforms.  There's no
 reason the code that calls airpcap_if_set_device_channel() under Windows
 can't (and shouldn't) use the SIOCSIWFREQ ioctl under Linux.

...at least with drivers that support the wireless extension.

Similarly, it could use the SIOCS80211 ioctl, with 
IEEE80211_IOC_CHANNEL, under BSDs.

At some point, in my Copious Free Time(TM), I'd like to get libpcap to 
support setting arbitrary properties on an open pcap_t, including the 
channel on wireless adapters.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] Malformed packets in CORBA protocol plugin

2006-12-07 Thread Andy . Ling
I originally posted this to the user list, but it was suggested
this is a better forum.

I am having problems with a CORBA protocol plugin. I have generated
the .c file using :-

omniidl -p c:\wireshark-0.99.3a\tools -b wireshark_be q_quentinv3.idl  
packet-quentinv3.c

and built and installed the .dll without problems.

But when I enable the protocol analyser, any IDL method that doesn't
have any arguments is marked as [Malformed Packet: Q_QUENTINV3]
Those with arguments have the arguments decoded correctly and
are not marked with any error.

If I disable my protocol analyser then no packets show errors.

I'm using version 0.99.3a on Win2K

Thanks for any help

Andy Ling
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissectors/: Makefile.nmake packet-ieee80211.c /trunk/epan/: libwireshark.def /trunk/gtk/: Makefile.nmake airpcap_dlg.c airpcap_d

2006-12-07 Thread Joerg Mayer
Gerald,

On Wed, Dec 06, 2006 at 02:53:31PM -0800, Gerald Combs wrote:
 The WPA code (specifically the modules in the airpdcap directory) is
 Windows-specific because we might use same code base for WPA decryption
 in Wireshark and in the Airpcap driver.  We're working on
 de-Windows-izing the code, which should be done in the next few days.
 At that point we can remove the HAVE_AIRPDCAP define.

:-)

 BTW, we now have encryption code in airpdcap/* and epan/crypt-*.[ch].
 (including duplicate MD5 implementations).  Should this all be moved to
 a common directory, e.g. epan/crypt/?

Yes, I think that would be the proper place.

 As far as the Airpcap code being Windows-specific: we've tried to
 generalize it so that it can be adapted to other platforms.  There's no
 reason the code that calls airpcap_if_set_device_channel() under Windows
 can't (and shouldn't) use the SIOCSIWFREQ ioctl under Linux.

The long term best place would be an integration of the capture part of
airpcap into libpcap, but until such a time adding support for other
OSses into airpcap would be nice too.

Btw, the files in airpcap (except the Makefile) lack copyright headers
and license information headers.

 Ciao
  Joerg
-- 
Joerg Mayer   [EMAIL PROTECTED]
We are stuck with technology when what we really want is just stuff that
works. Some say that should read Microsoft instead of technology.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Malformed packets in CORBA protocol plugin

2006-12-07 Thread Anders Broman \(AL/EAB\)
Hi,
Perhaps a fault in the GIOP dissector. Can you send the text output of
the failed decoding?
BR
Anders 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: den 7 december 2006 10:53
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Malformed packets in CORBA protocol plugin

I originally posted this to the user list, but it was suggested this is
a better forum.

I am having problems with a CORBA protocol plugin. I have generated the
.c file using :-

omniidl -p c:\wireshark-0.99.3a\tools -b wireshark_be q_quentinv3.idl 
packet-quentinv3.c

and built and installed the .dll without problems.

But when I enable the protocol analyser, any IDL method that doesn't
have any arguments is marked as [Malformed Packet: Q_QUENTINV3] Those
with arguments have the arguments decoded correctly and are not marked
with any error.

If I disable my protocol analyser then no packets show errors.

I'm using version 0.99.3a on Win2K

Thanks for any help

Andy Ling
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] Malformed packets in CORBA protocol plugin

2006-12-07 Thread Andy . Ling
[EMAIL PROTECTED] wrote on 07/12/2006 12:52:43:

 Hi,
 Perhaps a fault in the GIOP dissector. Can you send the text output of
 the failed decoding?
 BR
 Anders 
 

I'm not 100% sure which bit you are after, but the packet
bytes look like :-

Frame 199 (130 bytes on wire, 130 bytes captured)

   00 01 af 15 fd df 00 30 48 12 04 d4 08 00 45 00  ...0H.E.
0010   00 74 11 d2 40 00 80 06 9a e6 0a a5 0b 78 0a a5  [EMAIL PROTECTED]
0020   2d 0a 04 87 04 04 20 52 7c 07 0d a9 71 d6 50 18  -. R|...q.P.
0030   fd bb 8e 33 00 00 47 49 4f 50 01 02 01 00 40 00  [EMAIL PROTECTED]
0040   00 00 ec 00 00 00 03 00 00 00 00 00 00 00 1b 00  
0050   00 00 14 01 0f 00 52 53 54 45 6d a5 36 00 05 98  ..RSTEm.6...
0060   4a 00 00 00 01 00 00 00 01 00 00 00 02 00 0b 00  J...
0070   00 00 67 65 74 52 65 66 54 69 6d 65 00 00 00 00  ..getRefTime
0080   00 00..

And the decode window above shows:-

General Inter-ORB Protocol Request
  Request id: 236
  Response flags: SYNC_WITH_TARGET (3)
  Reserved: 0 0 0
  TargetAddress Discriminant: 0
  KeyAddr (object key length): 27
  KeyAddr (object key): RSTEm.6...J
  Operation length: 11
  Request operation: getRefTime
  ServiceContextList
Sequence Length: 0
[Malformed Packet: Q_QUENTINV3]

If I turn off our Q_QUENTINV3 protocol then the last line is not printed.

Another bit of information that might help. If I set the filter to giop
then the info in the main window looks like :-

Q_QUENTINV3 GIOP 1.2 Request 236: getRefTime[Malformed Packet]

Without the giop filter the [Malformed Packet] string is missing

Regards

Andy Ling

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


[Wireshark-dev] [PATCH] Fix build on OSX, packet-isakmp

2006-12-07 Thread Stig Bjørlykke

Hi.

The newly added eap_handle in packet-isakmp (revision 20054) breaks  
building on OSX.
The attached patch will fix this for packet-isakmp and packet-radius,  
which had the same variable name eap_handle.


I find alot of dissectors using global dissector_handle_t.  Should  
this be fixed for all of them?
packet-ansi_map.c, packet-bthci_acl.c, packet-camel.c, packet- 
catapult-dct2000.c, packet-cigi.c, packet-gsm_map.c, packet-inap.c,  
packet-isns.c, packet-isns.c, packet-isup_thin.c, packet-isup_thin.c,  
packet-kerberos.c, packet-llt.c, packet-msrp.c, packet-ncp.c, packet- 
rsync.c, packet-tcap.c, packet-tcap.c, packet-tcap.c, packet-tipc.c,  
packet-wfleet-hdlc.c, packet-winsrepl.c



--
Stig Bjørlykke



eap_handle.patch
Description: Binary data


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] [PATCH] range_string and OSPF bcmodelid

2006-12-07 Thread Stephen Fisher
On Wed, Dec 06, 2006 at 02:20:52PM +0100, Francesco Fondelli wrote:

 Could you write up some documentation changes to doc/README.developer 
 so others will know how to use this feature.  You can send a diff of 
 only README.developer since we already have the other patches.  We 
 will then review it for inclusion in Wireshark.
 
 You find it attached. My English sucks so check it out more carefully 
 than my code :-)

Both the documentation and code look fine.  I have committed the 
range_string feature as SVN revision 20061.  I committed your OSPF 
changes as revision 20063.  Thanks for your contributions!


Steve

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev


Re: [Wireshark-dev] [Wireshark-commits] rev 20049: /trunk/ /trunk/epan/dissectors/: Makefile.nmake packet-ieee80211.c /trunk/epan/: libwireshark.def /trunk/gtk/: Makefile.nmake airpcap_dlg.c airpcap_d

2006-12-07 Thread Guy Harris
Loris Degioanni wrote:

 Yes, this would be the optimal option, but it would require adding to 
 libpcap features that are not strictly capture oriented, like setting 
 a channel or configuring a set of decryption keys.

I'd consideer setting a channel capture-oriented, as a capture 
application might want to have a UI that lets you set the channel or 
that does scanning.

Configuring decryption keys is another matter; I suspect that, for most 
normal 802.11 adapters (as opposed to capture-only adapters such as 
AirPcap), that's done as part of setting the machine up to connect to a 
given protected network.  If you're capturing in non-promiscuous or 
promiscuous mode, you're capturing only on the network you're on, as far 
as I know; only in monitor mode do you capture everything the radio 
picks up, and I don't know whether any adapters will do decryption in 
monitor mode.  (The channel is also configured if you're on a given 
network, but, in monitor mode, you're probably able to change the 
channel arbitrarily.)

 I'd like to hear what people think about extending libpcap in that 
 direction (Guy?); if it's considered interesting, I could give it a try.

I think some option for setting the 802.11 channel should be offered by 
libpcap, to hide the OS-dependent details.  My inclination would be to have:

an extensible list of device settings, including monitor mode, channel, 
and anything else that a particular network type might have;

a way to inquire what settings are available for a particular adapter 
(so that an analyzer can, for example, decide what to offer in the UI);

a way to get the current value of a setting and to change the value of 
a setting;

perhaps a way to set the initial value when you open the device, 
although I suspect that wouldn't have an advantage over opening the 
device and then changing the setting.
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev