FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
514 views 1 comments
by anonymous

RUT240 - RUT2_R_00.07.02.1

I'm using my RUT240 in "bridge mode" toward my SRX300 router and seeing an odd issue with arp.

I got the connection up, DHCP working fine to the SRX but traffic wasn't getting out.

From the RUT I was seeing echo request and reply but the reply wasn't reaching the SRX.

root@gb-lte:/tmp# tcpdump -i wwan0 -vv -nn

tcpdump: listening on wwan0, link-type RAW (Raw IP), capture size 262144 bytes

23:29:14.075157 IP (tos 0x0, ttl 62, id 42582, offset 0, flags [none], proto ICMP (1), length 84)

    100.71.149.54 > 8.8.4.4: ICMP echo request, id 32296, seq 0, length 64

23:29:14.252186 IP (tos 0x0, ttl 114, id 0, offset 0, flags [none], proto ICMP (1), length 84)

    8.8.4.4 > 100.71.149.54: ICMP echo reply, id 32296, seq 0, length 64

The SRX was also receiving ARP requests from the RUT sourcing from br-lan's native address:

gareth@gb-srx# run monitor traffic interface irb.100 layer2-headers no-resolve

verbose output suppressed, use <detail> or <extensive> for full protocol decode

Address resolution is ON. Use <no-resolve> to avoid any reverse lookup delay.

Address resolution timeout is 4s.

Listening on irb.100, capture size 96 bytes

00:39:15.826101  In 00:1e:42:39:ff:fd > Broadcast, ethertype 802.1Q (0x8100), length 56: vlan 100, p 0, ethertype ARP, arp who-has 100.71.149.54 tell 192.0.2.1

00:39:17.810876  In 00:1e:42:39:ff:fd > Broadcast, ethertype 802.1Q (0x8100), length 56: vlan 100, p 0, ethertype ARP, arp who-has 100.71.149.54 tell 192.0.2.1

Looking at the RUT's arp table I could see the entry was flagged as incomplete (despite having a valie mac and exit interface)

root@gb-lte:/tmp# arp -an

IP address       HW type     Flags       HW address            Mask     Device

192.0.2.2        0x1         0x2         44:aa:50:49:f4:70     *        br-lan

100.71.149.54    0x1         0x0         44:aa:50:49:f4:70     *        br-lan

100.71.149.54    0xfffe      0xc         00:00:00:00:00:00     *        wwan0

100.71.149.53    0x1         0xc         00:00:00:00:00:00     *        br-lan

So I simply replaced it with the same data.

root@gb-lte:/tmp# ip neighbor replace 100.71.149.54 lladdr 44:aa:50:49:f4:70 dev br-lan

root@gb-lte:/tmp# arp -an

IP address       HW type     Flags       HW address            Mask     Device

192.0.2.2        0x1         0x2         44:aa:50:49:f4:70     *        br-lan

100.71.149.54    0x1         0x6         44:aa:50:49:f4:70     *        br-lan

100.71.149.54    0xfffe      0xc         00:00:00:00:00:00     *        wwan0

100.71.149.53    0x1         0xc         00:00:00:00:00:00     *        br-lan

It's now working, however being a mobile connection that IP will likely change so this is not a fix or even a good workaround.

Ideas?

by anonymous

The SRX will not respond to arp requests sourced from an IP not on that interface; it's also not possible to have DHCP and a static secondary address to try to overcome that.

There is no interface with an address within the subnet assigned to the RUT to source it from either so it's not arp flux which can be solved with setting sysctl flags.

I've bodged it by editing /lib/functions/mobile.sh with:

        mac=$(eval uci -q get network.mob1s1a1.mac 2>/dev/null);

        ip neighbor replace "$bridge_ipaddr" lladdr "$mac" nud noarp dev br-lan extern_learn 2>/dev/null

This gets around putting a static entry in and extern_learn also stops arp gc from flushing it out.

1 Answer

0 votes
by anonymous

The SRX will not respond to arp requests sourced from an IP not on that interface; it's also not possible to have DHCP and a static secondary address to try to overcome that.

There is no interface with an address within the subnet assigned to the RUT to source it from either so it's not arp flux which can be solved with setting sysctl flags.

I've bodged it by editing /lib/functions/mobile.sh:

        ip route add default dev "$dev" table 42   

        ip route add default dev br-lan table 43  

        ip route add "$bridge_ipaddr" dev br-lan

          

+        ip route del scope link metric 0 dev br-lan

+        ip rule flush table 42

                  

        ip rule add pref 5042 from "$bridge_ipaddr" lookup 42

        ip rule add pref 5043 iif "$dev" lookup 43

        #sysctl -w net.ipv4.conf.br-lan.proxy_arp=1 #2>/dev/null

 

+        ip neighbor flush proxy

                        

        ip neighbor add proxy "$bridge_gateway" dev br-lan

        ip neighbor add proxy "$bridge_ipaddr" dev "$dev" 2>/dev/null

                                               

+        mac=$(eval uci -q get network.mob1s1a1.mac 2>/dev/null);

+        ip neigh flush dev br-lan 2>/dev/null

+        ip neighbor add "$bridge_ipaddr" lladdr "$mac" nud noarp dev br-lan extern_learn 2>/dev/null

                                                                      

        iptables -A postrouting_rule -m comment --comment "Bridge mode" -o "$dev" -j ACCEPT -tnat

This gets around putting a static entry in and extern_learn also stops arp gc from flushing it out.

Also added some cleaning up as whenever the connection restarted it wasn't clearing out old entries.

Best answer