able/windows-nt
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
windows-nt/Source/XPSP1/NT/net/atm/arp/atmarpc/notes.txt
CryptoAlgo Inc b3cac27891 Add source files
2020-09-26 16:20:57 +08:00

986 lines
39 KiB
Plaintext
Raw Blame History

3/24/1998 JosephJ Sample stack:
ut
ChildEBP RetAddr Args to Child
f2caf9a0 802acd69 40010010 00000000 00000000 NDIS!NdisCmMakeCallComplete+0xf
f2caf9cc f28f557c 80764828 807648c8 00000000 NDIS!NdisClMakeCall+0x9f
f2cafa10 f28f746f 80583c88 805fdd68 80583f90 atmarpc!AtmArpMakeCall+0x156
f2cafa34 f28f7693 805fdd74 8076b020 80583c88 atmarpc!AtmArpMcSendToMARS+0x67
f2cafa54 f28f4578 8076a9c4 f2cafa78 00000103 atmarpc!AtmArpMcSendRequest+0xe5
f2cafa7c f28f3ef5 8055e500 8055e568 80583c88 atmarpc!AtmArpResolveIpEntry+0x9e
f2cafa8c f28f2200 8055e568 805f2028 00000000 atmarpc!AtmArpQueuePacketOnIPEntry+0x3d
f2cafabc f28f1f79 8055e57c 805f2028 020000e0 atmarpc!AtmArpIfTransmit+0x25e
f2cafad8 f804561a 80583c88 f2cafb10 00000001 atmarpc!AtmArpIfMultiTransmit+0x2b
f2cafb00 f8030a42 80564ca8 020000e0 805f2028 tcpip!SendIPPacket+0x126
f2cafb8c f804d2da 80564ca8 00000005 8055e908 tcpip!IPTransmit+0x12ad
f2cafbe4 f8037e45 00000016 8055e908 020000e0 tcpip!SendIGMPReport+0xd2
f2cafc38 f8038c06 805fbb00 020000e0 00000000 tcpip!IGMPAddrChange+0x24f
f2cafc4c f80449dd 805fbb48 80583d90 80583c88 tcpip!InitIGMPForNTE+0x3a
f2cafcc0 f28f51e4 00000001 00000000 8072d490 tcpip!IPAddInterface+0x3d7
f2cafd74 802a4647 80584608 00000000 00000000 atmarpc!AtmArpCoAfRegisterNotifyHandler+0x18e
f2cafd98 80298d0f 805b5800 00000000 f2cafddc NDIS!ndisNotifyAfRegistration+0x55
3/26/1998 JosephJ
adapter.c: AtmArpPnpEventHandler checks if this is for us (atmarp) or IP.
If it's us, it calls AtmArpPnPReconfigHandler which
currently does nothing. I need to stop and restart the
ip interface.
Q: we specifically look for Reconfig and if not that we
pass it up to IP -- shouldn't we be more discerning? How
do IP reconfigs happen?
callmgr.c AtmArpCoRequestHandler currently handles:
OID_CO_ADDRESS_CHANGE
OID_CO_AF_CLOSE
Calls AtmArpShutdownInterface(pInterface), which
is onlyc alled from here and AtmArpUnbindAdapterHandler.
Q: what events lead to each of the above?
Q: Useful debugger extensions? ndis/atm-specific?
Q: Dumping pInterface and other atmarpc structures?
Q: How to set bps on ALL (or most) AtmArpC entrypoints?
Following is debug spew at aaDebugLevel=0x6, immediately after rt-clicking
on disconnect from the connections entry:
AtmArpC: MakeCall Complete: Status 0xc0000001, VC 0xfe75ace4, pAtmEntry 0xfe6a18
04
AtmArpC: Closing call on VC 0xfe663e24, VC Flags 0x49, Ref 3, NdisVcHandle 0xfe6
68aa8
AtmArpC: Abort IP entry 0xfe676364, Flags 0x4000, ATM Entry 0x0, IP Addr 224:0:0
:2
AtmArpC: Abort IP entry 0xfe746164, Flags 0x4000, ATM Entry 0x0, IP Addr 255:255
:255:255
AtmArpC: SendIPDelInterface: IF 0xfe6a1c64, IPContext 0xfe6a2868
AtmArpC: IfDelAddress: Ctxt 0xfe6a1c64, Type 0x1, IPAddr 0x20000e0, Mask 0x0, Re
t 1
AtmArpC: IfDelAddress: Ctxt 0xfe6a1c64, Type 0x1, IPAddr 0x10000e0, Mask 0x0, Re
t 1
AtmArpC: IfGetEList: pIf 0xfe6a1c64, pList 0xfe6d4000, Cnt 11
AtmArpC: IfGetEList: returning 1, MyAT 3, MyIF 4, pList 0xfe6d4058, Size 11
AtmArpC: IfDelAddress: Ctxt 0xfe6a1c64, Type 0x0, IPAddr 0x284aa8c0, Mask 0x0, R
et 1
AtmArpC: IfClose: will deallocate pIf 0xfe6a1c64, RefCount 1
AtmArpC: Deallocate Interface 0xfe6a1c64
AtmArpC: PnPEventHandler: pIF 0x0, pEvent 0xf7c90b58, Status 0x0
AtmArpC: UnbindAdapterHandler: pAdapter 0xfe6d1384, UnbindContext 0xf7c90b0c
AtmArpC: CompleteUnbindAdapter: pAdapter 0xfe6d1384, UnbindContext 0xf7c90b0c
3/27/1998 JosephJ
The ndispnpapi pnp irp eventually goes down to ndisPnPNotifyBinding()
in ndis\ndis\ndispnp.c.
Reconfig can complete asynchronously....
Currently, TCPIP calls AtmArpPnpComplete, which calls ndisCompletePnPEvent.
4/3/1998 JosephJ
To do the reconfig, I need to...
1. Identify the adapter and interface.
2. Save state, including async completion handle for the reconfig request.
2. Bring down that specific interface.
3. When interface is down (callback from ip), queue worker item
4.
Vi settings to use:
EXINIT=set ai sm showmode ts=4 hardtabs sw=4
4/21/1998 JosephJ
Implementing GetCfInfoName handler. Other place which this is implemented:
ndis\trfccntl\psched3\psched.
Need to return a systemwide unique unicode string
* (confirm with ofer).
atmarpc needs to allocate this and keep it alive for the duration of
the flowinfo object. Simplest solution is to allocate it on creation
of the flow (in the AtmArpGpcAddCfInfoNotify function).
Since it needs to be unique, we'll base it on the WMI interface name
and keep a per-interface "flow index" which we'll tack on to the name.
* Check with Ofer if this is ok.
TODO: change to new address reporting format:
NETWOR_ADDRESS: AttressType needs to be filled in to
NDIS_PROTOCOL_ID_TCPIP
NETWORK_ADDDRESS_LIST: the Address array needs to be filled with
type NETWORK_ADDRESS_IP, not the dword-sized IP_ADDRESS.
Fuction: AtmArpWmiGetAddressList
4/22/1998 JosephJ
Removed the commented-out precomp-header lines from sources. Build was not
handling these commented-out lines correctly, causing it to recompile all
all files each time because it didn't find the precompiled headers!
5/8/ 1998 JosephJ
Diagnostic statistics to add....
Per interface IP statistics:
arp:
-
send:
- time of last send request
- status of last send request
- 1st 32 bytes of last send packet
- number of pkts sent successfully
- number of pkts sent unsuccessfully
recv:
- time of last recv request
- status of last recv request
- 1st 32 bytes of last recv packet
- number of pkts recvd successfully
- number of pkts recvd unsuccessfully
5/11/1998 JosephJ
Places which mess with pInterface->pAtmArpList:
adapter.c: AtmArpShutdownInterface
arpproc.c: AtmArpSearchForAtmentry -- looks for an atmentry and optionally
creates one if it doesn't match
marspkt.c: AtmArpMcHandleMulti -- adds an atm entry.
utils.c: AtmArpDereferenceAtmEntry -- unlink an atmentry.
utils.c: AtmArpDeallocateInterface -- deallocating pInterface (goes
through and MEM_FREEs all atmarp entries.)
Interface shutdown operation:
1st thing to do is to claim interface lock and set "shutting down bit" for
each list.
2nd: Do not allow list items to be added once this shutting-down bit
is set.
3rd: list is NEVER unlocked with entries having ref-count zero.
4th: If entry is unlocked and in list and list, it is always
in a consistant state -- even just before deallocating.
4th: If the entry is DOWN, don't do anything constructive with them.
5/12/1998 JosephJ
pInterface->pJoinList; is not protected when shutting down.
it is manipulated in ipmcast.c, with the interface lock held, so
it would be a matter of aquiring the interface lock when cleaning
up pJoinList in ShutdownInterface.
pUnresolvedVcs: locked by pInterface, but it is not protected
in AtmArpCallConnectedHandler(...):
pVc->pNextVc = pInterface->pUnresolvedVcs;
pInterface->pUnresolvedVcs = pVc;
(there is a check that pInterface->AdminState is up, but
we never claim the lock on pInterface!).
(However, this applies only for PVCs, so perhaps this is not
such a big deal.)
pAtmEntry->pVcList;
AtmArpHandleInARPReply(...) acquires locks in the following order...
AA_ACQUIRE_IF_LOCK(pInterface);
AA_ACQUIRE_IE_LOCK_DPC(pIpEntry);
AA_ACQUIRE_AE_LOCK_DPC(pAtmEntry);
AA_ACQUIRE_VC_LOCK_DPC(pVc);
5/12/1998 JosephJ
ndis\uni\admin -- console app "atmadm"
atmarps -- look at the M3 IOCTLS. Name of device to open is in ioctl.h.
5/15/1998 JosephJ More robustness-improving changes...
typedef
void (*PFNVALIDATE)(void *pObj);
typedef struct
{
PFNVALIDATE pfnValidate;
ULONG uFlags;
// Lock
// RefCount
} ATMARP_HEADER;
#define ATMARP_VALIDATE(_pObj) (_pObj)->Hdr.pfnValidate((PVOID)_pObj);
5/16/1998 JosephJ
Information on Timers
5/21/1998 JosephJ suggested form of validation routines
ValidateX(ExpectedState)
{
// General validation
switch(ExpectedState)
{
case Loading:
case Active:
case Deallocating:
// check that various timer are not pending
// check that "in-parent-list" bit is clear
}
}
Structures to validate:
Following structures have timers/refcounts/locks
ATMARP_ATM_ENTRY: RefCount Lock
ATMARP_IPMC_ATM_ENTRY: Timer
ATMARP_IPMC_JOIN_ENTRY: Timer RefCount
ATMARP_IP_ENTRY: Timer RefCount Lock
ATMARP_VC: Timer RefCount Lock
ATMARP_INTERFACE: Timer RefCount InterfaceLock
McTimer ArpTableLock
AtmEntryListLock
TimerLock
WmiLock
We can assert that contained timers are not active on deallocation of
a structure.
Following table lists the logical "parent" of each structure
ATMARP_ATM_ENTRY: In INTERFACE:AtmEntryList
flag:AA_ATM_ENTRY_ACTIVE
ATMARP_IPMC_ATM_ENTRY: In AtmArpEntry
flag:AA_IPMC_AE_VALID use this?
ATMARP_IPMC_ATM_INFO:
flag: AA_IPMC_AI_LOAD_ALIVE
ATMARP_IPMC_JOIN_ENTRY: In AtmArpEntry flag:
ATMARP_IP_ENTRY: In ArpTable
flags: AA_IP_ENTRY_IDLE
ATMARP_VC: In AtmEntry
flags: AA_VC_OWNER
ATMARP_INTERFACE: In Adapter.
flags: AA_IF_, AAMC_IF_
We can maintain a "keep alive" bit which is set once the item is in the
the parent and cleared when it is removed from the
parent. We will assert that the "keep alive" bit is clear when deallocating
the structure.
LOAD_STATE
LS_LOADING -- don't use yet
LS_LOADED -- ok to use
LS_UNLOADING -- don't start any new activity
LS_UNLOADED -- ok to delete.
5/28/1998 JosephJ
Holes dealing with the McEntryList:
In AtmArpMcPrepareAtmEntryForClose
//
// First, prune all members that aren't connected.
//
for (pMcAtmEntry = pAtmEntry->pMcAtmInfo->pMcAtmEntryList;
pMcAtmEntry != NULL_PATMARP_IPMC_ATM_ENTRY;
pMcAtmEntry = pNextMcAtmEntry)
{
pNextMcAtmEntry = pMcAtmEntry->pNextMcAtmEntry;
//
// Stop any timer running here.
//
(VOID)AtmArpStopTimer(&(pMcAtmEntry->Timer), pInterface);
if (AA_IS_FLAG_SET(pMcAtmEntry->Flags,
AA_IPMC_AE_CONN_STATE_MASK,
AA_IPMC_AE_CONN_DISCONNECTED))
{
AtmArpMcUnlinkAtmMember(
pAtmEntry,
pMcAtmEntry
);
//
// AE Lock is released within the above.
//
AA_ACQUIRE_AE_LOCK(pAtmEntry);
}
}
6/1/1998 JosephJ
Fixed above problem: AtmArpMcUnlinkAtmMember now doesn't release the lock.
6/1/1998 JosephJ
Other changes for today's checkin:
* Added extra asserts that timer is not active when the containing
structure is freed (look for TIMER_IS_ACTIVE)
* Added ULONG Filler to AAD_ALLOCATION so that allocated structures
retain 8-byte allignment -- not having this allighment was causing
the checked alpha build to fault when executing the following:
AA_PUSH_TO_SLIST(
&(pInterface->HeaderPool[HdrType].HeaderBufList),
STRUCT_OF(AA_SINGLE_LIST_ENTRY, &(pNdisBuffer->Next), Next),
&(pInterface->BufferLock.SpinLock)
);
(&(pInterface->HeaderPool[HdrType].HeaderBufList) needs to
be quadword (8-byte) aligned on the alpha, else it faults).
Note: SLIST_HEADER is a union which includes "LONGLONG", so
it WILL be quadword aligned provided it's hierarchy of parent
structures is aligned, no matter where this occurs within the
parent structures. Also added use of AA_INIT_SLIST to initialize
BufferPool slists.
* Fixed misuse of certain bits of the IPEntry.Flags which were resulting
in Flags getting into an incorrect state. ("|=" was used instead
of AA_SET_FLAG when setting AA_IP_ENTRY_ARPING and
AA_IP_ENTRY_INARPING).
* Make sure timer is stopped when unlinking a McAtmEntry.
* Protected adding AtmEntry by locking the interface list lock
in AtmArpMcHandleMulti. This also required some re-ordering
of reference counting.
6/9/1998 JosephJ
Note: intrinsic functions (/Oi) must be enabled in order for this
to compile under the win98 environment (otherwise it can't find
the prototoypes for functions like memcmp()).
6/9/1998 JosephJ
Support adding a canned set of arp entries -- this is a request as well
as useful for isolating problems with the arp server.
typedef struct
{
ULONG Sig;
ULONG Flags; // reserved.
ATMADDRESS; // binary format.
IPADDRESS; // network format.
}
ARPENTRYDATA;
6/30/1998 JosephJ
On ArvindM's advice: Changed AtmArpCompleteUnbindAdapter() so that it
doesn't block waiting for NdisCloseAdapter to complete if it returns
pending -- instead we return immediately and do the actual cleanup
in the AtmArpCloseAdapterCompleteHandler. This also eliminated a specific
bug where were were faulting because we weren't blocking when we should.
arpproc.c AtmArpAbortIPEntry: *ppNextIpEntry = pIpEntry->pNextToAtm;
this is done while holding the ATM_ENTRY's lock, but
in AtmArpInvalidateAtmEntry, we count the number of ip entries
in the atm_entry's list, and use this count, all without holding
the atm_entry's lock.
Also in AtmArpMcHandleMulti, marspkt.c, line 793 -- the list is added to...
we should fail the earlier SearchFor...
Also in AtmArpUnlinkIpEntryFromAtmEntry (utils.c), but no one seems to
call it.
7/8/1998 JosephJ
This concerns bug 191188(Intermittent loss of connections during
multicast IP and Ws stress).
There are three issues so far:
1. Sometimes, an AtmEntry gets in the CLOSING state, but it never goes
away. I still haven't figured why it doesn't go away, but the
workaround (checked in today) is for AtmArpSearchForAtmEntry to
clear the state from CLOSING if the entry is basically idle (no
IP entries, multicast entries and vc attached to it).
2. The mars server was sending us too-short packets. This is fixed
in the mars server (setting the ValidCounts field of the packet
in the mars server to FALSE). I also made a change to our
incoming packet handler to actually check packet length.
3. The multicast ip entries don't seem to ever get deleted -- I saw
over 500 entries after an hour or so of anilth's multicast stress.
This is still unresolved (bug#194613).
Note: on startup, the initial attempt to connect to the arp/mars server
often fails (when it's on the same machine as the client -- it's probably
an order-of load problem). Anyway, as a consequence of the call failing,
AtmArpInvalidateAtmEntry is called, which sets the AtmArpEntry state
to CLOSING -- it stays in that state for as long is the entry is alive.
However with the workaround #1 above, the CLOSING state is now cleared on
the first call to AtmArpSearchForAtmEntry after the initial vc is
cleared up.
7/8/1998 JosephJ
AbortIpAddress -- investigate impact of abort when using MCS
7/8/1998 JosephJ
One way to get the debugger to dump the calling function's name without
stopping:
db atmarpc!AtmArpSearchForAtmAddress "ln poi(esp); g"
0xFF8A6448
0xFF8A6448
0: kd> !aac ip[1]
[1] ATMARP_IP_ENTRY@0xFF9BBEE8 (104 Bytes)
aip_sig [0,4]: 0x41414950
IPAddress [4,4]: 0x56feffeb
pNextEntry [8,4]: 0x0
pNextToAtm [c,4]: 0xff98a108
Flags [10,4]: 0x6004 RESOLVED MC_NO_REVALIDATION MC_RESOLVED NUCAST
RefCount [14,4]: 0x2
pInterface [20,4]: 0xffa20028
pAtmEntry [24,4]: 0xffa1d868
pNextMcEntry [28,4]: 0x0
NextMultiSeq [2c,2]: 0x1
Timer [30,20]
ff9bbf18: 00000000 00000000 00000000 00000000 |....|....|....|....|
ff9bbf28: 00000003 00000000 f95dc48a ff9bbee8 |....|....|..].|....|
RetriesLeft [50,4]: 0x3
PacketList [54,4]: 0x0
pRCEList [58,4]: 0x0
Refs [60,5]
ff9bbf48: 01000000 ffffff01 ffffffff ffffffff |....|. | | |
7/14/1998 JosephJ
Looking at a an assert failure during reconfig -- the assert is
in AtmArpCallCompleteHandler (assert(rc==0):
else
{
//
// The Interface is going down: clean up everything first.
//
...
else
{
// MakeCall had failed. (And the IF is going down)
rc = AtmArpDereferenceVc(pVc); // Create Vc ref
AA_ASSERT(rc == 0); // The VC should have been deallocated
^^^^^^^^^^^^^^^^^^ above asser failed.
...
NOTE: AtmArpCloseCallMgr munges the pInterface but without holding
its lock (it's called either on a failed init or on
AtmArpShutdownInterface).
NOTE: in AtmArpMakeCallCompleteHandler(), we look at the
pInterface->AdminState without claiming its lock:
if (pInterface->AdminState == IF_STATUS_UP)...
NOTE: Since NdisCoDeleteVc is called only when rc==0 (in the context
of AtmArpDereferenceVc), if the ref count doesn't go to zero, NdisCoDeleteVc
will never be called. This means that the CloseCallMgr completion
handler will never get called, which means that we'll never complete
the reconfig request! So this explains why after hitting "g" after the
assert, ndis complained that I never completed the reconfig request.
So now I've got to track down why the ref count is still one. One thing
in our favor is that this is a freshly created call -- it was make call
that failed asynchronously.
Some things to note:
The only atm_entry has no vc links, and the vc has no atm_entry link.
The interface is closing and it's af-handle is null, indicating that
NdisClCloseAf has been called (as one would expect).
The vc flags are: outgoing, svc, closing.
rc = AtmArpDereferenceVc(pVc);
// Create Vc ref -- derefed when calling NdisCoDeleteVc
// Call ref -- derefed in closecall complete handler
// Atm ref. -- derefed when unlinking linkage with atmentry.
So in this particular case, the bug was that in the above code
in AtmArpCallCompleteHandler we need an extra dereference (for
call ref) just above the assert. So I added the following lines just
before the assert:
//
// Delete the Call reference
//
rc = AtmArpDereferenceVc(pVc);
AA_ASSERT(rc > 0);
Case closed. (Code checked in 7/17/1998, callmgr.c).
7/14/1198 JosephJ
QoS folks hit a bugcheck when sending on an unspecified flow.
(198733 bugcheck in atmarpc!AtmArpDereferenceAtmEntry with best-effort
flow installed).
7/17/1998 JosephJ
Above bugcheck was due to a hole in AtmArpLearnIPToAtm -- it would
not have a ref on the atmentry when it sent packets on the entry at the
end of the function. Fixed this by adding a temp ref. Also changed
some AA_ACQUIRE/RELEASE_IE/AE_LOCK_DPC in this function to the non-DPC
versions (they should have been the non-DPC versions all along).
7/17/1998 JosephJ
Another bugcheck hit during alpha mcast stress --
The bugcheck in the tick handler happened because of a bogus timer entry.
The timer entry itself was part of a freed structure that was formerly owned
by arpc, and was clearly a previously freed ATMARP_IPMC_JOIN_ENTRY (also,
the other, timers at that particular location in the timer list were all valid
join entries).
So the question is why was this join entry prematurely freed?
Looking at the code, I see one place where there is a race condition.
The entire join entry list is in general protected by the interface lock.
However, in AtmArpMcSendPendingJoins, the lock is released briefly while
processing the list -- this is not good and could definitely cause things
like starting a timer on a just-released (by some other thread) join entry.
I couldn't find any more race conditions or other problems on the join list--
everywhere else the IF lock is held the whole time, plus the ref counting
seems to be good everywhere as far as I can see.
The workaround, in AtmArpMcSendPendingJoins, is to go through the list of
joins with the interface lock held once, counting the number of joins that
need to be sent. I then allocate space to hold all the ipaddresses and masks
and then go through a 2nd time (still holding the interface lock), picking
up the ip addresses and masks. I then send each of these ip addresses
(the if lock gets released per send, but that's ok).
This is checked in today.
8/31/1998 JosephJ Promiscuous mode multicast
We treat promiscuous mode multicast as a special case:
On enabling, we send a "JOIN-all" request.
On disabling, we send a "LEAVE-all".
Note, tcpip keeps a ref count of apps which request a particular type of
filter, so if multiple apps request the same type, it sends down multiple
calls to enable it, but only ONE call to disable it -- when the last app that
requested it disables it. It does send each type independantly -- i.e., even
if promiscuous mode is already requested, it will send down a ALL_MULTICAST
if an app subsequently asks for that.
Summary of changes made:
arpif.c,util.c: new entrypoint AtmArpIfSetNdisRequest -- it calls
AtmArpMcAdd/DelAddress, specifying the entire address range.
ipmcast.c, marspkt.c: now deal with non-zero mask values in JOIN_ENTRY -- when
searching for a particular join entry, checks both IP address
and mask (so group 224.0.0.0 can coexist with the join
entry representing the entire class-d address space -- both have
IP address value of 224.0.0.0).
AtmArpMcHandleJoinOrLeaveCompletion -- has extra parameter: Mask.
atmarp.h: ATMARP_INTERFACE has a new DWORD: EnabledIPFilters -- used
to track whether promiscuous mode is enabled or not -- required
because we may get multiple enable requests but only one
disable request.
sources: cdefine PROMIS added, enabling promiscuous mode code.
Test Using \\anilth_1\allpkts\obj\i386\allpkts.....
Winsock(1)== all pkts == OID(0x20==NDIS_PACKET_TYPE_PROMISCUOUS)
Winsock(2)== all mcast pkts == OID(0x04==NDIS_PACKET_TYPE_ALL_MULTICAST)
Winsock(3)== all igmp pkts == OID(0x04==NDIS_PACKET_TYPE_ALL_MULTICAST)
We specifically look for OID NDIS_TYPE_ALL_MULTICAST and fail for
others.
Test cases: start allpkts.exe before/after someone has started sending
to a particular mcast exe. Boundary cases: have allpkts.exe running on
a machine which is also monitoring 224.0.0.0 and 239.-1.-1.-1.
Various combinations of MCS-served address ranges.
09/21/1998 JosephJ
Fix for bug# 225578 ATMAPRC Hangs when disabling in UI
Following changes to get rid of a atmarpc not completing shutdown because
there was an active vc that (the vc to the arp/mars server was always
in the closing state even as new calls were made to it).
* AtmArpAtmEntryIsReallyClosing() also check if there are any VCs active
when checking if the entry is truly idle.
* AtmArpSearchForAtmAddress -- fail if interface is down.
* AtmArpMakeCall -- fail if interface is down or if atm entry is REALLY
closing (i.e., AtmArpAtmEntryIsReallyClosing returns TRUE).
09/23/1998 JosephJ
A couple of anomalies:
1. When joining a vc-mesh mcast group for which there is already at least one
member and there is a local send already in progress, the local host
does not add itself to the vc mesh -- it gets the JOIN from the mars
server on the cc vc, but simply treates as the JOIN completion. Fix
is to ALSO process these "self-JOINS" which come on the ccvc to see
if they must be added to current P2MP vc-mesh connections.
[Fixed on 9/25/1998 checkin]
2. If a make-call fails with a non-NULL flow, the link between flow and vc
is not deleted when the call is cleaned up -- leaving the flow referencing
a dangling vc (only ref to the vc is the flow). This means that all
subsequent vc's created for that flow will not be linked to the flow and
so all send packets will need to explicitly look for vc's based on
flow characteristics. Fix is to delete the flow-vc association if it
exists when handling a failed makecallcomplete.
[Fixed on 9/25/1998 checkin]
NOTE: FlowsInfo's are not protected by a crit sect, so race conditions
are possible, for example:
(a) flow is removed (AtmArpGpcRemoveCfInfoNotify) at the same time that the
vc is closing (AtmArpCloseCall) -- both could try to un-link the
vc and flow at the same time. It doesn't help that both claim the vc
lock. Potential fixes: (a) add lock to flows or (b) use
Interlocked[Compare]ExchangePointer when modifying FlowInfo->pVc.
[Fixed on 9/25/1998 checkin, using the Inerlocked functions approach]
09/23/1998 JosephJ
Static validation of flows (when they are installed). BUG#156534
Here are the relevant structures...
typedef struct _TC_GEN_FLOW {
FLOWSPEC SendingFlowspec;
FLOWSPEC ReceivingFlowspec;
ULONG TcObjectsLength; // number of optional bytes
QOS_OBJECT_HDR TcObjects[1];
} TC_GEN_FLOW, *PTC_GEN_FLOW;
typedef struct _flowspec
{
ULONG TokenRate; /* In Bytes/sec */
ULONG TokenBucketSize; /* In Bytes */
ULONG PeakBandwidth; /* In Bytes/sec */
ULONG Latency; /* In microseconds */
ULONG DelayVariation; /* In microseconds */
SERVICETYPE ServiceType;
ULONG MaxSduSize; /* In Bytes */
ULONG MinimumPolicedSize; /* In Bytes */
} FLOWSPEC, *PFLOWSPEC, * LPFLOWSPEC;
Here is the validation plan (added to AtmArpGpcValidateCfInfo()) for the
fields of FLOWSPEC:
Ignored fields:
Latency
DelayVariation
Default handling
MinimumPolicedSize: ignored
TokenRate: BE:line-rate; GS:invalid CLS: invalid
TokenBucketSize: MTU
PeakBandwidth: line-rate
ServiceType:BE
MaxSduSize: MTU
Valid ranges
MinimumPolicedSize <= MTU
0<TokenRate <= LineRate
0<TokenBucketSize <=MTU
0<TokenRate <= PeakBandwidth
ServiceType: valid type
0<MaxSduSize <= MTU
MaxSduSize<TokenBucketSize
[Fixed in 9/25/98 checkin]
9/25/1998
Ageing of IP entries -- once resolved (via ARP reply typically) the IP
entries' ageing timeout is started.
RCE entries -- IP calls AtmArpIfInvalidate in which case we unlink the RCE
and IP, potentially deleting the ip if the refcount goes to zero.
What about the ageing timer for multicast entries?
pIPEntry->pAtmEntry set to NULL in:
AtmArpInvalidateEntry, which is called by ShutdownInterface, AbortIP,
AtmArpIncomingCloseHandler, AtmArpMakeCallCompleteHandler,
AtmArpCloseCallCompleteHandler (only if p2mp call).
Set to non-null in McHandleMullti
MarsHandleMulti marspkt.c line 1034: pAtmNumber = (PUCHAR)pAtmNumber + AtmNumberLength;
NOTE: Should be AtmNumberLength+AtmSubaddressLength when we decide to support subaddresses.
9/28/1998 JosephJ
arpif.c -- For WIN98 only, munged the 1st 2 bytes of the MAC reported up to
IP to be be 0x0a and 0xac -- this is so that it will be different from the
MAC reported by lane. This needs to be done only for win98 because on win98
ip/atm's mac size is 6 (same as LANE's) while on NT it is 7. [9/29 checkin]
9/28/1998 JosephJ
Fixed bug in AtmArpSearchForIPAddress -- when creating a new
MCAST entry, it was not chaining itself to the interface's list of
multicast entries -- instead it was just setting itself to be the first and
only element of this list! [9/29 checkin]
To clean up stale IPMCAST entries (bug#194613), added new function
AtmArpCleanupArpTable (called from AtmArpServerRefreshTimeout). This
function goes through the entries in pInterface->pMcSendList, calling
AtmArpAbortIPAddress on those entries which have no associated atm address.
(Note, this also required the fix to the bug in the above paragraph).
[9/29 checkin]
To clean up stale IPMCAST entries (bug#194613), added new function
AtmArpCleanupArpTable (called from AtmArpServerRefreshTimeout). This
function goes through the entries in pInterface->pMcSendList, calling
AtmArpAbortIPAddress on those entries which have no associated atm address.
(Note, this also required the fix to the bug in the above paragraph).
[9/29 checkin]
Fixed AtmArpMcHandleMARSFailure so that it doesn't restart timer when the
interface is not up -- this was causing the interface to never go away because
the refcount was 1 (for the timer) but the timer was never fired because the
interface was down. [9/29 checkin]
9/29/1998 JosephJ Task Offload.
ip\arp.c ARPRegister sets ai_OffloadFlags, TcpLargeSend
ip\arp.c ARPBindAdapter sets BindInfo.lip_OffloadFlags, lip_MaxOffloadSize and
lip_MaxSegments.
ip\init.c IPAddInterface sets it's IF.if_Offloadflags etc to these.
ip\iproute.c and ipxmit.c use these flags when deciding whether to do xsum
computation or not.
TCP_LARGE_SEND_OFFLOAD is used in tcp\tcpsend.c
IPSEC_OFFLOAD_* only set in ip\ai_OffloadFlags
10/06/1998 JosephJ QOS interface changes
Look at #if(NEWQOS) code in arpwmi.h
AtmArpWmiSendTCIfIndication -- uses new struct TC_SUPPORTED_INFO_BUFFER.
Took out check for BucketSize > MTU in qos.c, per ericeil.
Added support for task offloading (not enabled) -- #ifdef ATMOFFLOAD --
adapter.c: new functions AtmArpQueryAndEnableOffload and AtmArpDisableOffload
atmarp.h: Adapter struct had new sub-struct "Offload"
Also removed #ifndef NEWARP (obsolete) code from adapter.c, atmarp.h and
utils.c
[All of the above checked in today]
10/14/1998 JosephJ llipif.h change
From: Amritansh Raghav
Sent: Tuesday, October 13, 1998 2:27 PM
Subject: RE: new llipif.h
(i) Pass the old interface name as the DeviceName and NULL for the IfName
(ii) Pass 0 for Requested Index
(iii) You need to have place holders for the 3 functions, but you dont need
to call those functions ever.
Reasons:
(i) If you multiplex different connections over the same device, s.t. at any
given time only one connection is active, then the ifName allows you to
associate a name different that the device name with the interface. This
is done so that if you have a phonebook entry called Redmond and it is
connected, doing ipconfig shows Redmond and not NdiswanIpOut{Guid}
(ii) This allows wanarp to reserve certain indices so that the ifIndex
doesnt change when the router starts
(iii) The three functions basically change the info above
Changes made in ntentry.c, utils.c and callmgr.c
10/20/1998 JosephJ
Checked in above change
Other changes in todays checkin:
Added the assert AA_ASSERT(AA_IE_IS_ALIVE(pIpEntry)) pretty much every time
we lock the pIpEntry. This is because in principle it's possible for
the ip entry to be used justafter it's been removed from the the arp table.
arpproc.c:
AtmArpCleanupArpTable -- don't delete entries if they are in the ARPING
state.
AtmArpResolveIpEntry - don't do it if !AA_IE_IS_ALIVE
AtmArpAbortIPEntry - remove packet queue AFTER claiming lock on IpEntry for
the last time (otherwise others could queue packets in between us
taking the packets and freeing the entry.
AtmArpQueuePacketsOnIPEntry - dont do it if !AA_IE_IS_ALIVE
marspkt.c: AtmArpMcHandleMulti -- don't bindly assume that if the pAtmEntry
exists then it is compatible with the received MULTI pkt: i.e.,
MCS served or VC-mesh served. Added code to abort the IP entry if
they are incompatible.
sources: enabled ATMOFFLOAD and IFCHANGE1 (which enables new llipif.h change
referred to in the 10/14/1998 entry).
10/21/1998 JosephJ
Chun Ye made changes to the IPSEC task offloading -- ip\arpc.c:
10-19-98@14:42 chunye in arp.c v69 ipsec offload spec. change
So I reflected that in adapter.c,
11/12/1998 JosephJ
Qos.c -- had an incorrect check of size of pQosInfo in AtmArpGpcValidateCfInfo.
fixed and checked in today -- bug#249110
11/30/1998 JosephJ
Following is a potential fix for bug#256385.
arppkt.c v15 AtmArpSendInArprequest: release lock on failed exit
(I saw a stress case where the vc lock was not released
so and reviewed the code and found this place, although
it's unlikely that this case was hit during stress).
Following two are fixes for bug#256791
(IDS: MM Break in atmarpc!AtmArpMcUnlinkAtmMember)
callmgr.c v24 AtmArpCloseCall: pVc flags was being set here without
holding the vc lock.
ipmcast.c v11 McUpdateConnection: bail if vc is being closed. We
were hitting a case where we were trying to add a party
using an already-deleted entry, which we
avoid by this check. The use of already-deleted entry was
probably because we run through the list of entries
but release the atm lock in the middle -- fixed that as
well.
1/14/1999 JosephJ
Added code to fail initialization if adapter does not support atleast 9188.
adapter.c v22 #272355 DO not less than 9188 A
atmarp.h v16 #272355 DO not less than 9188 A
callmgr.c v25 #272355 DO not less than 9188 A
externs.h v23 #272355 DO not less than 9188 A
Added code to enable the ageing timer if the vc can't be associated with
a flow (because some other vc is already associated with the flow). We
made this fix in anticipation of the use of flows that could match multiple
VCs, shuch as a flow that matches "all data sent to UDP port 80."
arpproc.c v16 #272272 QOS: VCs don't age out
I noticed that we were zeroing out the info structure after picking
up the offload capabilities.
utils.c v17 Fix typo in setting task offloa
2/12/1999 JosephJ
This concerns the fact that we force IP to copy receive packets which
have multiple mdls.
The bugs in question are:
214430 PERF: atmarpc gives iprecv the wrong paramters for a multi-buffer packet
169877 ATM:ARPC: Bugcheck in TCPIP checksum, first MDL buffer
We need to put back the 1-line fix in AtmArpCoReceivePacketHandler
to avoid copy (arppkt.v8) which was backed out to "fix" 169877 (arppkt.v9).
However we do this only if the buffer length is at-least 512, so that we don't
report up partial IP and TCPIP headers.
---------- TDI\TCPIPMERGE\IPATMC\arppkt.c next ----------
683c683
< BufferLength - sizeof(AA_PKT_LLC_SNAP_HEADER),
---
> TotalLength - sizeof(AA_PKT_LLC_SNAP_HEADER),
2/12/1999 Josephj
arppkt.c above fix (#214430)
arpproc.c (1) incorrectly inserting mc ip entries into pMcSendList (#292305)
(2) AtmArpAbortIPEntry was pAtmEntry->pIpEntryList
callmgr.c Remove bogus assert in AtmArpMcTerminateMember
2/22/1998 JosephJ Inarp: dealing with multiple ip addresses.
arpif.c, AtmArpIfAddAddress: adds to list of addresses.
arppkt.c; AtmArpHandleInARPRequest -- sets src ip address to
be the FIRST ip address: pInterface->LocalIPAddress.IPAddress.
Fix is to cycle through, sending one inarp reply for each IP address.
NOTE: above fix not checked in -- saved in .\save02
2/25/1998 JosephJ
Unfortunately we have to back out YET AGAIN from the perf fix
(see 2/12/1999 note above) because large pings (eg ping -l 4000) doesn't
work -- bug#297784
See arppkt.c, line 710.
2/25/1998 JosephJ
When migrating arp/mars server to another machine on the fly, clients
bugchecked during mcast stress, because an mcast address switched from
being VC-mesh to MCS served, and we forget to deref the ipentry
before aborting the address: marspkt.c, look for
"HandleMulti: Type Mismatch!." Fix is to add the deref before
calling AbortIpEntry.
03/16/1999 JosephJ
arpwmi.c -- timothyw's code examination found some potential
cases (bug 303707), plus potential mem leak (bug 296220).
Trivial fixes.
callmgr.c -- fix for following bugs:
305905 *ATMARPC: bugcheck running TDI test
(needed to unlock vc if ref count is nonzero, instead of
assuming that the refcount was zero)
303172 *ATMARPC: doesn't call NdisClCloseCall when the miniport
fails to activate the VC
(if we get an incoming close call while the vc was not yet
connected, we need to act on it -- we "fake" the vc to be
active so that subsequent processing works).
qos.c -- fix for the following:
301210 *Traffic Control functional test failure on
ATM: expect ERROR_INVALID_PEAK_RATE, got
ERROR_INVALID_TOKEN_RATE
(fix is to change the error returned for this case --
see "3/15/1999 JosephJ: According to EricEil..." comment
in qos.c).
03/24/1999 JosephJ Fix for #310493
310493 ATMARPC bugchks on getting bad control packet
A rogue pkt was transmitted on the CCVC, causing all arp clients to bugchk
in AtmArpMcProcessPacket(...). Fix is essentially to change all length
variables in that function from SHORT to ULONG (SHORT vars could get -ve
values, which mess up comparisons and additions).
04/20/1999 JosephJ Proposed fix for 284644 Only one IP can be associated with
a PVC or group of PVCs
We're going to fix this in a general way by allowing static arp entries.
- On loading, we'll read a set of <atm-address>-to-<ip address> mappings and
populate the arp cache with that. Support is already present in atmarpc.sys
for static arp entries.
- User has to create custom PVCs for each destination from the call mgr
UI.
- User has to directly enter these mappings into the registry -- under
the atmarp settings under tcp settings for the adapter, we'll create a
new key:
StaticArpList - this is a REG_MULTI_SZ, with entries of the form:
<ip-address>-<atm-address>
<ip-address>-<atm-address>
...
5/19/99 ArvindM 330544 Fix for bugcheck in TickHandler
The suspect is a Join Entry that has been freed in AtmArpMcHandleMARSFailure
(the IF flags were 0x1100 in one case). The timer could have been in the
expired list held by TickHandler. Added code to ref/deref Join Entries.
8/4/99 ArvindM 382619 Race between Unbind and AfRegisterNotify handlers
NDIS isn't serializing calls to these handlers, so we hit a case where the
AfRegisterNotify handler is chugging along when the Unbind handler comes in
and deletes the Interface. Workaround is to note down the fact that we are
processing an Af Notification and in Unbind handler, wait for that notification
thread to complete. Added ATMARP_ADAPTER.UnbindBlock and an Adapter flag
AA_ADAPTER_FLAGS_PROCESSING_AF for this. Note that this only shortens the
window - the proper fix should be in NDIS.
08/09/1999 JosephJ Cleanup error handling code in DriverEntry
We were deleting the device object twice in the error path.
08/12/1999 ArvindM 386639 Access NULL McAtmEntry in McMakeCallComplete.
In McUpdateConnection, we used to simply pick up the first MC ATM Entry in the
list to use as the party context in a MakeCall. Now this entry could
be running the retry-delay timer. If this timer fires before the MakeCall
completes, it will overwrite the MC ATM Entry state to DISCONNECTED.
In McMakeCallComplete, we look for an MC ATM Entry whose state is WACK_ADD_xxx,
and fail to find one.
The fix is in AtmArpMcUpdateConnection: search the list of MC ATM entry
structures for one that is VALID and DISCONNECTED. If there isn't any, bail out.
If we find one, move it to the start of the MC Entry list, because AtmArpMakeCall
always uses the first entry!
08/13/1999 ArvindM 387755 Add OutstandingSends counter to VC structure.
We ran into an issue where we referenced a VC prior to sending a packet
on it, but by the time NdisCoSendPackets was called, the VC was closed
and DeleteVc'ed (it was owned by the call manager). So the call to NdisCoSendPackets
bugchecked because the NdisVcHandle was bogus. To fix this, use this counter
to keep track of outstanding (and on-the-verge-of-being-sent) packets on the VC. In
AtmArpCloseCall, don't close the call if this count is non-zero. In CoSendComplete,
check if the VC needs to be closed, and this count (after decrementing) just went
to zero. If so, call AtmArpCloseCall.
10/15/1999 JosephJ dealing with suspend/resume and multiple AF registrations
Fix for 415806:
Now AtmArpCoAfRegisterNotifyHandler will skip adapter-wide init
(calling AtmArpCfgOpenLISConfiguration and AtmArpAddInterfaceToAdapter)
if it's already been called before for this adapter.
The previously-checked-in version would return failure immediately if
it's been called for this adapter -- this was causing failure to re-add
the IF after a hybernate (we are not getting a unbind/bind after hybernate
because we passon the pnp-request up to IP which returns that it *can*
handle hybernate) -- so instead the AF goes away and a new registeraf
notification comes in on resume.
We *do* need to skip the adapter-wide init because doing it a 2nd time
causes some memory to be leaked.
Reference in a new issue View git blame Copy permalink