dpz@dorm.rutgers.edu (David P. Zimmerman) (11/22/88)
I've got the new CMU PC/IP distribution from husc6.harvard.edu (without docs, but who needs those anyway? :-), and have come to the conclusion that the WD8003 driver is spitting out random garbage onto the network. The PC/IP code works fine with the 3C501 (after I use the old NETDEV.SYS - the new one won't hang around in memory and let itself be used), and the WD8003 is very usable under NCSA Telnet and FTP Software's PC/TCP. My setup in NETDEV.SYS is normal. NCSA FTP has errors initializing the network, but I haven't looked into that yet. Peeking into the network shows me a really funny looking packet coming out. I use PING.EXE to bounce an ICMP echo off of some host on the same net, and my multiport tranceiver blinks once on the port my PC is connected to. Fine, so a packet did get out. I grab it on my netsniffer and stare at it for a while. Nope, no life in there at all. Even the Ethernet address is hopelessly botched. I did this a couple of times, hoping that the various fields merely suffered from an Off By x Bug, but the packet truly is garbage. And of course PING comes back and cries at me (see output at the end of this message). The funny thing is that HADDR.EXE comes back with the right Ethernet address of the damn card. Hmph. If I play with the stuff too much in one session, things get even better - the machine hangs. Badly. We're talking power cycle. I figure some stack is getting trashed somewhere, or at least the programs are writing wildly into memory. Anyone have any source fixes, or even a working set of binaries? David ping (\pcip\wd8003\iping.exe@soliloquy.rutgers.edu) whines: Initializing Tasking. IP: setting handler for protocol 17 UDP: Opened InterNet connection. IP: setting handler for protocol 1 ICMP: Opened ip conn IP: setting handler for protocol 3 GGP: opened ip con in_write: pkt[264] prot 1 to 128.6.18.2, route 128.6.18.2 icmp: can't send echo request Couldn't send (net address unknown?) on try 0 Ether Stats: My ethernet address: 00.00.C0.07.47.10 0 ints 0 pkts rcvd 1 pkts sent 0 ints lost 0 underflows 0 colls 0 16 colls 1 rdys 0 FCS errs 0 overflows 0 dribbles 0 shorts 0 missed 0 unknown 0 refused 0 too big 0 dropped 0 multi max q depth 0 1 ARPs sent 0 ARP reqs rcvd 0 ARP reps rcved 0 ARP reqs not for me 0 bad ARPs 0 unexpected replies 0 bad lengths IP Stats 0 pkts rcvd 1 pkts sent 0 pkts dropped because of: 0 bad xsums 0 bad protocols 0 bad vers 0 bad lens 0 not for me 0 ttl expired 0 frags 0 destination unreachables rcvd Packet stats: 10 free packets now Min depth: 8 Max depth: 10 netclose() called -- David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc dpz@dorm.rutgers.edu rutgers!dpz dpzimmerman@zodiac.bitnet
ddl@husc6.harvard.edu (Dan Lanciani) (11/24/88)
In article <Nov.21.22.46.50.1988.904@dorm.rutgers.edu>, dpz@dorm.rutgers.edu (David P. Zimmerman) writes: > > I've got the new CMU PC/IP distribution from husc6.harvard.edu > (without docs, but who needs those anyway? :-), and have come to the I will dig out the original doc package if it still exists... > conclusion that the WD8003 driver is spitting out random garbage onto > the network. The PC/IP code works fine with the 3C501 (after I use > the old NETDEV.SYS - the new one won't hang around in memory and let > itself be used), and the WD8003 is very usable under NCSA Telnet and Did you use custom to set the card's base memory address in netdev.sys? The driver works fine here. What do you mean about netdev.sys not hanging around? Dan Lanciani ddl@harvard.*
dpz@dorm.rutgers.edu (David P. Zimmerman) (11/26/88)
OK - my NCSA FTP problem was that I was using 1.02 instead of 1.04. I've got the 7/5/88 versions of both TELNET and FTP now, which work fine with my WD8003. Yes, I did use CUSTOM.EXE to set the card's base memory address in NETDEV.SYS. I set the base I/O address to 0x0360, the base memory address to 0xD0000 (which shows up as 0,D), the xmit and recv DMA channels to 0, and the interrupt vector to 5. Every jumper I could find on the card is set correctly. Theoretically, the PC/IP WD8003 library should be delving into the hardware to set the base memory address on its own - i.e., you don't muck with jumpers for that. I got the new NETDEV.SYS to work - but you guys may want to note something. I was using device=d:\pcip\obj.4d\netdev.sys in my CONFIG.SYS and nothing worked. CUSTOM.EXE spat out Error opening netcust.sys: No such file or directory and all the network programs said Error: open failed for netcust Check for improper NETDEV.SYS installation When I put device=d:\pcip\obj.4d\netdev.sys 1 in my CONFIG.SYS, suddenly birds are singing and flowers are blooming. Well, mostly. Anyway, I can play with the NETCUST1: (but not the NETCUST: !) device via CUSTOM.EXE, have the software find it, etc. I end up having to set NETCUST=NETCUST1 in my AUTOEXEC.BAT. What really blows my mind is the minuscule differences between the old NETDEV.ASM and the new one. I've come to the preliminary conclusion that what you guys think you are getting isn't really what you're getting. The only significant difference between the old and new versions is in the parsing of the command line ([si]*). I stared at the code for a while (learning 8088 assembly along the way) and followed the logic. The differences in the parsing start when you hit a space. The old version will skip all the characters until a space, skip that space, and take the character after it as the network device number if the character was 0x20 or greater. Otherwise it will return a space as the interface number. The new version will skip all the characters until a space, skip all the spaces, then take the next character unconditionally. Additionally, and most importantly, both versions will return a space as the interface number if they didn't find a space on the command line (i.e., you had "device=foo<cr>"). Both algorithms *should* work if MSDOS is doing the expected thing with the command line. I claim that I _shouldn't_ be seeing the effects that I'm seeing, and that MSDOS is slapping one or more spaces onto the end of the device=d:\pcip\obj.4d\netdev.sys line. Then, the new version of NETDEV.SYS would skip the space(s) and unconditionally return the CR as the interface number, *not* a space! The old version would do the "right" thing, which is to end up returning a space. My bugfix would be to just keep using the old version of NETDEV.ASM, unless someone has an emotional attachment to the new version. I don't see any technical reason to have mucked with it. What setup do you guys have your WD8003 stuff running successfully on? I'm bashing on a 5M Compaq 386/20, 360M disk in 12 partitions, a WD8003 (of course :-), and a VGA card/monitor. I'm using MSDOS 3.3x, MSC 5.0 and MASM 5.0. Incidentally, I had to hack both versions of NETDEV.SYS, new and old, due to what I think is an OBOB in MASM 5.0. Both instances of mov es:status[bx],00100H became mov WORD PTR es:status[bx],00100H If I tried using 00101H as a test, it compiled fine, but using 00100H made it complain and die bitterly. 00099H to the assembler is, understandably, not obvious whether it should be a byte or a word, but 00100H is most certainly a word. Also, MSC 5.0 made me put some /NOE flags into the link phases of some of the makefiles, specifically monitor.4d, custom.4d, netwatch.4d, term.4d, and tn.4d. The linker says: d:\pcip\lib\[argle].LIB(_wbyte.c) : error L2044: __wbyte : symbol multiply defined, use /NOE So I did :-). [argle] is different libraries at different time - for TERM it is H194D, for CUSTOM it is NET4D. I'm not sure if this would have anything to do with my WD8003 problems. Also also, \srccmd\monitor\monitor.c needed a ; on line 642 for MSC 5.0. David -- David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc dpz@dorm.rutgers.edu rutgers!dpz dpzimmerman@zodiac.bitnet
ddl@husc6.harvard.edu (Dan Lanciani) (11/27/88)
In article <Nov.25.21.14.10.1988.7198@dorm.rutgers.edu>, dpz@dorm.rutgers.edu (David P. Zimmerman) writes: | Yes, I did use CUSTOM.EXE to set the card's base memory address in | NETDEV.SYS. I set the base I/O address to 0x0360, the base memory | address to 0xD0000 (which shows up as 0,D), the xmit and recv DMA | channels to 0, and the interrupt vector to 5. Every jumper I could | find on the card is set correctly. Theoretically, the PC/IP WD8003 | library should be delving into the hardware to set the base memory | address on its own - i.e., you don't muck with jumpers for that. Ah, that address should be D0000000, the hex representation of a far pointer to D000:0000. I should probably note that in the custom menu... | I got the new NETDEV.SYS to work - but you guys may want to note | something. I was using | | device=d:\pcip\obj.4d\netdev.sys | | in my CONFIG.SYS and nothing worked. CUSTOM.EXE spat out | | Error opening netcust.sys: No such file or directory | | and all the network programs said | | Error: open failed for netcust | Check for improper NETDEV.SYS installation | | When I put | | device=d:\pcip\obj.4d\netdev.sys 1 | | in my CONFIG.SYS, suddenly birds are singing and flowers are blooming. | Well, mostly. Anyway, I can play with the NETCUST1: (but not the | NETCUST: !) device via CUSTOM.EXE, have the software find it, etc. | I end up having to set NETCUST=NETCUST1 in my AUTOEXEC.BAT. | | What really blows my mind is the minuscule differences between the old | NETDEV.ASM and the new one. I've come to the preliminary conclusion | that what you guys think you are getting isn't really what you're | getting. The only significant difference between the old and new | versions is in the parsing of the command line ([si]*). I stared at | the code for a while (learning 8088 assembly along the way) and | followed the logic. | | The differences in the parsing start when you hit a space. The old | version will skip all the characters until a space, skip that space, | and take the character after it as the network device number if the | character was 0x20 or greater. Otherwise it will return a space as | the interface number. The new version will skip all the characters | until a space, skip all the spaces, then take the next character | unconditionally. Additionally, and most importantly, both versions | will return a space as the interface number if they didn't find a | space on the command line (i.e., you had "device=foo<cr>"). | | Both algorithms *should* work if MSDOS is doing the expected thing | with the command line. I claim that I _shouldn't_ be seeing the | effects that I'm seeing, and that MSDOS is slapping one or more spaces | onto the end of the | | device=d:\pcip\obj.4d\netdev.sys | | line. Then, the new version of NETDEV.SYS would skip the space(s) and | unconditionally return the CR as the interface number, *not* a space! | The old version would do the "right" thing, which is to end up | returning a space. My bugfix would be to just keep using the old | version of NETDEV.ASM, unless someone has an emotional attachment to | the new version. I don't see any technical reason to have mucked with | it. The technical reason to "muck" with it is that the old routine doesn't work with DOS 3.3, always ignoring its argument. Of course, I failed to test the new routine with DOS <= 3.1 and no argument. If someone would like to tell me exactly what various versions of DOS pass here, I'll fix it... | | What setup do you guys have your WD8003 stuff running successfully on? | I'm bashing on a 5M Compaq 386/20, 360M disk in 12 partitions, a | WD8003 (of course :-), and a VGA card/monitor. I'm using MSDOS 3.3x, | MSC 5.0 and MASM 5.0. | | Incidentally, I had to hack both versions of NETDEV.SYS, new and old, | due to what I think is an OBOB in MASM 5.0. Both instances of | | mov es:status[bx],00100H | | became | | mov WORD PTR es:status[bx],00100H | | If I tried using 00101H as a test, it compiled fine, but using 00100H | made it complain and die bitterly. 00099H to the assembler is, | understandably, not obvious whether it should be a byte or a word, but | 00100H is most certainly a word. | | Also, MSC 5.0 made me put some /NOE flags into the link phases of some | of the makefiles, specifically monitor.4d, custom.4d, netwatch.4d, | term.4d, and tn.4d. The linker says: | | d:\pcip\lib\[argle].LIB(_wbyte.c) : error L2044: __wbyte : | symbol multiply defined, use /NOE | | So I did :-). [argle] is different libraries at different time - for | TERM it is H194D, for CUSTOM it is NET4D. I'm not sure if this would | have anything to do with my WD8003 problems. | | Also also, \srccmd\monitor\monitor.c needed a ; on line 642 for MSC 5.0. Yup, I know about the problems with 5.0 versions of C and MASM. One of these days I'll grit my teeth and "fix" them. Now that /NOE is described in the manual and I can stop calling it /NOERROR :) Dan Lanciani ddl@harvard.*
dpz@dorm.rutgers.edu (David P. Zimmerman) (11/28/88)
Bingo! D0000000 did it. I'm not sure of my "appended spaces bug" theory any more. Even with that bug, the old driver shouldn't be ignoring the argument under DOS 3.3, so it has to be something else. Dunno. I see what is going on with the device name stuff - I tried device=d:\pcip\obj.4d\netdev.sys w in my CONFIG.SYS, and didn't need to set NETCUST = to anything when I used the WD8003 programs. I'd still like to keep it generic though, and not have to have an argument. Therefore, I fixed the "device line without an argument not giving a NETCUST:" bug in the new driver. You can now have device=d:\pcip\obj.4d\netdev.sys again, using the new code, with no arguments, and get the NETCUST: device. It is fairly straightforward code, and thus not really optimal, especially with the hack to get around not being able to use relative jumps to such a far place. I'll leave better code to you guys, because I'm more or less sick of assembly and machines with no reset buttons for now. Theoretically the Rutgers version should work across all the DOS versions. Thanks for your help! David Rutgers' diffs to netdev.asm: *** netdev.org Sun Nov 27 17:20:50 1988 --- netdev.asm Sun Nov 27 17:29:38 1988 *************** *** 157,163 **** push es okay: ! mov es:status[bx],00100H done: pop es pop ds --- 157,163 ---- push es okay: ! mov WORD PTR es:status[bx],00100H done: pop es pop ds *************** *** 205,211 **** netinit: mov WORD PTR es:lastaddr[bx],OFFSET _TEXT:_etext mov es:lastaddr+2[bx],cs ! mov es:status[bx],00100H lds si,es:bpb[bx] --- 205,211 ---- netinit: mov WORD PTR es:lastaddr[bx],OFFSET _TEXT:_etext mov es:lastaddr+2[bx],cs ! mov WORD PTR es:status[bx],00100H lds si,es:bpb[bx] *************** *** 221,232 **** again: mov al,[si] inc si cmp al,020H jz again mov cs:name7,al ! jmp done _etext: NETDEV ENDP _TEXT ENDS --- 221,236 ---- again: mov al,[si] inc si + cmp al,0aH + jz bye + cmp al,0dH + jz bye cmp al,020H jz again mov cs:name7,al ! bye: jmp done _etext: NETDEV ENDP _TEXT ENDS -- David P. Zimmerman, the Dorm Networking Pilot Project, the UUCP Project, etc dpz@dorm.rutgers.edu rutgers!dpz dpzimmerman@zodiac.bitnet