Is anyone here running Rocky 8 as an IPv6 gateway? If so, how did you get a reasonable prefix delegation size? It seems that NetworkManager has no way to specify a prefix delegation request size, and I’m ending up with a /128 “prefix” on my WAN interface, which leaves no addresses for my LAN devices.
It’s bad enough that Comcast/Xfinity offers residential customers only a /64 prefix (which doesn’t allow subnetting), but that’s still a lot better than a /128.
Based on my experience, there isn’t a way to request a delegation size. With that being said, the /128 is the IP your ISP is giving the router, which is not related to any prefix they would delegate. They are supposed to give a prefix to you as long as the request was sent by the router.
I’ve heard of ipv6.method shared being a way to help with this. You essentially use ipv6.method dhcp on your WAN interface and then the LAN interface gets ipv6.method shared. If this doesn’t work you may need to fall back to using dhclient in scripts that can be ran by network manager.
Just to make it clear, this Rocky 8 installation is my router.
Once, just once, I somehow managed to get a /64 prefix delegated. Alas, that situation did not survive a reboot.
My fairly minimal understanding of the IPv6 setup process** is that I request addressing information from the upstream DHCPv6 server and it sends me info about the addresses that are available for my use. I have no way to inspect what is returned, since Wireshark won’t attach to an interface until that interface is up, and that is long after all the packets of interest have been received. For all I know, I might be offered a /64 prefix and the internal DHCP client in NetworkManager just isn’t using it.
Your Rocky Linux 8 box being a router wasn’t lost on me, as I’ve traditionally ran CentOS (and now Rocky) as my routers. That’s why I was suggesting ipv6.method shared on the LAN interface.
This is what I would suggest doing:
Beyond this, you may need to put network manager into debug mode so you can try to determine where the issue is. You can do this by modifying /etc/NetworkManager/NetworkManager.conf or running nmcli general logging level TRACE domains ALL and then viewing journalctl -u NetworkManager.
That gave me the clue I needed. I had been selecting “Automatic” in the GUI IPv6 configuration dialog. That uses SLAAC setup, which is never going to give me anything but a single global address. The description of “DHCP only” (“Choose this option to not use RA”) suggested that it was wrong for a gateway.
So, I’m getting my /64 prefix now, and recent info indicates that’s the best I’m going to get. I’ll have to play some truly awful games with my DHCP6 server and the IPv6 firewall to effectively segregate the IoT clients that I would like to have on a separate subnet, but I’ll just have to make do with that.
Thanks much. I was getting lost in this rabbit hole, but you pointed me to the way out.
And, I spoke too soon. After a reboot, I’m back to the /128 prefix, which is useless on a gateway.
I’ve looked at the trace output in the journal, and the only lease I’m being offered is the /128. I’ll try changing the DHCP6 DUID to see if a fresh lease is any better.
Well, that didn’t help. I figured out how to change the DUID that is sent. That results in a different lease, but it’s still a /128 address. Below is the (not very interesting) trace output from the time the link-local address from the upstream router becomes valid. My IPv6 firewall is wide open – everything is accepted.
<trace> [1678657016.7689] ipv6ll[eecc3357170b74d3,ifindex=2]: changed: address fe80::9a9e:9a2c:2963:fa4c is ready
<trace> [1678657016.7689] l3cfg[e9bdab3895210076,ifindex=2]: commit type register (type "update", source "ipv6ll", existing 7a195f2976581222) -> 7a195f2976581222
<trace> [1678657016.7689] ipv6ll[eecc3357170b74d3,ifindex=2]: schedule changed signal on idle
<trace> [1678657016.7689] ipv6ll[eecc3357170b74d3,ifindex=2]: emit changed signal (state=ready, fe80::9a9e:9a2c:2963:fa4c)
<trace> [1678657016.7689] device[2d42ddae11476151] (enp3s0): ip:ll6: set state done (was pending, llstate=ready, lladdr=fe80::9a9e:9a2c:2963:fa4c)
<debug> [1678657016.7689] device[2d42ddae11476151] (enp3s0): ipv6.dhcp-iaid: using 3409513159 (0xcb390ac7) IAID (str: 'ifname', explicit 0)
<debug> [1678657016.7689] device[2d42ddae11476151] (enp3s0): ipv6.dhcp-duid: generate 00:04:52:86:e1:2b:5b:ed:bf:b5:0e:bd:5d:c3:1e:ec:99:47 DUID '00:04:52:86:e1:2b:5b:ed:bf:b5:0e:bd:5d:c3:1e:ec:99:47' (enforcing)
<trace> [1678657016.7689] dhcp6: creating IPv6 DHCP client of type NMDhcpSystemd
<trace> [1678657016.7689] dhcp6 (enp3s0): duid: set 00:04:52:86:e1:2b:5b:ed:bf:b5:0e:bd:5d:c3:1e:ec:99:47
<info> [1678657016.7689] dhcp6 (enp3s0): activation: beginning transaction (timeout in 45 seconds)
<trace> [1678657016.7689] dhcp6 (enp3s0): dhcp-client6: set 0x55972d6ece00
<trace> [1678657016.7690] libsystemd: enp3s0: DHCPv6 client: Starting in Solicit mode
<trace> [1678657016.7690] libsystemd: enp3s0: DHCPv6 client: State changed: stopped -> solicitation
<trace> [1678657016.7690] dbus-object[c519a98b77b2006c]: export: "/org/freedesktop/NetworkManager/DHCP6Config/2"
<trace> [1678657016.7691] libsystemd: enp3s0: DHCPv6 client: Sent Solicit
<trace> [1678657016.7691] libsystemd: enp3s0: DHCPv6 client: Next retransmission in 1s
<trace> [1678657016.7691] device[2d42ddae11476151] (enp3s0): ip6: check-state: state pending => pending, is_failed=0, is_pending=1, is_started=1 temp_na=0, may-fail-4=1, may-fail-6=1;; manualip4=done dhcp4=done; manualip6=done ll6=done dhcp6=pending
<trace> [1678657016.7691] device[2d42ddae11476151] (enp3s0): ip: check-state: (combined) state done => done
<trace> [1678657016.7885] libsystemd: enp3s0: DHCPv6 client: Processed Advertise message
<trace> [1678657017.8731] libsystemd: enp3s0: DHCPv6 client: State changed: solicitation -> request
<trace> [1678657017.8732] libsystemd: enp3s0: DHCPv6 client: Sent Request
<trace> [1678657017.8732] libsystemd: enp3s0: DHCPv6 client: Next retransmission in 996ms
<trace> [1678657017.8934] libsystemd: enp3s0: DHCPv6 client: Processed Reply message
<trace> [1678657017.8934] libsystemd: enp3s0: DHCPv6 client: T1 expires in 33min 53s
<trace> [1678657017.8934] libsystemd: enp3s0: DHCPv6 client: T2 expires in 43min 31s
<trace> [1678657017.8934] libsystemd: enp3s0: DHCPv6 client: Valid lifetime expires in 57min 29s
<trace> [1678657017.8935] libsystemd: enp3s0: DHCPv6 client: State changed: request -> bound
<debug> [1678657017.8935] dhcp6 (enp3s0): client event 12
<debug> [1678657017.8935] dhcp6 (enp3s0): lease available
<trace> [1678657017.8935] dhcp6 (enp3s0): notify: event=bound, l3cd=[3a9799318129a39f]
<info> [1678657017.8935] dhcp6 (enp3s0): state changed new lease, address=2001:558:6033:45:e5df:9527:9d34:b014
<debug> [1678657017.8935] dhcp6 (enp3s0): option dhcp6_name_servers => '2001:558:feed::1 2001:558:feed::2'
<debug> [1678657017.8935] dhcp6 (enp3s0): option ip6_address => '2001:558:6033:45:e5df:9527:9d34:b014'
<trace> [1678657017.8935] device[2d42ddae11476151] (enp3s0): ip:dhcp6: lease update
<trace> [1678657017.8936] l3cfg[e9bdab3895210076,ifindex=2]: IP configuration changed (mark dirty)
<trace> [1678657017.8936] l3cfg[e9bdab3895210076,ifindex=2]: commit on idle (scheduled) (auto)
<trace> [1678657017.8936] l3cfg[e9bdab3895210076,ifindex=2]: commit update (auto) (idle handler)
<trace> [1678657017.8936] l3cfg[e9bdab3895210076,ifindex=2]: emit signal (l3cd-changed, l3cd-old=[927bd62031612b31], l3cd-new=[34a95ea7d24242f4], commited=0)
I think you may want to use tcpdump on the WAN interface connecting to the ISP, and verify that we indeed receive a DHCPv6 Reply with the Delegated prefix. Maybe they are simply not configuring this option?
Unfortunately, tcpdump will not connect to an interface that is not currently up, and all the negotiations occur prior to that. I don’t know of any way to see those DHCP packets.
Could you paste the output of ip addr command?
As requested (public IPv4 address obscured):
# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether fc:aa:14:21:c4:24 brd ff:ff:ff:ff:ff:ff permaddr d8:5e:d3:8a:11:0d
inet xx.xx.xx.xx/21 brd xx.xx.yy.255 scope global dynamic noprefixroute enp3s0
valid_lft 341499sec preferred_lft 341499sec
inet6 2001:558:6033:45:2da9:d06f:c570:d836/128 scope global dynamic noprefixroute
valid_lft 3520sec preferred_lft 3520sec
inet6 fe80::9a9e:9a2c:2963:fa4c/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 68:1c:a2:12:b0:ea brd ff:ff:ff:ff:ff:ff
inet 192.168.43.1/24 brd 192.168.43.255 scope global noprefixroute enp5s0
valid_lft forever preferred_lft forever
This is with IPv6 method “Automatic, DHCP only” set for enp3s0, and IPv6 disabled on the enp5s0 LAN interface. I’ve omitted the “wlo” and “virbr” interfaces since they are not relevant.
If I try to use the above-suggested “Shared with other computers” IPv6 method for the LAN interface, that interface won’t come up at all, perhaps because of the lack of a usable IPv6 prefix on the WAN.
Note that there is no default IPv6 route, and any attempt to “ping -6” results in “Network is unreachable.” If I use the “Automatic” method (which uses SLAAC), I do get a usable global route, but that method understandably assigns just a single 128-bit address, which cannot be shared on my LAN,
That blog post is from 2015, and things have changed a lot since then.
I’ll take a look and see if it still makes any sense.
“Automatic” method in IPv6 does not just mean SLAAC. It means either SLAAC or stateful DHCPv6 (or even both), depending on the flags that are set in the RA message you receive from the ISP. Another thing to note is that stateful DHCPv6 is only meant to provide IPv6 address, so a /128 is actually expected. Other stuff like default route and prefix length should only come from the RA.
From what you described in your last sentence (“I do get a usable global route, but that method understandably assigns just a single 128-bit address”), I suspect that you’ve received an RA message which had the M flag set (indicates using stateful DHCPv6, hence the /128 address), and the A flag was not set (hence your device didn’t generate any global /64 address). Your ISP probably didn’t configure the PD option for DHCPv6 either.
Can you ask them for this information? Or maybe setup a tap device or a network switch in between and configure SPAN port to capture traffic?
Yeah, I originally thought this was because of Network Manager doesn’t support DHCPv6 PD, but turned out it does based on this blog post: IPv6 with NetworkManager. So, I think the problem is something related to your ISP’s configuration.
I was still able to tcpdump on my wired card which had no cable attached to it (NO-CARRIER). I don’t know why it doesn’t work in your case.
~$ ip -br link show | grep enp0
enp0s31f6 DOWN 00:2b:67:a8:70:ca <NO-CARRIER,BROADCAST,MULTICAST,UP>
~$
~$ sudo tcpdump -nni enp0s31f6
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp0s31f6, link-type EN10MB (Ethernet), snapshot length 262144 bytes
Looks like there is more than one level of “down-ness”. If I use “ifconfig enp3s0 down”, then tcpdump will not connect. If I tell NetworkManager to “disconnect”, then tcpdump will attach to the interface.
If I start tcpdump on the disconnected interface and then tell NetworkManager to connect, I do see RA packets with /64 prefixes. I’d like to upload the packet capture in text form, but it appears that the only file types I can upload are image files (.jpg, .gif, etc), so I guess I’ll have to past the text here. Sorry about that. The edited gaps are various MDNS packets that appear to be from CUPS, and TCP packets that seem to be from Firefox.
1 10:36:21.595870 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 3675881598:3675881645, ack 16791773, win 116, options [nop,nop,TS val 579666436 ecr 2537936129], length 47
2 10:36:21.870636 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 0:47, ack 1, win 116, options [nop,nop,TS val 579666711 ecr 2537936129], length 47
3 10:36:22.158568 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 0:47, ack 1, win 116, options [nop,nop,TS val 579666999 ecr 2537936129], length 47
4 10:36:22.702653 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 0:47, ack 1, win 116, options [nop,nop,TS val 579667543 ecr 2537936129], length 47
5 10:36:23.178987 IP6 _gateway > ff02::1: ICMP6, router advertisement, length 144
6 10:36:23.758861 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 0:47, ack 1, win 116, options [nop,nop,TS val 579668599 ecr 2537936129], length 47
7 10:36:26.062616 IP6 2602:fd3f:0:ff06::111.https > omega-3x.local.46606: Flags [P.], seq 0:47, ack 1, win 116, options [nop,nop,TS val 579670903 ecr 2537936129], length 47
8 10:36:26.679168 IP6 _gateway > ff02::1: ICMP6, router advertisement, length 144
9 10:36:27.242143 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
10 10:36:27.792119 IP6 :: > ff02::1:ff63:fa4c: ICMP6, neighbor solicitation, who has omega-3x.local, length 32
11 10:36:27.984269 IP6 :: > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
12 10:36:28.816256 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
13 10:36:28.956989 IP6 omega-3x.local > ff02::2: ICMP6, router solicitation, length 8
14 10:36:28.965868 IP6 _gateway > ff02::1:ff63:fa4c: ICMP6, neighbor solicitation, who has omega-3x.local, length 32
15 10:36:28.965970 IP6 omega-3x.local > _gateway: ICMP6, neighbor advertisement, tgt is omega-3x.local, length 32
20 10:36:29.688365 IP6 _gateway > ff02::1: ICMP6, router advertisement, length 144
21 10:36:29.688844 IP6 omega-3x.local.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 solicit
22 10:36:29.709948 IP6 _gateway.dhcpv6-server > omega-3x.local.dhcpv6-client: dhcp6 advertise
23 10:36:29.777120 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 2 group record(s), length 48
27 10:36:29.958057 IP6 _gateway > ff02::1:ff63:fa4c: ICMP6, neighbor solicitation, who has omega-3x.local, length 32
28 10:36:29.958120 IP6 omega-3x.local > _gateway: ICMP6, neighbor advertisement, tgt is omega-3x.local, length 32
36 10:36:30.741464 IP6 omega-3x.local.dhcpv6-client > ff02::1:2.dhcpv6-server: dhcp6 request
37 10:36:30.760232 IP6 _gateway.dhcpv6-server > omega-3x.local.dhcpv6-client: dhcp6 reply
38 10:36:30.765202 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
41 10:36:30.958060 IP6 _gateway > ff02::1:ff63:fa4c: ICMP6, neighbor solicitation, who has omega-3x.local, length 32
42 10:36:30.958121 IP6 omega-3x.local > _gateway: ICMP6, neighbor advertisement, tgt is omega-3x.local, length 32
43 10:36:31.088205 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
70 10:36:33.019028 IP6 _gateway > ff02::1: ICMP6, router advertisement, length 144
71 10:36:33.022115 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
74 10:36:33.616246 IP6 omega-3x.local > ff02::16: HBH ICMP6, multicast listener report v2, 3 group record(s), length 68
Can you try this:
sudo tcpdump -nni <your_interface> 'icmp6 or port 546 or port 547' -vvv
That should filter out only ICMPv6 and DHCPv6 packets, and show more verbose output.
That “-vvv” output is a bit unwieldy to post here, so here’s the uuencoded raw pcap output. This will decode into setup2.pcap, which you can read into Wireshark or tcpdump.
begin 644 setup2.pcap
MU,.RH0(`!```````````````!``!````K^419+\\`0#&````Q@```#,S````
M`0`!7'[01H;=8`````"0.O_^@`````````(!7/_^?M!&_P(`````````````
M`````88`X:\`P`<(`#;N@````^@#!$````DZ@``$G4``````(`$%6$!``%P`
M``````````,$0```"3J```2=0``````@`0584`4`!````````````P1````)
M.H``!)U``````"`!!5A@,P!%```````````#!$````DZ@``$G4``````(`$%
M6(`(`````````````++E$639O@H`5@```%8````S,_]C^DS\JA0AQ"2&W6``
M````(#K_`````````````````````/\"`````````````?]C^DR'`&CE````
M`/Z`````````FIZ:+"EC^DP.`8&**QX%9;+E$604K`P`Q@```,8````S,P``
M``$``5Q^T$:&W6``````D#K__H`````````"`5S__G[01O\"````````````
M``````&&`.&O`,`'"``V[H````/H`P1````).H``!)U``````"`!!5A`0`!<
M```````````#!$````DZ@``$G4``````(`$%6%`%``0```````````,$0```
M"3J```2=0``````@`0588#,`10```````````P1````).H``!)U``````"`!
M!5B`"`````````````"SY1%DKI$-`#X````^````,S,````"_*H4(<0DAMU@
M#O#Y``@Z__Z`````````FIZ:+"EC^DS_`@`````````````````"A0`DO```
M``"VY1%D72<+`,8```#&````,S,````!``%<?M!&AMU@`````)`Z__Z`````
M`````@%<__Y^T$;_`@`````````````````!A@#AKP#`!P@`-NZ````#Z`,$
M0```"3J```2=0``````@`0580$``7````````````P1````).H``!)U`````
M`"`!!5A0!0`$```````````#!$````DZ@``$G4``````(`$%6&`S`$4`````
M``````,$0```"3J```2=0``````@`058@`@`````````````MN419.\I"P"5
M````E0```#,S``$``ORJ%"'$)(;=8`ID]0!?$0'^@````````)J>FBPI8_I,
M_P(```````````````$``@(B`B,`7^/U`<63I0`.`````P`,RSD*QP``````
M`````"<`$0$(;VUE9V$M,W@%;&]C86P```8`"@`7`!@`'P`X`%(``0`2``12
MAN$K6^V_M0Z]7<,>[)E)``@``@``MN419%9U"P"Z````N@```/RJ%"'$)``!
M7'[01H;=8`````"$$4#^@`````````(!7/_^?M!&_H````````":GIHL*6/Z
M3`(C`B(`A#W(`L63I0`!`!(`!%*&X2M;[;^U#KU=PQ[LF4D``@`.``$``18+
M<KL4_K7507L``P`HRSD*QP`!D64``H([``4`&"`!!5A@,P!%+:G0;\5PV#8`
M`R+*``,BR@`7`"`@`058_NT````````````!(`$%6/[M`````````````K?E
M$63;=@L`O0```+T````S,P`!``+\JA0AQ"2&W6`*9/4`AQ$!_H````````":
MGIHL*6/Z3/\"```````````````!``("(@(C`(=^$`./E(P``@`.``$``18+
M<KL4_K7507L``P`HRSD*QP````````````4`&"`!!5A@,P!%+:G0;\5PV#8`
M```````````G`!$!"&]M96=A+3-X!6QO8V%L```&``@`%P`8`!\`.``!`!(`
M!%*&X2M;[;^U#KU=PQ[LF4D`"``"``"WY1%DOK\+`+H```"Z````_*H4(<0D
M``%<?M!&AMU@`````(010/Z``````````@%<__Y^T$;^@````````)J>FBPI
M8_I,`B,"(@"$MR@'CY2,``$`$@`$4H;A*UOMO[4.O5W#'NR920`"``X``0`!
M%@MRNQ3^M=5!>P`#`"C+.0K'``!_R0`"%,D`!0`8(`$%6&`S`$4MJ=!OQ7#8
M-@`#(LD``R+)`!<`("`!!5C^[0````````````$@`058_NT````````````"
MM^419'PU#`!6````5@```#,S_W#8-ORJ%"'$)(;=8``````@.O\`````````
M````````````_P(````````````!_W#8-H<`&8L`````(`$%6&`S`$4MJ=!O
MQ7#8-@X!T!KGDZ$LN.419.O*"P!6````5@```#,S_W[01ORJ%"'$)(;=8```
M```@.O_^@````````)J>FBPI8_I,_P(````````````!_W[01H<`4*8`````
M_H`````````"`5S__G[01@$!_*H4(<0DN>419%=5#`!6````5@```#,S_W[0
M1ORJ%"'$)(;=8``````@.O\@`0588#,`12VIT&_%<-@V_P(````````````!
M_W[01H<`AA``````_H`````````"`5S__G[01@$!_*H4(<0DNN419`SN"0#&
M````Q@```#,S`````0`!7'[01H;=8`````"0.O_^@`````````(!7/_^?M!&
M_P(``````````````````88`X:\`P`<(`#;N@````^@#!$````DZ@``$G4``
M````(`$%6$!``%P```````````,$0```"3J```2=0``````@`0584`4`!```
M`````````P1````).H``!)U``````"`!!5A@,P!%```````````#!$````DZ
M@``$G4``````(`$%6(`(`````````````+KE$602LPP`5@```%8````S,_]^
MT$;\JA0AQ"2&W6``````(#K_(`$%6&`S`$4MJ=!OQ7#8-O\"````````````
M`?]^T$:'`(80`````/Z``````````@%<__Y^T$8!`?RJ%"'$)+OE$63'$@T`
M5@```%8````S,_]^T$;\JA0AQ"2&W6``````(#K_(`$%6&`S`$4MJ=!OQ7#8
M-O\"`````````````?]^T$:'`(80`````/Z``````````@%<__Y^T$8!`?RJ
M%"'$)+OE$629,PT`5@```%8```#\JA0AQ"0``5Q^T$:&W6``````(#K_(`$%
M6&`S`$4``````````2`!!5A@,P!%+:G0;\5PV#:(`)4QX````/Z`````````
M`@%<__Y^T$8"`0`!7'[01KOE$62C-0T`5@```%8```#\JA0AQ"0``5Q^T$:&
MW6``````(#K_(`$%6&`S`$4``````````2`!!5A@,P!%+:G0;\5PV#:(`)4Q
MX````/Z``````````@%<__Y^T$8"`0`!7'[01KWE$62&=`L`Q@```,8````S
M,P````$``5Q^T$:&W6``````D#K__H`````````"`5S__G[01O\"````````
M``````````&&`.&O`,`'"``V[H````/H`P1````).H``!)U``````"`!!5A`
M0`!<```````````#!$````DZ@``$G4``````(`$%6%`%``0```````````,$
M0```"3J```2=0``````@`0588#,`10```````````P1````).H``!)U`````
1`"`!!5B`"```````````````
`
end
I’m not familiar with this format. Trying to read it with wireshark and tcpdump but no success. Can you point me to a link on how to convert it to a pcap file?
Or can you try upload the capture to cloudshark?
If you don’t have a command called “uudecode”, then you need to install the “sharutils” package. If you run uudecode on that block of text it will create a file “setup2.pcap”, which both wireshark and “tcpdump -r” will accept.