Udhcpd config for tethering (fixing, maybe?)

Platform Development
#1

Today I developed a new patch:

Description:

In some cases, the tethering via WiFi stops to deliver the DHCP service, and the reason is related to the /etc/udhcpd.conf file, which is replaced by usb-moded with a link pointing to a file in the temporary folder /run/usb-moded/udhcpd.conf. The quickest solution is to create a proper file with another name and instruct the udhcpd daemon to load the new /etc/udhcpd.tether instead of the default one.

At the moment, I am not aware if the lack of DHCP service on the tether interface happens because I am constantly in developer mode and I do reboot in that mode or because of my attitude to change some part of the system by command line.

Because the usb-moded is supposed to deal with the USB tethering and this is not affected by the problem but the WiFi tethering, because the USB tethering is not the only one but also the WiFi tethering uses 172.28.172.x, it seems to me a reasonable way to go about fixing the udhcpd service to fulfill its duty on the tether interface.

Moreover, I am quite surprised that I am the only one who is affected by this kind of problem because I suppose that many people use WiFi tethering with and without the developer mode. Possibly, I have overlooked something that is probably the root cause of the problem.

Every technical feedback is welcome.

1 Like
#2

UPDATE #1

After having applied this patch, the system continues to suffer of the problem and therefore I had to investigate the root cause. First of all, I started to play with the iptables and I discovered that the source and destination ports for offering the DHCP service are inverted, in that way the ports are for using the DHCP (client).

As you can see the second rule in the INPUT chain is the same which is set in connman-INPUT but the one that works for offering the service is the first. Both are necessary, obviously and thus I updated my patch as well.

    2   638 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

I am quite surprised to found out something like this because I cannot believe that nobody noticed before. Possibly, I am still overlooking something.

iptables investigation

iptables -nvL; iptables -nvL -t nat;

Chain INPUT (policy ACCEPT 46 packets, 3931 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    4  1312 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

Chain FORWARD (policy ACCEPT 1292 packets, 830K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 40 packets, 8071 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1250  157K connman-OUTPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain connman-INPUT (0 references)
 pkts bytes target     prot opt in     out     source               destination         
    4   240 ACCEPT     tcp  --  tether *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 multiport dports 22,2222
    0     0 ACCEPT     all  --  rndis0 *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     tcp  --  lo     *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 multiport dports 22,2222
    0     0 DROP       tcp  --  !rndis0 *       0.0.0.0/0            0.0.0.0/0            tcp flags:0x17/0x02 multiport dports 22,2222
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmp !type 8 code 0
    0     0 ACCEPT     33   --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1024:65535
    0     0 ACCEPT     sctp --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1024:65535
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1024:65535
    0     0 ACCEPT     udplite--  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1024:65535
    0     0 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            multiport dports 1024:65535
    0     0 ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     ah   --  *      *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
  374 31159 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Chain connman-OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all  --  *      rndis0  0.0.0.0/0            0.0.0.0/0           
   81 11775 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            icmp !type 0 code 0
Chain PREROUTING (policy ACCEPT 651 packets, 55779 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 123 packets, 11059 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 9 packets, 626 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 7758 packets, 493K bytes)
 pkts bytes target     prot opt in     out     source               destination         
  101  6824 connman-POSTROUTING  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

Chain connman-POSTROUTING (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   94  6340 MASQUERADE  all  --  *      rmnet_data1  172.28.172.0/24      0.0.0.0/0
1 Like
Some whole threads are "temporarily" closed for at least "X" days due to a "large" number of snowflake flaggings
#3

What specifically happens without patch (in ask to be able to understand the problem, to know if I had it too)?

#4

The WiFi tethering (using the smartphone like a WiFi hotspot) does not provide a dynamic address to the client - no dhcp service available - but with a static IP set on the client, it works.

I am going to expand this patch in order to cover also the USB tethering which require another configuration file therefore another udhcpd instance, therefore another service registered in systemd.

#5

Hmm, I am using the WiFi hotspot all the time and I have no such problems. I sometimes use my data for kids at a youth club, 10+ kids and no problem (other that the phone gets a bit hot :slight_smile: )

1 Like
#6

Me too, if I use the hotspot I can connect to it many devices, each of them with its own address.

#7

I am pretty sure that the problem is not with the SFOS vanilla system. Otherwise, many people would have complained about it since a long time ago.

The issue seems to be that the DHCP stops working as soon as someone changes a little bit the firewall configuration and/or in combination with the developer mode.

Moreover, in the direction I am moving, there is no the “developer mode” but there is only the “advanced user mode” in which some services are granted by default since the first day the end users activate them, when they choose to switch to RedFish OS. This is because there is no reason - IMHO - to use a GNU/Linux system without going to exploit all its powerful features and capabilities.

Probably, to fix the issue, I just need to uninstall the developer mode and reinstall it. In the past, I was going for a quick workaround. Nowadays, I do not care anymore about this Windows-like behavior (reboot to fix it). I want a GNU/Linux system on my smartphone that behaves like every server I have installed in the past: keep increasing the uptime until a kernel upgrade is scheduled with the bare minimum maintenance effort.

So, the real question is not “how to fix it” but “why does it get so easily broken”. The answer: “because I made a mistake in configuring the firewall” is acceptable. Instead, the answer: “it is not supposed that I play with iptables even when I am doing right” is not acceptable.

Post Scriptum

@fabio.87 quoting the whole my post is useless because the iptables rules displayed in that post are the result of a testing / investigation process as clearly stated in the post itself.

If you want the firewall changes that trigger the issue, you have to look at the patch above linked.

Update #1

This works in fixing the issue:

It fixes the issue with the new rule about 68,67 ports and despite the rules for SSH.

Update #2

Finally, I reach to the conclusion that the udhcpd service should wait for the IPv4 address to come up on the rndis0 interface and should restart always otherwise in some cases the service fails and never restart again.

The patch use a dirty workaround to obtain this feature (waiting) which needs to be improved and add a iptables rule to let the DHCP request served.