[ltp] ibmtr_cs 2.2.18 and DHCP

[Markus Alt]

Burt Silverman wrote:
> 
> Friedemann Baitinger asks:
> 
> >How can we determine whether our RPS is screwed up? What should be done
> >if it turns out be indeed screwed? Please provide a list of what to
> >check where such that our network technicians can understand what to do.
> 
> I was hoping that you would not ask!
> 
> I had an old trustworthy Network General sniffer at my disposal. You can
> set up the sniffer to trace all packets coming from your MAC address and
> set up the sniffer for bidirectional (from and to your MAC). The sniffer
> will tell you the nature of the packets, so you will know for certain which
> ones are to/from the RPS. You want to look at the Frame Control byte (FC)
> of the packets returned. It is the second byte in the packet, just before
> the 6 byte DA and right after the Access Control byte.
> 
> You probably will see several attempts by the adapter to request the
> parameters (if it does not open the first time), and a reply to each
> request. If the FC in every reply is 0, then you have a bad RPS. If some
> replies have 0 and some 1, this is OK; there is one adapter on the market
> that has a problem with receiving a FC==1, so that is why both values would
> be sent.
> 
> If you don't have a sniffer, I am fond of the iptrace utility on AIX, and
> it will do essentially the same thing. I would like to see something like
> it on Linux -- it probably exists and I haven't learned about it. tcpdump
> is either unusable for this, or at the least it is more difficult. If you
> use any of these things, maybe to be certain you are looking at the RPS
> packets, well, The RPS has a MAC/functional address of C0'00'00'00'00'02.
> There are not a large number of packets associated with the Open, so it
> shouldn't be too difficult.
> 
> When you discover that the RPS is troublesome, I am told that it is usually
> a matter of upgrading the software in the RPS (presumably, that means the
> Bridge) to a newer release. So the alternative is to find out what bridge
> you have, what software it is running, and what level is needed.
> 
> A bit of a nuisance, but it is certainly worth the trouble. Hope you can
> make time for it.
> 
> By the way, single ring networks with no bridges do not need to have an
> RPS. Part of the protocol lets the adapter know whether it should be
> looking for an RPS response or not. A network operations woman who appeared
> to be very knowledgable told me that there was no RPS on my lab network.
> WRONG!

Burt,

I talked to one of our network guys a few days ago about this RPS stuff.
I must admit that I didn't completely understand everything he was
telling me, but the bottom line is (as far as I got it): There is no
possibility to change the RPS even if it appears to be "misconfigured".
This is because we run a switched Token Ring network and therefore have
no more bridges. And the RPS setting is kind of hardcoded in the
switches' microcode.

Another point: Even if the screwed up RPS could (and will) be changed in
our LAN, I may still run into the same trouble when I connect to another
site's LAN where the RPS is also "misconfigured". As I wrote in my first
message starting this thread, I found out about this DHCP problem while
trying to get the network connection going in another IBM location next
to ours.

Conclusion: It would really be nice if the Token Ring driver would be
more "foregiving" as you said, Burt, with regard to any kind of
"misconfigured" LAN parameters. As earlier versions of driver have
shown, this should be possible.

And now the good news! ;-) Following Friedemann's recommendation, I
tried "pump" for the DHCP setup (instead of "dhclient" which comes with
SuSE by default) and got it going with Friedemann's help. (Thanks
again!) Some changes had to made in /etc/pcmcia/network to make it work
automagically, but now it works fine together with ibmtr_cs-2.2.18 and
pcmcia-cs-3.1.23.

I haven't had the time so far to cross-check if "dhclient" works with
these changes in /etc/pcmcia/network or if it's started manually, but
apparently - as "pump" works - the culprit was not the RPS. 

So finally I can work with DHCP again, which is most important for me at
the moment. As said, I will check if I get "dhclient" to work and let
you know. For the moment, thank you, Burt, for providing all these
details and for your continued support and development of the Token Ring
driver!

Markus
----- The Linux ThinkPad mailing list -----
The linux-thinkpad mailing list home page is at:
http://www.bm-soft.com/~bm/tp_mailing.html