OS/2, eCS & ArcaOS - Technical > Networking

OS/2, Realtek and NIC drivers

<< < (4/7) > >>

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. 8)

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


--- Quote ---neither TCP/IP nor MPTN worked
--- End quote ---

?

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:

--- Quote from: Neil Waldhauer on October 10, 2013, 02:40:14 am ---Well, what does it mean to say


--- Quote ---neither TCP/IP nor MPTN worked
--- End quote ---

?

--- End quote ---

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.


--- Quote from: Neil Waldhauer on October 10, 2013, 02:40:14 am ---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.

--- End quote ---

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:

--- Quote ---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.
--- End quote ---

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.


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

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).


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

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).


--- Quote ---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.
--- End quote ---

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: ---    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

--- End code ---

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.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version