Hallo zusammen!

Frame 12: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits) on interface eno1, id 0
Ethernet II, Src: Cisco_ac:58:46 (d4:8c:b5:ac:58:46), Dst: ASRockIn_da:f0:75 (a8:a1:59:da:f0:75)
Internet Protocol Version 6, Src: 2003:0:130e:9::1, Dst: 2a01:170:118f:2:621e:bbd4:997:f305
Internet Control Message Protocol v6
Type: Destination Unreachable (1)
Code: 0 (no route to destination)
Checksum: 0x0561 [correct]
[Checksum Status: Good]
Length of original datagram: 16
Reserved: 000000
Internet Protocol Version 6, Src: 2a01:170:118f:2:621e:bbd4:997:f305, Dst: 2444:5656:add::
Internet Control Message Protocol v6
Type: Echo (ping) request (128)
Code: 0
Checksum: 0xec00 [unverified] [in ICMP error packet]
[Checksum Status: Unverified]
Identifier: 0xa379
Sequence: 1
Data (56 bytes)
Data: a5585365000000005a6f010000000000101112131415161718191a1b1c1d1e1f20212223…
[Length: 56]
[Malformed Packet: ICMPv6]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]

Was ist daran jetzt malformed?
Das passiert bei allen, die ein no route to destination rausgeben, auch
bei IPs, die einem AS zugeordnet sind, aber nicht erreicht werden
können.

--
Gruß
Marco

Marco Moock wrote:
> Hallo zusammen!
>
> Frame 12: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits) on interface eno1, id 0
> Ethernet II, Src: Cisco_ac:58:46 (d4:8c:b5:ac:58:46), Dst: ASRockIn_da:f0:75 (a8:a1:59:da:f0:75)
> Internet Protocol Version 6, Src: 2003:0:130e:9::1, Dst: 2a01:170:118f:2:621e:bbd4:997:f305
> Internet Control Message Protocol v6
> Type: Destination Unreachable (1)
> Code: 0 (no route to destination)
> Checksum: 0x0561 [correct]
> [Checksum Status: Good]
> Length of original datagram: 16
> Reserved: 000000
> Internet Protocol Version 6, Src: 2a01:170:118f:2:621e:bbd4:997:f305, Dst: 2444:5656:add::
> Internet Control Message Protocol v6
> Type: Echo (ping) request (128)
> Code: 0
> Checksum: 0xec00 [unverified] [in ICMP error packet]
> [Checksum Status: Unverified]
> Identifier: 0xa379
> Sequence: 1
> Data (56 bytes)
> Data: a5585365000000005a6f010000000000101112131415161718191a1b1c1d1e1f20212223…
> [Length: 56]
> [Malformed Packet: ICMPv6]
> [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
> [Malformed Packet (Exception occurred)]
> [Severity level: Error]
> [Group: Malformed]
>
> Was ist daran jetzt malformed?

Das ist mir zu interpretiert... hast du einen hexdump des Pakets?

-is

Am 08.12.2023 um 18:48:30 Uhr schrieb Ignatios Souvatzis:

> Das ist mir zu interpretiert... hast du einen hexdump des Pakets?

0000 a8 a1 59 da f0 75 d4 8c b5 ac 58 46 86 dd 60 00
...Y..u....XF..`. 0010 00 00 00 70 3a 3b 20 03 00 00 13 0e 00 09 00 00
...p:; ......... 0020 00 00 00 00 00 01 2a 01 01 70 11 8f 00 02 65
e8 ......*..p....e. 0030 76 fe 38 f1 e0 11 01 00 88 d3 10 00 00 00
60 08 v.8...........`. 0040 65 6e 00 40 3a 3e 2a 01 01 70 11 8f 00
02 65 e8 en.@:>*..p....e. 0050 76 fe 38 f1 e0 11 24 44 56 56 0a dd
00 00 00 00 v.8...$DVV...... 0060 00 00 00 00 00 00 80 00 62 95 de
d8 00 02 9e 69 ........b......i 0070 73 65 00 00 00 00 af 0f 06 00
00 00 00 00 10 11 se.............. 0080 12 13 14 15 16 17 18 19 1a
1b 1c 1d 1e 1f 20 21 .............. ! 0090 22 23 24 25 26 27 28 29
2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01 00a0 32 33 34 35 36 37
234567

Das kommt aber diesmal vom Telekom-Netz am Übergang zu Opencarrier von
einem Opencarrier-Router.

Wird aber ebenfalls als malformed angezeigt.

Hi,

ich hab mal die Zeilenfrequenz deines Monitors justiert:

0000 a8 a1 59 da f0 75 d4 8c b5 ac 58 46 86 dd 60 00 ..Y..u....XF..`.
0010 00 00 00 70 3a 3b 20 03 00 00 13 0e 00 09 00 00 ...p:; .........
0020 00 00 00 00 00 01 2a 01 01 70 11 8f 00 02 65 e8 ......*..p....e.
0030 76 fe 38 f1 e0 11 01 00 88 d3 10 00 00 00 60 08 v.8...........`.
0040 65 6e 00 40 3a 3e 2a 01 01 70 11 8f 00 02 65 e8 en.@:>*..p....e.
0050 76 fe 38 f1 e0 11 24 44 56 56 0a dd 00 00 00 00 v.8...$DVV......
0060 00 00 00 00 00 00 80 00 62 95 de d8 00 02 9e 69 ........b......i
0070 73 65 00 00 00 00 af 0f 06 00 00 00 00 00 10 11 se..............
0080 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 .............. !
0090 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01
00a0 32 33 34 35 36 37 234567

hm.... ah, da ist noch ein ethernetheader davor, DIX ethernet mit IPv6 drin,
das IP-Paket beginnt bei offset 000E...

60 00 00 00 IPv6, traffic class 0, flow label 0,
00 70 3a 3b Payload length 0x70, next-header 58, hop limit 59

58 ist IPv6-ICMP, bis dahin also ok

2a030000... quelladresse
2a010170... zieladresse

Payload length 0x70, das Ende ist, wenn die Ethernetlaenge von 0x0e und
die IPv6-header-laenge von 0x28 (dez. 40) dazuzaehlt, bei 00A6.
Passt also bisher. ICMPv6 beginnt bei offset 0036

01 00 type=1 code=0 destination unreachable, no route to destination
88 d3 checksum (habe ich nicht nachgerechnet)
10 00 00 00 unused
hier beginnt soviel vom Ursprungspaket, wie noch reinpasst.

60 08 65 6e IPv6, traffic class 8, flow labe 8656e
00 40 3a 3e payload lenght 0x40, next-header 58, hp limit 62
(ebenfalls icmpv6)
2a010170... quelladresse (=zieladresse der antwort)
24444545... zieladresse

> Wird aber ebenfalls als malformed angezeigt.

Hm, ich wuesste (modulo mglw. falscher Checksum) nicht, warum.
Ach halt, stoert sich dein dumper an dem 10 00 00 00 im "unused"-Feld?

Unused != 0:

* darf senderseitig zwar nicht erzeugt werden (macht man oft so,
um ggfls. auf diesem Wege Protokollerweiterungen zu ermoeglichen)

* der Inhalt muss empfaengerseitig aber ignoriert werden.
(RFC 4443, S.8)

D.h. dein Analysetool ...

hat zwar Recht (also: der Route mit der Adresse
2a030000.... haette es so nicht erzeugen duerfen),

aber es hätte sich aber nicht beschweren dürfen ;-)

Sorry fuer die Verzoegerung.

-is

Am 26.01.2024 um 15:53:43 Uhr schrieb Ignatios Souvatzis:

> ich hab mal die Zeilenfrequenz deines Monitors justiert:

Zu spät, die Röhre ist im Sommer verkauft worden.

> Hm, ich wuesste (modulo mglw. falscher Checksum) nicht, warum.
> Ach halt, stoert sich dein dumper an dem 10 00 00 00 im "unused"-Feld?

Könnte sein, müsste ich mal mit nem Paketgenerator testen.
> Unused != 0:
>
> * darf senderseitig zwar nicht erzeugt werden (macht man oft so,
> um ggfls. auf diesem Wege Protokollerweiterungen zu ermoeglichen)
>
> * der Inhalt muss empfaengerseitig aber ignoriert werden.
> (RFC 4443, S.8)
>
> D.h. dein Analysetool ...
>
> hat zwar Recht (also: der Route mit der Adresse
> 2a030000.... haette es so nicht erzeugen duerfen),
>
> aber es hätte sich aber nicht beschweren dürfen ;-)

Die frage ist, was ignored hier genau bedeutet. Es trifft ja keine
relevante Fallentscheidung und wenn ein Sniffer anzeigt, dass ein Paket
nicht RFC-konform ist, ist das ja eher im Sinne des Nutzers.

Jetzt wäre es natürlich noch gut, wenn der Wireshark dann auch noch
anzeigen würde, warum das Paket fehlerhaft ist.