• Please review our updated Terms and Rules here

Another DOS IRC Client

Status
Not open for further replies.
It's a resounding success, with the exception that it decides to just quit on me, as if I had exited manually. This last time it exited, I was in the middle of typing a reply:

Code:
irc.gimp.ca 401 _Trixter_ This :No such nick/channel                            
brut_pcjr PRIVMSG #vc :You don't need to enter a command to send a msg, unless y
ou really want a private message.                                               
brut_pcjr PRIVMSG #vc :Try this:                                                
brut_pcjr PRIVMSG #vc : /privmsg brut_pcjr :msg goes here                       
_Trixter_: Okay, so this message is public...                                   
_Trixter_: /privmsg brut_pcjr ...and this message is private                    
brut_pcjr PRIVMSG #vc :Yep - by default everything goes to the channel that you
last joined.                                                                    
brut_pcjr PRIVMSG #vc :Just type and it will go to the channel.  True 'private m
essages' will come later.                                                       
_Trixter_: Every message I'm seeing says PRIVMSG #vc :..... so I can't tell if t
hese are private or public                                                      
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
But, display issues aside, I Irc Stats: Ping Responses: 0
Tcp Pkts Sent 39 Rcvd 37 Retrans 6 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 296  Dropped: 7  Sent: 48
           LowFreeBufferCount: 0

c:\internet\brutirc>

You can see me type "But, display issues aside, I " before it craps out.

Spurious keyboard interrupt? Is that an error output?

Display speed is fantastic, btw. I am curious how your "snow value" works (ie. higher numbers = less snow) but I'll respond to the snow discussion in the other thread first.
 
Well, come on back and try it again ..

I have no idea what caused the spontaneous death - it hasn't happened to me yet. Ctrl-X will do it.

I did notice from the ending statistics that your packet driver dropped some of the incoming packets because it ran out of buffer room. I'm curious about that - what card, which packet driver, and did you purposefully hit Pause or something to delay it for a while?

(There are 20 receive buffers for the packet driver, and I've never seen more than 5 used. You used all 20.)
 
New version posted yesterday with the following features:

  • Added filtering of gorp from the server on messages to and from users
  • Added easier way to send private messages (/msg)
  • Added a toggleable beeper for new incoming messages

Mike
 
Well, come on back and try it again ..

I have no idea what caused the spontaneous death - it hasn't happened to me yet. Ctrl-X will do it.

Yet I didn't hit ctrl-x :)

I did notice from the ending statistics that your packet driver dropped some of the incoming packets because it ran out of buffer room. I'm curious about that - what card, which packet driver, and did you purposefully hit Pause or something to delay it for a while?

Nope. Was just typing. I am using an Intel Etherexpress 8/16 (in 8-bit mode of course).

Keep in mind you have probably used slow packet devices (xircom) on slow machines, and fast devices on fast machines. But I am using a fast device (can do 40KB/s) on a slow machine (XT). Might that have had something to do with it?

Can you double the number of receive buffers to 40? @ 1500 that would still be under 64K...
 
New version posted yesterday with the following features:

  • Added filtering of gorp from the server on messages to and from users
  • Added easier way to send private messages (/msg)
  • Added a toggleable beeper for new incoming messages

Mike

Well, it dropped in the middle of typing something again :-(
I was typing "Me, I have CGA snow set " and it existed to DOS.
Here's the session, thanks to SNIPPER.COM (loaded AFTER the drop):

Code:
<_Trixter_> /msg brut386 although it looks like my messages are going public whe
n I do this                                                                     
<brut386 to _Trixter_> Yep .. private messages.                                 
<_Trixter_> /msg brut386 Ah, I see reverse video when receiving private but not
when sending... add that to the todo list:)                                     
<_Trixter_> This is really fantastic.  This is already part of my arsenal.      
<brut386 to _Trixter_> And for my friends with mono, the explicit "to" word     
<_Trixter_> /msg brut386 well, mono friends have regular, bright, and reverse, b
ut it is still appreciated                                                      
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
Me, I have CGA snow set Irc Stats: Ping Responses: 0
Tcp Pkts Sent 26 Rcvd 24 Retrans 8 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 245  Dropped: 23  Sent: 38
           LowFreeBufferCount: 0

Please send comments and bug reports to mbbrutman@yahoo.com


c:\internet\brutirc>

Is this a normal exit, as if I had requested the exit through ctrl-x? Because I definitely didn't hit that, so you may want to check for alternate ways the "exit" signal/command/whatever is getting through. If it's an error out then maybe some indication of the error...?
 
You are definitely having comm problems there. Here is the giveaway:

Code:
Tcp Pkts Sent 26 Rcvd 24 Retrans 8 Seq/Ack errs 0 Dropped 0
Pkt stats: Incoming pkts: 245  Dropped: 23  Sent: 38
           LowFreeBufferCount: 0

That tells me that you had a very short session (just 24 packets received from the IRC server), and it probably ended in error when a packet timed out and was retried a few times. Interesting, on the raw Ethernet you had 245 packets inbound, but only 38 outbound - there must be a metric buttload of broadcast traffic on your home network.

You definitely ran out of incoming buffer space for Ethernet frames, most of which were being tossed away anyway. But what killed you was a packet that you tried to send - my TCP stack will retry a packet six times before giving up and killing the connection.

The main loop exits when you hit Ctrl-X or when the server side closes the connection. I just added an error message for the remote connection being closed and tested it by yanking a cable. If you plug the cable back in quick enough the retry mechanism will save the connection, but after six retries it gives up. You had a combined total of 8 retries, so it probably recovered from a few dropped packets before things got hopelessly out of sync.

Here's the fun part ..
Code:
set debugging=255
set logfile=irc.log

That's going to generate a log file with a lot of stuff in it. It will be painful. It will still run on your XT or PC, but you will notice the hard drive exercising quite a bit. That log will help me diagnose exactly what caused the sequence of events that resulted in the dropped connection.

Also, do you have any TSRs that might be hogging the CPU? Every idle loop in my program checks for data that the Ethernet card dropped in the buffers, and pushes the data through the stack. I don't have anything that can cause such a delay that the buffer gets overrun, unless you are carpet bombing that PC with packets. (And even then, I know the machine can keep up with a stream of 40KB per second or so.) If you have a TSR that comes to the foreground and stops my app for a few seconds or more, then this could happen.

I can give you a debug copy that increases the incoming buffers to something like 40 or 100, and also cuts the mtu size down to 500 or so. For IRC packet size is never more than 512 bytes anyway, so a smaller MTU would work.

BTW, I had it online all day today from my office on the XT. Close to 1000 TCP/IP packets in and out, and 1200 Ethernet frames in (1000 or so out).
 
You definitely ran out of incoming buffer space for Ethernet frames, most of which were being tossed away anyway.

I have a very busy network. But should that be a reason for this to happen? The NCSA stack doesn't have a problem with this, for example, nor wattcp.

after six retries it gives up

What does the RFC say about retries? How many times?

That log will help me diagnose exactly what caused the sequence of events that resulted in the dropped connection.

I died again, so here's the fun part of that log:

Code:
23:31:35   Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01   ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 62 33 29 DE               ........b3).

23:31:35   Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01   ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 62 33 29 DE               ........b3).

23:31:35   Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01   ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 62 33 29 DE               ........b3).

23:31:35 W Tcp: (2e980004) Retrans, SEQ=1f1e7afd ACK=5314568d
23:31:35   Tcp: (2e980004) Send (2eaa0bfc) ESTABLISHED Len: 70 Win=10240 Tries: 7
23:31:35   Packet layer: Sending 124 bytes, dumping 124
00 16 B6 DA A3 77 00 AA 00 6F CF 6D 08 00 45 00   .....w...o.m..E.
00 6E 00 00 40 00 FF 06 DD FC C0 A8 47 58 82 EF   .n..@.......GX..
12 9D 14 82 1A 0B 1F 1E 7A FD 53 14 56 8D 50 10   ........z.S.V.P.
28 00 9F 5B 00 00 50 52 49 56 4D 53 47 20 23 76   (..[..PRIVMSG #v
63 20 3A 45 76 65 72 79 6F 6E 65 20 69 67 6E 6F   c :Everyone igno
72 65 20 6D 65 2C 20 49 27 6D 20 67 6F 69 6E 67   re me, I'm going
20 74 6F 20 73 65 6E 64 20 61 20 66 65 77 20 62    to send a few b
6F 67 75 73 20 6C 69 6E 65 73 0A 0A               ogus lines..

23:31:36   Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01   ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 62 33 29 DE               ........b3).

23:31:36 W Tcp: (2e980004) Timeout SEQ=fd7a1e1f ACK=8d561453
23:31:36   Tcp: (2e980004) destroy
23:31:36 W Tcp: (2e980004) Tried recv in state CLOSED
23:31:36 W Tcp: (2e980004) Tried to send a packet while in CLOSED
23:31:36   Tcp: (2e980004) shutdown( 0 )
23:31:36   Tcp: (2e980004) close called
23:31:36 W Tcp: -CC- Socket (2e980004) found 0 in lists
23:31:36   Tcp: (2e980004) closeLocal: socket state=CLOSED
23:31:36   Tcp: (2e980004) closeLocal: socket state now=CLOSED
23:31:36   Tcp: (2e980004) destroy
23:31:36 W Tcp: -CC- Socket (2e980004) found 0 in lists
23:31:36   Tcp: (2e980004) returned to free list
23:31:36   PACKET.CPP: Handle released

Also, do you have any TSRs that might be hogging the CPU?

Nope :) Just a busy network.
 
I think I've got the bug. I love trace files ...

As the log shows, it died trying to send that packet. On the 7th retransmit it failed.

The real clue is the incoming packets before:

Code:
23:31:35   Packet layer: Received 60 bytes, dumping 60
FF FF FF FF FF FF 00 19 1D E5 ED 50 00 06 00 01   ...........P....
AF 81 01 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 62 33 29 DE               ........b3).

I've been looking at that packet trying to figure out what the hell it is. It's not ARP and its not IP. IP would have 0800 in bytes 13 and 14, and ARP would have 0806 in those bytes. You have 00 06 so that tells me it is Ethernet 802.3, and it is actually a length field not a protocol type.

My bug is that when I get a packet type I don't understand I'm not discarding the packet - that will be fixed as soon as I get home. That bug has been in my code for at least 1.5 years! It also explains why you are running out of incoming buffer space ... after you get 20 such buffers you can't receiving any more packets, and that means that you can't receive ACKs for previously sent packets either. Hence the retries and eventual death.

Bravo! It will be fixed tonight ...

Can you confirm that you are running 802.3 and Ethernet II on the same subnet? I don't do this, which is why it always works for me ...
 
I've been looking at that packet trying to figure out what the hell it is. It's not ARP and its not IP. IP would have 0800 in bytes 13 and 14, and ARP would have 0806 in those bytes. You have 00 06 so that tells me it is Ethernet 802.3, and it is actually a length field not a protocol type.

Can you be more specific on "802.3"? There are a bazillion different variants (I'm assuming you mean something here: http://en.wikipedia.org/wiki/IEEE_802.3 )

My bug is that when I get a packet type I don't understand I'm not discarding the packet

Oh, well, heck yeah that's what it is :)

Can you confirm that you are running 802.3 and Ethernet II on the same subnet? I don't do this, which is why it always works for me ...

Only if you can confirm what you mean by 802.3 :)

The protocols I can think of that float around my network are TCP, UDP, ICMP, netbios, WDS (although that shouldn't be on the internal LAN)...

If I could figure out how to craft that data into something parsable by wireshark, we could let wireshark tell us...
 
Ok, I've got a test version ready!


There is a zip file with the application and a readme on that page. Give it a whirl and let me know what you think!

General DOS Networking help can be found here:


Support will be provided here and by email (mbbrutman@yahoo.com) if you need it. And of course on the #vc IRC channel on Gimp. (irc.us.gimp.net)

-Mike

my name is-a borat, i like-a you IRC client. is niiiiiice.

seems to work just fine. i only tried it under DOSBox so far. i have to go run some errands, but when i get back i am going to boot up the XT clone and copy your client over to it using the DOS FTP server i've been programming for the past couple days.

i'm curious to see how quick it runs on that machine. one thing i would try to do though, is just use one line at the bottom for text input. it would give more room to put the incoming data on the screen.

and also i haven't checked yet, but does the program let you scroll back and forth through the log? that kind of functionality is not necessarily required, but in LeetIRC i have 1000 lines allocated for buffer scrolling. it is very nice to have, say you've been out of the room for a while you can scroll back up to see if you missed anything. kinda cool to have, and comes in very handy sometimes.

mikebirc.png
 
I may have had it backwards, but from here is the relevant paragraph from that web page:

What is defined in earlier IEEE 802.3 standards is often confused for what is used in practice: most network frames you will find on an Ethernet will be DIX frames, since the Internet protocol suite will use this format, with the type field set to the corresponding IETF protocol type. IEEE 802.3x-1997 allows the 16-bit field after the MAC addresses to be used as a type field or a length field, so that DIX frames are also valid 802.3 frames in 802.3x-1997 and later versions of the IEEE 802.3 Ethernet standard.

My code assumes DIX frames, where the two bytes after the MAC addresses identify the protocol. Older 802.3 frames have a length field there instead, and then use 8 bytes for LLN/SNAP to identify the protocol.

There was a split at 802.3 and DIX. The split is reconciled again at 802.3x - look at the chart ...
 
mike b: question. when you were writing your TCP/IP stack, was packet driver communication basically done the same way my code communicates with TCPDRV? just software interrupt calls?

i know it's more complicated than my code talking to TCPDRV, since you have to handle packet framing and everything.
 
ok mike, i just wanted to let you know i ran it on my XT clone with an IBM monochrome card. i remember you were asking about it on mono in the readme file.

it works great on it, and it's very fast. good job!

two thumbs up! :thumbsup::thumbsup:
 
Hi everybody. Work got in the way today - I hate it when that happens.

Anyway, I posted a new version with the big bug fixed. I'm so happy that the trace was detailed enough to lead to the bug - that is exactly what the point of a trace is. Trixter, you should be able to run more than two minutes now. It would be fun to see what's running on your network with the non-DIX frames. Old versions of Novell maybe?

Mike C: I had not tested at all on a monochrome screen, so it is good to hear that it works. The theory of operation is the same, but my color selection is obviously a lot more limited. The rest of the screen handling is the same. There is no backscroll buffer yet.

Communication with the packet driver is through a software interrupt mechanism, which is very similar to what you do when you talk to the Trumpet TCP/IP TSR.

For receiving packets from the packet driver you have to provide a function for it to call. There is some ambiguity in the spec as to how one is supposed to code the return from the function.

All of the Crynwr packet drivers and their derivatives are 'good' in that they return the way you would expect (and the way the compiler generates the code). The Xircom PE3 10BT (which I use on the PCjr) has a crappy packet driver that does something nasty that caused me all sorts of grief. I can't remember the details now, but basically I had to write my own assembly code to replace the compiler generated code that does the return, so that the packet driver wouldn't blow up. I had quite a few emails back and forth with Russ Nelson (the force behind the packet driver specification) to understand the problem and work around it. Once I was able to send and receive raw Ethernet frames, the rest was just a simple matter of programming. (Ha!)

See here for the details on the packet spec:



Mike
 
thanks for the packet driver spec link, i am way ahead of you though.. i already printed that doc out last night and i have it sitting here stapled all nice and neat. :p

i was going to play around with it.
 
Actually, I'm about 2.5 years ahead of you with regards to having printed it out and coding to it. ;-0
 
Anyway, I posted a new version with the big bug fixed. I'm so happy that the trace was detailed enough to lead to the bug - that is exactly what the point of a trace is. Trixter, you should be able to run more than two minutes now. It would be fun to see what's running on your network with the non-DIX frames. Old versions of Novell maybe?

Oh hardy har har. :) I am working on work tonight :-( but I will do a dump of my network and look for those 60-byte packets and see if I can identify what they are. They're probably netbios.
 
Actually, I'm about 2.5 years ahead of you with regards to having printed it out and coding to it. ;-0

yeah, you win. i don't really plan to make my own TCP stack... at least not right now, and for SURE not in QB. i like transfer rates OVER 1 kB/s :eek:

i was just going to screw with it a bit... maybe make a packet sniffer and watch my network go crazy or something, i dunno.
 
Trixter - what were those funny packets?

In other news ... I've added support for a backscroll buffer. It looks like I did a pretty good job with the TCP stack because you can continue receiving data from the other side even while looking at the backscroll buffer. The incoming data just gets buffered, and if buffer space runs out the TCP stack reports a 'zero window' condition correctly to the server side. And it also responds correctly to 'zero window probes.

(Translation for normal people - you can sit all day looking at the backscroll buffer and even though data might stop flowing after the buffer space runs out, the connection won't error out.)

I'll have another version out for download in a few days. After that, what else are people interested in?


Mike
 
Status
Not open for further replies.
Back
Top