PPPoED some frame types are not recognized as answers

[Nord-1]

ENV:
Scapy 2.4.4 and Scapy 2.4.3
Linux kali 5.5.0-kali1-amd64 #1 SMP Debian 5.5.13-2kali1 (2020-04-03) x86_64 GNU/Linux
Python 3.8.6 (default, Sep 25 2020, 09:36:53)

ISSUE:
When sending PPPoED frames (PADI and PADR), the first srp1 recognized the response as answers while the second one did not. I also tried the srp, srp1loop...etc, but all did not recognize the returned frames after sending the PADR as "answers". If I use sniff() I can see that all returned frames were captured by Scapy without problems. also all captured frames are error and issue-free in Wireshark.
Note: I am not using any custom payload, this is the standard PPPoED. In other words, even if I change the Raw(bytes) with the correspondent PPPoED sublayer, the issue persists.

REPRODUCE:

>>> ans = srp1(Ether(dst='ff:ff:ff:ff:ff:ff')/PPPoED()/PPPoED_Tags())
Begin emission:
Finished sending 1 packets.
*
Received 1 packets, got 1 answers, remaining 0 packets
>>> ans = srp1(Ether(dst=ans[Ether].src)/PPPoED(version=1, type=1, code=25, sessionid=0)/Raw(load=b'\x01\x01\x00\x00\x01\x04\x00\x10%b' %ans[Ether][PPPoED][PPPoED_Tags][2].tag_value))
Begin emission:
Finished sending 1 packets.
......^C
Received 6 packets, got 0 answers, remaining 1 packets

[gpotter2]

Hi. Could you

• fill up the template
• give us an actually reproducible example (because yours is network dependent), based for instance on a pcap that you captured with packets that don't get recognized as an answer.

Thanks

[Nord-1]

Hi gpotter2

Thanks for your replay.

I attached a pcap file. After I sent the second packet (PADR), the returned packets were not considered as "answers" by Scapy.

Can you please tell me what do you mean by filling up the template?

pppoed-packets.zip

[gpotter2]

Thanks. When you create an issue there is a basic template that forces users to give extensive details about their issue: https://github.com/secdev/scapy/blob/master/.github/ISSUE_TEMPLATE.md

[Nord-1]

Thanks for your quick replay! got it!

am I missing any other requirements after submitting the pcap file? In the first post I stated clearly the issue and provided example of the scapy commands to reproduce?

[gpotter2]

It's fine. Ideally you would post an example that uses the pcap. Here's an example of a really great issue report: #2784

[Nord-1]

Thank you for providing the example, which is a good reference to use for future reports .

[gpotter2]

So I had a look, and I don't really understand what's wrong. I don't really know PPPoED.
Could you fill up the template? The expected result part will help. Thanks

[Nord-1]

Thanks for your efforts. I took two screenshots to explain it easier:

1- After I sent the PADI frame, Scapy considered all the returned frames form my modem as "answers" without issues:

2- Upon receiving the responses in the first step, I sent another frame called PADR frame. This time Scapy did not consider the returned frames as "answers", although the protocol in use is standard without any customization:

Note: I had to enter CTRL+C to cancel the operation, otherwise Scapy will loop forever ....

Expected Result:

• Scapy should consider the returned frames after sending the PADR frame (step 2) as "answers" too.
• What's the criteria that Scapy uses to mark a returned response as "answers" ?

RFC: https://tools.ietf.org/html/rfc2516

[gpotter2]

Thanks for this detailed explanation !

What's the criteria that Scapy uses to mark a returned response as "answers" ?

The answer packet should have a function called def answers(self, other): that returns True if self is an answer of other.

Though if we do try it on the pcap you've provided, it all seems to work alright:

>>> a = rdpcap("pppoed-packets.pcap")
>>> a[6:8].show()
0000 CookedLinux / PPPoE Active Discovery Request (PADR) / PPPoE TagsService-Name, AC-Cookie
0001 CookedLinux / PPPoE Active Discovery Session-confirmation (PADS) / PPPoE TagsService-Name, AC-Name, AC-Cookie, ??
>>> a[7].answers(a[6])
True
>>> a[7].hashret() == a[6].hashret()
True

If I got it right, only the PADS should count as an answer for the PADR.. right?

(To get the same outputs as me, you'll need #2853 where I've updated the PPPoED packet summaries)

[Nord-1]

If I got it right, only the PADS should count as an answer for the PADR.. right?

Correct, The PADS should be counted as an answer for the PADR;

Is there any workaround to access the PADS after sending the PADR?

[Nord-1]

Is there any workaround to make the PADS packet an answer for the PADR?

[gpotter2]

I can't really reproduce the issue. I've made commits like 236ea58 but have no way to test them since the "reproducible" example you've given requires to have certain network conditions...

Could you apply it and try it out? Thanks