Closed junhuanchen closed 10 months ago
junhuanchen
commented
10 months ago I found them there
juwan@raspberrypi:~ $ ip -6 neigh show proxy
4c9c:ce7e:4c9c:ce7e:b635:22ff:fe98:2f3e dev eth0 router proxy
4c9c:ce7e:4c9c:ce7e:b635:22ff:fe98:2b76 dev eth0 router proxy
juwan@raspberrypi:~ $I hope the documentation can add some operational steps or test results in this regard if possible
jerome-pouiller
commented
10 months ago Hi @junhuanchen,
I am a bit lost with usage of ifconfig. It is deprecated for 20 year at least. And especially, it does not play very well with ipv6. I strongly recommend to stop using it (use ip addr instead).
It seems ifconfig does not show you your GUA. Can you confirm that?
I think you have found at least one bug, wsbrd should not accept ipv6_prefix = fe80::/64. It make no sense to use a link-local address. From your traces, I believe, wsbrd finally use the first GUA of eth0 (because of neighbor_proxy=eth0).
In addition, I don't think you can use link-local addresses to reach device behind the neighbor proxy. You have to use their GUA.
jerome-pouiller
commented
10 months ago BTW, you don't show the result of ping 4c9c:ce7e:4c9c:ce7e:b635:22ff:fe98:2b76 from your Linux PC, can you share it?
junhuanchen
commented
10 months ago Yes, you are right, I need to reconfirm the GUA situation, because I am not sure how to do it correctly, I am running around like a bee in a cage, in fact, if possible, I hope you can help me to sort out the operation steps and the points to be confirmed, which involves a lot of network configuration confirmation. We can check whether each step is correct from the initial confirmation. For me, I don't know whether it can achieve the effect I expect. Thank you very much for your tips, I will further check later, if you know what I want to do, you can give me some guidance, thank you again!
junhuanchen
commented
10 months ago Now that I'm using the example parameters to test it, it looks much more normal, for now I probably need how to get GUA (Global unicast addresses)
# Prefix used to generate IP addresses for RPL traffic (DODAGID will derive from
# it). This prefix does not aim to change during network lifetime. You can
# directly use your GUA prefix (for example, 2001:db8::/64) here. However, for
# more flexibility, you may prefer to set an ULA here and add an extra GUA
# (not yet supported).
# If tun_autoconf is set to fa·lse, the IP prefix is deducted from the network
# interface address.
# Prefix lengths different from /64 are not supported yet
# ipv6_prefix = fd12:3456::/64
ipv6_prefix = 2001:db8::/64
# Create and maintain a transparent bridge between Wi-SUN and the network
# interface specified (for example, eth0). The `ipv6_prefix` parameter must use
# the same prefix as the bridged network interface (if your IPv6 is properly
# configured, it should be a GUA). Obviously, /proc/sys/net/ipv6/all/forwarding
# must also be set. Refer to the "Using IPv6 transparent proxy" section of the
# README for more information.
neighbor_proxy=eth0juwan@raspberrypi:~ $ 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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:e0:4c:68:05:56 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.168/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
valid_lft 85920sec preferred_lft 85920sec
inet6 fe80::81f2:f605:7c6e:889a/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 5e:94:f4:2c:01:81 brd ff:ff:ff:ff:ff:ff permaddr b8:27:eb:8e:63:aa
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc pfifo_fast state UP group default qlen 10
link/none
inet6 2001:db8::be33:acff:fefa:34a5/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::be33:acff:fefa:34a5/64 scope link
valid_lft forever preferred_lft forever
5: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:b9:a1:d0:ac brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
juwan@raspberrypi:~ $ I think for a moment, it is possible that my eth0 export router does not support IPV6 address assignment, so I cannot share GUA externally? But do I have to have the prefix 2001 if I want to communicate within a LAN
jerome-pouiller
commented
10 months ago Before to play with wsbrd, you have to ensure you have ipv6 connectivity. Try to ping ipv6.google.com.
Then, you have reuse the prefix provided by your ISP. You can't invent a prefix (in fact, yes you can, but it is beyond our current business).
junhuanchen
commented
10 months ago Yes, I have thought about it for a while, I plan to enter an ipv6 network through vpn, and change eth0 to a network with ipv6, and then access the device under this VPN network. Thank you very much for your reply, which means that there is no problem with my use, but only the problem of the external ISP
junhuanchen
commented
10 months ago For future reference, if your router does not have IPV6 but you want to simply test it for devices other than the router, you just need to follow the tips here and add the radvd announcement.
https://github.com/SiliconLabs/wisun-br-linux-docker#i-have-no-ipv6-network
Configure your Wi-SUN Border Router
ipv6_prefix = 2001:db8::/64
neighbor_proxy=eth0You can use radvd on rpi (debian) systems to send router announcement messages, which is required for IPv6 stateless autoconfiguration. Here are some steps to help you install and configure radvd on your Ubuntu system:
install radvd: Open the terminal and run the sudo apt-get install radvd command to install radvd
Configure radvd: Edit the /etc/radvd.conf file to configure radvd. For example, you can add the following to a file:
interface eth0 {
AdvSendAdvert on;
prefix 2001:db8:0:1::/64 {
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
};Please note that you need to modify this according to your network interface and IPv6 prefix
Run the sudo /etc/init.d/radvd restart command to start the radvd daemon
At this point, all devices will get the ipv6 address from the global published by rpi, which is available for access.
jerome-pouiller
commented
10 months ago Indeed, there are hundreds of ways to get IPv6 infrastructure. Because this can't be summarized in a README, we knowingly don't this aspect in the documentation of wsbrd.
The wisun-br-linux-docker project aims to demonstrate the most usual recipes (and you have notice it is a project by its own). Unfortunately, because the lack of interest of the users, wisun-br-linux-docker has not been updated for a while (typically, it does not demonstrate use of neighbor_proxy).
Anyway, thank you for your feedback.
Hi, I'm using rpi3 for gateway tun0 forwarding eth0 and there's some uncertainty about how to configure it.
Refer to https://github.com/SiliconLabs/wisun-br-linux#using-ipv6-transparent-proxy
My expectation is to be able to supply the wisun device to other hosts on the LAN (egress to rpi's eth0 network card) and use my PC linux computer to access a device in the WISUN network within the RPI3 device under the current WIFI router.
Here's an excerpt of the main modifications to my wsbrd.conf:
After I modify the above configuration, I will find that the network condition of rpi changes as follows:
The two devices I tested got brand new addresses with ipv6 prefixes
At this point in my rpi3 ping 4c9c:ce7e:4c9c:ce7e:b635:22ff:fe98:2b76 is feasible, I expect that on my PC machine can also ping it.
Finally, I would like to add that my PC can ping through the ipv6 address of eth0 of rpi3, but cannot further ping through devices in WISUN. How do I determine the problem? Or provide more parameter information.
Thank you for providing a window for questions, which is good, because I think this section is not detailed enough, so I hereby raise the issue for others' reference and confirmation.
That's what I want to achieve in the end