[Gelöst] Probleme mit der Netzwerkkarte unter Ubuntu 8.10

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • [Gelöst] Probleme mit der Netzwerkkarte unter Ubuntu 8.10

      Hallo Forum,


      mit meinem ersten Posting hier komm ich gleich mit einem Problem um die Ecke - hab mich hier schon ein bisschen durchgelesen aber konnte nix vergleichbares finden, daher dieser Thread.


      Nachdem ich nach gut 5 Jahren mein Acer Extensa jetzt endgültig in Rente geschickt hab, gabs ein aktuelles M1530 und ich muss sagen dass ich recht begeistert davon bin - die erste Aktion war dass ich direkt das mitgelieferte Vista gekillt und Ubuntu Intrepid installiert hab :D

      Funktioniert soweit auch alles ganz toll, sogar "Gimmicks" wie der Fingerabdruckscanner funktionieren nach etwas Gefummel :)

      Einzig und allein die Kabelnetzwerkkarte macht Probleme und ich muss sagen dass ich recht ratlos bin und keine Ahnung habe wo ich ansetzen soll.

      Die Karte an sich scheint wunderbar erkannt zu werden - funktionieren will sie aber irgendwie nicht.

      lspci:
      09:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8040 PCI-E Fast Ethernet Controller (rev 12)


      lshw:
      *-network
      description: Ethernet interface
      product: 88E8040 PCI-E Fast Ethernet Controller
      vendor: Marvell Technology Group Ltd.
      physical id: 0
      bus info: pci@0000:09:00.0
      logical name: eth0
      version: 12
      serial: 00:21:9b:de:b0:ee
      width: 64 bits
      clock: 33MHz
      capabilities: bus_master cap_list ethernet physical
      configuration: broadcast=yes driver=sky2 driverversion=1.22 firmware=N/A latency=0 module=sky2 multicast=yes



      Soweit, so gut - sobald ich ein Kabel anstecke versucht sich der networkmanager per DHCP eine Adresse zu holen und sagt - allerdings immer nur beim 1. Versuch nach einem Reboot - er wäre verbunden, aber jegliche Verbindungsversuche ins Internet oder auch LAN (ping etc.) schlagen fehl - Network unreachable. Weitere Versuche scheinen mit einem Timeout abgebrochen zu werden und auch Wireshark zeigt keinerlei Aktivität auf eth0 mehr an.

      Da ich das ganze zum ersten mal in einem Hotel - die schön öfter Probleme mit ihrem Internet hatten - bemerkt habe, hab ich das ganze als Problem mit deren Netzwerk abgehakt, erstmal auf später verschoben und bin stattdessen per UMTS ins Netz.

      Nachdem ich dann am Wochenende auch mal zuhause Zeit hatte das ganze auszuprobieren bin aber zu demselben Ergebniss gekommen - dasselbe LAN funktioniert problemlos mit einem anderen Laptop oder auch per WLAN auf diesem Laptop funktioniert das ganze einwandfrei - somit bin ich ein Stück weit ratlos :(

      Für sachdienliche Hinweise bin ich mehr als dankbar, wenn mehr / andere Angaben gewünscht sind werde ich die gern nachreichen (im Anhang noch ein Dump von Wireshark von besagtem ersten Verbindungsversuch).

      Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von phrozen77 ()

    • ifconfig:

      eth0 Link encap:Ethernet Hardware Adresse 00:21:9b:de:b0:ee
      UP BROADCAST MULTICAST MTU:64 Metrik:1
      RX packets:2 errors:0 dropped:0 overruns:0 frame:0
      TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
      Kollisionen:0 Sendewarteschlangenlänge:1000
      RX bytes:1152 (1.1 KB) TX bytes:1836 (1.8 KB)
      Interrupt:16


      Nein, den Router von dem der DHCP ACK kommt, den kann ich nicht anpingen (10.0.0.3 in dem PCAP file)
    • Hat denn keiner eine Idee?

      Gestern war ein Kollege mit einem Windows-Laptop hier und bei diesem ging das Netzwerk einwandfrei :(

      Ich hab heute noch ein paar Sachen durchprobiert aber mit wenig Erfolg.


      rmmod sky2 & modprobe sky2 schreibt folgendes ins syslog/dmesg:


      [ 255.133160] sky2 eth0: disabling interface
      [ 255.149205] sky2 0000:09:00.0: PCI INT A disabled
      [ 258.469338] sky2 0000:09:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
      [ 258.469370] sky2 0000:09:00.0: setting latency timer to 64
      [ 258.469411] sky2 0000:09:00.0: v1.22 addr 0xf1ffc000 irq 16 Yukon-2 FE+ rev 0
      [ 258.471963] sky2 eth0: addr 00:21:9b:de:b0:ee
      [ 262.504626] sky2 eth0: enabling interface
      [ 263.999224] sky2 eth0: Link is up at 100 Mbps, full duplex, flow control both


      Soweit so gut, IRQ 16 mhh?

      cat /proc/interrupts


      CPU0 CPU1
      0: 110126 110778 IO-APIC-edge timer
      1: 1189 1180 IO-APIC-edge i8042
      8: 47 51 IO-APIC-edge rtc0
      9: 0 0 IO-APIC-fasteoi acpi
      12: 61 59 IO-APIC-edge i8042
      14: 6186 5894 IO-APIC-edge ata_piix
      15: 0 0 IO-APIC-edge ata_piix
      16: 718 700 IO-APIC-fasteoi ohci1394, nvidia
      18: 0 0 IO-APIC-fasteoi mmc0
      20: 6801 6710 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb4, ehci_hcd:usb7
      21: 4133 4044 IO-APIC-fasteoi uhci_hcd:usb2, uhci_hcd:usb5, HDA Intel
      22: 164 162 IO-APIC-fasteoi ehci_hcd:usb3, uhci_hcd:usb6
      217: 321 275 PCI-MSI-edge iwlagn
      218: 17 19 PCI-MSI-edge eth0
      219: 10839 10771 PCI-MSI-edge ahci
      NMI: 0 0 Non-maskable interrupts
      LOC: 97584 77177 Local timer interrupts
      RES: 33029 33347 Rescheduling interrupts
      CAL: 11314 6562 function call interrupts
      TLB: 348 370 TLB shootdowns
      SPU: 0 0 Spurious interrupts
      ERR: 0
      MIS: 0


      Sollte da bei IRQ16 nicht das sky2 Modul mit dabeistehen?

      Nur so nebenbei bemerkt hatte ich schon bei einem Desktop-Rechner mal ein Problem als sich Netzwerkkarte und Grafikkarte einen IRQ teilen wollten - wie könnte man das umkonfigurieren?


      Dann mal nebenbei probiert ob sich das ganze nicht doch per dhclient überreden lässt:

      dhclient -r:


      Internet Systems Consortium DHCP Client V3.1.1
      Copyright 2004-2008 Internet Systems Consortium.
      All rights reserved.
      For info, please visit isc.org/sw/dhcp/

      wmaster0: unknown hardware address type 801
      wmaster0: unknown hardware address type 801
      Listening on LPF/eth0/00:21:9b:de:b0:ee
      Sending on LPF/eth0/00:21:9b:de:b0:ee
      Listening on LPF/pan0/fa:b4:3b:6c:3a:c3
      Sending on LPF/pan0/fa:b4:3b:6c:3a:c3
      Listening on LPF/wlan0/00:21:5c:8b:cc:9d
      Sending on LPF/wlan0/00:21:5c:8b:cc:9d
      Listening on LPF/wmaster0/
      Sending on LPF/wmaster0/
      Sending on Socket/fallback


      dhclient eth0:


      Internet Systems Consortium DHCP Client V3.1.1
      Copyright 2004-2008 Internet Systems Consortium.
      All rights reserved.
      For info, please visit isc.org/sw/dhcp/

      wmaster0: unknown hardware address type 801
      SIOCSIFADDR: No buffer space available
      wmaster0: unknown hardware address type 801
      Listening on LPF/eth0/00:21:9b:de:b0:ee
      Sending on LPF/eth0/00:21:9b:de:b0:ee
      Sending on Socket/fallback
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
      send_packet: Message too long
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
      send_packet: Message too long
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 17
      send_packet: Message too long
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19
      send_packet: Message too long
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
      send_packet: Message too long
      DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 1
      send_packet: Message too long
      No DHCPOFFERS received.
      No working leases in persistent database - sleeping.


      Und jetzt bin ich eiiiiiigentlich wieder am Anfang und wüsste grad spontan nicht was ich sonst noch überprüfen / probieren könnte :(
    • Ok, jetzt weiss ich worans lag....

      Beim Googlen nach "dhclient send_packet: Message too long" bin ich auf folgendenen Eintrag im Launchpad gestossen.

      Analog dazu hab ich in der shell dann die MTU von eth0 angepasst mit:


      ifconfig eth0 mtu 1500


      Und siehe da - dann ging auch die Anfrage an den DHCP per dhclient durch :D


      Internet Systems Consortium DHCP Client V3.1.1
      Copyright 2004-2008 Internet Systems Consortium.
      All rights reserved.
      For info, please visit isc.org/sw/dhcp/

      wmaster0: unknown hardware address type 801
      wmaster0: unknown hardware address type 801
      Listening on LPF/eth0/00:21:9b:de:b0:ee
      Sending on LPF/eth0/00:21:9b:de:b0:ee
      Sending on Socket/fallback
      DHCPREQUEST of 10.0.0.109 on eth0 to 255.255.255.255 port 67
      DHCPACK of 10.0.0.109 from 10.0.0.3
      bound to 10.0.0.109 -- renewal in 34036 seconds.
    • der default MTU is übrigens 1492. Vllt magste den Wert entsprechend anpassen um in Zukunft definitiv keine Probs mehr damit zu kriegen. ^^


      Ich hatte die Tage ein ähnlich lustiges Problem, nur genau anders rum.
      Hab meine ganze alte Hardware aus dem Schrank gekramt und nen "neuen" Rechner aufgesetzt. Kleiner Server fürs Heimnetz halt. Lustigerweise ging aus unerfindlichen Gründen der onboard Netzwerkanschluss nicht. Sowohl in XP/2003/Vista kam immer, er könne nur eingeschränkte Connection blabla.
      Dann mal ne gute alte Knoppix gebootet und bim geht einwandfrei.

      Ich hab keine Ahnung warum das onboard Teil unter Windows nicht will, habe das Bios einmal komplett umgekrempelt. ^^
      Ein WLAN USB-Stick ging natürlich einwandfrei. Aber WLAN ist mir zu unbeständig von der Performance trotz Draft-N.
      Zum Glück hatte ich noch ne gute alte 10/100 PCI Netzwerkkarte von 3com rumfliegen.


      Edit: Ich habe Netzwerkfrickelei unter Linux schon im Studium immer gehasst. Egal ob Lan, Wlan, Bluetooth oder Handykrams, alles Mist. ^^

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von niggurath ()

    • Original von niggurath
      der default MTU is übrigens 1492. Vllt magste den Wert entsprechend anpassen um in Zukunft definitiv keine Probs mehr damit zu kriegen. ^^


      Hrm, da hast du wieder recht - ich war so glücklich dass der Mist endlich ging dass ich da dran nimmer gedacht habe.

      Bleibt die Frage wo ich den Kram reinpack ohne dass ich auf so gefrickel wie /etc/rc.local zurückgreifen muss.

      /etc/dhcp3/dhclient.conf?


      Edit: Eigentlich ne blöde Frage - lesen regelt mal wieder. Weiter unten im Launchpad Eintrag steht dass der "interface-mtu" Parameter in der /etc/dhcp3/dhclient.conf dafür verantwortlich ist dass uns der Router erzählen darf was für eine MTU verwendet wird - und diese erzählen scheinbar mal gerne Blödsinn, bei Problemen also probehalber entfernen.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von phrozen77 ()