1000bt LAN

[Soren Morton]

I have a SuperDome running 11i with a 1000bt LAN card. I was trying to configure it, but there are no device files for it. I tried using mksf, mknod, and insf to install the files, but nothing worked.

Anyway, at this point I went into SAM and configured it and it works, but there are still no device files for it. I ran a find on /dev/ for lan* and ge*, but found nothing. Nothing shows up in the ioscan either. How is it working?

[John Carr_2]

Hi

goto /dev

ls -lagtr | tail -10 see if you can see some files with time stamps relating to when you configured with sam.

cheers
john.

[John Payne_2]

That is weird. Without a driver or a device file, it will not work. Are you should this is the Giga-NIC you are seeing that is working? Is there another card on the box that is you are actually seeing?

I take that back, because SAM should not see it if the ioscan does not see it... what is the output of 'ioscan -kfnClan'?

John

[S.K. Chan]

Did you try running ..

# insf -e

to recreate the device file ?

[Sandip Ghosh]

Do a lanscan.
See the Hardware address for that LAN Card
do an ioscan and find out the Hardware address
Then find out the driver which it is taking.

Go to /etc/rc.config.d/netconf
find out the interface name
do an ifconfig on that interface.

Sandip

[melvyn burnard]

sanity check time

Since HP-UX 11.00, all these fast ethernet cards do NOT get a /dev/lan* device file which was needed for the older LLA or Link Level Addressing, as they now use dlpi.
check for /dev/dlpi* files, and you should now see these.

You can mknod them as much as you like, but they will be of no use :-}

[Soren Morton]

Melvyn,

Your post would explain this phenomenon, however I would like a little more info. I thought the /dev/dlpi* device files were only used for low-level "data-link" layer communication (rpcd, etc).

If the LAN cards are ONLY using /dev/dlpi* device files how do you know which one belongs to which card? Why are there 6 device files when I only have 2 configured ports out of 12 possible?

[melvyn burnard]

Not sure of the specifics here, but to my knowledge, when you do lanscan you get:Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
2/0/0/1/0 0x001083FDCDC9 0 UP lan0 snap0 1 ETHER Yes 119
2/0/2/0/0 0x00306E0C848D 1 UP lan1 snap1 2 ETHER Yes 119
2/0/9/0/0 0x00306E0C94A2 2 UP lan2 snap2 3 ETHER Yes 119
2/0/10/0/0 0x0060B05825F5 3 UP lan3 4 FDDI Yes 119
2/0/14/0/0 0x00306E0F09CA 4 UP lan4 snap4 5 ETHER Yes 119


and the listed net-interface nameppa gives you the PPA or Physical Point of Attachment, and this is also the numeric value that appends to the /dev/dlpi* file.

e.g. lan3 -> /dev/dlpi3

[Michael Tully]

Hi,

I don't have a superdome, but here is the output from an rp8400, which is regarded as a baby superdome. Hopefully the output is what you need.


# /usr/sbin/ioscan -fnkC lan
Class I H/W Path Driver S/W State H/W Type Description
====================================================================
lan 0 1/0/0/1/0 gelan CLAIMED INTERFACE HP A3639-60019 1000Base-T Built-in I/O
lan 1 1/0/12/0/0 gelan CLAIMED INTERFACE HP A4929A PCI 1000Base-T Adapter
lan 2 1/0/14/0/0 gelan CLAIMED INTERFACE HP A4929A PCI 1000Base-T Adapter
# lanscan
sh: lanscan: not found.
# /usr/sbin/lanscan
Hardware Station Crd Hdw Net-Interface NM MAC HP-DLPI DLPI
Path Address In# State NamePPA ID Type Support Mjr#
1/0/0/1/0 0x00306E0A60A5 0 UP lan0 snap0 1 ETHER Yes 119
1/0/12/0/0 0x00306E0FA949 1 UP lan1 snap1 2 ETHER Yes 119
1/0/14/0/0 0x00306E0FA938 2 UP lan2 snap2 3 ETHER Yes 119
# ll /dev/l*
lrwxr-xr-x 1 root sys 9 Jan 16 18:49 /dev/lan -> /dev/dlpi

[Angus Crome]

I am also seeing this behavior. I have an N-4000 with an
HP A4926A PCI 1000Base-SX Adapter.

Under HPUX 11.00 it generated a device file as /dev/ge1. When I re-installed it with HPUX 11.11, it now shows up without a device in ioscan, and no device in /dev. It was a little disconcerting to see this effect. I also tried the normal tricks (insf -e, ioscan -fnC lan, ioscan -fn, and mknod) but to no avail.
I don't understand how it works, but work it does.

[rick jones]

IIRC, when one says "ifconfig lan0", /dev/dlpi will be opened, and then the code will attach to a specified PPA. each open of /dev/dlpi results in a different stream. In DLPI speak this is a "type provider (I can never remeber if it is type1 or type 2 - I _think_ it is type 2)

The /dev/dlpiN files are for something different - they are (again IIRC) the non-cloning files - something akin to a party line. They are not necessarily associated with a specific interface.

If you want to do link-level access, the DLPI manuals online at docs.hp.com are a must.

[Soren Morton]

I would say that the PPA/NM ID does not correspond to the /dev/dlpi? number. I don't have a /dev/dlpi7, but I am using lan7 for one of my networks.

I tried the following, but it still works. I wonder how.

# chmod 000 /dev/dlpi*
# ll /dev/dlpi*
c--------- 1 root sys 72 0x000077 Feb 13 18:59 /dev/dlpi
c--------- 1 root sys 119 0x000000 Feb 13 18:59 /dev/dlpi0
c--------- 1 root sys 119 0x000001 Feb 13 18:59 /dev/dlpi1
c--------- 1 root sys 119 0x000002 Feb 13 18:59 /dev/dlpi2
c--------- 1 root sys 119 0x000003 Feb 13 18:59 /dev/dlpi3
c--------- 1 root sys 119 0x000004 Feb 13 18:59 /dev/dlpi4

# ping sd2bellf
PING sd2bellf: 64 byte packets
64 bytes from 15.47.21.32: icmp_seq=0. time=0. ms
64 bytes from 15.47.21.32: icmp_seq=1. time=0. ms

Also my /dev/lan is NOT linked to /dev/dlpi. I may have to take a HP-UX 11i class just to find out how this works.

[rick jones]

your ping still works because ping does not open /dev/dlpi. ping probably calls socket() (you can confirm with tusc if you are sufficiently motivated :).

the tcp/ip transport has already made the association between IP and that NIC, so a chmod after the fact will do nothing to the regular transport. however, it might affect your ability to do subsequent ifconfig commands, or perhaps lanadmin, but both of those are just guesses