---

Hej !

På mit lille hjemmenetværk har jeg to næsten ens W98 maskiner koblet på
nettet gennem en 3Com 891 router. Tingene fungerer sådann set Ok, men i ca.
20 % af opkaldene får routeren ikke "fat" i min udbyder (jeg bruger TD).
Boksen forsøger at kalde op, men B1 og B2-dioderne ender med at stå og
blinke. Dette skulle ifølge manualen betyde "dårlig linje". Det sjove er, at
med mit tidligere No-name ISDN _modem_ var der ingen problemer - derfor er
jeg skeptisk.

Tele Danmark har beredvilligt testet linjen til og med NT-boksen uden at
finde fejl.

Desuden er der lavet en måling over længere tid (DLM-måling tror jeg det
hedder), hvor jeg samtidig skulle registerere de fejlende opkald. Her blev
der heller ikke fundet noget unormalt, og ydermere kunne man se, at
forbindelsen fra routeren til centralen var koblet op - mystisk.

De "blinkende lygter" ophører efter 60 sekunder (når routeren smider røret
igen - som jeg har bedt den om) - herefter kan jeg som regel koble op uden
problemer. Når først forbindelsen er der, er den stabil og hastigheden OK,
men hvis forbindelsen kobles ned i en session pga. "inactivity" kan
problemet opstå igen - irriterende, hvis man er i gang med home-banking
eller lignende !.

Når jeg har "blinkende lygter" kan jeg browse til routeren, og se at den
også mener, at opkaldet er i gang. En DOS netstat på den tilsluttede PC
"hænger" så længe fænomenet optræder.

TD's eneste forslag har været "prøv andet udstyr og se om problemet stadig
er der" - meen før jeg gør det ville jeg lige høre her ...

Alle gode råd modtages med tak !

//Per

---

> Alle gode råd modtages med tak !

Har du prøvet med en ny firmware ?

---

>Har du prøvet med en ny firmware ?
>
Yep, installationsproceduren ender på 3Coms web-site hvor man kan hente et
nyt FW-image.
Det hjalp ikke , så nu har den fået kniven ( = factory settings). Så
starter vi der ...

//Per

---

"Per Tolbøll" <per_tolboll@mail.dk> skrev i en meddelelse
news:3c1e27b3$0$93432$edfadb0f@dspool01.news.tele.dk...
> Boksen forsøger at kalde op, men B1 og B2-dioderne ender med at stå og
> blinke. Dette skulle ifølge manualen betyde "dårlig linje". Det sjove
er, at
> med mit tidligere No-name ISDN _modem_ var der ingen problemer -
derfor er
> jeg skeptisk.

Tyder på fejl på højere lag
Har du noget PPP-log?

--
Martin Højriis Kristensen - http://www.makr.dk/?usenet
http://www.makr.dk/?javaspil - Underholdning for folket
Jeg repræsenterer med dette indlæg mig selv og ikke TDC Internet

---

>Tyder på fejl på højere lag
>Har du noget PPP-log?
>
- Jeg troede faktisk ikke at dimsen kunne sådan noget, men jeg prøvede for
sjov at telnette til den - og sandelig: der findes et totalt udokumenteret
telnet-interface, incl et "3com-only" med masser af log-muligheder, på alt
fra enkelte LAN/WAN-pakker og opad derfra. Gode ideer til, hvad jeg skal
kigge efter ?.

PS: En google-søgning på 3c891 + telnet gav ikke bid. Ligger nogen inde med
bare lidt på skrift om mulighederne

----
//Per

---

"Per Tolbøll" <per_tolboll@mail.dk> skrev i en meddelelse
news:3c1e6ad3$1$52955$edfadb0f@dspool01.news.tele.dk...
> >Tyder på fejl på højere lag
> >Har du noget PPP-log?
> fra enkelte LAN/WAN-pakker og opad derfra. Gode ideer til, hvad jeg
skal
> kigge efter ?.

ja, PPP-log ville jeg mene var det interessante.
Hvis det var linjeforhandlingen der fejlede ville det være noget q.931
trace

--
Martin Højriis Kristensen - http://www.makr.dk/?usenet
http://www.makr.dk/?javaspil - Underholdning for folket
Jeg repræsenterer med dette indlæg mig selv og ikke TDC Internet

---

> Ligger nogen inde med
> bare lidt på skrift om mulighederne

http://www.hal-pc.org/~wdg/OCLM.html

---

JH skrev i meddelelsen ...
>> Ligger nogen inde med
>> bare lidt på skrift om mulighederne
>
>http://www.hal-pc.org/~wdg/OCLM.html
>

Yes ! - Lige hvad jeg manglede. Så skal der pilles !!!

//Per

---

>
>Tyder på fejl på højere lag
>Har du noget PPP-log?
>
Det har jeg fået nu - så vidt jeg kunne tyde er det ISP-enden, der gør vold
på protokollen i forbindelse med forhandlinger om kompressionsalgoritmen.
Jeg har samlet to eksempler, et hvor det går godt og et der fejler.

Har dette interesse for en bredere kreds (og kan nogen tyde sådan en
PPP-log) eller skal jeg smide i hovedet på en TDC-supporter ?

----
//Per

---

On Tue, 18 Dec 2001 23:21:23 +0100, Per Tolbøll wrote:
>>
>>Tyder på fejl på højere lag
>>Har du noget PPP-log?
>>
> Det har jeg fået nu - så vidt jeg kunne tyde er det ISP-enden, der gør vold
> på protokollen i forbindelse med forhandlinger om kompressionsalgoritmen.
> Jeg har samlet to eksempler, et hvor det går godt og et der fejler.
>
> Har dette interesse for en bredere kreds (og kan nogen tyde sådan en
> PPP-log) eller skal jeg smide i hovedet på en TDC-supporter ?

Prøv at poste den her.

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jesper Skriver skrev i meddelelsen ...

>Prøv at poste den her.
>
>--

OK - her er et fejlet mail-opkald (til mail.tele.dk)
Jeg har efter bedste evne forsøgt at dekode protokollerne, efter et par
timers selvstudium af diverse RFC'er.
Jeg er derfor ikke sikker på, at mine tolkninger er rigtige
Til sammenligning har jeg et vellykket opkald også, kan postes på
forlangende.

//Per

+++ Log start +++

Dumping Event Log...
Product ID: 3C891
Serial Number: X1LD859034
Ethernet Address: 08-00-4E-85-90-34
Software Version: 6.2.1, Check Sum: 0xCEC5
Boot Version: 6.0.0, Check Sum: 0x2E00
Profile Version: 2.72, Profile Length: 9584
Date: 2001/12/18, Time:19:52:11
Time (since last reset): 76176 seconds
Enabled Modules: ct ppp
CT :65356:DNS req (CallDown) RmId=0,Source_Ip=c0a80102
CT :65356:Contents:30 bytes:
00 01 01 00 00 01 00 00 00 00 00 00 04 6d 61 69 | ^^^^^^^^^^^^^mai
6c 04 74 65 6c 65 02 64 6b 00 00 01 00 01 | l^tele^dk^^^^^
CT :65356:Client <2500> Call SETUP req for RmId=0,Alter_Multi=0
CT :65356:Send Call SETUP to CC for RmId=0,rate=64,calltype=2
CT :65356:Called Party Number: 63130170
CT :65357:TEI Assignment Request: SAPI=0,LCN=0 L1=0 (cm_sysprof.tei=-1)
CT :65357:Layer1 Activation Request
MAINT :65358:BRI is activated.
CT :65358:TEI Assignment Request: SAPI=0,LCN=0 L1=1 (cm_sysprof.tei=-1)
CT :65359:TEI Assigned TEI=76,SAPI=0,LCN=0
CT :65359:Layer2 Established LCN=0
CT :65363:SR rcvd CC Conn: magic=0xffff8001,Bchan=0
CT :65363:SR send Est Req to PPP: RmId=0,Bchan=0
PP :65363:ppp - Link Est req rcvd from SR
PP :65363:ppp - Link est req for Bch 0,Rid 0
PP :65363:MP - Map:0,ch0:0,last:0,ch1:0,last:0,Calls:0
PP :65363:MP - Init.. ch:0
PP :65363:MP - Map:0,ch0:0,last:0,ch1:0,last:0,Calls:0
PP :65363:ppp - rcvd a link up event for Ch:0
PP :65363:
PP :65363:===>>> Sending Packet to WAN <<====
PP :65363:______ Length :37,Ch :0 ______
PP :65363:______ Buffer :176dd0,rptr :19cbc0,wptr :19cbe5 cnt :37
PP :65363:______ Buf hex dump :37 bytes:

LCP; Configure request, ID=1, 0x21 bytes

ff 03 c0 21 01 01 00 21 01 04 05 dc 05 06 00 00 | ^^^!^^^!^^^^^^^^
54 e2 11 04 05 dc 12 02 13 09 03 08 00 4e 85 90 | T^^^^^^^^^^^^N^^
34 17 04 00 00 | 4^^^^
PP :65363:
PP :65364:
PP :65364:===>>> Packet received from WAN <<====
PP :65364:Routepacket - ptr:177628,len:24,stack:255,unit:0
PP :65364:______ Protocol is c021 ______
PP :65364:______ Length :24,Ch :0 ______
PP :65364:______ Buffer :177628,rptr :19f0f4,wptr :19f10c cnt :24
PP :65364:______ Buf hex dump :24 bytes:

LCP; Configure request, ID=a8, 0x18 bytes

01 a8 00 18 03 05 c2 23 05 05 06 d1 c0 9f 33 11 | ^^^^^^^#^^^^^^3^
04 05 f4 13 05 01 4f 44 | ^^^^^^OD
PP :65364:
PP :65364:fsm - fsm state 6,Code 1
PP :65364:
PP :65364:===>>> Sending Packet to WAN <<====
PP :65364:______ Length :28,Ch :0 ______
PP :65364:______ Buffer :177628,rptr :19f0f0,wptr :19f10c cnt :28
PP :65364:______ Buf hex dump :28 bytes:

LCP; Configure ack, ID=a8, 0x18 bytes

ff 03 c0 21 02 a8 00 18 03 05 c2 23 05 05 06 d1 | ^^^!^^^^^^^#^^^^
c0 9f 33 11 04 05 f4 13 05 01 4f 44 | ^^3^^^^^^^OD
PP :65364:
PP :65364:
PP :65364:===>>> Packet received from WAN <<====
PP :65364:Routepacket - ptr:177790,len:10,stack:255,unit:0
PP :65364:______ Protocol is c021 ______
PP :65364:______ Length :10,Ch :0 ______
PP :65364:______ Buffer :177790,rptr :1a27a4,wptr :1a27ae cnt :10
PP :65364:______ Buf hex dump :10 bytes:

LCP; COnfigure REJECT !, ID=01, 0x0a bytes

04 01 00 0a 12 02 17 04 00 00 | ^^^^^^^^^^

PP :65364:
PP :65364:fsm - fsm state 8,Code 4
PP :65364:
PP :65364:===>>> Sending Packet to WAN <<====
PP :65364:______ Length :31,Ch :0 ______
PP :65364:______ Buffer :177790,rptr :1a27a0,wptr :1a27bf cnt :31
PP :65364:______ Buf hex dump :31 bytes:

LCP; Configure request, ID=02, 0x21 bytes

ff 03 c0 21 01 02 00 1b 01 04 05 dc 05 06 00 00 | ^^^!^^^^^^^^^^^^
54 e2 11 04 05 dc 13 09 03 08 00 4e 85 90 34 | T^^^^^^^^^^N^^4
PP :65364:
PP :65364:
PP :65364:===>>> Packet received from WAN <<====
PP :65364:Routepacket - ptr:176a58,len:27,stack:255,unit:0
PP :65364:______ Protocol is c021 ______
PP :65364:______ Length :27,Ch :0 ______
PP :65364:______ Buffer :176a58,rptr :19b92c,wptr :19b947 cnt :27
PP :65364:______ Buf hex dump :27 bytes:

LCP; Configure ack, ID=2, 0x1b bytes

02 02 00 1b 01 04 05 dc 05 06 00 00 54 e2 11 04 | ^^^^^^^^^^^^T^^^
05 dc 13 09 03 08 00 4e 85 90 34 | ^^^^^^^N^^4
PP :65364:
PP :65364:fsm - fsm state 8,Code 2
PP :65364:fsm - setting state to opened 1
PP :65364:LCP - add comp got :0 his :0,pcom got: 0 his: 0
PP :65364:
PP :65364:===>>> Packet received from WAN <<====
PP :65364:Routepacket - ptr:177328,len:23,stack:255,unit:0
PP :65364:______ Protocol is c223 ______
PP :65364:______ Length :23,Ch :0 ______
PP :65364:______ Buffer :177328,rptr :1a0044,wptr :1a005b cnt :23
PP :65364:______ Buf hex dump :23 bytes:

CHAP, Challenge, ID=cd, 0x17 bytes

01 cd 00 17 10 6c e0 dc 8e 07 ac e6 a5 75 f7 5d | ^^^^^l^^^^^^^u^]
ae 7c fe 24 d3 4f 44 | ^|^$^OD
PP :65364:
PP :65364:
PP :65364:===>>> Sending Packet to WAN <<====
PP :65364:______ Length :37,Ch :0 ______
PP :65364:______ Buffer :177328,rptr :1a0040,wptr :1a0065 cnt :37
PP :65364:______ Buf hex dump :37 bytes:

CHAP, Response, ID=cd, 0x21 bytes

ff 03 c2 23 02 cd 00 21 10 d8 20 b7 e9 8d 98 14 | ^^^#^^^!^^ ^^^^^
af 04 90 fc 2e 94 19 d4 b2 31 32 30 30 31 30 33 | ^^^^.^^^^1200103
35 35 39 38 38 | 55988
PP :65364:
PP :65367:
PP :65367:===>>> Packet received from WAN <<====
PP :65367:Routepacket - ptr:1768a8,len:4,stack:255,unit:0
PP :65367:______ Protocol is c223 ______
PP :65367:______ Length :4,Ch :0 ______
PP :65367:______ Buffer :1768a8,rptr :19f66c,wptr :19f670 cnt :4
PP :65367:______ Buf hex dump :4 bytes:

CHAP, Succes, ID=cd, 0x04 bytes

03 cd 00 04 | ^^^^
PP :65367:
PP :65367:MP - Map:0,ch0:1,last:0,ch1:0,last:0,Calls:1
PP :65367:BACP - rcvd a lowerdown <0>
PP :65367:MP: Sending on link 0
PP :65367:
PP :65367:===>>> Sending Packet to WAN <<====
PP :65367:______ Length :32,Ch :0 ______
PP :65367:______ Buffer :177628,rptr :19f0f0,wptr :19f0fa cnt :10
PP :65367:______ Buf hex dump :10 bytes:

Proto: 003d, Multilink first/last packet, IPCP config request, ID=1 0x16
bytes
Request for IP address

ff 03 00 3d c0 00 00 00 80 21 | ^^^=^^^^^!
PP :65367:______ Buffer :1768a8,rptr :19f668,wptr :19f67e cnt :22
PP :65367:______ Buf hex dump :22 bytes:
01 01 00 16 03 06 00 00 00 00 81 06 00 00 00 00 | ^^^^^^^^^^^^^^^^
83 06 00 00 00 00 | ^^^^^^

PP :65367:
PP :65367:DCOMP - initialising history :0
PP :65367:MP: Sending on link 0
PP :65367:
PP :65367:===>>> Sending Packet to WAN <<====
PP :65367:______ Length :19,Ch :0 ______
PP :65367:______ Buffer :177718,rptr :1a10a8,wptr :1a10b2 cnt :10
PP :65367:______ Buf hex dump :10 bytes:

Proto: 003d, Multilink first/last packet, IPCP config request, ID=1 0x09
bytes
Request for Stac compression

ff 03 00 3d c0 00 00 01 80 fd | ^^^=^^^^^^
PP :65367:______ Buffer :176b90,rptr :19af50,wptr :19af59 cnt :9
PP :65367:______ Buf hex dump :9 bytes:
01 01 00 09 11 05 00 01 03 | ^^^^^^^^^
PP :65367:
PP :65368:
PP :65368:===>>> Packet received from WAN <<====
PP :65368:Routepacket - ptr:176b18,len:10,stack:0,unit:0
PP :65368:______ Protocol is 8021 ______
PP :65368:______ Length :10,Ch :0 ______
PP :65368:______ Buffer :176b18,rptr :19c304,wptr :19c30e cnt :10
PP :65368:______ Buf hex dump :10 bytes:

IPCP config request, ID=1, 0x0a bytes
My IP address is: c3 f9 00 54

01 01 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65368:
PP :65368:fsm - fsm state 6,Code 1
PP :65369:MP: Sending on link 0
PP :65369:
PP :65369:===>>> Sending Packet to WAN <<====
PP :65369:______ Length :20,Ch :0 ______
PP :65369:______ Buffer :1768a8,rptr :19f668,wptr :19f672 cnt :10
PP :65369:______ Buf hex dump :10 bytes:

IPCP config reply, ID=1, 0x0a bytes
Your IP address is c3 f9 00 54

ff 03 00 3d c0 00 00 02 80 21 | ^^^=^^^^^!
PP :65369:______ Buffer :177718,rptr :1a10a8,wptr :1a10b2 cnt :10
PP :65369:______ Buf hex dump :10 bytes:
02 01 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65369:
PP :65369:
PP :65369:===>>> Packet received from WAN <<====
PP :65369:Routepacket - ptr:1774d8,len:10,stack:0,unit:0
PP :65369:______ Protocol is 80fd ______
PP :65369:______ Length :10,Ch :0 ______
PP :65369:______ Buffer :1774d8,rptr :19d024,wptr :19d02e cnt :10
PP :65369:______ Buf hex dump :10 bytes:

Request for Microsoft PPC compression ?

01 01 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^
PP :65369:
PP :65369:fsm - fsm state 6,Code 1
PP :65369:MP: Sending on link 0
PP :65369:
PP :65369:===>>> Sending Packet to WAN <<====
PP :65369:______ Length :20,Ch :0 ______
PP :65369:______ Buffer :177718,rptr :1a10a8,wptr :1a10b2 cnt :10
PP :65369:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 03 80 fd | ^^^=^^^^^^
PP :65369:______ Buffer :1774d8,rptr :19d020,wptr :19d02a cnt :10
PP :65369:______ Buf hex dump :10 bytes:

Reject Microsoft PPC ?

04 01 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^

PP :65369:
PP :65388:

Her går det galt !

PP :65388:===>>> Packet received from WAN <<====
PP :65388:Routepacket - ptr:177028,len:10,stack:0,unit:0
PP :65388:______ Protocol is 8021 ______
PP :65388:______ Length :10,Ch :0 ______
PP :65388:______ Buffer :177028,rptr :19b6fc,wptr :19b706 cnt :10
PP :65388:______ Buf hex dump :10 bytes:
01 02 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65388:
PP :65388:fsm - fsm state 8,Code 1
PP :65388:MP: Sending on link 0
PP :65388:
PP :65388:===>>> Sending Packet to WAN <<====
PP :65388:______ Length :20,Ch :0 ______
PP :65388:______ Buffer :1768a8,rptr :19f668,wptr :19f672 cnt :10
PP :65388:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 04 80 21 | ^^^=^^^^^!
PP :65388:______ Buffer :177718,rptr :19b6f8,wptr :19b702 cnt :10
PP :65388:______ Buf hex dump :10 bytes:
02 02 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65388:
PP :65388:
PP :65389:===>>> Packet received from WAN <<====
PP :65389:Routepacket - ptr:176dd0,len:10,stack:0,unit:0
PP :65389:______ Protocol is 80fd ______
PP :65389:______ Length :10,Ch :0 ______
PP :65389:______ Buffer :176dd0,rptr :19cbc4,wptr :19cbce cnt :10
PP :65389:______ Buf hex dump :10 bytes:
01 02 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^
PP :65389:
PP :65389:fsm - fsm state 6,Code 1
PP :65389:MP: Sending on link 0
PP :65389:
PP :65389:===>>> Sending Packet to WAN <<====
PP :65389:______ Length :20,Ch :0 ______
PP :65389:______ Buffer :1768a8,rptr :19f668,wptr :19f672 cnt :10
PP :65389:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 05 80 fd | ^^^=^^^^^^
PP :65389:______ Buffer :176dd0,rptr :19cbc0,wptr :19cbca cnt :10
PP :65389:______ Buf hex dump :10 bytes:
04 02 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^
PP :65389:
PP :65390:MP: Sending on link 0
PP :65390:
PP :65390:===>>> Sending Packet to WAN <<====
PP :65390:______ Length :32,Ch :0 ______
PP :65390:______ Buffer :1768a8,rptr :19f668,wptr :19f672 cnt :10
PP :65390:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 06 80 21 | ^^^=^^^^^!
PP :65390:______ Buffer :176dd0,rptr :19cbc0,wptr :19cbd6 cnt :22
PP :65390:______ Buf hex dump :22 bytes:
01 01 00 16 03 06 00 00 00 00 81 06 00 00 00 00 | ^^^^^^^^^^^^^^^^
83 06 00 00 00 00 | ^^^^^^
PP :65390:
PP :65409:
PP :65409:===>>> Packet received from WAN <<====
PP :65409:Routepacket - ptr:177580,len:10,stack:0,unit:0
PP :65409:______ Protocol is 8021 ______
PP :65409:______ Length :10,Ch :0 ______
PP :65409:______ Buffer :177580,rptr :1a524c,wptr :1a5256 cnt :10
PP :65409:______ Buf hex dump :10 bytes:
01 03 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65409:
PP :65409:fsm - fsm state 8,Code 1
PP :65409:MP: Sending on link 0
PP :65409:
PP :65409:===>>> Sending Packet to WAN <<====
PP :65409:______ Length :20,Ch :0 ______
PP :65409:______ Buffer :177718,rptr :19b6f8,wptr :19b702 cnt :10
PP :65409:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 07 80 21 | ^^^=^^^^^!
PP :65409:______ Buffer :1768a8,rptr :1a5248,wptr :1a5252 cnt :10
PP :65409:______ Buf hex dump :10 bytes:
02 03 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65409:
PP :65409:
PP :65409:===>>> Packet received from WAN <<====
PP :65409:Routepacket - ptr:177790,len:10,stack:0,unit:0
PP :65409:______ Protocol is 80fd ______
PP :65409:______ Length :10,Ch :0 ______
PP :65409:______ Buffer :177790,rptr :1a27a4,wptr :1a27ae cnt :10
PP :65409:______ Buf hex dump :10 bytes:
01 03 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^
PP :65409:
PP :65409:fsm - fsm state 6,Code 1
PP :65409:MP: Sending on link 0
PP :65409:
PP :65409:===>>> Sending Packet to WAN <<====
PP :65409:______ Length :20,Ch :0 ______
PP :65409:______ Buffer :177718,rptr :19b6f8,wptr :19b702 cnt :10
PP :65409:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 08 80 fd | ^^^=^^^^^^
PP :65409:______ Buffer :177790,rptr :1a27a0,wptr :1a27aa cnt :10
PP :65409:______ Buf hex dump :10 bytes:
04 03 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^
PP :65409:
PP :65420:MP: Sending on link 0
PP :65420:
PP :65420:===>>> Sending Packet to WAN <<====
PP :65420:______ Length :32,Ch :0 ______
PP :65420:______ Buffer :177220,rptr :19b6f8,wptr :19b702 cnt :10
PP :65420:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 09 80 21 | ^^^=^^^^^!
PP :65420:______ Buffer :177718,rptr :1a29d0,wptr :1a29e6 cnt :22
PP :65420:______ Buf hex dump :22 bytes:
01 01 00 16 03 06 00 00 00 00 81 06 00 00 00 00 | ^^^^^^^^^^^^^^^^
83 06 00 00 00 00 | ^^^^^^
PP :65420:
PP :65429:
PP :65429:===>>> Packet received from WAN <<====
PP :65429:Routepacket - ptr:176a58,len:10,stack:0,unit:0
PP :65429:______ Protocol is 8021 ______
PP :65429:______ Length :10,Ch :0 ______
PP :65429:______ Buffer :176a58,rptr :19b92c,wptr :19b936 cnt :10
PP :65429:______ Buf hex dump :10 bytes:
01 04 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65429:
PP :65429:fsm - fsm state 8,Code 1
PP :65429:MP: Sending on link 0
PP :65429:
PP :65429:===>>> Sending Packet to WAN <<====
PP :65429:______ Length :20,Ch :0 ______
PP :65429:______ Buffer :1768a8,rptr :1a5248,wptr :1a5252 cnt :10
PP :65429:______ Buf hex dump :10 bytes:
ff 03 00 3d c0 00 00 0a 80 21 | ^^^=^^^^^!
PP :65429:______ Buffer :176a58,rptr :19b928,wptr :19b932 cnt :10
PP :65429:______ Buf hex dump :10 bytes:
02 04 00 0a 03 06 c3 f9 00 54 | ^^^^^^^^^T
PP :65429:
PP :65429:
PP :65429:===>>> Packet received from WAN <<====
PP :65429:Routepacket - ptr:177328,len:10,stack:0,unit:0
PP :65429:______ Protocol is 80fd ______
PP :65429:______ Length :10,Ch :0 ______
PP :65429:______ Buffer :177328,rptr :1a0044,wptr :1a004e cnt :10
PP :65429:______ Buf hex dump :10 bytes:
01 04 00 0a 12 06 00 00 00 01 | ^^^^^^^^^^

+++ Log stop +++

---

On Wed, 19 Dec 2001 21:02:21 +0100, Per Tolbøll wrote:
>
> Jesper Skriver skrev i meddelelsen ...
>
>>Prøv at poste den her.
>
> OK - her er et fejlet mail-opkald (til mail.tele.dk)
> Jeg har efter bedste evne forsøgt at dekode protokollerne, efter et par
> timers selvstudium af diverse RFC'er.
> Jeg er derfor ikke sikker på, at mine tolkninger er rigtige
> Til sammenligning har jeg et vellykket opkald også, kan postes på
> forlangende.

Jeg har ikke lige overskud til at dekode det - og en TD@ supporter
vil sikkert ikke forstå noget - hvis det er et generelt problem
med den adapter, så kan TD@ lave en test sammen med de af mine
kolleger som har ansvaret for dial-in kasserne, og så kan de
debugge PPP forhandlingen på Cisco kasserne, hvor debug output'et
kommer i langt mere forståeligt format.

mvh
Jesper

--
Jesper Skriver, CCIE #5456
FreeBSD committer

---

Jeg havde lige samme problem med mit 3C891 og Tiscali. Første gang den
kalder op er der forbindelse i få sekunder og så er forbindelsen væk selv om
der er et opkald. Jeg må så lukke den ned manuelt og kalde op igen manuelt
eller automatisk og så virker det fint igen. Indtil den timer out næste
gang.

Men jeg har ingen løsning på det.
Jeg har skiftet det ud til et Diva lan modem, der var simpelthen så mange
ting som ikke virkede på det.

--
mvh
Thomas


"Per Tolbøll" <per_tolboll@mail.dk> skrev i en meddelelse
news:3c1e27b3$0$93432$edfadb0f@dspool01.news.tele.dk...
> Hej !
>
> På mit lille hjemmenetværk har jeg to næsten ens W98 maskiner koblet på
> nettet gennem en 3Com 891 router. Tingene fungerer sådann set Ok, men i
ca.
> 20 % af opkaldene får routeren ikke "fat" i min udbyder (jeg bruger TD).
> Boksen forsøger at kalde op, men B1 og B2-dioderne ender med at stå og
> blinke. Dette skulle ifølge manualen betyde "dårlig linje". Det sjove er,
at
> med mit tidligere No-name ISDN _modem_ var der ingen problemer - derfor er
> jeg skeptisk.
>
> Tele Danmark har beredvilligt testet linjen til og med NT-boksen uden at
> finde fejl.
>
> Desuden er der lavet en måling over længere tid (DLM-måling tror jeg det
> hedder), hvor jeg samtidig skulle registerere de fejlende opkald. Her blev
> der heller ikke fundet noget unormalt, og ydermere kunne man se, at
> forbindelsen fra routeren til centralen var koblet op - mystisk.
>
> De "blinkende lygter" ophører efter 60 sekunder (når routeren smider røret
> igen - som jeg har bedt den om) - herefter kan jeg som regel koble op uden
> problemer. Når først forbindelsen er der, er den stabil og hastigheden OK,
> men hvis forbindelsen kobles ned i en session pga. "inactivity" kan
> problemet opstå igen - irriterende, hvis man er i gang med home-banking
> eller lignende !.
>
> Når jeg har "blinkende lygter" kan jeg browse til routeren, og se at den
> også mener, at opkaldet er i gang. En DOS netstat på den tilsluttede PC
> "hænger" så længe fænomenet optræder.
>
> TD's eneste forslag har været "prøv andet udstyr og se om problemet stadig
> er der" - meen før jeg gør det ville jeg lige høre her ...
>
> Alle gode råd modtages med tak !
>
> //Per
>
>

---

Jeg har samme problem (og det er ski.. irreterende), og jeg kalder op til
CC, så hvis du finder en løsning så er jeg MEGET interesseret. !!

"Per Tolbøll" <per_tolboll@mail.dk> wrote in message
news:3c1e27b3$0$93432$edfadb0f@dspool01.news.tele.dk...
> Hej !
>
> På mit lille hjemmenetværk har jeg to næsten ens W98 maskiner koblet på
> nettet gennem en 3Com 891 router. Tingene fungerer sådann set Ok, men i
ca.
> 20 % af opkaldene får routeren ikke "fat" i min udbyder (jeg bruger TD).
> Boksen forsøger at kalde op, men B1 og B2-dioderne ender med at stå og
> blinke. Dette skulle ifølge manualen betyde "dårlig linje". Det sjove er,
at
> med mit tidligere No-name ISDN _modem_ var der ingen problemer - derfor er
> jeg skeptisk.
>
> Tele Danmark har beredvilligt testet linjen til og med NT-boksen uden at
> finde fejl.
>
> Desuden er der lavet en måling over længere tid (DLM-måling tror jeg det
> hedder), hvor jeg samtidig skulle registerere de fejlende opkald. Her blev
> der heller ikke fundet noget unormalt, og ydermere kunne man se, at
> forbindelsen fra routeren til centralen var koblet op - mystisk.
>
> De "blinkende lygter" ophører efter 60 sekunder (når routeren smider røret
> igen - som jeg har bedt den om) - herefter kan jeg som regel koble op uden
> problemer. Når først forbindelsen er der, er den stabil og hastigheden OK,
> men hvis forbindelsen kobles ned i en session pga. "inactivity" kan
> problemet opstå igen - irriterende, hvis man er i gang med home-banking
> eller lignende !.
>
> Når jeg har "blinkende lygter" kan jeg browse til routeren, og se at den
> også mener, at opkaldet er i gang. En DOS netstat på den tilsluttede PC
> "hænger" så længe fænomenet optræder.
>
> TD's eneste forslag har været "prøv andet udstyr og se om problemet stadig
> er der" - meen før jeg gør det ville jeg lige høre her ...
>
> Alle gode råd modtages med tak !
>
> //Per
>
>