My router may have been flashed.

One of the ironies of my LAN is, I am hosting a Web-site from it, but I do not even own my present router. Mine is a router owned by my ISP, and which provides me with proprietary TV as well.

This means that my ISP has the right to perform a firmware update on the router, which can also be called ‘flashing the router’.

I suspect that this may have happened, around Wednesday Morning, November 9.

My main reason for suspecting this, was a subtle change in the way my router manages my LAN.

According to This Earlier Posting, I previously needed to set my router as the WINS server as well.

To explain in lay-terms what this means, I need to mention that the local IP addresses which computers have on a LAN do exist, in addition to which Windows has introduced its own way of giving the local computers names. Linux can mimic how this works, using its ‘Samba’ software suite, but also tries to avoid ‘NetBIOS’ (naming) as much as possible, outside of Samba network browsing, or ‘copying-and-pasting of files, between computers on a LAN’.

Just like domain-names need to be resolved into IP addresses on the Internet, which is the WAN to this LAN – the Wide-Area Network – on the Local Area Network, computer-names also need to be resolved into IP addresses, before the computers can actually ‘talk to each other graphically’. Traditionally, Windows offered its whimsical mechanism for doing so, which was named NetBIOS, by which any and every computer could act as the WINS server – thus offering its repository of LAN locations to the WINS clients, but alternatively, there could also exist one dedicated WINS server.

What I had grown used to, was that on my LAN, the router would insist that it be my WINS server, thus ‘not trusting’ any of my Linux boxes to do so in some way. I therefore had to defer to this service, as provided by the router.

I had previously set my ‘/etc/samba/smb.conf‘ to

   wins support = no

   dns proxy = yes

Well as of Wednesday, the LAN had suddenly ‘looked different’ according to client-browsers. Each computer had suddenly remained aware only of its own identity, with no Workgroup of other computers to network with.

This was all happening, while my connection to the WAN still seemed secure and operative.

Long story short, I think that my ISP may have performed the Firmware Update, and that according to the new firmware version, the router was suddenly not willing to provide this service anymore. And so what I felt I had to do next, was change these settings back to

 

   wins support = no

   dns proxy = no

 

Now that I have done so, each computer can ‘see’ my whole Workgroup again – which was apparently not feasible according to earlier experiences.

Further, for laypeople I might want to emphasize, that it is not just a frivolous exercise of mine, to give each computer a name. If they did not have names, then according to the screen-shot below, I would also not be able to tell them apart, since they all have the same icon anyway:

phoenix_nmbd_1

 

Now I suppose that an inquiring mind might ask, “Since Linux can imitate Windows, why does Dirk not just set ‘wins support = yes‘ as well?” My answer to this hypothetical question would be, that

  • According to common sense, this option will just make the current machine available, as a potential WINS Server, but
  • In my practical experience, the LAN will interpret this as more of an imperative gesture, of a kind that will actually cause a feud to break out between the machines.

In my experience, if I even set one of my Linux machines to do this, all the other Linux machines will refer to its repository of (4) LAN names, the others becoming clients, but the Windows 7 machine named ‘Mithral’ will refuse to have it. In this case, Mithral will insist that it must be the WINS Server, and not some Linux box. And then, further logic-testing of which machines can see which, will reveal that in practice, I must leave this option switched off, if there is also to be any Windows machine to share the LAN with.

Dirk

 

RTL8723BE WiFi Stable Under Linux

On the laptop I name ‘Klystron’, I have kernel version ‘‘, and the misfortune of a WiFi chip-set that uses the kernel module ‘‘ with its companion kernel modules. Fortunately, I believe that it finally, fully stable!

I think that the most important detail on my part to getting this kernel module stable, was to add the file ‘‘ to contain the following code:


options rtl8723be fwlps=0
options rtl8723be swlps=0


Yet, as a series of blog postings already shows, it was not so quick and easy to obtain stability. One reason I think that my WiFi was failing on me recently, was my persistence in trying to put the laptop to Sleep, aka “Suspend To RAM”. This was never fully supported, and after Resuming from this sort of suspend mode, the WiFi would always be unstable. The only way I had to remedy this, was to change my user-level configuration, never to put the laptop to Sleep again.

Even with the WiFi supposedly stable in this way, the malfunction remains, that for any duration of time I close the laptop lid, the WiFi temporarily cuts off, which I think is a problem with the antenna. My solution: Leave the laptop idling, with its lid open. The result: Days and days of steady connection. Some small amount of dust on the laptop keyboard.

But there seemed to have been another problem with my WiFi specifically. The modem-router which I rent from Bell seems to have a specific policy. It sets itself to be the DNS server for my LAN, which downloads the IP addresses from its DNS parent. The WiFi router seems to have a zero-tolerance policy, if any computers try to bypass it as my DNS server. And this problem can be so strict, that even to have my LAN machines act as server, will cause problems and stability issues, which mimic hardware WiFi disconnection issues.

In my ‘‘, I needed to set


   wins support = no

   dns proxy = yes


Otherwise, the member servers would fail to see each other as Samba-connected, and finally lose their connection altogether.

Further, I had scripted the idea into my configuration files, to prepend IP address 8.8.8.8 as an additional DNS server into ‘‘ on boot-up, just hoping to obtain wider connectivity. But then one additional problem with that was, that this public DNS server would suggest IPv6 addresses in addition to IPv4, and that even though my user-level settings for the network said to ignore IPv6 addresses, a malfunction in the kernel – which has not bee remedied – would cause the WiFi client to try to request the IPv6 addresses anyway. My user-level settings were being ignored.

Thus, I think that getting rid of the 8.8.8.8 was instrumental in achieving stability.  Since this router does not tolerate IPv6, and since it is now my only DNS server, there is no risk of IPv6 addresses ever getting mentioned on my LAN.

On that note: It is normal on a dual-stack machine, for each NIC to have an IPv4 as well as a local, “Link” IPv6 address. But I think that one aspect in which the behavior of Ethernet cards is different from WiFi, is that the Ethernet card will not try to use its IPv6 address, because that will recognize this is not a global address, which would need to be assigned by the router. It would only try to use its “link” IPv6, if it was to try to connect directly to another machine on my LAN. OTOH, It would seem that a WiFi chip-set will not recognize that its IPv6 is invalid, and will ask for “Global” IPv6 addresses.

This can be an embarrassment, if the router did not specify any, and if the router assumes that it is the only DNS server.

Dirk

 

WiFi on Laptop named Klystron, RTL8723BE

One subject which I have commented on often, but which in recent months I have gotten little or no new information about, was the stability of the WiFi chip-set on my laptop ‘Klystron’, which is driven by the kernel modules known as ‘RTL8732BE’.

Here is an earlier posting on this subject.

Since that posting, there have been 2 firmware updates to that laptop specifically. One, to version 1.159, and the next, to version 1.160.

What I found was that firmware version 1.159 actually seemed to make the WiFi very unstable again – a regression. But firmware version 1.160 seemed to make it stable again.

In the meantime, I have a script in directory

/lib/systemd/system-sleep

which is intended to deal with A Different Problem that laptop has, which was, that after resuming from sleep, the laptop system clock would seem to jump ahead exactly 68 hours. I had changed that script as an experiment. But now I have changed it back again, to:


#!/bin/bash
#
# fixing https://bbs.archlinux.org/viewtopic.php?id=173487

case "$1" in
  pre)
    date +%s > /tmp/suspend.log
    ;;
  post)
    was=`cat /tmp/suspend.log`
    now=`date +%s`
    # time shifts for 68 hours
    if [ $now -gt `expr $was + 244800` ]; then
      date -s "`date -R --date="68 hours ago"`"
    fi
    /bin/sh -c "sleep 20; /etc/init.d/nmbd restart; /etc/init.d/smbd restart" &
    ;;
  *)
    ;;
esac

I often did suspect that problems which I had specifically associated with the kernel module, may not in fact stem from the kernel module. On my LAN, I use a router which is not owned by me, but rather by my ISP, and that router has numerous settings – as well as its own Firmware flashing – under the control of my ISP rather than under my direct control.

This router is still useful to me, because I subscribe to “Bell Fibe” and get to watch TV through it, in 1920x1080i resolution, which I could not do, if I was to try switching to a router owned by me.

But many of the problems which Klystron has on my WiFi, may all be policy issues with this router. Since I cannot get deep into the router settings, I am left guessing as to what router policies the laptop may not be abiding by.

But what this can do is lead to Samba problems specifically, which seem to mimic general WiFi connectivity issues, but which are not really examples of that.

Dirk

 

New SAMBA Versions have some Conflict With the Old Ones.

Many desktop users are accustomed to the ability, to open “a network share” on a remote computer – acting as the LAN server – and then to be able to drag-and-drop, or to copy-and-paste files to and from a folder that represents this remote server, on our local client.

Under Linux, this has largely been duplicated.

But what many users are less-aware of, is the fact that this ability is commonly provided by a Microsoft protocol named ‘SMB’ or, ‘Server Message Block’.

Even though Linux has its own network drives via ‘NFS’, many Linux computers have been tuned to access the SMB protocol, through a Linux version of it named “Samba”. This is largely possible, because the first version of SMB, was not fully owned by Microsoft.

But the existence of Samba servers and clients under Linux, is what provides this ability, and in order to have Samba running, we also need to have elaborate configuration scripts.

What some Linux users may additionally not know, is that even if we have tweaked our ‘smb.conf‘ files to the maximum, our most up-to-date Samba versions will no longer be compatible with older Linux implementations.

On my LAN, I typically have 4 computers which are constantly connected:

  • Phoenix – This Linux server,
  • Mithral – A Powerful Windows client,
  • Walnut – An Ancient, Linux server which is by now obsolete,
  • Klystron – That powerful Linux laptop which has problems, sometimes difficult to distinguish if they are happening at the same time.

 

There is no specific reason why the behavior of ‘Walnut‘ should affect the other servers, even though this example is an ancient platform according to standards today.

And yet only recently I found, that Klystron could not connect to the share on Phoenix, even though Klystron seemed to have unrestricted access to the WAN. Furthermore, both Klystron and Walnut seemed to indicate, that there was no Workgroup to be found.

This problem was resolved, when I rebooted Walnut. Apparently, Walnut sometimes ‘thinks’ that it is supposed to act as the Workgroup Server, even though its smb.conf file says otherwise, and then it determines that certain clients are not a part of that Workgroup.

And then, after I just rebooted Walnut, Klystron and Phoenix were able to connect again. Sigh.

Dirk