Bugzilla Bug 234583

The Huawei E220 is a really annoying little device that fails in strange ways
unless wins options are actually accepted and passed back in the ConfReq
transmissions, the patch I'll attach in a second is a cleanup of a patch
available elsewhere to apply cleanly on the gentoo pppd 2.4.4-r15 and fixes
this problem.  You might want to restrict application of this patch with a
"wins" or "huawei-wins" USE flag, but the patch is simple enough that I can't
imagine it would break anything, nor does it actually expose the "accepted"
WINS servers anywhere.

Reproducible: Always

Steps to Reproduce:

Created an attachment (id=162797) [details]
pppd-wins.patch

Original at
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg419128.html -
which also describes much of the logic.

ups... sorry bad fix of Summary

Fixed in -r20. Your patch will be applied only when the newly added wins-ack
USE flag is enabled.

I cannot believe that an ISP actually sends WINS server offerings to his
clients!

I don't think it's that the ISP is passing WINS, as I've tried to explain on
http://jkroon.blogs.uls.co.za/it/networking/huawei-e220 I suspect it's the
modem.  Some kind of race condition or something, essentially what I suspect is
that the ppp connection only runs down to the modem, not to the GSM network, so
the modem is using the WINS stuff as a way to delay or throttle the connecting
side until it managed to established a connection with the GSM network or
something as the modem itself eventually NAKs the WINS settings that it
initially provided.  Really weird stuff but with this patch it works and the
DNS servers ends up being correct, without it I get the wrong DNS servers about
9 out of 10 times.

(In reply to comment #3)
> I cannot believe that an ISP actually sends WINS server offerings to his
> clients!

We use PPTP to make a VPN to login from home into the office network. We use
Windows for clients (samba for file server, ppp and pptpd for the VPN), and
WINS is important for us for name resolving. From out login we should use the
IP address as the target computer name. I will try it, but i hope from now we
can use computer names as well.
Now you can imagine one situation..

This patch does nothing more than acknowledging WINS servers provided by the
peer. Since pppd do not use them, the correct way of dealing with it should be
to NACK them, but apparently some broken peers are getting upset by this
rejection.

Indeed.  But exposing the values if it ends up being accepted via environment
variables shouldn't be difficult, would exposing them as WINS1 and WINS2 be
acceptable?  I don't think I want to bother with updating the ip-up/down
scripts as I use my own highly customized ones in any case and whatever I do
there will not be generally applicable.

Here is my suggestion then, I'll modify the patch to add two parameter options:

1.  acceptwins
2.  usepeerwins

The first will basically negate the reason for the USE flag in that it will
only ack the wins servers if this parameter is passed, and usepeerwins will
cause the wins servers to actually be requested (which will be needed if you're
dialing into a non-broken pppd stack).

/me gets down to coding.

I find "usepeerwins" a little misleading. usepeerdns option actually sets your
/etc/resolv.conf while this option will do... what?

I propose you add only one option called "acceptwins" and pass the WINS servers
to the ip-up script as $WINS1 and $WINS2. How about that?

No.  usepeerdns doesn't actually set up /etc/resolv.conf either.  It creates
/etc/ppp/resolv.conf but on Gentoo at least this isn't used afaik instead using
some other way of updating /etc/resolv.conf.

there is two things that needs to happens here:

1.  A way to request the peer to actually send us the WINS servers (for when
dialing into pptp/l2tp servers that has the ms-wins option set).  A correct
implementation won't send us the WINS servers unless we ask for them (Linux
pptpd + pppd doesn't, but I've managed to get them now by requesting them).

2.  A way to tell pppd to ack the wins servers without actually requesting them
(yes, actually requesting them from the Huawei E220 again breaks the DNS stuff
- I just checked).

So we do need two options, would requestwins and acceptwins be better naming
for you?  I figured usepeerwins to keep with usepeerdns, but I'm more than
willing to change these parameter names - it is just a string in the code after
all.

(In reply to comment #9)
> No.  usepeerdns doesn't actually set up /etc/resolv.conf either.  It creates
> /etc/ppp/resolv.conf but on Gentoo at least this isn't used afaik instead using
> some other way of updating /etc/resolv.conf.

Beside /etc/ppp/resolv.conf creation, usepeerdns also sets $DNS1 and $DNS2. We
choose to use the environment variables in the ip-up script rather than
replacing the resolv.conf file because this way we can preserve the other stuff
lying there.

> there is two things that needs to happens here:
> 
> 1.  A way to request the peer to actually send us the WINS servers (for when
> dialing into pptp/l2tp servers that has the ms-wins option set).  A correct
> implementation won't send us the WINS servers unless we ask for them (Linux
> pptpd + pppd doesn't, but I've managed to get them now by requesting them).

But why would you request such servers? What could you possibly do with these
on a Linux box?

Names are second concern right now. We need to establish their purpose first,
then came up with the best name.

> > 1.  A way to request the peer to actually send us the WINS servers (for when
> > dialing into pptp/l2tp servers that has the ms-wins option set).  A correct
> > implementation won't send us the WINS servers unless we ask for them (Linux
> > pptpd + pppd doesn't, but I've managed to get them now by requesting them).
> 
> But why would you request such servers? What could you possibly do with these
> on a Linux box?

Because I'm dialing into a Windows network and would like to get winbind to
resolve names for machines on the other end?  See comment #5 - although I
suspect he's using pptpd+pppd for the dial-in server and the ms-wins option may
well be good enough for him.  So if I have WINS1 and WINS2 I can quite probably
update /etc/samba/smb.conf to add the remote WINS server(s) as WINS servers for
samba on this end.

And then of course ... because we can?

When you connect to a VPN, chances are you already know the WINS servers, so
why wouldn't you manually add them in your smb.conf? Better yet, why not
replacing such a brain-dead service like WINS with the sane alternative which
is DNS?

But OK, lets do it like this:
  1) acceptwins - shall not require WINS servers from the peer, but will gladly
accept any WINS offerings from the peer
  2) usepeerwins - will request WINS servers from the peer

Both options shall pass WINS servers to ip-up script through $WINS1 and $WINS2
environment variables. Please update the pppd man page with the new options.

Optional: It wouldn't hurt to post here a /etc/ppp/ip-up.d/xx-wins.sh script
that would modify the smb.conf.

Created an attachment (id=163126) [details]
pppd-usepeerwins.patch

As it turns out - when correctly implemented the usepeerwins option does make
the Huawei E220 work as well.  At least, it did on the handful of test runs I
just made.  Without this the _first_ connection attempt after plugging in the
modem reliably gets me 10.11.12.13 and 10.11.12.14 as the DNS servers, with
usepeerwins I get the right results on all runs.

This patch should be treated as experimental, but I would love feedback from
other users.

Created an attachment (id=163127) [details]
ip-up.d/45-wins.sh

Created an attachment (id=163129) [details]
ip-down.d/45-wins.sh

Please note that the ip-up/down scripts has not been tested exhaustively.  They
should work, however, they rely on the fact that the "wins server" option
already exists in smb.conf, and that it's uncommented, is written in lower
case, that only one such option exists, and that the only place there may be a
space in the naming itself is between wins and server (According to the
smb.conf manpage half of these assumptions cannot be made, amongst others
options are case insensitive and spaces are all stripped out, in other words
"WinS Se rVer" is just as legal as "winsseRVer" as "wins server").

Created an attachment (id=163135) [details]
ip-up.d/45-wins.sh

"tag" the entries being added to smb.conf to allow samba to function in
multiple name spaces and thus be able to have different "sets" of WINS servers
(effectively allowing samba to realize that you're connected to different
networks and resolve each network separately).

Created an attachment (id=163136) [details]
ip-down.d/45-wins.sh

And with ip-up goes ip-down ... need to match.

(In reply to comment #12)
> When you connect to a VPN, chances are you already know the WINS servers, so
> why wouldn't you manually add them in your smb.conf? Better yet, why not
> replacing such a brain-dead service like WINS with the sane alternative which
> is DNS?

btw, I don't like WINS either.  But consider this quickly, Linux is busy
gaining some popularity, and in turn, lots and lots of new users (I still say
Linux is NOT Windows: http://linux.oneandoneis2.org/LNW.htm - but at the same
time I feel that we should make, where applicable, things as easy as possible
for those who do wish to migrate).  They expect to be able to use a name as it
stands.  The way pppd functions we cannot (without using dhcp clients over
pppd) set up a search domain, and even if we could, I'd say the search domain
should probably be left at whatever it is for the local LAN.  Most users
however won't know, or even care what WINS or DNS is, they just want to be able
to say smb://foo in the KDE environment (Or whatever other alternative they're
using), and not have to care about dns suffixes.  So whilst I hate WINS as much
as anybody (I wasted many more hours than I'd care to admit on it, min ttls are
evil), but it has it's uses.  Also, people still use "network browsers", which
will only really function for remote links if either WINS is available, or some
kind of bcrelay is in use.

Gentoo may not be aimed at these types of users, but nothing stops us from
creating these kinds of patches and at least using them in an environment where
you average user is somewhat savvy about what's going on before unleashing it
to the hordes via the binary distributions.  Also, testing these kinds of
patches in a meta-distribution like Gentoo is simpler, and frankly, makes much
more sense in my head than using for example Debian.

Fixed in ppp-2.4.4-r21, thanks! 

I removed wins-ack USE flag (the new patch is applied unconditionally).

I've made the following changes:
 - use 30-wins.sh as ip-{up,down} script name
 - improve ip-{up,down} scripts to make it work on every possible smb.conf