Organization: Oklahoma State University, Stillwater, OK
Lines: 44
Description of my testing methods.
When trying to open a telnet connection with CUTCP I sent out 11 perfectly
formed ARP packets. With our general datacomm Sniffer I can see these packets
go out and also see responces to them. Therefore send works for ARP.
Now I load up the Netcure software on my driver and retransmit those packets
that were captured from before. The ones to my mechine show up in netcapt so
conclusion receive works for ARP.
Now I load up ibmtoken on a mechine and do a telnet session to get data loaded
into the sniffer quit and load up oditrpkt and netcapt. Transmit data from
sniffer back threw my driver into netcapt. Go into netview and IP/TCP packets
look OK. Conclusion Driver receives IP/TCP packets ok.
Summary
ARP transmit and receive work
TCP/IP only receive works
My guess is that TCP/IP traffic is getting stopped at the lsl or mlid since I
never see a packet go out on the wire. There have been two times when I
actually got a TCP packet out on the wire.
The only difference in the way I treat ARP and TCP/IP in my sending routine is I change the hardware type in the ARP packet on transmit and receive and I
reduce size to eliminate excess on incomming arp_packets. I also round all
incomming packets up to 60. I am doing raw receives, but I am giving a
specific StackID on sends although I have only bound a prescan stack.
I have tried raw sends, default and prescan stacks. I have also tried
binding a perticular stack but I had less success there.
Question: Are the stack ID's the same as the ProtocolID's?
Is it necessary to bind a stack to send things?
Why would ARP work and TCP/IP not work.
Does anyone have any suggestions on things to try?
Seen something simular before?
I am also in need of Tools and ideas for debuging. Anyone know of any shims
that I can fit into here to gain more knowledge on where the packets are getting
lost?
All speculations, ideas, and any other help greatly appreciated.
