Mux example from XP DDK.

NTDEV
1

Hi,

A) I need to write driver which has to emulate few network cards from
only one physical network card. Every virtual card should be part of the
TCP/IP network connection with full functionality.

  • Is it possible to create such driver on the base of MUX example?
  • Could I configure such connection via DHCP service?

B). I build and run this example. With VLAN ID set to 0 I could use
first netwok connection for Internet browsing. But I see two another
problems.

  • All my connection based on the virtual miniports, except first one,
    have status “nplugged Network Cable”. Is it ok?

  • If I change miniport VLAN ID in first working connection from zero
    to any other digit this connection loose its functionality. Is it
    valid behaviour?

Thank in advance and sorry for naive questions.

–
Best regards,
Sergey mailto:kipnis@wp.pl

2

> - Is it possible to create such driver on the base of MUX example?

Yes.

  • Could I configure such connection via DHCP service?

If your network frame format does not spoil DHCP frames - then yes.

  • All my connection based on the virtual miniports, except first one,
    have status “nplugged Network Cable”. Is it ok?

No. Be sure you properly respond to media sense OIDs and properly propagate the
media sense status.

  • If I change miniport VLAN ID in first working connection from zero
    to any other digit this connection loose its functionality. Is it
    valid behaviour?

Yes, any other VLAN adapters on the network must also change their IDs.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

3

Hello Sergey,

Friday, February 20, 2004, 12:56:23 PM, you wrote:

SK> - If I change miniport VLAN ID in first working connection from zero
SK> to any other digit this connection loose its functionality. Is it
SK> valid behaviour?

If I have two miniports and enable both I have crash after an attempt to
use network.

It looks as something wrong with receive buffer(data should be copied
from it) in the Realtek NIC miniport driver. Source of data is addressed as 0x22. Wrong.

This function is called by mux!MPTransferData+0xcb
[d:\b2\driver\miniport.c @ 1173].

I do not do TODO in protocol.c
// TODO: Allocate a packet pool and buffers for send & receive.
//
Driver is used as is.
Where may be a problem?

–
Best regards,
Sergey mailto:kipnis@wp.pl

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000022, memory referenced
******************************** fault here
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f9df9817, address which referenced memory

Debugging Details:

READ_ADDRESS: 00000022

CURRENT_IRQL: 2

FAULTING_IP:
RTL8139!RTFast_TransferData+ab
f9df9817 f3a5 rep movsd

DEFAULT_BUCKET_ID: DRIVER_FAULT

BUGCHECK_STR: 0xD1

LAST_CONTROL_TRANSFER: from f9962a42 to f9df9817

TRAP_FRAME: 80539164 – (.trap ffffffff80539164)
ErrCode = 00000000
eax=00000000 ebx=000000b6 ecx=0000002d edx=000000b6 esi=00000022 edi=824c2a28
eip=f9df9817 esp=805391d8 ebp=805391f4 iopl=0 nv up ei pl nz na po cy
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010207
RTL8139!RTFast_TransferData+0xab:
f9df9817 f3a5 rep movsd
Resetting default scope

STACK_TEXT:
805391f4 f9962a42 8256ee98 80539360 826a5008 RTL8139!RTFast_TransferData+0xab
80539220 f996396d 826b4f40 80539464 00000014 NDIS!ndisMTransferData+0xf6
80539240 f96f920b 80539268 826b4f40 80539464 NDIS!NdisTransferData+0x19
80539278 f9962a42 824f0d78 80539360 826e7d30 mux!MPTransferData+0xcb [d:\b2\driver\miniport.c @ 1173]
805392a4 f7fb2844 82596840 80539464 00000014 NDIS!ndisMTransferData+0xf6
805392c4 f7f87977 8258f208 80539464 00000000 tcpip!ARPXferData+0x24
80539364 f7f823b0 82591288 82578b6a 82591350 tcpip!IPRcvPacket+0x2f6
805393a4 f7f9890c 00000001 80539464 82578b48 tcpip!ARPRcvIndicationNew+0x143
805393d4 f996e5f5 8258f208 80539464 82578b48 tcpip!ARPRcv+0x38
80539408 f96fbd2d 00000008 80539464 82578b48 NDIS!EthFilterDprIndicateReceive+0x20a
80539484 f996e4c9 82670438 80539464 82578b48 mux!PtReceive+0x42d [d:\b2\driver\protocol.c @ 1806]
805394b8 f9df96fd 826a5d98 826a5008 82578b48 NDIS!EthFilterDprIndicateReceive+0xde
805394f8 f9df9503 826a5008 826a5060 8267a480 RTL8139!RTFast_IndicatePacket+0x7b
80539510 f9964049 006a5008 80542000 80541da0 RTL8139!RTFast_HandleInterrupt+0x2f
8053952c 805317a9 826a5074 826a5060 00000000 NDIS!ndisMDpc+0x100
80539540 80518023 80541da0 ffdffc50 00000000 nt!KiRetireDpcList+0x46
80539550 80531722 00000000 0000000e 00000000 nt!PopIdle0+0x47

FOLLOWUP_IP:
RTL8139!RTFast_TransferData+ab
f9df9817 f3a5 rep movsd

SYMBOL_STACK_INDEX: 0

FOLLOWUP_NAME: MachineOwner

SYMBOL_NAME: RTL8139!RTFast_TransferData+ab

MODULE_NAME: RTL8139

IMAGE_NAME: RTL8139.SYS

DEBUG_FLR_IMAGE_TIMESTAMP: 3b148fe1

STACK_COMMAND: .trap ffffffff80539164 ; kb

BUCKET_ID: 0xD1_RTL8139!RTFast_TransferData+ab