[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #24 from Guy Harris  ---
(In reply to Mike Baker from comment #23)
> And BTW, Guy, these are typically personal laptops that wireshark is
> installed on.

Then you might want to try just putting the scripts in
%APPDATA%\Wireshark\plugins; that way, you don't have to change init.lua at
all, and upgrades won't affect the scripts at all.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #23 from Mike Baker  ---
And BTW, Guy, these are typically personal laptops that wireshark is installed
on.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #22 from Mike Baker  ---
Created attachment 15749
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15749=edit
Error dialog if struct.lua is not put in C:\Program Files\Wireshark

Again, thanks for all your help on this issue, Guy!

I could not find good docs on the proper syntax for use of "dofile" --
specifically, if I wanted to reference a different folder, like
c:\WiresharkDissectors, do you know what works?

e.g., this works:
dofile(DATA_DIR.."struct.lua")
dofile(DATA_DIR.."../../WiresharkDissectors/bcp_dissector.lua")
dofile(DATA_DIR.."../../WiresharkDissectors/dsmcc_dissector.lua")
dofile(DATA_DIR.."../../WiresharkDissectors/ictvprot_dissector.lua")
dofile(DATA_DIR.."../../WiresharkDissectors/rfbtv_dissector.lua")

But if I try to put struct.lua into any folder other than 
C:\Program Files\Wireshark\, I get the attached error msg.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #21 from Guy Harris  ---
(In reply to Mike Baker from comment #20)
> Guy, our company has 5 dissectors for custom protocols we use.  Previously,
> we had been copying these .lua files to C:\Program
> Files\Wireshark\plugins\x.y.z folder each time a new wireshark release was
> available -- otherwise the .lua files would be gone after the upgrade.

So are these on personal computers, in the true sense of the word "personal" -
i.e., only one person uses it - or are they either shared computers (e.g., in a
lab) or servers?

If they're truly *personal* computers, an alternative would be to install the
custom dissectors in the personal configuration directory of the user whose
computer it is.

If not, then:

> A
> recently-discovered alternative was to instead copy the .lua files to
> C:\Program Files\Wireshark\, and just append the "dofile" lines, one per
> dissector, at the bottom of init.lua, per the example below:
> 
> dofile(DATA_DIR.."dsmcc_dissector.lua")
> dofile(DATA_DIR.."twcssp.lua")

perhaps there needs to be a global directory, probably under Program
Files\Wireshark, for site modifications such as plugins.  That directory would
*not* be affected by an upgrade - either the upgrade would leave it alone, or,
if necessary, it'd move it out of the way and move it back when the upgrade is
done.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #20 from Mike Baker  ---
Guy, our company has 5 dissectors for custom protocols we use.  Previously, we
had been copying these .lua files to C:\Program Files\Wireshark\plugins\x.y.z
folder each time a new wireshark release was available -- otherwise the .lua
files would be gone after the upgrade.  A recently-discovered alternative was
to instead copy the .lua files to C:\Program Files\Wireshark\, and just append
the "dofile" lines, one per dissector, at the bottom of init.lua, per the
example below:

dofile(DATA_DIR.."dsmcc_dissector.lua")
dofile(DATA_DIR.."twcssp.lua")

My mistake was to NOT append the new init.lua, but just overwrite 2.4.0
C:\Program Files\Wireshark\init.lua with the 2.2.8 init.lua version.  My bad!

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13949] macOS home-brew link on https://www.wireshark.org/download.html does not work

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13949

Alexis La Goutte  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|CONFIRMED   |RESOLVED

--- Comment #3 from Alexis La Goutte  ---
Thanks,

the link working now

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #19 from Guy Harris  ---
(In reply to Mike Baker from comment #18)
> Thank you, Stig!
> 
> Indeed, that was the problem with the handling of the lua code using
> ftypes.ETHER.  I had copied the older .lua file across, not realizing there
> had been changes.

"Copied" as in "overwrote the 2.4.0 init.lua under C:\Program Files\Wireshark
with the 2.2.8 one", or as in "copied the 2.2.8 init.lua from C:\Program
Files\Wireshark to your personal configuration directory"?

You should never do the first of those, as init.lua is part of the Wireshark
release and is subject to change from release to release - if you are making
changes to the global init.lua file, you need to record the changes and, when
you upgrade to a new version of Wireshark, apply those changes to the file that
comes with Wireshark.

You shouldn't need to do the second of those - your personal init.lua is run
*in addition to* the global init.lua, not *instead of* the global init.lua.

Also, what changes did you make to init.lua?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

Mike Baker  changed:

   What|Removed |Added

 Resolution|FIXED   |NOTABUG

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

Mike Baker  changed:

   What|Removed |Added

 Status|INCOMPLETE  |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Mike Baker  ---
Thank you, Stig!

Indeed, that was the problem with the handling of the lua code using
ftypes.ETHER.  I had copied the older .lua file across, not realizing there had
been changes.

Specifically, in the 2.2.8 version of init.lua, notice that UINT8 has the value
= 3:

-- Field Types
ftypes = {
["NONE"] = 0,
["PROTOCOL"] = 1,
["BOOLEAN"] = 2,
["UINT8"] = 3,
["UINT16"] = 4,
...
["STRINGZ"] = 26,
["UINT_STRING"] = 27,
["ETHER"] = 28,
["BYTES"] = 29,
...
}

While in the 2.4.0 version of init.lua, there is a new "CHAR" type inserted
with value = 3.  This has a rippling effect down to change the value of the
ETHER ftype:

-- Field Types
ftypes = {
["NONE"] = 0,
["PROTOCOL"] = 1,
["BOOLEAN"] = 2,
["CHAR"] = 3,
["UINT8"] = 4,
["UINT16"] = 5,
...
["STRINGZ"] = 27,
["UINT_STRING"] = 28,
["ETHER"] = 29,
["BYTES"] = 30,
...
}

Sorry for the trouble I caused in reporting this -- I am resolving the issue,
thanks again!

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #17 from Stig Bjørlykke  ---
I suspect you are using a init.lua file from version 2.2.x which has an entry
in the ftypes table ["ETHER"] = 28 on a 2.4.0 installation which interprets the
value 28 as FT_UINT_STRING (because the values has changed between 2.2 and
2.4).  This gives the described error.

So, please check this entry in your global init.lua file.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #16 from Guy Harris  ---
(In reply to Mike Baker from comment #14)
> BTW, when I copied the .lua files to the "plugins" folder, namely C:\Program
> Files\Wireshark\plugins, I also get no complaints.  But if then I open a
> .pcap file that the dissector should handle, it doesn't.

That's because that's not the right directory for *global* plugins.

But when I put twcssp.lua in my *personal* plugin folder, either on macOS with
a tip-of-the-master-branch build or on Windows 7 with the 2.4.0 release, I get
no complaints, *and* dsmcc_ssp is a valid protocol in the display filter field,
and if I type a "." after it, it gives me a list of the fields, so presumably
that dissector is loaded.

So I can't reproduce this, even on Windows.

Try un-installing Wireshark, *deleting C:\Program Files\Wireshark*, making sure
there's nothing with a name containing "Wireshark" in C:\Program files, and
then re-downloading and re-installing 2.4.0.  Then try installing your Lua
plugins, and see what happens.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #15 from Guy Harris  ---
(In reply to Mike Baker from comment #14)
> Thanks for your comments, Guy, as well as renaming the title of this bug.
> 
> My understanding of the proper folder for .lua files is C:\Program
> Files\Wireshark\plugins\2.4.0.

That's the *global* directory for Lua plugins.  That's for plugins that should
be considered part of the installation.

The *personal* directory for Lua plugins, which is for your own personal
plugins, is the "plugins" directory under your personal configuration
directory; that's %APPDATA%\Wireshark on Windows (or %USERPROFILE%\Application
Data\Wireshark if %APPDATA% isn't set), and ~/.config/wireshark on UN*X (or
~/.wireshark if ~/.config/wireshark doesn't exist).

That's the directory I was using.

The scan for Lua plugins also searches *subdirectories* of the Lua plugin
directory.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #9 from Pascal Quantin  ---
(In reply to conall.prendergast from comment #8)
> Could we use the SCCP calling GT? 
> Taking into account a possible change in the first replay, as mentioned by
> Vasil here. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13739#c6

And in https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13739#c8 he says
that it will not work either.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #8 from conall.prenderg...@anam.com ---
Could we use the SCCP calling GT? 
Taking into account a possible change in the first replay, as mentioned by
Vasil here. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13739#c6

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

Alexis La Goutte  changed:

   What|Removed |Added

 Status|INCOMPLETE  |CONFIRMED

--- Comment #4 from Alexis La Goutte  ---
Hi Kenneth,

Thanks for feedback and explication !
I will be possible to add a heuristic for NEC Phone (i think) with the class id
actually for Alcatel Lucent (heuristic and phone...) there is no check of class
id or other... it is why there is a error with your pcap

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #7 from Pascal Quantin  ---
So this capture is the opposite of bug 13739. We have a match both for the
source tid / source address, and destination tid / destination address.
Either we test first with the source tid / address, and this solves this bug
but breaks 13739. Or we test first the destination tid / address, and it solves
bug 13739 but breaks this bug.
What extra info could be used to differentiate them?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

--- Comment #3 from Kenneth Coombes  ---
Thank you for feedback.

@Alexis
Thank you for the idea.  While the phone is not an Alcatel phone, I was indeed
able (in Wireshark 2.4 only) to disable the Alcatel-Lucent heuristic in Analyze
-> Enabled Protocols and get rid of the error.

@Jaap
Sounds good.
- The phone is indeed an NEC phone.  It is an NEC DT700/730G/820 series phone
running our Standard SIP firmware.
- The relay was a Cisco Catalyst with the "ip helper-address" command to
forward the DHCP Discover packets.  
- The DHCP server is Windows Server 2008 R2's DHCP server.
- The VoIP platform is an NEC UNIVERGE 3C UCM system.
- Option 66 is used by the phone as expected: it tells the phone where the boot
server is for firmware and configuration files.
- Option 60 in the DHCP Discover for this phone firmware will always be
"NECSDT700" even for DT820s).
- 192.168.205.52 is an FTP server, HTTPS server, and TFTP Server (all hosted by
the UNIVERGE 3C server). The phone could use any of these protocols to download
FW and config files, but FTP is almost always used.
- Option 66 could be specified for these phone using any of the following
string formats:
 * [IP|FQDN] only (in this case, FTP is assumed)
 * ftp://[IP|FQDN]
 * https://[IP|FQDN]
 * tftp://[IP|FQDN]

Not sure how the heuristic part works (maybe key off of Option 60 in the
previous Discover?), but since the phone treats (sub)Option 66 in the standard
way, it would be nice to see it fully dissected as a Boot Server option (aka
TFTP Server Name per RFC).  There is nothing proprietary about it for the
phone.  The only reason to use DHCP Option 43 is where option 66 is already
being used in the same subnet by other non-NEC-phone hosts.

Thanks,
Kenneth

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

Jaap Keuter  changed:

   What|Removed |Added

 Resolution|REMIND  |---
 Status|RESOLVED|INCOMPLETE

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #6 from Pascal Quantin  ---
Given than code points can also change and cannot be used as part of the key to
find matches, I do not see how to solve this for now.

How can we differentiate that the end message is sent by the host that also
sent the begin message (what happens in this capture) and not by the
destination host of the begin message (what I always saw in the few captures I
worked on - bug 13739 and 10841).
Here codepoint 11330 is also using aa0 as source tid for packet 6, thus the
mismatch.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13950] Using ftypes.ETHER in ProtoField.new gives "Unsupported ProtoField field type" error

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13950

--- Comment #14 from Mike Baker  ---
Thanks for your comments, Guy, as well as renaming the title of this bug.

My understanding of the proper folder for .lua files is C:\Program
Files\Wireshark\plugins\2.4.0.  (the "x.y.z" version folder, not the "plugins"
folder.  When I do so, the error dialog appears per my last comment.  The same
exact dialog appears if instead use the dofile lines in init.lua.

BTW, when I copied the .lua files to the "plugins" folder, namely C:\Program
Files\Wireshark\plugins, I also get no complaints.  But if then I open a .pcap
file that the dissector should handle, it doesn't.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #5 from conall.prenderg...@anam.com ---
4c585f would be the otid in this case. 

That TCAP END is being sent by OPC=11334.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #4 from Pascal Quantin  ---
I saw that they use one common tid.
But packet 5 is using source tid 4c585f and packet 17 is using destination tid
aad0. Based on the previous logs in bug 13739, I would have expected it to
be 4c585f instead. Could you please clarify?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

--- Comment #3 from conall.prenderg...@anam.com ---
Hi Pascal,

Apologies for the confusion.
In the trace above, there are two distinct TCAP transactions, but they happen
to use a common transaction ID (ad0).

You are correct in saying that stid and dtid are stable in a transaction.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13926] TCAP SRT Analysis incorrectly matched TCAP begins and ends

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13926

Pascal Quantin  changed:

   What|Removed |Added

 CC||pascal.quan...@gmail.com,
   ||vvvelich...@gmail.com
 Ever confirmed|0   |1
 Status|UNCONFIRMED |INCOMPLETE

--- Comment #2 from Pascal Quantin  ---
Hi Conall,

Packet 17 sends its message to destination tid aad0, which matches the
source tid of packet 6 but not packet 5 (that uses 4c585f).
Packet 18 sends its message to destination tid 4c4b8b that does not match any
begin message.
During the discussion in bug 13739, I was notified that code points could
change so I did the relevant changes. But I was not told that tid could change
also( please keep in mind that I'm not a TCAP user and I do not know how this
is supposed to work nor have currently access to the spec).
Based on the discussion in bug 13739, I assumed that the source tdi /
destination tid were supposed to be stable (sa opposed to the code points that
can change). Is this assumption false? Could you please provide some technical
background or spec content explaining how this is supposed to work?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13745] RADIUS dictionary: BEGIN-VENDOR does not support format=Extended-Vendor-Specific-*

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13745

--- Comment #23 from João Valverde  ---
(In reply to Marius Paliga from comment #20)
> I just built windows version and everything is OK here. So I have problem
> just with linux version.

Can you confirm how you are building the Linux version? I'm seeing different
results with different build options.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

Angie  changed:

   What|Removed |Added

 Resolution|--- |REMIND
 CC||angiestamme...@gmail.com
 Status|CONFIRMED   |RESOLVED

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13938] RADIUS: Filter issue when Extended attributes defined in dictionary

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13938

--- Comment #7 from João Valverde  ---
(In reply to Marius Paliga from comment #6)
> (In reply to João Valverde from comment #5)
> > I don't see any duplicates in your example dictionary, unless they were
> > omitted for brevity. One entry shown is for VSA 11 (Alc-Subsc-ID-Str) and
> > the other is for EVS-1 11 (Alc-Ext-Attribute3).
> > 
> > It's unclear to me whether you are using the word "same" to describe both or
> > not.
> > 
> > I quickly tested this again and it's not loading the custom dictionary how
> > I'd expect. Appears to be one of the problems you are having, so that's
> > good. I need to check that later.
> 
> I use different custom dictionary (different from the attached sample) where
> I had duplicates. But this is not an issue any more.
> 
> The issue is that now we have two entries (as you wrote):
> VSA   11 (Alc-Subsc-ID-Str)
> EVS-1 11 (Alc-Ext-Attribute3)
> There are not duplicates but the filter is still not created.
> When I remove "EVS-1 11 (Alc-Ext-Attribute3)" the filter for
> Alc-Subsc-ID-Str is created.

I cannot reproduce this, can you attach again a minimal but complete dictionary
to this bug that I can use to test?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13952] MRCPv2 not decoded correctly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13952

Dario Lombardo  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13952] MRCPv2 not decoded correctly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13952

--- Comment #6 from Gerrit Code Review  ---
Change 23013 merged by Dario Lombardo:
mrcpv2: fix bug in use of ws_strtou32.

https://code.wireshark.org/review/23013

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13952] MRCPv2 not decoded correctly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13952

--- Comment #5 from Gerrit Code Review  ---
Change 23013 had a related patch set uploaded by Alexis La Goutte:
mrcpv2: fix bug in use of ws_strtou32.

https://code.wireshark.org/review/23013

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13952] MRCPv2 not decoded correctly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13952

--- Comment #4 from Gerrit Code Review  ---
Change 23012 merged by Alexis La Goutte:
mrcpv2: fix bug in use of ws_strtou32.

https://code.wireshark.org/review/23012

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13942] SIP Statistics extract does not work

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13942

--- Comment #3 from Pascal Quantin  ---
(In reply to Michael Mann from comment #2)
> (In reply to Pascal Quantin from comment #1)
> > Indeed simple_statistics_dialog.cpp lacks the implementation of the
> > getTreeAsString(st_format_type format) virtual method.
> 
> While I agree it lacks the implementation, should the parent class's
> TapParameterDialog::getTreeAsString cover it?  It don't know Qt enough to
> know why that logic isn't iterating over the whole tree/list.

Maybe because it is not making any assumption on the way the data is stored
(which looks sane to me).

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13952] MRCPv2 not decoded correctly

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13952

--- Comment #3 from Gerrit Code Review  ---
Change 23012 had a related patch set uploaded by Dario Lombardo:
mrcpv2: fix bug in use of ws_strtou32.

https://code.wireshark.org/review/23012

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

--- Comment #2 from Jaap Keuter  ---
Oh, this is rather interesting. You've got a NEC phone going through a DHCP
relay to a DHCP server where this was captured. Can you tell which type of
phone it is, on what VoIP platform? Maybe we can add some heuristic to find out
that this option has to be treated differently in this context.

What service is provided at 192.168.205.52 (as found in text in the undissected
option)?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 13953] Dissection of DHCP Option 43 falsely reporting error on suboption

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13953

Alexis La Goutte  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||alexis.lagou...@gmail.com
 Status|UNCONFIRMED |CONFIRMED

--- Comment #1 from Alexis La Goutte  ---
Hi Kenneth,

Your phone is a Alcatel Lucent phone ?
Because i think, there is a weak heuristic for Alcatel Lucent 43 Option
You can disable the heuristic on Analyze -> Enabled Protocols

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe