So make a separate RSA key table within the amp protocol preferences? And
then pass that along to SSL when the protocol goes encrypted?
I assume the same issue impacts LDAP/TLS and XMPP?
-Rob
On Fri, Jan 10, 2014 at 11:51 AM, Jeff Morriss wrote:
> I think for that you can't enter the encryptio
On Jan 10, 2014, at 10:59 AM, Stig Bjørlykke wrote:
> Updating the RTSE dissector to a new-style was done by returning
> tvb_length(tvb), which in this case is always 0. Returning 0 from a
> new-style dissector means this package was not for us, which is wrong
> in this case.
That's why I neve
On Jan 10, 2014, at 11:26 AM, Evan Huus wrote:
> Perhaps we should add an option to Pcapng to store
> original-host-endianess as well, ie something that persists in this
> case?
Doesn't help if you're writing pcap files, or if the code reading the file
doesn't know about that pcap-ng option.
On Jan 10, 2014, at 11:21 AM, Jakub Zawadzki wrote:
> In packet-nflog.c I'm trying to guess endianess (nflog_tvb_byte_order())
Sadly, nflog doesn't have a fixed amount of fixed-format data that is in host
byte order, with everything else in a standard byte order, so guessing the byte
endianne
On Jan 10, 2014, at 4:33 AM, Michal Labedzki wrote:
> Is there option to dissector know byte order of... "interface"?
No.
For live capture on a local interface, the byte order is the machine's byte
order.
For reading pcap and pcap-ng files, the byte order in the file is changed to
the byte
On Fri, Jan 10, 2014 at 2:21 PM, Jakub Zawadzki
wrote:
> Hi,
>
> On Fri, Jan 10, 2014 at 01:33:49PM +0100, Michal Labedzki wrote:
>> Probably PCAP/PCAPNG have ordering info by magic bytes, but I do not
>> know how to do that while live capturing (current code work for this
>> case)
>
> Still magic
Hi,
On Fri, Jan 10, 2014 at 01:33:49PM +0100, Michal Labedzki wrote:
> Probably PCAP/PCAPNG have ordering info by magic bytes, but I do not
> know how to do that while live capturing (current code work for this
> case)
Still magic numbers are always saved in current host endianess ;|
So if you (
On Fri, Jan 10, 2014 at 12:56 PM, Stig Bjørlykke wrote:
> This commit introduced a bug where I always get
> "[Malformed Packet: PRES]" in X.400 traffic.
Reassembly in RTSE is a bit special. The reassembly is done when
receiving a SES "MAJOR SYNC POINT", as this indicates the end of the
COTP DT Da
I think for that you can't enter the encryption keys in the UAT but
rather your amp dissector would need to register for the SSL after the
negotiation.
On 01/09/14 11:55, Rob Napier wrote:
That was exactly it. Thank you!
I'm now seeing a much less critical issue:
The amp protocol starts off
Specifically, see the byte_swapped boolean in wiretap/libpcap.c and
wiretap/pcapng.c
On Fri, Jan 10, 2014 at 9:06 AM, Evan Huus wrote:
> Wireshark definitely reads and stores the byte-order from the pcap header
> when opening the file. I don't think that is exposed currently, but it should
> be
On Fri, Jan 10, 2014 at 02:07:37PM +0100, Michal Labedzki wrote:
> I have one more question: how tfshark works?
> ./tshark -V -r file.elf # works ok
> ./tfshark -V -r file.elf # does not work
>
> How to display dissector fields with tfshark? (in case I do not know
> their names)
Similar behavior h
On Fri, Jan 10, 2014 at 07:33:23AM -0500, mman...@netscape.net wrote:
> Unfortunately, yes it still needs to link with libwiretap. I believe my
> initial copy/paste tried to remove it but I ended up restoring it so I could
> at least commit the "initial" version of fileshark. Perhaps I didn't r
Wireshark definitely reads and stores the byte-order from the pcap header when
opening the file. I don't think that is exposed currently, but it should be
relatively easy to do (from wiretap).
> On Jan 10, 2014, at 7:33 AM, Michal Labedzki
> wrote:
>
> Hello,
>
> Is there option to dissector
Ok, I sent patch to you.
I have one more question: how tfshark works?
./tshark -V -r file.elf # works ok
./tfshark -V -r file.elf # does not work
How to display dissector fields with tfshark? (in case I do not know
their names)
On 10 January 2014 13:33, wrote:
> Unfortunately, yes it still nee
Hello,
Is there option to dissector know byte order of... "interface"? I am
thinking about:
1) PCAP File
2) PCAPNG file
3) live capturing
Please look at packet-usb.c.
There is:
---
/* Adds the Linux USB pseudo header fields to the tree.
* NOTE: The multi-byte fields in this h
Unfortunately, yes it still needs to link with libwiretap. I believe my
initial copy/paste tried to remove it but I ended up restoring it so I could at
least commit the "initial" version of fileshark. Perhaps I didn't restore it
in all build configurations. You can send me a patch for autoto
On Tue, Nov 5, 2013 at 7:47 PM, wrote:
> Log:
> In an effort to reduce the use of pinfo->private_data (and some true global
> variables), I converted the ASN.1 dissectors that use pinfo->private_data to
> exchange a SESSION_DATA_STRUCTURE to instead only exchange it in the context
> of ASN.1.
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Vishnu Bhatt
Sent: den 10 januari 2014 10:54
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Siginificance of pinfo->fd->flags.visited
Thanks for the explanation.
1. <<
Hello Michael,
I still have a problem building tfshark with autotools:
CCLD tfshark
/usr/bin/ld: tfshark-cfile.o: undefined reference to symbol
'wtap_file_get_idb_info'
/usr/bin/ld: note: 'wtap_file_get_idb_info' is defined in DSO
src/wireshark/wiretap/.libs/libwiretap.so.0 so try adding it t
Thanks for the explanation.
1. << The result of a packet dissection is thrown away as soon as the packet
has been read and presented, so if you 'click' on a new packet the dissection
has to be redone.>>
"Thrown away" means it's not stored anywhere. Am I right? If yes, why is it
thrown away?
From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Vishnu Bhatt
Sent: den 10 januari 2014 08:59
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Siginificance of pinfo->fd->flags.visited
>Hello all,
>
>Can anyone please explain me the sig
Hello all,
Can anyone please explain me the significance of pinfo->fd->flags.visited. I
know that this variable is set to TRUE if a packet has been visited once but if
we click on the same packet then why all things are done again? Logically if a
frame has been dissected once, it should not be
22 matches
Mail list logo
