NETBIOS

Pumpelhuber · Beitrag von **Pumpelhuber** » 17 Aug 2008, 11:05

Moin Moin,
vielleicht hab ich ja nur "ein Brett vor'm Kopf" und seh den Wald vor lauter Bäumen nicht:

Unterschiedliche Netzwerke, in der Regel die gleichen Topologie:
Mehrere Router, alle die gleiche Arbeitsgruppe, Netbios aktiviert, Netbios-Proxy aktiviert. Arbeitsgruppen können im Windows Browser geöffnet werden. Auf Serverresourcen ist über Router hinweg ein Zugriff auf Freigaben möglich. Soweit keine Probleme.

Auf einigen Routern gibt es seit der 7.54 folgende Feststellung:
Der letzte Router, der Gateway zum nächsten Standort ist, schickt einen Netbios-Brodcast auf die 255 los. Jetzt passiert das, was laut meinen Kenntnisstand nicht passieren sollte: Der Router empfängt seinen eigenen Brodcast und DoS-Protection schlägt zu, weil das Packet von seinem Gerät mit seiner IP kommt. Gemeinsamkeit bei den betroffenen Routern: Alles 1711er.

Trace ohne IP-Router:

[NetBIOS] 2008/07/24 22:06:06,230
NetBIOS - browsing local network

[NetBIOS] 2008/07/24 22:06:06,230
NetBIOS Name Service
Overwrite Demand:
host OFFICE01 <00> is 192.168.37.1

Tx: LAN-1, INTRANET - DestIp: 192.168.37.255

[NetBIOS] 2008/07/24 22:06:06,230
NetBIOS Name Service
Node Status Request:
* <00>

Tx: LAN-1, INTRANET - DestIp: 192.168.37.255

[Firewall] 2008/07/24 22:06:06,230
Packet matched rule DoS protection
DstIP: 192.168.37.1, SrcIP: 192.168.37.1, Len: 96, TOS: ----
Prot.: UDP (17), DstPort: 137, SrcPort: 137

Filter info: packet with same source and destination address received from interface LAN-1
send SNMP trap
packet dropped

**************************************************************************

Trace mit IP-Router

[NetBIOS] 2008/08/17 10:19:01,260
NetBIOS - browsing local network

[NetBIOS] 2008/08/17 10:19:01,260
NetBIOS Name Service
Overwrite Demand:
host OFFICE01 <00> is 192.168.37.1

Tx: LAN-1, INTRANET - DestIp: 192.168.37.255

[NetBIOS] 2008/08/17 10:19:01,260
NetBIOS Name Service
Node Status Request:
* <00>

Tx: LAN-1, INTRANET - DestIp: 192.168.37.255

[Firewall] 2008/08/17 10:19:01,260
Packet matched rule DoS protection
DstIP: 192.168.37.1, SrcIP: 192.168.37.1, Len: 96, TOS: ----
Prot.: UDP (17), DstPort: 137, SrcPort: 137

Filter info: packet with same source and destination address received from interface LAN-1
packet dropped

[Firewall] 2008/08/17 10:19:01,260
Packet matched rule DoS protection
DstIP: 192.168.37.1, SrcIP: 192.168.37.1, Len: 78, TOS: ----
Prot.: UDP (17), DstPort: 137, SrcPort: 137

Filter info: packet with same source and destination address received from interface LAN-1
packet dropped

Das Spiel wiederholt sich entsprechend der gesendeten Brodcasts vom Router. Eine Firewallregel, die Packete von sich selbst auf Port 137 UDP von Port 137 UDP verwirft, kann nicht greifen, weil wohl die DoS-Protection von der Hirarchie her vorher zuschlägt.
Bei Workstations oder Servern kann soetwas nicht passieren, da die ihre eigenen Brodcasts ja ignorieren. Wie kann ich das Problem vermeiden, ohne Netbios zu deaktivieren?

Gruß aus dem sonnigen Kiel!

backslash · Beitrag von **backslash** » 18 Aug 2008, 16:14

Hi Pumpelhuber

Jetzt passiert das, was laut meinen Kenntnisstand nicht passieren sollte: Der Router empfängt seinen eigenen Brodcast und DoS-Protection schlägt zu, weil das Packet von seinem Gerät mit seiner IP kommt.

Das LANCOM reagiert auf einen Node-Status-Request gar nicht, daher kann das angemeckerte Paket eigentlich nicht vom LANCOM kommen. Selbst wenn das LANCOM auf einen Node-Status-Request reagieren würde, dann würde das auch im NetBIOS-Trace auftauchen...

Mach doch mal einen Ethernet-Trace parallel dazu (sinnvollerweise auf UDP beschränkt: trace # eth @ udp).

Bei Workstations oder Servern kann soetwas nicht passieren, da die ihre eigenen Brodcasts ja ignorieren.

Das LANCOM ignoriert eigene Broadcasts ebenfalls - das macht schon der Ethernettreiber, der Pakete verwirft, die als Absenderadresse die MAC-Adresse des LANCOM haben...

Gruß
Backslash

alf29 · Beitrag von **alf29** » 18 Aug 2008, 16:20

Moin,

Das LANCOM ignoriert eigene Broadcasts ebenfalls - das macht schon der Ethernettreiber, der Pakete verwirft, die als Absenderadresse die MAC-Adresse des LANCOM haben...

Nein, das macht aktuell so gut wie kein Ethernet-Treiber
im LCOS mehr. Alleine schon, weil es Protokolle gibt,
die explizit auf den Empfang solcher Pakete angewiesen
sind (z.B. zur Schleifenerkennung).

Die einzige Ausnahme dieser Regel ist ein WLAN im
Client-Modus, da läßt es sich aufgrund der Struktur
einer Funkzelle nicht verhindern, daß ein Client seine
eigenen (vom AP in die Zelle zurückgespiegelten)
Broadcasts hört...

Gruß Alfred

Pumpelhuber · Beitrag von **Pumpelhuber** » 18 Aug 2008, 20:24

Das LANCOM ignoriert eigene Broadcasts ebenfalls - das macht schon der Ethernettreiber, der Pakete verwirft, die als Absenderadresse die MAC-Adresse des LANCOM haben...

Nun denn, hier ist ein Trace:

[Ethernet] 2008/08/18 20:08:04,260
Received 110 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-1
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:09:4f:0c:0c:d2
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 96
ID : 13873
Fragment : Offset 0
TTL : 63
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.1
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 76
Body : 34 23 28 10 00 01 00 00 4#(.....
00 00 00 01 20 45 4c 45 .... ELE
4a 46 45 46 4b 45 46 45 JFEFKEFE
43 45 46 46 43 45 48 43 CEFFCEHC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 41 41 00 00 20 ACAAA..
00 01 c0 0c 00 20 00 01 ..... ..
00 00 00 00 00 06 06 00 ........
c0 a8 25 01 ..%.

[Ethernet] 2008/08/18 20:08:04,260
Sent 92 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : ff:ff:ff:ff:ff:ff
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 78
ID : 37377
Fragment : Offset 0
TTL : 60
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.255
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 58
Body : 34 24 00 90 00 01 00 00 4$......
00 00 00 00 20 43 4b 41 .... CKA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 00 00 21 AAAAA..!
00 01 ..

[Ethernet] 2008/08/18 20:08:04,270
Received 92 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-1
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:09:4f:0c:0c:d2
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 78
ID : 13874
Fragment : Offset 0
TTL : 63
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.1
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 58
Body : 34 24 00 90 00 01 00 00 4$......
00 00 00 00 20 43 4b 41 .... CKA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 41 41 41 AAAAAAAA
41 41 41 41 41 00 00 21 AAAAA..!
00 01 ..

[Ethernet] 2008/08/18 20:08:05,260
Sent 92 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : ff:ff:ff:ff:ff:ff
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 78
ID : 37418
Fragment : Offset 0
TTL : 60
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.255
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 58
Body : 34 25 01 10 00 01 00 00 4%......
00 00 00 00 20 45 43 45 .... ECE
42 46 43 45 48 43 41 43 BFCEHCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 42 4f 00 00 20 ACABO..
00 01 ..

[Ethernet] 2008/08/18 20:08:05,260
Received 104 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-4
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:19:66:6f:63:15
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 90
ID : 12145
Fragment : Offset 0
TTL : 128
Protocol : UDP
Src Address : 192.168.37.101
Dest Address : 192.168.37.1
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 70
Body : 34 25 85 00 00 00 00 01 4%......
00 00 00 00 20 45 43 45 .... ECE
42 46 43 45 48 43 41 43 BFCEHCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 42 4f 00 00 20 ACABO..
00 01 00 04 93 e0 00 06 ........
e0 00 c0 a8 25 65 ....%e

und hier kommt ein Bild vom Lanmonitor.
Zwischenzeitlich hatte ich SNMP abgeschaltet, damit ich "mein Unglück" nicht immer sehen muss.

Gruß, ich

Pumpelhuber · Beitrag von **Pumpelhuber** » 18 Aug 2008, 21:58

Hier noch einmal ein Trace mit tr # firewall.
Die Packete auf die Brodcastadresse gehen heute regelmäßig jede 32 Minuten.

[Ethernet] 2008/08/18 21:47:04,260
Sent 110 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : ff:ff:ff:ff:ff:ff
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 96
ID : 50329
Fragment : Offset 0
TTL : 60
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.255
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 76
Body : 34 6d 28 10 00 01 00 00 4m(.....
00 00 00 01 20 46 45 45 .... FEE
46 46 44 46 45 46 46 46 FFDFEFFF
44 45 46 46 43 43 41 43 DEFFCCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 41 44 00 00 20 ACAAD..
00 01 c0 0c 00 20 00 01 ..... ..
00 00 75 30 00 06 66 00 ..u0..f.
c0 a8 65 cb ..e.

[Ethernet] 2008/08/18 21:47:04,260
Received 110 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-1
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:09:4f:0c:0c:d2
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 96
ID : 19550
Fragment : Offset 0
TTL : 63
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.1
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 76
Body : 34 6d 28 10 00 01 00 00 4m(.....
00 00 00 01 20 46 45 45 .... FEE
46 46 44 46 45 46 46 46 FFDFEFFF
44 45 46 46 43 43 41 43 DEFFCCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 41 44 00 00 20 ACAAD..
00 01 c0 0c 00 20 00 01 ..... ..
00 00 75 30 00 06 66 00 ..u0..f.
c0 a8 65 cb ..e.

[Firewall] 2008/08/18 21:47:04,270
Packet matched rule DoS protection
DstIP: 192.168.37.1, SrcIP: 192.168.37.1, Len: 96, TOS: ----
Prot.: UDP (17), DstPort: 137, SrcPort: 137

Filter info: packet with same source and destination address received from interface LAN-1
send SNMP trap
packet dropped

[Ethernet] 2008/08/18 21:47:05,330
Sent 110 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : ff:ff:ff:ff:ff:ff
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 96
ID : 50350
Fragment : Offset 0
TTL : 60
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.255
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 76
Body : 34 6f 28 10 00 01 00 00 4o(.....
00 00 00 01 20 46 45 45 .... FEE
46 46 44 46 45 46 46 46 FFDFEFFF
44 45 46 46 43 43 41 43 DEFFCCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 41 44 00 00 20 ACAAD..
00 01 c0 0c 00 20 00 01 ..... ..
00 00 75 30 00 06 66 00 ..u0..f.
c0 a8 65 cb ..e.

[Ethernet] 2008/08/18 21:47:05,330
Received 110 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-1
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:09:4f:0c:0c:d2
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 96
ID : 19551
Fragment : Offset 0
TTL : 63
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.1
-->UDP Header
Src Port : NBNS
Dest Port : NBNS
Length : 76
Body : 34 6f 28 10 00 01 00 00 4o(.....
00 00 00 01 20 46 45 45 .... FEE
46 46 44 46 45 46 46 46 FFDFEFFF
44 45 46 46 43 43 41 43 DEFFCCAC
41 43 41 43 41 43 41 43 ACACACAC
41 43 41 41 44 00 00 20 ACAAD..
00 01 c0 0c 00 20 00 01 ..... ..
00 00 75 30 00 06 66 00 ..u0..f.
c0 a8 65 cb ..e.

[Firewall] 2008/08/18 21:47:05,340
Packet matched rule DoS protection
DstIP: 192.168.37.1, SrcIP: 192.168.37.1, Len: 96, TOS: ----
Prot.: UDP (17), DstPort: 137, SrcPort: 137

Filter info: packet with same source and destination address received from interface LAN-1
send SNMP trap
packet dropped

[Ethernet] 2008/08/18 21:47:06,650
Received 83 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-4
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Source : 00:a0:57:13:04:f1 (LANCOM 13:04:f1)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 69
ID : 35722
Fragment : Offset 0
TTL : 59
Protocol : UDP
Src Address : 192.168.37.2
Dest Address : 192.168.37.1
-->UDP Header
Src Port : 58783
Dest Port : DNS
Length : 49
-->DNS Packet
ID : 2102
Type : Standard Recursion-Desired Query
No. of Queries : 1
No. of Answers : 0
No. of Name Servers : 0
No. of Add. Records : 0
-->DNS Query Record
Name : NTPS1-0.CS.TU-BERLIN.DE
Type : A (Host address)
Class : IN (Internet)

[Ethernet] 2008/08/18 21:47:06,720
Sent 99 byte Ethernet packet via LAN-1:
HW Switch Port : LAN-4
-->IEEE 802.3 Header
Dest : 00:a0:57:13:04:f1 (LANCOM 13:04:f1)
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 85
ID : 8335
Fragment : Offset 0 DontFrag
TTL : 60
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.2
-->UDP Header
Src Port : DNS
Dest Port : 58783
Length : 65
-->DNS Packet
ID : 2102
Type : Standard Recursion-Desired Recursion-Available Response
Reply Code : No error
No. of Queries : 1
No. of Answers : 1
No. of Name Servers : 0
No. of Add. Records : 0
-->DNS Query Record
Name : NTPS1-0.CS.TU-BERLIN.DE
Type : A (Host address)
Class : IN (Internet)
-->DNS Answer Record
Name : NTPS1-0.CS.TU-BERLIN.DE
Type : A (Host address)
Class : IN (Internet)
TTL : 80294 second(s)
Address : 130.149.17.21

[Ethernet] 2008/08/18 21:47:09,290
Sent 90 byte Ethernet packet via LAN-1:
-->IEEE 802.3 Header
Dest : ff:ff:ff:ff:ff:ff
Source : 00:a0:57:13:04:ff (LANCOM 13:04:ff)
Type : IPv4
-->IPv4 Header
Version : 4
Header Length : 20
Type of service : Precedence 0
Total length : 76
ID : 50390
Fragment : Offset 0
TTL : 1
Protocol : UDP
Src Address : 192.168.37.1
Dest Address : 192.168.37.255
-->UDP Header
Src Port : NTP
Dest Port : NTP
Length : 56
Body : 1d 02 06 f9 00 00 0f 5b .......[
00 00 05 80 83 ea 89 18 ........
cc 54 50 3d 4a 3d 70 4e .TP=J=pN
00 00 00 00 00 00 00 00 ........
00 00 00 00 00 00 00 00 ........
cc 54 50 3d 4a 3d 70 4e .TP=J=pN

Gruß, ich

alf29 · Beitrag von **alf29** » 19 Aug 2008, 07:55

Moin,

also die fraglichen Pakete mit gleicher Quell- und Ziel-IP-Adresse kommen nicht von einem
LANCOM, sondern von der MAC-Adresse 00:09:4f:0c:0c:d2 . 00:09:4f gehört als OUI
übrigens zu Elmeg. Hast Du eine solche im Netz? Wenn ja, würde ich bei selbiger
mal nach den rechten schauen. Irgendetwas in deren IP/NetBIOS-Stack baut da Mist...

Gruß Alfred

Pumpelhuber · Beitrag von **Pumpelhuber** » 19 Aug 2008, 08:44

Ja, dort hängt so eine Telefonanlage, mit einen Wartungszugang durchs Netzt. Muss ich erstmal rausbekommen, wo ich das Passwort herbekomme.
Antworten tut mir die Anlage auf der IP 192.168.37.200

Dank Dir für den Hinweis!

backslash · Beitrag von **backslash** » 19 Aug 2008, 18:10

Hi Punmpelhuber,

ich habe das Paket mal auseinander genommen, vielleicht hilft es dir ja weiter:

Code: Alles auswählen

DNS-Header:

34 23                              TID
28 10                              Override Demand Broadcast
00 01                              QdCnt 1
00 00                              AnCnt 0
00 00                              NsCnt 0
00 01                              ArCnt 1

Question-Record:

20                                 Label-Länge: 32
45 4c 45                     ELE   K
4a 46 45 46 4b 45 46 45 JFEFKEFE   ITZE 
43 45 46 46 43 45 48 43 CEFFCEHC   BERG
41 43 41 43 41 43 41 43 ACACACAC 
41 43 41 41 41          ACAAA        00
00                                 Label-Länge: 0 (Ende des Namen)
00 20                              RRT_NB
00 01                              RRC_IN

Additional-Record:

c0 0c                              Label-PTR: 12 -> "Kitzeberg<00>"
00 20                              RRT_NB
00 01                              RRC_IN
00 00 00 00                        TTL: 0
00 06                              Record-Länge: 6
06 00                              Flags: active + permanent
c0 a8 25 01                        IP-Adresse: 192.168.37.1

Hier teilt also ein Host namens "KITZEBERG" seine IP-Adresse mit. Irgendwie hat dieser Host die gleiche IP-Adresse wie das LANCOM (192.168.37.1) und denkt, die 192.168.37.1 wäre die Broadcastadresse für sein Netz...

Also mit dem LANCOM hat das nichts zu tun (denn das heißt ja OFFICE01)...

Gruß
Backslash

Pumpelhuber · Beitrag von **Pumpelhuber** » 19 Aug 2008, 19:44

Hi Backslash,
das hab ich nun davon, wenn ich nicht voll mit offenen Karten spiele: Also, die 192.168.37.1 ist der Lancom 1711 mit Lancom-Namen Kitzeberg. Im ersten Trace hatte ich den Namen ersetzt in Office(blablabla).
Insoweit ist es schon interessant, dass es Bedingungen gibt, unter denen der Lancom-Router sich mit seinem eigenen Brodcast beschäftigt.
Allerdings hat es wiederum auch durchaus einen Zusammenhang mit der Konfiguration im Netz und mit der Elmeg ICT8080 (192.168.37.200). Da ist ein vollwertiger Router verbaut, sieht nach Bintec aus.
In dessen Konfiguration war als erster DNS der Lancom eingetragen, auch als Gateway. Das war richtig, nur der DNS-Suffix war falsch. Den hab ich richtig eingetragen.
Als ersten WINS hatte die Elmeg den Lancom-Router Kitzeberg, mit seiner richtigen IP .37.1. Eigentlich richtig, weil in dem Subnet kein vollwärtiger WINS-Server steht. Auch diese Konfiguration hab ich geändert. Ich hab einen WINS, der zur DNS-Domäne gehört und zu dem der Lancom eine VPN hat, als ersten WINS in die Elmeg eingetragen, als zweiten WINS den LANCOM, falls die VPN wegfliegt.
Seit dieser Änderung gibt es keine Brodcastauswertung vom Lancomrouter mit der 192.168.37.1 an 192.168.37.1 mehr.
Was mir unverständlich bleibt sind die Traces oben und die Firewallmeldungen ganz klar vom Lancom-Router an Lancomrouter.
In einem Packettrace von der Elmeg, sind deren Brodcasts mit der Absenderadresse 192.168.37.200 und der richtigen MAC rausgegangen.
In dem zweiten Netz, wo dieses Problem auch aufgetreten ist, hab ich in Printservern zwischenzeitlich den betroffenen 1711er Router als zweiten WINS eingetragen. Seitdem ist auch dort das Problem beseitigt. Ich hab das Gefühl, es sollte der Programmierer doch noch mal nach den Variablen für die Platzhalter schauen. Vielleicht ist eine vertauscht. Im zweiten Netz hab ich einem Netzwerkdrucker von Canon und einem Belkin Printserver den ersten WINS geändert. Mir ist schon bewusst, dass solche Geräte evtl. vor der Olympiade im entsprechenden Land mit heissen Stäbchen gestrickt wurden. Aber hin und wieder schleicht sich auch mal ein korregierbares Böckchen im Germany-Produkt ein.

Gruß aus Kiel, Sommer geht wohl zu Ende - und Dank für Eure Hilfe.

backslash · Beitrag von **backslash** » 19 Aug 2008, 20:11

Hi Pumpelhuber,

könnte es sein, daß der Router in der Elmeg für NetBIOS-Broadcasts ein Forwarding an seinen ersten WINs macht? Das wäre aber ein extremer Fehler in der Elmeg - zumindest wenn der WINS im selben Netz steht, aus dem der Broadcast kam, denn dann hat der WINS den Broadcast auch gesehen...

Ich bleibe daher dabei, daß es kein Problem des LANCOMs ist, denn wenn einfach der Broadcast gerichtet an das LANCOM zurückgeschickt wird (durch einen fehlerhaften NetBIOS-Forwarder), kann das LANCOM nicht anders als es anzumeckern...

Gruß
Backslash

Pumpelhuber · Beitrag von **Pumpelhuber** » 19 Aug 2008, 20:54

Ja, das ist denkbar. Ich traue gar keiner Hard- und Software mehr, von der man nicht (fast) alles weiss oder sehen kann

Leider wird das Netzwerk benutzt, so dass ich da nicht so testen kann, wie ich will. Jede Konfiguration, die ich auf den Elmeg-Router-Modul zurückschreibe, führt zum Neustart der gesamten Telefonanlage (Dauer fast 90 Sek.). Und man kann ums verrecken aus der Ferne nicht sehen, ob ein FAX drüberflitzt oder jemand telefoniert. Zwei Neustarts hab ich heute schon fabriziert, bei dem ich einen bösen Anruf als Quittung bekam

Wenn ich mal so eine Anlage zum spielen habe, so um die 1000 € bei dem Ausbaustand, dann teste ich das mal aus. In den nächsten 10 Tagen hab ich dazu keine Gelegenheit. Erstmal hab ich das ja so hingebogen.
In Netzen, wo nicht solche Peripherie eingebunden ist, hatten wir auch noch nicht solche Probleme (eine weitere Gemeinsamkeit).

LANCOM-Forum.de

NETBIOS

NETBIOS

Elmeg

Gelöst und doch nicht gelöst: