Ethereal-dev: Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.
From: Motonori Shindo <mshindo@xxxxxxxxxxx>
Date: Tue, 04 Dec 2001 15:01:00 +0900 (JST)
Hi, From: Motonori Shindo <mshindo@xxxxxxxxxxx> Subject: Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format Date: Tue, 04 Dec 2001 09:50:35 +0900 (JST) > I've finally come up with an idea, such that a lexer now treats 4 > consecutive white spaces as a token and if such a token is present, > the rest of any characters till end of line will be ignored by a > lexer. (snip) > If there's no objection, I will post a patch here shortly. A patch attached. I have tested a couple of Ascend/Lucent debug outputs (both in old and new format) and all worked well. Regars, =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--= +----+----+ |.. .| | Motonori Shindo |_~__| | | .. |~~_~| Sr. Systems Engineer | . | | CoSine Communications Inc. +----+----+ C o S i n e e-mail: mshindo@xxxxxxxxxxxxx Communications =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
Index: wiretap/ascend-grammar.y
===================================================================
RCS file: /cvsroot/ethereal/wiretap/ascend-grammar.y,v
retrieving revision 1.21
diff -u -r1.21 ascend-grammar.y
--- ascend-grammar.y 2001/11/13 23:55:42 1.21
+++ ascend-grammar.y 2001/12/04 04:24:29
@@ -64,7 +64,43 @@
RECV-187:(task: B0292CA0, time: 18042251.92) 16 octets @ 800018E8
[0000]: FF 03 C0 21 09 01 00 0C DE 61 96 4B 00 30 94 92
+ In TAOS 8.0, Lucent slightly changed the format as follows:
+ Example 'wandisp' output data (TAOS 8.0.3): (same format is used
+ for 'wanopen' and 'wannext' command)
+
+RECV-14: (task "idle task" at 0xb05e6e00, time: 1279.01) 29 octets @ 0x8000e0fc
+ [0000]: ff 03 c0 21 01 01 00 19 01 04 05 f4 11 04 05 f4 ...!.... ........
+ [0010]: 13 09 03 00 c0 7b 9a 9f 2d 17 04 10 00 .....{.. -....
+XMIT-14: (task "idle task" at 0xb05e6e00, time: 1279.02) 38 octets @ 0x8007fd56
+ [0000]: ff 03 c0 21 01 01 00 22 00 04 00 00 01 04 05 f4 ...!..." ........
+ [0010]: 03 05 c2 23 05 11 04 05 f4 13 09 03 00 c0 7b 80 ...#.... ......{.
+ [0020]: 7c ef 17 04 0e 00 |.....
+XMIT-14: (task "idle task" at 0xb05e6e00, time: 1279.02) 29 octets @ 0x8007fa36
+ [0000]: ff 03 c0 21 02 01 00 19 01 04 05 f4 11 04 05 f4 ...!.... ........
+ [0010]: 13 09 03 00 c0 7b 9a 9f 2d 17 04 10 00 .....{.. -....
+
+ Example 'wandsess' output data (TAOS 8.0.3):
+
+RECV-Max7:20: (task "_brouterControlTask" at 0xb094ac20, time: 1481.50) 20 octets @ 0x8000d198
+ [0000]: ff 03 00 3d c0 00 00 04 80 fd 02 01 00 0a 11 06 ...=.... ........
+ [0010]: 00 01 01 03 ....
+XMIT-Max7:20: (task "_brouterControlTask" at 0xb094ac20, time: 1481.51) 26 octets @ 0x800806b6
+ [0000]: ff 03 00 3d c0 00 00 00 80 21 01 01 00 10 02 06 ...=.... .!......
+ [0010]: 00 2d 0f 01 03 06 89 64 03 08 .-.....d ..
+XMIT-Max7:20: (task "_brouterControlTask" at 0xb094ac20, time: 1481.51) 20 octets @ 0x8007f716
+ [0000]: ff 03 00 3d c0 00 00 01 80 fd 01 01 00 0a 11 06 ...=.... ........
+ [0010]: 00 01 01 03 ....
+
+ The changes since TAOS 7.X are:
+
+ 1) White space is added before "(task".
+ 2) Task has a name, indicated by a subsequent string surrounded by a
+ double-quote.
+ 3) Address expressed in hex number has a preceeding "0x".
+ 4) Hex numbers are in lower case.
+ 5) There is a character display corresponding to hex data in each line.
+
*/
#ifdef HAVE_CONFIG_H
@@ -114,7 +150,9 @@
data_packet:
| wds_hdr datagroup
- | wds7_hdr datagroup
+ | wds8_hdr datagroup
+ | wdp7_hdr datagroup
+ | wdp8_hdr datagroup
| wdd_date wdd_hdr datagroup
| wdd_hdr datagroup
;
@@ -152,10 +190,34 @@
}
;
+/* RECV-Max7:20: (task "_brouterControlTask" at 0xb094ac20, time: 1481.50) 20 octets @ 0x8000d198 */
+/* 1 2 3 4 5 6 7 8 9 10 11 12 13 */
+wds8_hdr: wds_prefix string decnum KEYWORD string KEYWORD hexnum KEYWORD decnum decnum decnum KEYWORD HEXNUM {
+ wirelen = $11;
+ caplen = ($11 < ASCEND_MAX_PKT_LEN) ? $11 : ASCEND_MAX_PKT_LEN;
+ /* If we don't have as many bytes of data as the octet count in
+ the header, make the capture length the number of bytes we
+ actually have. */
+ if (bcount > 0 && bcount <= caplen)
+ caplen = bcount;
+ secs = $9;
+ usecs = $10;
+ if (pseudo_header != NULL) {
+ /* pseudo_header->user is set in ascend-scanner.l */
+ pseudo_header->type = $1;
+ pseudo_header->sess = $3;
+ pseudo_header->call_num[0] = '\0';
+ pseudo_header->chunk = 0;
+ pseudo_header->task = $7;
+ }
+
+ bcur = 0;
+}
+;
/* RECV-187:(task: B050B480, time: 18042248.03) 100 octets @ 800012C0 */
/* 1 2 3 4 5 6 7 8 9 10 */
-wds7_hdr: wds_prefix decnum KEYWORD hexnum KEYWORD decnum decnum decnum KEYWORD HEXNUM {
+wdp7_hdr: wds_prefix decnum KEYWORD hexnum KEYWORD decnum decnum decnum KEYWORD HEXNUM {
wirelen = $8;
caplen = ($8 < ASCEND_MAX_PKT_LEN) ? $8 : ASCEND_MAX_PKT_LEN;
/* If we don't have as many bytes of data as the octet count in
@@ -172,6 +234,31 @@
pseudo_header->call_num[0] = '\0';
pseudo_header->chunk = 0;
pseudo_header->task = $4;
+ }
+
+ bcur = 0;
+}
+;
+
+/* XMIT-44: (task "freedm_task" at 0xe051fd10, time: 6258.66) 29 octets @ 0x606d1f00 */
+/* 1 2 3 4 5 6 7 8 9 10 11 12 */
+wdp8_hdr: wds_prefix decnum KEYWORD string KEYWORD hexnum KEYWORD decnum decnum decnum KEYWORD HEXNUM {
+ wirelen = $10;
+ caplen = ($10 < ASCEND_MAX_PKT_LEN) ? $10 : ASCEND_MAX_PKT_LEN;
+ /* If we don't have as many bytes of data as the octet count in
+ the header, make the capture length the number of bytes we
+ actually have. */
+ if (bcount > 0 && bcount <= caplen)
+ caplen = bcount;
+ secs = $8;
+ usecs = $9;
+ if (pseudo_header != NULL) {
+ /* pseudo_header->user is set in ascend-scanner.l */
+ pseudo_header->type = $1;
+ pseudo_header->sess = $2;
+ pseudo_header->call_num[0] = '\0';
+ pseudo_header->chunk = 0;
+ pseudo_header->task = $6;
}
bcur = 0;
Index: wiretap/ascend-scanner.l
===================================================================
RCS file: /cvsroot/ethereal/wiretap/ascend-scanner.l,v
retrieving revision 1.21
diff -u -r1.21 ascend-scanner.l
--- ascend-scanner.l 2001/11/13 23:55:43 1.21
+++ ascend-scanner.l 2001/12/04 04:24:37
@@ -95,6 +95,8 @@
%s sc_wdd_chunknum
%s sc_wdd_type
+%s sc_chardisp
+
%%
<INITIAL,sc_gen_byte>{XPFX} {
@@ -117,7 +119,7 @@
unput(after); unput(colon);
- if (after != '(') {
+ if (after != '(' && after != ' ') {
BEGIN(sc_wds_sess);
if (pseudo_header != NULL) {
strncpy(pseudo_header->user, atcopy, ASCEND_MAX_STR_LEN);
@@ -141,12 +143,16 @@
return DECNUM;
}
-<sc_gen_task>{H}+ {
+<sc_gen_task>(0x|0X)?{H}+ {
BEGIN(sc_gen_time_s);
ascendlval.d = strtoul(ascendtext, NULL, 16);
return HEXNUM;
}
+<sc_gen_task>\"[A-Za-z0-9_ ]+\" {
+ return STRING;
+}
+
<sc_gen_time_s>{D}+ {
BEGIN(sc_gen_time_u);
ascendlval.d = strtol(ascendtext, NULL, 10);
@@ -181,6 +187,14 @@
return HEXBYTE;
}
+<sc_gen_byte>" "{4} {
+ BEGIN(sc_chardisp);
+}
+
+<sc_chardisp>.* {
+ BEGIN(sc_gen_byte);
+}
+
<INITIAL,sc_gen_byte>{WDD_DATE} {
BEGIN(sc_wdd_date_d);
return WDD_DATE;
@@ -256,11 +270,10 @@
BEGIN(sc_gen_task);
return KEYWORD;
}
-
-{H}+ { return HEXNUM; }
+(0x|0X)?{H}+ { return HEXNUM; }
-task:|time:|octets { return KEYWORD; }
+task:|task|at|time:|octets { return KEYWORD; }
<<EOF>> { at_eof++; yyterminate(); }
This message has been 'sanitized'. This means that potentially
dangerous content has been rewritten or removed. The following
log describes which actions were taken.
Sanitizer (start="1007446358"):
Replaced MIME boundary: >>--Next_Part--<<
with: >>MIMEStream=_0+160283_17274201515402_684835651<<
Writer (pos="1312"):
Total modifications so far: 1
Part (pos="1358"):
SanitizeFile (filename="unnamed.txt", mimetype="Text/Plain"):
Match (rule="2"):
Enforced policy: accept
Part (pos="2410"):
SanitizeFile (filename="ascend.diff", mimetype="Text/Plain"):
Match (rule="default"):
Enforced policy: accept
Anomy 0.0.0 : Sanitizer.pm
$Id: Sanitizer.pm,v 1.32 2001/10/11 19:27:15 bre Exp $
- Follow-Ups:
- References:
- Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- From: Hamish Moffatt
- Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- From: Motonori Shindo
- Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- From: Motonori Shindo
- Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- Prev by Date: Re: [Ethereal-dev] Help - configure won't build ethereal
- Next by Date: Re: [Ethereal-dev] Introducing additional capture-stop capabilities
- Previous by thread: Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- Next by thread: Re: [Ethereal-dev] Pls advise for supporting new Ascend/Lucent format
- Index(es):





