OS/2, Realtek and NIC drivers

[Ben]

By r8169-0.3.1.wpi not working I meant that while it installed without error, with everything in place and as expected, neither TCP/IP nor MPTN worked.

No errors showed up... at least during the install. If there are logs to look at, I know not of them.

Tomorrow I have made time to give this another go.

I will remove all other NICs, (re)activate the onboard chip set and try the three drivers individually. I will jot down any peculiarities and note what works and doesn't work, after setup is complete, and I will post the findings in more detail... hoping to find something to add.


With respect to posting a bug report I say again that after having posted many bug reports, (many of them repeated), over the years, virtually every single, one of them has been a complete waste of time.

IIRC, only one, single, thing that I have ever reported was addressed... and that took many years and five or six bug reports/personal E-mails to the programmer(s). I simply do not have that kind of time to waste. It is a more efficient use of my time to simply go buy new hardware for drivers that I know work.

The obvious and frequent response to that question is that "if you do not report the bugs then don't expect them to get fixed", but like I said, bugs getting fixed by bug reports submitted happens only in dreams; whether I report them or whether I do not, there is no resulting difference! It is like buying a lottery ticket; you are buying "hope"... with no chance to win!.. only an illusion.

While others may have a higher success rate than I have, many, many OS/2 users here and elsewhere, have reported similar in the past.

In fact, I would not at all be surprised if others came out to report similar, and to support my statement via reply to this thread... though I am not encouraging it, because there is no need for redundancy or corroboration; it is common knowledge.

Programmers complain that users do not post bug reports and people who post bug reports stop making them because it is useless.

It is a circle jerk.

I could give many examples with copies of reports and E-mails but, why? It would serve no purpose whatsoever other than to cascade a series of meaningless typing.

Having said that, I most certainly do appreciate every and all minutes anyone has ever spent helping out the OS/2 community whether for pay or for spiritual growth... whatever your definition of that term defines.

And I mean what I say... unlike most people... both the good and the bad. So, now a nit has been picked, and a tick-comb has been used.

Anyway...

Tomorrow I will post my findings... maybe something new will turn up, or a non-obvious, flaky, install will be supplanted by a true one and I will have good news to post. If not... then there is always the "drop test"... but that is a story for another day... and if someone wants to hear it, then they will have to ask! But if you know what the "flotation test" is, then you already know the story... (and you don't).

[Neil Waldhauer]

Well, what does it mean to say

neither TCP/IP nor MPTN worked

?

Many times with the Realtek drivers, and I mean all of them, I had to specify the Network Address in the driver parameters. Then it worked fine. If this has happened to you, you'd install, get no error messages, and things in general won't work.

More important, if you try netstat -n, you'll discover that the physical address of the network adapter is 0. If you correct this with the Network Address parameter, networking will work well.

[Ben]

Well, what does it mean to say

neither TCP/IP nor MPTN worked

?

I made no additional adjustments other than adding a "6" to the TCP/IP protocol in the MPTN config to denote "Ethernet".

For me, that has always been enough to get networking cards to work.

Many times with the Realtek drivers, and I mean all of them, I had to specify the Network Address in the driver parameters. Then it worked fine. If this has happened to you, you'd install, get no error messages, and things in general won't work.

More important, if you try netstat -n, you'll discover that the physical address of the network adapter is 0. If you correct this with the Network Address parameter, networking will work well.

OK. I'll give that a go.

One more thing that I thought I had put up here, but haven't;

After my initial replacement of the rtgnd13 driver with the Mensys  one, I started getting a popup window stating;

"UPM0004C:The program failed to start. The Exit code returned from the program is :17"

The above is from the Mugwepop.exe program when startup2.cmd is auto-executed in an XWorkplace Startup Folder.

This has never gone away since the initial driver change post hardware upgrade.

Initially, I took a completely working and configured OS/2 hard drive and moved it directly into this new board... which is an ASUS P5G4IT-M LX Series motherboard.

For those who have been following this, I have reattempted to install the rtgnda13 driver and then the Mensys one, both have yielded the exact same results; TCP/IP works, no MPTN.

I have not yet tried the GenMAC driver; that one is next.

Neil, I just did a "netstat -n" as you suggested and the physical address is indeed set to a whole bunch of zeros!

Now, the question is, how do I find out the physical address, (MAC address), of my card? I have always used "netstat -n" to get it.

[Doug Bissett]

With respect to posting a bug report I say again that after having posted many bug reports, (many of them repeated), over the years, virtually every single, one of them has been a complete waste of time.

Not my experience, at all. You DO have to take the time to properly create a report. As I said earlier, a report that says "It doesn't work", with no supporting documentation, or description of what doesn't work, will often be ignored. Many people also fail to follow up and answer the developers questions. I don't blame them, at all, for ignoring such reports.

No errors showed up... at least during the install. If there are logs to look at, I know not of them.

Which "install" are you talking about. The WarpIn installer simply puts the proper files in place (look at the WarpIn log). You then have to use the Adapters and Protocols tool (AKA MPTS), or the new NAPS tool (which is broken in eCS 2.2 beta), to configure the Network, or manually change PROTOCOL.INI (correctly), to "install" the NIC. You may also need to do the complete power off (pull the plug, and remover the battery, if it is a laptop, to get the NIC reset so that it will communicate over the cable).

both have yielded the exact same results; TCP/IP works, no MPTN.

What do you mean by "no MPTN"? There is TCPIP, and there is NETBIOS. I assume you mean no "MultiProtocol Transport Services", but that isn't true, because you say that TCP/IP works. So, the bug is probably that NETBIOS is not working. I need to see if I can set up a couple of machines with that installed, and try it (it has been many years).

Neil, I just did a "netstat -n" as you suggested and the physical address is indeed set to a whole bunch of zeros!

Now, the question is, how do I find out the physical address, (MAC address), of my card? I have always used "netstat -n" to get it.

Do you have another OS installed? Try using that to find the MAC address. If not, just create a number that is not all zeros, with the same number of digits, and use that. The all zeros MAC address is, in fact, a valid MAC address, however, it seems that many routers will, incorrectly, reject it as being invalid. It can also cause a problem, if there are two, or more, of them doing the same thing, on the same subnet.

In Linux, you can do this:

Code: [Select]

    As the root user (or user with appropriate permissions)
    Type "ifconfig -a"
    From the displayed information, find eth0 (this is the default first Ethernet adapter)
    Locate the number next to the HWaddr. This is your MAC address

So now, after much prompting, it seems that we have a suspect area to investigate (NETBIOS, and/or the all zeros MAC address). If your other problem reports went like this, it is not surprising that you have not had good results from making problem reports.

[Ben]

Using "netstat -arp" or "arp -a" yields the following information:

          ARP table contents:

interface     hardware address         IP address   minutes since last use
  lan0       0 :18:e7:18:36:89          192.168.0.2            2

Note that there seems to be a digit missing; a space between the first zero and the first colon.

I filled this in with another zero, (in the NIC configuration settings in Adapters and Protocols). This caused the TCP/IP and the LAN services, (in this case Netbios), to stop working; before this change, (no entry in the "Network Adapter Address"), TCP/IP worked fine.

Removing the 12 digit hex number brought back the TCP/IP connection... and I am using it to type this message.

At this point I suspect that Neil is on the right track, (at least it is something tangible to work with), but something seems wrong with the adapter address that arp is giving me. I have never seen one with a blank space before.

Of course, I cannot cut and paste the address for the entry field will not accept blanks or colons. It only accepted 0018e7183689... which as I said, doesn't work.

WRT r8169-0.3.1.wpi, I say this; Installation of all drivers went without incident. "Did not work" means everything installed fine and without error, but nothing worked; For the extent of this thread that means no TCP/IP and no Netbios.

I am only interested in those two protocols; the rest are of no value to me.


WRT "bug reports" I have wasted far too much time on that topic.

WRT the "NAPS Tool" I am assuming that you mean the little popup window that prompts the user to select from a choice of available LANs; Lan0 or Lan1, etc.

That pops up and I use it, but if it is broken I have no way of testing it.

I do not have *nix installed; I do have W7 on this same machine.

WRT to this being a report, it is not. It is a troubleshooting and diagnoses session. I would have thought that would have been obvious... to everyone... since this is a Forum and not a Technical Bug Reporting site.

People making bug reports are not programmers, nor do they have ESP. If a programmer wants specific information then use the damn machine that he is trying to work with and send a simple E-mail... or can he only communicate with jargon?

Better yet, make widely available everything that he needs to know and not keep it in his head to make him feel falsely superior as a soothing mechanism for his personal insecurities and inadequacies.

Stop browbeating the user who can only learn things through reading and successful communication and not merely by strong desires that the user become knowledgeable through deep wishes and empty words that communicate nothing of value, but serve to clutter the Internet and to simulate a DoS attack.

Now... back to the topic of importance and relevance.

I will boot to W7 and see if it can give me a better Adapter Address than ARP does.

[Ben]

OK.

Two things of note.

ARP -a or netstat -arp in the above posting is reporting the hardware address of a NIC on another machine. This other machine is connected to this one. But there is nothing else given by ARP -a or netstat -arp. I have no idea why this is so, but I'm sure that someone in the OS/2 community does.

Secondly, W7 was able to successfully produce my Adapter Address.

I entered it into the Network Adapter Address entry field for the Mensys RTL driver, (via "Adapters and Protocols"), and rebooted. This time the TCP/IP works... but the Netbios still does not.

Thanks, Neil, it was a good idea, but has not been effective. However, the Physical Address of my onboard NIC is now properly displayed in "netstat -n"... which is something.

Now I have to find that GenMAC RTL driver and see if that works.


Addendum:

But before I do that, there is one more thing of note:

When I first tried the onboard NIC using the rtgnda13 driver that was already installed, (I moved my hardrive from my previous machine to this one), Netbios did not work.

However, when I disabled the onboard NIC and installed my previous NIC in a PCI slot and rebooted, everything worked fine. But I needed that NIC for another machine. I reactivated the onboard NIC and installed the Mensys RTL driver.

Since then, Netbios will not work with either of these NICs; I keep getting that Mugwepop.exe popup when I try to logon the network.

I suspect that installing the Mensys driver altered something else that is not being updated... what that can be I yet, have no idea; time will tell.

[Doug Bissett]

Note that there seems to be a digit missing; a space between the first zero and the first colon.

That seems to be a cosmetic thing. I see the same.

It only accepted 0018e7183689... which as I said, doesn't work.

I haven't needed that with any of my Realtek NICS, using the Multimac driver. When I was using RTGNDA, I needed to modify the rtgnda.nif file with this section, at the end:

Code: [Select]

[NETADDRESS]
tag = NETADDRESS
display = "Network adapter address"
type = hexstring
strlength = 12
default="3c970e67241b"
optional = yes
editable = yes
help = "NETADDRESS alternates the MAC address of the adapter
with the one fixed in the hardware(in the EEPROM)."
3c970e67241b is the MAC address of the Realtek NIC. Perhaps it needs the quotes.

WRT the "NAPS Tool" I am assuming that you mean the little popup window that prompts the user to select from a choice of available LANs; Lan0 or Lan1, etc.

No. It is a replacement for the Adapters and Protocols configuration program (AKA MPTS). The fixed one is working well, for me.

Since then, Netbios will not work with either of these NICs; I keep getting that Mugwepop.exe popup when I try to logon the network.

Interesting. Is there a program by that name somewhere on your machine? I find no such thing on my systems.

It appears that you have now isolated the problem to NETBIOS, but it would be good for somebody else to verify that. I will try to find the time to install NETBIOS, on two machines using the Multimac Realtek driver, to see if it will work, or not. If that fails, you have three options: 1) report it properly. 2) use a different NIC, 3) Change to NETBIOS over TCPIP. If I can make it fail, I will report it, but a second report would help to get attention. If it doesn't fail, you need to look elsewhere for your problem. A new install would probably help in that case, but I have a bit of work to do to do a test.

[Ben]

C:/MUGLIB/MUGWEPOP.EXE 3-23-04  10:56a          7,365

It has to do with the Netbios logon. It is in the same folder where Mugwepop.exe resides.

You probably do not have it because you have removed it or have not installed it, instead choosing to use SAMBA. And if I knew that the OS/2 handlers of  SAMBA had solved the EA problems, (particularly WRT PMVIEW and images), I'd give it another go, because it does solve a lot of problems that exist with OS/2 LAN Services... it was just that for me the problems with SAMBA were worse than the problems that it solved.

As I said before, the last time I communicated with them, they had done nothing to address those issues and had no intentions of doing so. That was a few years ago... maybe I'll send them another E-mail.

But, WRT Mugwepop.exe, this program strikes a weak bell in my memories from back in a time period when I knew plenty about all things networking WRT OS/2.

The problem with becoming proficient with something is that based upon your skill/knowledge you can put together something really good! Then you do not have to look at it again for ten years... and by then you have forgotten large chunks of it from a complete lack of use.

The only solution then is;

• Go through the frustration of relearning it in long cycles.
• Get someone else to do it or
• Keep it fresh in your mind by wasting time doing the necessaries to keep it up.

Of course, some skills you keep fresh because your way of life keeps it fresh. With everyone, it is a choice. Keep one fresh at the expense of another.

Oh, well. It is just one of the troughs of those long-term cycles reoccurring.

Hmmph! 8|

Anyway. I'll solve it. It is just a question of how much piss and vinegar I have to spit first.


These days I covet every moment of my time and give it up only with a battle. In fact, one of the reasons that I use OS/2 is because ONCE SETUP, it will work very well indeed, with little need for attention... unlike any flavour of Windows or *nix... which require nursemaiding and constant attention if only in the incessant learning of arcane parameters designed to be jampacked full of obscure, completely unintuitive, jargon that is designed to appeal to the the mind of the socially inept, introvert.

Being able to use it or learn to use it, is irrelevant - though clearly it is a personal thing - Why? I simply have more important things to do with my time... though in my youth, I did waste much time there, I have grown. So, now when I have to "waste my time" (re)learning this, it bothers me; I feel like I'm being robbed!

But, like any sh*t job, it is best to just do it and be done with it.

But enough for today. The rest will be handled tomorrow... if I can keep it open that is...

[Doug Bissett]

It appears that you have now isolated the problem to NETBIOS, but it would be good for somebody else to verify that. I will try to find the time to install NETBIOS, on two machines using the Multimac Realtek driver, to see if it will work, or not. If that fails, you have three options: 1) report it properly. 2) use a different NIC, 3) Change to NETBIOS over TCPIP. If I can make it fail, I will report it, but a second report would help to get attention. If it doesn't fail, you need to look elsewhere for your problem. A new install would probably help in that case, but I have a bit of work to do to do a test.

Well, that was an interesting exercise. I discovered two things:
1) NETBIOS works fine with the latest Multimac driver for Realtek devices, in either direction.
2) Apparently it is just NETBIOS over TCPIP that does not coexist with SAMBA. NETBIOS seems to be okay with it (which makes sense after thinking about it).

So, it would seem that you have some other problem...

[Alex Taylor]

Examine \ibmcom\lantran.log for clues, or better still, post it here.

[Ben]

Here is the Log:

file:///C:/IBMCOM/LANTRAN.LOG

--
IBM OS/2 LANMSGDD [05/21/04] 6.00 is loaded and operational.
IBM OS/2 NETBEUI 6.00.0
NETBEUI: Using a 32-bit data segment.
IBM OS/2 NETBIOS 4.0
Adapter 0 has 223 NCBs, 130 sessions, and 20 names available to NETBIOS applications.
NETBIOS 4.0 is loaded and operational.
R8169 NDIS device driver @#D Azarewicz:0.3.1#@##1## 17 May 2013 08:46:29     DAZAR1    ::::1::SVN253@@Realtek 8169/1Gb PCIe MAC Driver
R8169 Hardware detected: RTL8168e/8111e.

IBM OS/2 LAN Netbind

--

That's all that there is.

The Mugwepop.exe file first showed itself after I installed the Mensys driver. And no matter what I do, it will not go away, even if I go back to the once fully working combo of the rtgnda13 driver and PCI NIC, (not the onboard RTL chip). Now that is not much to go by, but it is the dividing line. Whether the timing is merely coincidental or not, I cannot say. Whether it is the cause, a manifestation of the cause, or entirely irrelevant remains to be determined.

After I post this I'm going to give the GenMAC driver a go.

[Ben]

GenMAC WPI install detected an RTL 8168 chipset and installed from there.

In Adapters and Protocols I changed over the Mensys driver for the GenMAC driver and rebooted.

I could no longer ping anything including this machine, ping presenting only "sento: No route to host". I ran \bin\setup.cmd, (sometimes that will alter things), but this had no effect.

I added the Adapter Address to the Netbios configuration and rebooted and nothing changed. I had to switch back to Mensys driver to send this message.

The old RTL 8169 NIC that I used for many years with the rtgnda13 driver should work. As I have said, it did work on this machine when I first put it in, but I can no longer get it to work with Netbios. It works now exactly as the Mensys driver does allowing good TCP/IP but no Netbios. Obviously something was changed that wasn't changed back.

Find that and I'll be on the track of the problem and on the path to a solution. At least, that's my conclusion at this point.

Now I have two options;

• Hunt down that problem or
• once more consider SAMBA

If anyone else has a suggestion now is the time.

In the meantime I will see what has changed with SAMBA in the interim.

[Alex Taylor]

CONFIG.SYS, PROTOCOL.INI and IBMLAN.INI all have to be in agreement with each other as far as how each network interface & protocol is configured.  Probably one or more of them got out of sync with the others when you started changing the NIC drivers around.

If you post all three somebody might be able to find the culprit.

[Doug Bissett]

Some time back, you posted:

"Found Realtek NIC at bus 3:1:0: 10EC:8169 version 3 (RTL8169sb/8110sb)"

Now, Lantran.log says:

R8169 Hardware detected: RTL8168e/8111e.

The first one, is the one that has always worked with Multimac, for me. The second one is probably the same as the one that never worked, for me, until the very latest driver was produced (which seems to be the one that you are using).

Which one is it? Use RtlChipId.exe to find out. The "e" is probably "evl" (sort of like "evil").

I agree with Alex, that something has got out of sync somewhere.

What I would do is this:
Go to Adapters and Protocols (or whatever it may be called), and delete ALL of the entries. Then put the device back in, and add the appropriate protocols. Try it (after reboot) without changing anything, and check to see if the MAC address got picked up. If not, you need to add that. Then, try the rest of what you need to work. If it works, you are done. If not, I would start looking in IBMLAN.INI, since that is the one that is unique to NETBIOS. I don't think TCPIP would work if the others were out of sync.

[Ben]

Right now I have the onboard RTL active and I'm using the Mensys driver.

I took out the PCI NIC about 30 hours ago and it isn't going back unless the onboard chipset is a complete no-go.

Here are the Config.sys lines that are added by A & P at the end. If the rest of the networking lines are required let me know.

DEVICE=C:\MPTN\PROTOCOL\SOCKETSK.SYS
DEVICE=C:\MPTN\PROTOCOL\AFOS2.SYS
DEVICE=C:\MPTN\PROTOCOL\AFINETK.SYS
REM DEVICE=C:\MPTN\BIN\VDOSTCP.VDD
RUN=C:\MPTN\BIN\CNTRL.EXE
CALL=C:\OS2\CMD.EXE /Q /C C:\MPTN\BIN\MPTSTART.CMD >NUL
REM RUN=C:\MPTN\BIN\VDOSCTL.EXE
DEVICE=C:\IBMCOM\PROTOCOL\NETBEUI.OS2
DEVICE=C:\IBMCOM\PROTOCOL\NETBIOS.OS2
DEVICE=C:\IBMCOM\MACS\R8169.OS2

Protocol.ini

[PROT_MAN]

   DRIVERNAME = PROTMAN$

[IBMLXCFG]

   netbeui_nif = netbeui.nif
   tcpip_nif = tcpip.nif
   r8169_nif = r8169.nif

[NETBIOS]

   DriverName = netbios$
   ADAPTER0 = netbeui$,0

[netbeui_nif]

   DriverName = netbeui$
   Bindings = r8169_nif
   NETADDRESS = "5404A6CFBF51"
   ETHERAND_TYPE = "I"
   USEADDRREV = "YES"
   OS2TRACEMASK = 0x0
   SESSIONS = 130
   NCBS = 225
   NAMES = 21
   SELECTORS = 50
   USEMAXDATAGRAM = "NO"
   ADAPTRATE = 1000
   WINDOWERRORS = 0
   MAXDATARCV = 4168
   TI = 30000
   T1 = 1000
   T2 = 200
   MAXIN = 1
   MAXOUT = 1
   NETBIOSTIMEOUT = 500
   NETBIOSRETRIES = 3
   NAMECACHE = 1000
   RNDOPTION = 1
   PIGGYBACKACKS = 1
   DATAGRAMPACKETS = 50
   PACKETS = 300
   LOOPPACKETS = 8
   PIPELINE = 5
   MAXTRANSMITS = 6
   MINTRANSMITS = 2
   DLCRETRIES = 10
   FCPRIORITY = 5
   NETFLAGS = 0x0

[tcpip_nif]

   DriverName = TCPIP$
   Bindings = r8169_nif
   IfType = 6

[r8169_nif]

   DriverName = R8169$
   MODE = "1000FULL"
   NETADDRESS = "5404A6CFBF51"

IBMLAN.INI

; OS/2 LAN Requester initialization file

[networks]

; This information is read by the redirector at device initialization time.
  net1 = NETBEUI$,0,LM10,34,100,14

[requester]

; The following parameters generally do not need to be
; changed by the user.
  charcount = 16
  chartime = 250
  charwait = 3600
  keepconn = 600
  keepsearch = 600
  maxcmds = 16
  maxerrorlog = 100
  maxthreads = 10
  maxwrkcache = 64
  numalerts = 12
  numcharbuf = 10
  numservices = 7
  numworkbuf = 40
  numdgrambuf = 14
  othdomains =
  printbuftime = 90
  sesstimeout = 45
  sizcharbuf = 512
  sizerror = 1024
  sizworkbuf = 4096
  wrkheuristics = 1111111121311111110001011120111221001111100
  wrkservices = MESSENGER
  wrknets = net1

[messenger]

  logfile = messages.log
  sizmessbuf = 4096

[peer]

  auditing = resource
; The following parameters generally do not need to be changed
  guestacct = guest
  autodisconnect = -1
  maxauditlog = 100
  maxchdevjob = 2
  maxchdevs = 1
  maxconnections = 26
  maxlocks = 64
  maxopens = 160
  maxsearches = 150
  maxsessopens = 80
  maxsessreqs = 25
  maxsessvcs = 1
  maxshares = 16
  maxusers = 5
  numbigbuf = 4
  numfiletasks = 1
  numreqbuf = 48
  sizreqbuf = 4096
  srvhidden = yes
  srvheuristics = 111101411113110013311
  SRVSERVICES =
  srvnets = net1

  SRVCOMMENT =
[replicator]

  replicate = IMPORT
  importpath = C:\ibmlan\repl\import
  tryuser = yes
  password =

[services]

  messenger = services\msrvinit.exe
  peer = services\peerinit.exe
  replicator = services\replicat.exe
  requester = services\wksta.exe

I cut most of the REM'd lines. If you see something missing just let me know.