Read MAC Address

[christian_rackl]

Can anybody tell me how to read the network-cards mac address?

I know there is a way in the win32 api, but i didnt find the function netbios translated for visual fortran.

also i tried to call the dll directly but i could not get it working

thank you everybody in advance

Chris

[Intel_C_Intel]

Chris,
I have been using a very inelegant method for some time now. I would also like a Win32 API method, so if others can please lend a hand?

My technique is to redirect the output of nbtstat to a text file which I then parse for the MAC. Open a command shell and type;

nbtstat -a systemname

where "systemname" is you computer's netbios name. If you prefer, nbtstat has the option to use an IP Address rather than netbios name.

Good Luck, Cliff

[Jugoslav_Dujic]

See this thread -- (follow also the link to MS KB Article for a C example, but I think its translation to F90 is pretty straightforward).

Jugoslav

[christian_rackl]

Thank you - this hint has brought me quite far!

I still get stuck at the definition of the ncb struct.

according to dfwinty.f90 ncb_command can either be of type integer*1 or character*1 depending on __KEEP_OLD_CHARACTER_ARRAYS

in my case it seems to be a character value. therefore i cannot define NCBASTAT as integer value. so whats the corresponding character value?

thank you

[Jugoslav_Dujic]

D'oh -- it's a mis-mistranslation in DFWINTY.f90.

Once upon a time, C structures in DFWINTY.f90 were mistranslated so that

C declaration BYTE item[Length]became character item(length) instead of character(length) item. Also, some BYTEs and UCHARs (intended as bitfields) were translated as CHARACTERs instead of INTEGER(1)s. Then,CVF folksfixed it and included __KEEP_OLD_CHARACTER_ARRAYS preprocessor constant just in case someone wants the old behaviour.

Then, apparently, in case of T_NCB, they got it wrong way round. Instead of

!DEC$ IF DEFINED(__KEEP_OLD_CHARACTER_ARRAYS)
character(1) ncb_command ! knowns UCHAR
!DEC$ ELSE
integer(UCHAR) ncb_command ! knowns UCHAR
!DEC$ ENDIF

they wrote the reverse somehow. (ncb_callname and ncb_name should be strings)

<>

So, your options are:

a) Roll your own correct MY_T_NCB structure in a separate module, with INTEGER(1) (=INTEGER(UCHAR)) instead of CHARACTER. Rewrite the INTERFACE block to reflect new state.

b) Use the current definition from DFWINTY, but use TRANSFER to "hack characters into integers", e.g.

NCB%ncb_command = TRANSFER(NCBSEND, "A")

Good luck,

Jugoslav

[christian_rackl]

I found a sample source for the retrieval of the mac address written in c.

there they often use the memset function to initialize the structures.

is tis also important in fortran? if so, how can it be done efficiently?

thanks everybody

[Jugoslav_Dujic]

call ZeroMemory(loc(ncb), sizeof(ncb))

Jugoslav

[christian_rackl]

Thank you!

The program works fine now!

Does anyone need the complete source?

[Steven_L_Intel1]

It's actually a bit more complicated than Jugoslav explains.

He is correct that fields which are character strings had been incorrectly declared as arrays of single characters in earlier versions of VF. In 6.1 or 6.5, I can't tell which, the declarations were changed to use the KEEP_OLD_CHARACTER_ARRAYS so that arrays of characters were turned into character variables. But as late as 6.5, fields such as ncb_command were still defined as character.

6.6 did a new translation, but got this case more wrong. Now, fields that were of type UCHAR - a single character - were declared by default as CHARACTER(1) with the "old" define being an integer(UCHAR) - even though that "old" declaration never existed in the past.

What I think has to happen is that all of the non-array UCHARs need to be turned into integer(UCHAR) instead of CHARACTER(1). But that would break existing code, so I'm somewhat reluctant to change it now. We'll have to see how extensive the error is - noting that it's been that way for many years.

[Jugoslav_Dujic]

FWIW, I vote for the change (fix). I examined (CVF) Dfwinty.f90 and UCHAR occurs on 126 places, but all of them are very exotic structures I've never heard of (Find in Files accross SDK .h files also shows 490 entries on exotic headers). The only "non-exotic" ones (i.e. that could IMO reasonably be used in CVF users' codebase) are T_NCB and in_addr (from Winsock).

Also, the good thing is that the change will trigger compile-time errors about type mismatch, so that, even when the compatibility breaks, users will be able to fix the code back easily rather than having silent misbehaviour.

Jugoslav

[christian_rackl]

It seems to me that it would be best if i writethe usedmodules myself with use of the w32 platform documentation

so i do not need the dfwinty.for anymore:

BTW what does the "!knowns" mean??

so this is my module:

Code:

 module mymodule
        integer, parameter :: POINTER_LEN = INT_PTR_KIND() ! 4 for WIN32 systems
                                                           ! 8 for IA64 systems
        integer, parameter :: UCHAR  = 1        ! INTEGER(1)
        integer, parameter :: PUCHAR   = POINTER_LEN      ! INTEGER(4)
        integer, parameter :: WORD   = 2        ! INTEGER(2)
        integer, parameter :: LPVOID   = POINTER_LEN      ! INTEGER(4)
        integer, parameter :: HANDLE = POINTER_LEN ! INTEGER(4/8)
        integer, parameter :: DWORD  = 4        ! INTEGER(4)
  !ncb_commands
        integer, parameter :: NCBASTAT = #33
        integer, parameter :: NCBRESET = #32
        integer, parameter :: NRC_GOODRET = #00
     TYPE T_ADAPTER_STATUS
    SEQUENCE
       character(6) adapter_address
       integer(UCHAR) rev_major ! knowns  UCHAR 
       integer(UCHAR) reserved0 ! knowns  UCHAR 
       integer(UCHAR) adapter_type ! knowns  UCHAR 
       integer(UCHAR) rev_minor ! knowns  UCHAR 
       integer(WORD) duration ! knowns  WORD 
       integer(WORD) frmr_recv ! knowns  WORD 
       integer(WORD) frmr_xmit ! knowns  WORD 
       integer(WORD) iframe_recv_err ! knowns  WORD 
       integer(WORD) xmit_aborts ! knowns  WORD 
       integer(DWORD) xmit_success ! knowns  DWORD 
       integer(DWORD) recv_success ! knowns  DWORD 
       integer(WORD) iframe_xmit_err ! knowns  WORD 
       integer(WORD) recv_buff_unavail ! knowns  WORD 
       integer(WORD) t1_timeouts ! knowns  WORD 
       integer(WORD) ti_timeouts ! knowns  WORD 
       integer(DWORD) reserved1 ! knowns  DWORD 
       integer(WORD) free_ncbs ! knowns  WORD 
       integer(WORD) max_cfg_ncbs ! knowns  WORD 
       integer(WORD) max_ncbs ! knowns  WORD 
       integer(WORD) xmit_buf_unavail ! knowns  WORD 
       integer(WORD) max_dgram_size ! knowns  WORD 
       integer(WORD) pending_sess ! knowns  WORD 
       integer(WORD) max_cfg_sess ! knowns  WORD 
       integer(WORD) max_sess ! knowns  WORD 
       integer(WORD) max_sess_pkt_size ! knowns  WORD 
       integer(WORD) name_count ! knowns  WORD 
     END TYPE
     TYPE T_NAME_BUFFER
    SEQUENCE
       character(16) name
       integer(UCHAR) name_num ! knowns  UCHAR 
       integer(UCHAR) name_flags ! knowns  UCHAR 
     END TYPE
  type t_astat
   SEQUENCE
   type(T_ADAPTER_STATUS):: adapt
   type(T_NAME_BUFFER):: NameBuff(30)
  end type
  type t_my_ncb
   SEQUENCE
   integer(UCHAR):: ncb_command
   integer(UCHAR):: ncb_retcode
   integer(UCHAR):: ncb_lsn
   integer(UCHAR):: ncb_num
   integer(PUCHAR):: ncb_buffer
   integer(WORD)::  ncb_length
   character*16::  ncb_callname
   character*16::  ncb_name
   integer(UCHAR):: ncb_rto
   integer(UCHAR):: ncb_sto
   integer(LPVOID):: ncb_post
   integer(UCHAR):: ncb_lana_num
   integer(UCHAR):: ncb_cmd_cplt
   character*10::  ncb_reserve
   integer(HANDLE):: ncb
_event
  end type

 end module

[Steven_L_Intel1]

I am not sure what !knowns means - it could be a note that the datatype is directly translated from C.