Re: [Wireshark-dev] h.223 robustness fixes

Hi, Compile failes on Windows with: packet-h223.c packet-h223.c(596) : warning C4018: '<' : signed/unsigned mismatch packet-h223.c(1156) : error C2065: 'uint' : undeclared identifier packet-h223.c(1156) : error C2146: syntax error : missing ';' before identifier 'needed' packet-h223.c(1156) : error

Re: [Wireshark-dev] H.223 dissector - separate "bitswapping" intoseparate dissector

Committed revision 20893. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 19 februari 2007 02:33 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] H.223 dissector - separate "bitswapping" i

Re: [Wireshark-dev] DESEGMENT_ONE_MORE_SEGMENT over iax

Committed revision 20892. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 16 februari 2007 19:12 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] DESEGMENT_ONE_MORE_SEGMENT over iax Hi,

Re: [Wireshark-dev] defragmentation over RTP

Committed revision 20891. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 16 februari 2007 16:20 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] defragmentation over RTP Hi, Here's a pa

Re: [Wireshark-dev] g_assert -> DISSECTOR_ASSERT in stream.c

Committed revision 20889. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 15 februari 2007 22:44 Till: Developer support list for Wireshark Ämne: [Wireshark-dev] g_assert -> DISSECTOR_ASSERT in stream.c

Re: [Wireshark-dev] reassembly.c: fragment_set_partial_reassembly() forfragment_add_seq

Committed revision 20888. Without the makefile changes to build the test program as I can't test it on Windows. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För Richard van der Hoff Skickat: den 15 februari 2007 22:36 Till: Developer suppo

Re: [Wireshark-dev] having trouble building a minimal dissector

On Tue, Feb 20, 2007 at 01:21:47PM -0800, David Bunch wrote: > Hi im trying to build a dissector for a protocol that runs on top of > udp. I have read the README.developer and README.pluggin however I am > still having trouble getting a bare minimal dissector up and running > and showing up in

[Wireshark-dev] having trouble building a minimal dissector

Hi im trying to build a dissector for a protocol that runs on top of udp. I have read the README.developer and README.pluggin however I am still having trouble getting a bare minimal dissector up and running and showing up in the supported protocol list in the supported protocol list window. Doe

Re: [Wireshark-dev] TCP ZeroWindowProbe problem / question

On Feb 20, 2007, at 9:34 PM, Ulf Lamping wrote: > Michael Tuexen wrote: >> Hi Ulf, >> >> just to be clear: >> The sender is allowed to send 1 byte more than the rwnd allows. >> This is used for zero window probing. >> > Yes, your remarks sounds reasonable and reflects the effects I've > seen. >

Re: [Wireshark-dev] TCP ZeroWindowProbe problem / question

Michael Tuexen wrote: > Hi Ulf, > > just to be clear: > The sender is allowed to send 1 byte more than the rwnd allows. > This is used for zero window probing. > Yes, your remarks sounds reasonable and reflects the effects I've seen. Just out of interest: What will happen if the sender will sen

Re: [Wireshark-dev] TCP ZeroWindowProbe problem / question

On 2/20/07, Ulf Lamping <[EMAIL PROTECTED]> wrote: > Interestingly, the effect I saw is that the window size is zero before > and after the probe byte, although the receiver actually ACK'ed the > "probe byte". Do you use window scaling? If you have window scaling the most likely explanation for y

Re: [Wireshark-dev] TCP ZeroWindowProbe problem / question

Hi Ulf, just to be clear: The sender is allowed to send 1 byte more than the rwnd allows. This is used for zero window probing. The receiver has a rwnd which he uses to accept data or not. But he is free to advertise less, for example for SWS avoidance. This is what you experience: the receiver a

Re: [Wireshark-dev] TCP ZeroWindowProbe problem / question

ronnie sahlberg wrote: > So if the window is still zero, the ACK will indicate this by NOT > advancing to cover the new byte. > If the window is no longer zero, the receiver can handle the byte and > the ACK will be advanced to cover the new byte. > > First of all, thanks a lot for the detaile

Re: [Wireshark-dev] Function to decode messages when several encodingcan be used

Committed revision 20878. Best regards Anders -Ursprungligt meddelande- Från: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] För [EMAIL PROTECTED] Skickat: den 20 februari 2007 13:07 Till: wireshark-dev@wireshark.org Ämne: [Wireshark-dev] Function to decode messages when several encodingcan b

Re: [Wireshark-dev] Adding a dissector for "Analyze->Decode As" only

Thanks for the info.This protocol runs directly on tcp. I have been able to use the approach you suggested to get an initial stub to work. thanks, Ravi. -- Forwarded message -- From: Guy Harris < [EMAIL PROTECTED]> To: Developer support list for Wireshark Date: Fri, 16 Feb 2007

Re: [Wireshark-dev] Patch for bug 310

Ulf Lamping wrote: > Steve Schaeffer wrote: >> Let us review... >> >> I submitted this bug report 18 months ago and you said you'd have a look >> at it. >> > I *had* a look at that problem some time ago, and tried a few hours to fix > it - when I remember correct I dropped my test because of a c

[Wireshark-dev] Problem LUA + MEGACO/H248

Hello, I have a problem using LUA with h248. I wrote a script trying to take only one communication out of a capture file. The problem is when I want to have the terminationID, it doesn't work. He doesn't find it. Here are the code lines: terminationId = Field.new("h248.terminationID") extract_

[Wireshark-dev] H.223 over rtp

This patch registers H.223 as a dissector for RTP CLEARMODE payloads - and makes some other modifications to the H.223 dissector to make this work correctly. It assumes that both my earlier patches to the H.223 dissector ('H.223 dissector - separate "bitswapping" into separate dissector' and '

[Wireshark-dev] h.223 robustness fixes

Hi, This patch improves the general robustness of the h.223 dissector (making it less likely to crash on malformed data). Hopefully this also fixes a bug raised by Fabio Sguanci a few weeks ago. Fabio: I think a better way to fix the problem is to stop the dissector crashing when it finds a

[Wireshark-dev] Function to decode messages when several encoding can be used

This patch provide a new function to decode messages when several ASN1 encoding can be used. This is the case, for example, when a same message has different encoding according to the MAP version, or in case of ASN1 encoder optimization. At the same time, I did remove the configuration variable "o

Re: [Wireshark-dev] Building RPM with Lua support

Hi Luis The "problem" was that the settings for the RPM build are not controlled by switches to the root "./configure" call, but by switches specified in "./packaging/rpm/SPECS/wireshark.specs.in" (which gets used _by_ the root "./configure" to build "wireshark.spec", which in turn _contains_ a se

Re: [Wireshark-dev] Patch to decode ERF type 5 record

I am still working on the subject, but I think it will not be a new WTAP_ENCAP. I tried to introduce a kind of extension for the linktype to give more information, like FCS presence. Concerning the different formats stored in the ERF record with type MC_HDLC, I have no other details. Personnally,