Jamie BoothI can't figure out if I have a Solaris 8 config problem, a hardware failure, or something with my home network that isn't "Sun compatible". I can not get either the onboard TPE or the off board TPE+SCSI adapter to connect to my network. The Ultra 1 can see inbound traffic but nothing being sent is received on the other end of the link.
rwhitworth@jamie Ethernet frame type II? Any chance Sun used something different?
Dave Fischer@jamie If you have two interfaces running, the default would be for them to use the same mac address. Which modern systems do not like.
Yeah, I noticed that which struck me as odd. However, I only have one connected at a time. So, the rest of the network shouldn't care.
The issue was with the MAC address. Not duplicates, but the address prefix that Sun/Oracle used to map hostid to MAC is some sort of multicast group address and the other network devices didn't like seeing that as a source MAC.
I went to the vendor DB for MAC prefix registrations and found one of the Oracle values. Updated the MAC with ifconfig and voila!
@jamie Weird! Never encountered that...
DrScripttWhat is on the other end of the cable? Is it by chance a VMware system?
It looks like the old MAC (00:50:56:76:36:69) has an OUI belonging to VMware.
I find it quite odd that anything SUN would have that OUI in it's Ethernet MAC address in ROM.
The new MAC address (00:00:7d:76:e6:69) does has an OUI assigned to Oracle, as you say.
My suspicion is that something on the other end was filtering the Ethernet frame because of the VMware OUI on what almost certainly shouldn't have been the case.
I have more questions than answers.
But I'm glad that you got it working.
That was my first test to see if the MAC was the problem. Something about the original ff:* MAC address is seen as multicast by Wireshark and it says it not valid as a source address.
@jamie @davefischer I didn’t see a MAC address starting with FF:
I’d have to look things up but I do know that one of the bits in the first / most significant byte of the MAC address does have something to do with groups. The “u/g” or universal / group bit comes to mind.
@jamie @davefischer sorry, unicast / multicast is the last (least significant) of the first (most significant) byte.
Check out the Unicast vs Multicast (I/G bit) section of:
• https://en.m.wikipedia.org/wiki/MAC_address
So if the first byte was FF, that would mean the I/G bit was a 1 which means that it was a group address.
Which makes sense why that would be filtered as an invalid source MAC address.
I think. I could easily be wrong.
The original system MAC was further up the command window and didn't make the picture. 🤷
I figured something like that might be the case.
@jamie when did Solaris get variable length subnet-mask (VLSM/CIDR) support?
Also check netmask and broadcast settings.
snoop / ether find (?) and tcpdump are your friends.
It definitely supports a subnet mask. You can even pass a CIDR string to ifconfig when bringing up an interface.
Snoop is where I figured out it was seeing inbound traffic which was a major breakthrough. It's something to do with the sending. I haven't tried ether. I'll give it a go.