Guy Harris wrote:
No, because I don't have the Linux kernel source handy at present, but
what you want to do is edit net/core/dev.c, look for case
SIOCGIFHWADDR: somewhere around line 2362, and change the code to do
Actually, the existing code already refuses to copy more than sizeof
Hello Anders,
Here is the fragment from the ASN.1 specification for H.248.
TerminationStateDescriptor ::= SEQUENCE
{
propertyParms SEQUENCE OF PropertyParm,
eventBufferControl EventBufferControl OPTIONAL,
serviceStateServiceState OPTIONAL,
...
}
As I understand, SEQUENCE
This is a resend of a patch I sent September 8th, it seems to have been
misplaced somwhere ;)
/ Regards, Peter
---BeginMessage---
Hi,
the attached patch adds a missing inlude to packet-tcp.h
/ Regards, Peter
Index: C:/wireshark-win32-libs/epan/dissectors/packet-tcp.h
Hi,
Too bad, since the patch doesn't match RFC 4590 table 2.
Care to fix it?
Thanx,
Jaap
On Wed, 20 Sep 2006, Joerg Mayer wrote:
Did anyone fix this?
Committed revision 19266.
Thanks!
Joerg
___
Wireshark-dev mailing list
On Wed, Sep 20, 2006 at 04:27:43PM +0200, Jaap Keuter wrote:
Too bad, since the patch doesn't match RFC 4590 table 2.
Care to fix it?
The only thing I could do is to revert the patch. Should I do that?
Ciao
Joerg
--
Joerg Mayer [EMAIL PROTECTED]
Hi,
No need, already patched the patch ;)
Thanx,
Jaap
On Wed, 20 Sep 2006, Joerg Mayer wrote:
On Wed, Sep 20, 2006 at 04:27:43PM +0200, Jaap Keuter wrote:
Too bad, since the patch doesn't match RFC 4590 table 2.
Care to fix it?
The only thing I could do is to revert the patch. Should I
You nailed it Gilbert! My string value array was missing the last necessary record of :{ 0, NULL }wThe reason I removed it was because we identify a NOP command as 0x00. I put this final record in and I no longer get a run time fatal error and crash. It looks like my filters are working. My
Hi List!
It seems to be a common mistake to forget the terminating zero entry in a
value_string, I've done this myself before and it's hard to track it down if
you don't have a clue what's going wrong.
Even worse, this mistake might not make any problems for a long time as usually
the values
I believe we do this in the build-bot testing, by doing:
tshark -G values
Since that operation iterates across all the value_string arrays, a
non-terminated array will result in an error or at least it
should.
Is that enough testing?
--gilbert
On 9/20/06, Ulf Lamping [EMAIL PROTECTED]
Hello,
i have written a Parser for the Realtime Ethernet Protocol
EhterCAT devolped by
Beckhoff Automation GbmH as plugin in wireshark. I tested
the plugin with windows
and with the linux suse distribution.Information to EtheCAT can
be found on ethercat.org.
I would like this plugin
Hi,
Well, make it a regular dissector first, since you're going public anyway.
Then post a patch adding the dissector to the current tree.
Then duck for all the comments flying your way ;)
Thanx,
Jaap
On Wed, 20 Sep 2006, [iso-8859-1] Richard K?mmel wrote:
Hello,
i have written a Parser for
Bill Fassler wrote:
My concern now is
that the first and last entries are zero. Could this create any run
time problems?
{0x00, No Operation}
.
.
.
{0, NULL}
No, that won't cause a problem. It's the null string pointer that's the
key, not the 0 value.
Alas, I have arrived at the same place. If I understand MSVC's debugging function correctly (questionable), then it's crashing at an fgetline call in libwireshark.dll. libwireshark.dll!fgetline(char * * buf=0x0012fc20, int * size=0x0012fc1c, _iobuf * fp=0x77c5fce0) Line 588 + 0xa bytesC That's
On Wed, Sep 20, 2006 at 11:36:13AM -0700, Bill Fassler wrote:
Apparently my company has not yet officially registered their self
selected ethernet type designation with IANA (or whoever it is
supposed to be registered with). Can anyone give me some advice on
the least painful method of
Maybe I'm getting alittle closer here... It looks like fgetline is failing when it tries to read from the hosts file. The file pointer returned by eth_fopen(hostspath, "r") in the read_hosts_file function is bad. I don't understand why...hostspath is correct
Shelly Cadora wrote:
Maybe I'm getting a little closer here...
It looks like fgetline is failing when it tries to read from the hosts
file. The file pointer returned by eth_fopen(hostspath, r) in the
read_hosts_file function is bad.
Bad in what sense?
If it's null, the open failed -
Guy Harris [EMAIL PROTECTED] wrote:Shelly Cadora wrote: Maybe I'm getting a little closer here... It looks like fgetline is failing when it tries to read from the hosts file. The file pointer returned by eth_fopen(hostspath, "r") in the read_hosts_file function is bad."Bad" in what
I have a small request: Can http_dissector_add (from packet-http.c) be
added to libwireshark.def? I'm writing a dissector in a plugin, and I'd
like to use this function, but since that symbol isn't exported, I have
to make a new [custom] build of wireshark (which I'm trying to avoid)
for
Brian Vandenberg wrote:
As far as I can tell, basically, I can't use a heuristic dissector to
dissect anything http has already looked at if another dissector has
registered itself as a subdissector for the given port. Is that about
accurate?
Yes.
The same problem exists with TCP or
Hi,
The last time this was asked it was answered:
http://www.ethereal.com/lists/ethereal-dev/200604/msg00097.html
Hi,
There doesn't seem to be a coding rule within the Ethereal code base that
states that a header file itself must include the header files it depends
on. If it is we have a whole
20 matches
Mail list logo
