Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: aGGreSSor on April 05, 2015, 08:25:44 PM
-
I have a lot of time trying to connect A1200 through different RTL8139 drivers.
Note at once: official driver from Elbox doesn't work for me because don't have chips update.
By using last 68k openpci_8139.device (1.2b1 and 1.22b4) with openpci.library 2.1beta4 68k (08.10.09) found an annoying bug hinder connection. Somewhere in the driver set wrong ARP ethertype.
It works the same for Genesis and MiamiDX 1.0c so I think on the driver.
Test the connection between the two network interfaces (AmigaOS and Debian), cross-over cable. I trying through different network cards in different Mediator PCI-slots not yet launched tcpdump and wireshark (preferable).
ping Linux -> AmigaOS
source: 78:54:2e:6f:8e:67
dest.: Broadcast
Protocol: ARP
0000 ff ff ff ff ff ff 78 54 2e 6f 8e 67 08 06 00 01 ......xT .o.g....
0010 08 00 06 04 00 01 78 54 2e 6f 8e 67 c0 a8 02 01 ......xT .o.g....
0020 00 00 00 00 00 00 c0 a8 02 02
ping AmigaOS -> Linux
source: 00:4c:3c:10:4e:98
dest.: Broadcast
Protocol: 0x0608 (unknown)
0000 ff ff ff ff ff ff 00 4c 3c 10 4e 98 06 08 01 00 .......L <.N.....
0010 00 08 04 06 01 00 00 4c 3c 10 4e 98 a8 c0 02 02 .......L <.N.....
0020 00 00 00 00 00 00 a8 c0 01 02 b5 56 b5 56 b5 56 ........ ...V.V.V
0030 b5 56 b5 56 b5 56 b5 56 00 00 00 00 00 00 00 00 .V.V.V.V ........
ARP has hexadecimal protocol code the ethertype 0x0806
openpci_8139.device sends nonexistent code 0x0608!
Normal ethertype from Debian 7.0
(http://savepic.su/5563473m.jpg) (http://savepic.su/5563473.htm)
Wrong ethertype from Miami DX 1.0c
(http://savepic.su/5561425m.jpg) (http://savepic.su/5561425.htm)
Wrong ethertype from Genesis
(http://savepic.su/5548113m.jpg) (http://savepic.su/5548113.htm)
-
What is a "chips update" ?
Haven't had an issue with the official Elbox driver or the open pci driver with connecting to a network. I had an FTP server setup, browsed the net etc.
So not sure about your issue.
-
Perhaps it would send the correct code if you had the "chips update?"
-
What is a "chips update" ?
Hardware keys appear as MACHs chips.
I didn't buy MMCD with hardware keys (http://eu-shop.elbox.com/en_US/p/Mediator-Multimedia-CD-with-hardware-keys/42). Without keys almost any Elbox drivers open a window with message "Hardware ID code missing.." I have one the first Mediator PCI 1200 releases, no updates. This theme has been discussed many times, no fresh news.
Haven't had an issue with the official Elbox driver
You are lucky. :) Some less fortunate, for example (http://www.amiga.org/forums/showthread.php?t=24658)
or the open pci driver with connecting to a network. I had an FTP server setup, browsed the net etc.
Which openpci_8139.device version? Which TCP/IP stack version?
So not sure about your issue.
You will not believe tcpdump and wireshark? :laugh1: Perhaps this bug has affected only the latest versions for 68k. The most likely reason RPN is forgotten when cross-compiling. Bug seems quite typical. I don't have older versions for test this hypothesis. While I don't have a patch for the driver. I could be wrong, though unlikely..
-
A few fields after the ethertype seem to be swapped as well, so the problem seems more general. Have you tried other versions of openpci.library?
-
A few fields after the ethertype seem to be swapped as well, so the problem seems more general. Have you tried other versions of openpci.library?
Haven't tried it, I use latest openpci.library 2.1beta4 68k (08.10.09). Latest openpci_8139.device requires a minimum version 2.1.
Version 2.1beta3 68k (05.05.05) seems has trouble opening drivers. You're right, after the ethertype the same, but MAC field sends correctly.
This means that there are no problems in the physical layer. I've read OpenPCI SDK by Benjamin Vernoux which describes a high-level
operations: pci_find_slot(), pci_read_config_byte(), pci_allocdmamem(), etc. There is a warning for coders:
For that use ALWAYS swap macro of the MorphOS Team included by libraries/openpci.h.
This macro are :
SWAPWORD(unsigned short value) : return swaped 16bits value (Big Endian <-> Little Endian
conversion)
SWAPLONG(unsigned long value) : return swaped 32bits value (Big Endian <-> Little Endian
conversion)
Maybe the problem is here, and then maybe the bug isn't affected more earlier version of openpci_8139.device and openpci.library..
-
Have you tried other versions of openpci.library?
I adore you. This is a victory! :banana:
- openpci_8139.device 1.22b4 with openpci.library 2.1beta4 (08.10.09) - work, but swap ethertype and next fields.
- openpci_8139.device 1.22b4 with openpci.library 2.1beta3 (05.05.05) - guru when miami:miamiping
- openpci_8139.device 1.2b1 with openpci.library 2.1beta3 (05.05.05) - work!! normal ethertype!!!
ping Amiga -> Linux
0000 4c 00 10 3c 98 4e 78 54 2e 6f 8e 67 08 06 00 01 L..<.NxT .o.g....
0010 08 00 06 04 00 01 78 54 2e 6f 8e 67 c0 a8 02 01 ......xT .o.g....
0020 00 00 00 00 00 00 c0 a8 02 02 ........ ..
(http://savepic.su/5536713m.jpg) (http://savepic.su/5536713.htm)
UPD.
openpci_8139.device 1.2b1 with openpci.library 2.1beta4 (08.10.09) - work, but swap ethertype and next fields.
The Conclusion: openpci.library 2.1beta4 bugged, but openpci_8139.device 1.22b4 dont't work with 2.1beta3. Topic can be closed