gwlim / mips24k-ar71xx-lede-patch

Patchset for MIPS24Kc AR71xx For LEDE Project
33 stars 15 forks source link

package MWAN3 not working after fast path patch applied #5

Open tacuar opened 7 years ago

tacuar commented 7 years ago

someone posted something herebelow, i did not understand well, but i quote and re-post here in order to let you see and maybe you could make the MWAN3 working after the fast path patch is applied:

because MWAN3 uses fwmark, which is not supported by fast path, thus the nat to fwmark is lost, causing match to routing table. the fast path shall, however, support priority of SKB and DSCP, therefore the MWAN3 shall work properly by patching tos instead of fwmark:

define SFE_IPV4_CONNECTION_MATCH_FLAG_PRIORITY_REMARK (1<<5)

                                    /* remark priority of SKB */

define SFE_IPV4_CONNECTION_MATCH_FLAG_DSCP_REMARK (1<<6)

/ remark DSCP of packet /

tacuar commented 7 years ago

the regret is with me here because i am not able to figure it out by myself something simple. i'm a greenhand.

gwlim commented 7 years ago

It is not so simple SFE itself uses FWMark I need to spend more time to understand what it does also we have other pressing issues like IPv6 Fast Path not working and I need to find out why even though the code seems to be in.

lsiudut commented 6 years ago

EDIT: ouch, this is basically what's in first comment. Ignore me.

lsiudut commented 6 years ago

Here's interesting thing. It seems that once flow hits fast classify it mixes gateways but keeps the right source ipaddr. This is mix of two dumps from two different interfaces from my gateway (mocked two wans). Keep an eye on destination mac address + I've prepended each of line with interface name:

wan1: e8:94:f6:cd:47:3c > 20:28:18:a1:78:4f, ethertype IPv4 (0x0800), length 1514: 192.168.1.2.34001 > 78.153.202.240.80: Flags [.], seq 70952:72400, ack 1, win 229, options [nop,nop,TS val 211204627 ecr 1900765311], length 1448: HTTP
wan2: e8:94:f6:cd:47:3c > 20:28:18:a1:78:4e, ethertype IPv4 (0x0800), length 1514: 192.168.1.2.34001 > 78.153.202.240.80: Flags [.], seq 71292:72740, ack 1, win 229, options [nop,nop,TS val 211200762 ecr 1900764345], length 1448: HTTP
wan1: e8:94:f6:cd:47:3c > 20:28:18:a1:78:4f, ethertype IPv4 (0x0800), length 1514: 192.168.1.2.34001 > 78.153.202.240.80: Flags [.], seq 73848:75296, ack 1, win 229, options [nop,nop,TS val 211204627 ecr 1900765311], length 1448: HTTP

Middle packet was sent to bad interface. Source address is correct. They all should've been sent to wan1 though.

Lot of packages get mixed like this (about 80% was sent to bad interface). In my test env, since in fact I've used single WAN connection, it worked, but in scenario with trully different broadbands it will obviously fail.

Edit: it seems to me like a race condition between fast classifier and routing (?). Maybe I'll find some time to dig into this.