[bug]: admin macaroon: unmarshal v2: field data extends past end of buffer

[blob42]

Background

I am trying to connect to LND from Zeus using the hex admin macaroon but I keep getting the error: unmarshal v2: field data extends past end of buffer

Zeus: v0.7.7 LND: 0.17.2-beta commit=v0.17.2-beta

I upgraded recently lnd from 0.16.X to 0.17.2 and deleted the old admin macaroon to use the new format which was required for lightning terminal to start. It seems that this problem appeared since then. I had a previous macaroon that work on a previous version of Zeus v0.6.1 unfortunately I don't have anymore access to it.

I could previously connect without issues. Is there any way to debug this issue properly ?

I Know I can use the Lightning Connect method ( which indeed works ) but I would like to keep having access directly through LND rest interface as well.

Your environment

Zeus: v0.7.7 LND: 0.17.2-beta commit=v0.17.2-beta

Steps to reproduce

Tell us how to reproduce this issue. Please provide stacktraces and links to code in question.

1. I created the hex format of the macaroon using: xxd -ps -u -c1000 admin.macaroon | qrencode -t utf8

2. I paste the hex macaroon in Zeus LND(REST) connection form

4. On LND I get the following errors:

lnd  | 2023-11-24 22:13:00.954 [ERR] RPCS: [/lnrpc.Lightning/WalletBalance]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:00.955 [ERR] RPCS: [/lnrpc.Lightning/GetTransactions]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:00.955 [ERR] RPCS: [/lnrpc.Lightning/ChannelBalance]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:00.960 [ERR] RPCS: [/lnrpc.Lightning/GetInfo]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:01.092 [ERR] RPCS: [/lnrpc.Lightning/ListChannels]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:01.092 [ERR] RPCS: [/lnrpc.Lightning/ClosedChannels]: unmarshal v2: field data extends past end of buffer
lnd  | 2023-11-24 22:13:01.092 [ERR] RPCS: [/lnrpc.Lightning/PendingChannels]: unmarshal v2: field data extends past end of buffer

Expected behaviour

Connecting to my LND node.

Actual behaviour

gRPC error displayed on Zeus and LND log.

[guggero]

It sounds to me like the QR code wasn't created correctly. Can you check the output of your xxd command before piping it into qrencode? There should be no line breaks (might need to adjust -c to a higher number if there are). Also, is this just a typo in the issue or did you use xdd instead of xxd?

[blob42]

Thanks @guggero for the quick reply.

Sorry for the typo the command to encode the macaroon is xxd -ps -u -c1000. Before the original post I have already tried with higher column values up to 10000 and also tried to copy paste the hex code directly without qrencode. All of these result in the same error.

Is there some script somewhere or tool to check the encoding/decoding of the macaroon before digging deeper ?

[guggero]

Hmm, okay. Very weird. You can try this tool: https://guggero.github.io/cryptography-toolkit/#!/macaroon Or you can also try lncli printmacaroon <hex_string>.

[blob42]

Thanks for the tool, I am now getting a better error message: Error: Unexpected field type, got 114 want 0

Command used (arch linux): xxd -ps -c 1000 macaroon | xclip -selection clipboard

I used xxd piped to xclip to avoid selecting with mouse. I alos tried a previously backed up macaroon which gave me the same error.

EDIT: What is a safe way to save the current node private keys and start with a new node key ? Can I start a separate profile if I change the root working dir of lnd ? I would like to try with a clean macaroon and also post here if I keep getting the error.

[guggero]

Do you get that error with the web tool or also with lncli printmacaroon?

Also, if you use lncli locally against the same machine using that macaroon (try explicitly specifying it with --macaroonpath ...) do things work normally?

When you re-created the macaroons, how exactly did you do that? Delete all *.macaroon files in .lnd/data/chain/... and then restart lnd? Might be worth trying that again.

Just to make sure your xxd doesn't do anything unexpected, can you try the following?

xxd -ps -c 9999 ~/.lnd/.../admin.macaroon > /tmp/hex-macaroon.txt
cat /tmp/hex-macaroon.txt | xxd -ps -r > /tmp/decoded.macaroon
diff ~/.lnd/.../admin.macaroon /tmp/decoded.macaroon

The output of the last command should be empty.

What is a safe way to save the current node private keys and start with a new node key?

Does the node have channels? Then I would avoid trying anything like that. What you can try is to remove the .lnd/data/chain/.../macaroons.db as well as all *.macaroon files, to force a new macaroon root key DB to be created.

[guggero]

I would like to try with a clean macaroon and also post here

Can you perhaps send me hex string on our Slack? You can invalidate the macaroon by deleting the macaroons.db file as mentioned above.

[blob42]

Also, if you use lncli locally against the same machine using that macaroon (try explicitly specifying it with --macaroonpath ...) do things work normally?

Yes, I use a docker vm. The admin macaroon is shared with other vms through a shared volume and it works flawlessly. The issue is only with encoding?/decoding.

When you re-created the macaroons, how exactly did you do that? Delete all *.macaroon files in .lnd/data/chain/... and then restart lnd?

Yes that's what I did. However I did not delete the macaroons.db. Now I tried again and also removed the macaroons.db and I still have the same issue. The macaroon file can be read directly but cannot be encooded then recoded.

Just to make sure your xxd doesn't do anything unexpected, can you try the following?

The output is indeed empty .

I don't have a slack account, is there an other way I can send you the macaroon.

[blob42]

@guggero I found the issue, it's my fault. My command to copy the macaroon was like this: docker exec .... cat admin.macaroon | xxd -ps -c 9999 Which would do a cat on the vm (alpine alpine linux) then run xxd on the host system. The piping from docker was modifying the resulting hex code in the middle so I didn't notice when I was comparing the header/footer of the hex code.

Running xxd directly on the vm docker exec ... xxd -p -c 9999 admin.macaroon | qrencode ... then the resulting hex can be decoded without issue.

Thanks for your time, hopefully this issue will help someone in the future doing the same errors as me.