public inbox for b.a.t.m.a.n@lists.open-mesh.org
 help / color / mirror / Atom feed
* Unable to get DHCP after join wlan0 WIFI mesh network
@ 2021-11-05 23:22 Dweb Fan
  2021-11-06 21:08 ` Linus Lüssing
  2021-11-06 21:17 ` Linus Lüssing
  0 siblings, 2 replies; 4+ messages in thread
From: Dweb Fan @ 2021-11-05 23:22 UTC (permalink / raw)
  To: b.a.t.m.a.n

Dear all,

Thanks for making such a great project!

I'm following the guide from
https://github.com/binnes/WiFiMeshRaspberryPi, and setting up wifi
mesh network on top of raspberry pi 3B+. Below steps are good now:
 - batctl ping works (peer can ping each other through both IP and MAC address)
 - mac os wifi client can discover the ad-host network, and join the network

But, after joining the wifi network, the client can not get DHCP, and
I did below debugging
1. configure static IP in the same subnet at the mac OS wifi client
manually, and unable to ping other nodes
2. I run "batctl td bat0" to dump packets, and I am unable to see
packets from wifi client MAC address
3. I run "batctl td wlan0" to dump packets, and I can see dhcp
request, but unable to see further packets
$ sudo batctl td -p 256 wlan0
09:01:23.945726 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 18:65:90:d1:cf:79, length 300
09:01:26.457608 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 18:65:90:d1:cf:79, length 300
09:01:30.999474 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 18:65:90:d1:cf:79, length 300
09:01:39.903231 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP,
Request from 18:65:90:d1:cf:79, length 300

4. I follow the document
https://www.kernel.org/doc/Documentation/networking/batman-adv.txt,
but seems like unable to see batman related files/folders under
/sys/class/net/wlan0. Here is output:
$ ls /sys/class/net/wlan0
addr_assign_type  carrier             device    duplex
ifindex    mtu                   operstate       phys_switch_id  speed
      tx_queue_len  wireless
address           carrier_changes     dev_id    flags
iflink     name_assign_type      phy80211        power
statistics  type
addr_len          carrier_down_count  dev_port  gro_flush_timeout
link_mode  napi_defer_hard_irqs  phys_port_id    proto_down
subsystem   uevent
broadcast         carrier_up_count    dormant   ifalias
master     netdev_group          phys_port_name  queues
testing     upper_bat0

I searched from google, and seems all documents only mentioned about
setting up bat0 interfaces, but not one like me. So wonder to know if
anyone here can share insight on how to debug it.

More information for your reference:
- Hardware: Raspberry PI 3B+
- OS Image: The latest 64bit Raspberry OS
- Kernel: 5.10.63-v8+ #1459 SMP PREEMPT Wed Oct 6 16:42:49 BST 2021 aarch64
- Batctl version: 2021.3
- Output of "batctl if"
$ sudo batctl if
wlan0: active
- Output of "ifconfig"
$ ifconfig
bat0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.199.1  netmask 255.255.255.0  broadcast 192.168.199.255
        inet6 fe80::1eba:7eaf:a368:c6b  prefixlen 64  scopeid 0x20<link>
        ether 26:62:68:1a:9e:60  txqueuelen 1000  (Ethernet)
        RX packets 459  bytes 19278 (18.8 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 54 (54.0 B)
        TX errors 0  dropped 124 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.1.45  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fd7d:f80:9055:0:1d0c:6985:efd9:a41  prefixlen 64
scopeid 0x0<global>
        inet6 2601:646:8600:6ba:a5c0:ef19:893f:d9b3  prefixlen 64
scopeid 0x0<global>
        inet6 fd7d:f80:9055::5a8  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::2435:6879:8cc:a782  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:14:84:89  txqueuelen 1000  (Ethernet)
        RX packets 2943  bytes 484286 (472.9 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 582  bytes 86581 (84.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 9  bytes 728 (728.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 9  bytes 728 (728.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 169.254.75.154  netmask 255.255.0.0  broadcast 169.254.255.255
        inet6 fe80::ba27:ebff:fe41:d1dc  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:41:d1:dc  txqueuelen 1000  (Ethernet)
        RX packets 289  bytes 91371 (89.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4084  bytes 467767 (456.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

- Files under /sys/class/net/bat0
$ tree /sys/class/net/bat0
/sys/class/net/bat0
├── addr_assign_type
├── address
├── addr_len
├── broadcast
├── carrier
├── carrier_changes
├── carrier_down_count
├── carrier_up_count
├── dev_id
├── dev_port
├── dormant
├── duplex
├── flags
├── gro_flush_timeout
├── ifalias
├── ifindex
├── iflink
├── link_mode
├── lower_wlan0 ->
../../../platform/soc/3f300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0
├── mtu
├── name_assign_type
├── napi_defer_hard_irqs
├── netdev_group
├── operstate
├── phys_port_id
├── phys_port_name
├── phys_switch_id
├── power
│   ├── autosuspend_delay_ms
│   ├── control
│   ├── runtime_active_time
│   ├── runtime_status
│   └── runtime_suspended_time
├── proto_down
├── queues
│   ├── rx-0
│   │   ├── rps_cpus
│   │   └── rps_flow_cnt
│   └── tx-0
│       ├── byte_queue_limits
│       │   ├── hold_time
│       │   ├── inflight
│       │   ├── limit
│       │   ├── limit_max
│       │   └── limit_min
│       ├── traffic_class
│       ├── tx_maxrate
│       ├── tx_timeout
│       ├── xps_cpus
│       └── xps_rxqs
├── speed
├── statistics
│   ├── collisions
│   ├── multicast
│   ├── rx_bytes
│   ├── rx_compressed
│   ├── rx_crc_errors
│   ├── rx_dropped
│   ├── rx_errors
│   ├── rx_fifo_errors
│   ├── rx_frame_errors
│   ├── rx_length_errors
│   ├── rx_missed_errors
│   ├── rx_nohandler
│   ├── rx_over_errors
│   ├── rx_packets
│   ├── tx_aborted_errors
│   ├── tx_bytes
│   ├── tx_carrier_errors
│   ├── tx_compressed
│   ├── tx_dropped
│   ├── tx_errors
│   ├── tx_fifo_errors
│   ├── tx_heartbeat_errors
│   ├── tx_packets
│   └── tx_window_errors
├── subsystem -> ../../../../class/net
├── testing
├── tx_queue_len
├── type
└── uevent

8 directories, 73 files

Looking forward to hearing from you and have a good day!

Best Regards
Dweb

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Unable to get DHCP after join wlan0 WIFI mesh network
  2021-11-05 23:22 Unable to get DHCP after join wlan0 WIFI mesh network Dweb Fan
@ 2021-11-06 21:08 ` Linus Lüssing
  2021-11-06 23:59   ` Dweb Fan
  2021-11-06 21:17 ` Linus Lüssing
  1 sibling, 1 reply; 4+ messages in thread
From: Linus Lüssing @ 2021-11-06 21:08 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

Hi,

Glad to see that more and more people are experimenting with WiFi
mesh networks.

On Fri, Nov 05, 2021 at 04:22:11PM -0700, Dweb Fan wrote:
> Dear all,
> 
> Thanks for making such a great project!
> 
> I'm following the guide from
> https://github.com/binnes/WiFiMeshRaspberryPi, and setting up wifi
> mesh network on top of raspberry pi 3B+. Below steps are good now:
>  - batctl ping works (peer can ping each other through both IP and MAC address)
>  - mac os wifi client can discover the ad-host network, and join the network

This guide seems to set up two WiFi interfaces. wlan0 in ad-hoc
mode and wlan1 in AP mode. wlan0 is a secondary interface of bat0
and wlan1+bat0 are bridged:

    ---br0---
   /         \
 bat0      wlan1(ap)
  |
wlan0(adhoc)

On wlan0 is supposed to be only used to interconnect batman-adv
nodes. The batman-adv protocol is primarily spoken there.

Client traffic from your mac os wifi client is probably not able
to speak the batman-adv protocol and is therefore supposed to go
"over" bat0 instead of "under" bat0. So your mac os client should
connect to the wlan1 AP interface.

The traffic is then bridged from wlan1 to bat0 and batman-adv will
then encapsulate the client traffic. And then forward the
*encapsulated* traffic on wlan0 automatically to the correct
neighbor node.

Hope this helps.

Regards, Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Unable to get DHCP after join wlan0 WIFI mesh network
  2021-11-05 23:22 Unable to get DHCP after join wlan0 WIFI mesh network Dweb Fan
  2021-11-06 21:08 ` Linus Lüssing
@ 2021-11-06 21:17 ` Linus Lüssing
  1 sibling, 0 replies; 4+ messages in thread
From: Linus Lüssing @ 2021-11-06 21:17 UTC (permalink / raw)
  To: The list for a Better Approach To Mobile Ad-hoc Networking

On Fri, Nov 05, 2021 at 04:22:11PM -0700, Dweb Fan wrote:
> 4. I follow the document
> https://www.kernel.org/doc/Documentation/networking/batman-adv.txt,
> but seems like unable to see batman related files/folders under
> /sys/class/net/wlan0. Here is output:
> $ ls /sys/class/net/wlan0

Hm, seems this link is outdated. Not sure who can update this or
when it is going to be updated. Here is a more recent version of
this file:

https://www.kernel.org/doc/html/latest/networking/batman-adv.html

sysfs and debugfs supported is deprecated for a while. Instead
batctl and "ip link" should be used.

Regards, Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Unable to get DHCP after join wlan0 WIFI mesh network
  2021-11-06 21:08 ` Linus Lüssing
@ 2021-11-06 23:59   ` Dweb Fan
  0 siblings, 0 replies; 4+ messages in thread
From: Dweb Fan @ 2021-11-06 23:59 UTC (permalink / raw)
  To: Linus Lüssing
  Cc: The list for a Better Approach To Mobile Ad-hoc Networking

Hi Linus,

Thanks for the detailed explanation. This really answers my question,
although one small confusion is why these 2 directories:
/sys/kernel/debug/batman_adv/ and /sys/class/net/wlan0/batman_adv, are
not present. I even upgraded to the latest 5.14 kernel on Raspberry
Pi, unable to find.

Seems like 3 options can help eliminate wlan1 and use wlan0 for both
protocol communication and real data communication:
1. Develop a client agent at wifi client side to encapsulate regular
IP packets into batman protocol packets, but the agent need be ported
into different OS, MAC, Windows, even IOS, Android.
2. Develop a server agent to intercept batman packets, and convert to
regular ip packets.
3. Enhance batman kernel module to detect packet type, and support the
use case natively. :-)

I'd like to do more research on it, and like to hear your suggestions
on which option is better.

Best Regards
Dwebf

On Sat, Nov 6, 2021 at 2:08 PM Linus Lüssing <linus.luessing@c0d3.blue> wrote:
>
> Hi,
>
> Glad to see that more and more people are experimenting with WiFi
> mesh networks.
>
> On Fri, Nov 05, 2021 at 04:22:11PM -0700, Dweb Fan wrote:
> > Dear all,
> >
> > Thanks for making such a great project!
> >
> > I'm following the guide from
> > https://github.com/binnes/WiFiMeshRaspberryPi, and setting up wifi
> > mesh network on top of raspberry pi 3B+. Below steps are good now:
> >  - batctl ping works (peer can ping each other through both IP and MAC address)
> >  - mac os wifi client can discover the ad-host network, and join the network
>
> This guide seems to set up two WiFi interfaces. wlan0 in ad-hoc
> mode and wlan1 in AP mode. wlan0 is a secondary interface of bat0
> and wlan1+bat0 are bridged:
>
>     ---br0---
>    /         \
>  bat0      wlan1(ap)
>   |
> wlan0(adhoc)
>
> On wlan0 is supposed to be only used to interconnect batman-adv
> nodes. The batman-adv protocol is primarily spoken there.
>
> Client traffic from your mac os wifi client is probably not able
> to speak the batman-adv protocol and is therefore supposed to go
> "over" bat0 instead of "under" bat0. So your mac os client should
> connect to the wlan1 AP interface.
>
> The traffic is then bridged from wlan1 to bat0 and batman-adv will
> then encapsulate the client traffic. And then forward the
> *encapsulated* traffic on wlan0 automatically to the correct
> neighbor node.
>
> Hope this helps.
>
> Regards, Linus

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2021-11-06 23:59 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-11-05 23:22 Unable to get DHCP after join wlan0 WIFI mesh network Dweb Fan
2021-11-06 21:08 ` Linus Lüssing
2021-11-06 23:59   ` Dweb Fan
2021-11-06 21:17 ` Linus Lüssing

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox