Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 234583 - net-dialup/ppp-2.4.4-r15 patch for Huawei E220 support
Summary: net-dialup/ppp-2.4.4-r15 patch for Huawei E220 support
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Alin Năstac (RETIRED)
URL: http://jkroon.blogs.uls.co.za/it/netw...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-12 23:31 UTC by Jaco Kroon
Modified: 2008-08-19 18:27 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
pppd-wins.patch (pppd-wins.patch,2.64 KB, patch)
2008-08-12 23:33 UTC, Jaco Kroon
Details | Diff
pppd-usepeerwins.patch (pppd-usepeerwins.patch,8.27 KB, text/plain)
2008-08-17 19:11 UTC, Jaco Kroon
Details
ip-up.d/45-wins.sh (45-wins.sh,560 bytes, text/plain)
2008-08-17 19:12 UTC, Jaco Kroon
Details
ip-down.d/45-wins.sh (45-wins.sh,362 bytes, text/plain)
2008-08-17 19:12 UTC, Jaco Kroon
Details
ip-up.d/45-wins.sh (45-wins.sh,689 bytes, text/plain)
2008-08-17 20:03 UTC, Jaco Kroon
Details
ip-down.d/45-wins.sh (45-wins.sh,406 bytes, text/plain)
2008-08-17 20:04 UTC, Jaco Kroon
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jaco Kroon 2008-08-12 23:31:20 UTC
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:
Comment 1 Jaco Kroon 2008-08-12 23:33:47 UTC
Created attachment 162797 [details, diff]
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.
Comment 2 Michal Kurgan (RETIRED) gentoo-dev 2008-08-13 04:36:02 UTC
ups... sorry bad fix of Summary
Comment 3 Alin Năstac (RETIRED) gentoo-dev 2008-08-15 09:05:58 UTC
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!
Comment 4 Jaco Kroon 2008-08-15 17:19:06 UTC
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.
Comment 5 Csaba Tóth 2008-08-16 12:19:18 UTC
(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..
Comment 6 Alin Năstac (RETIRED) gentoo-dev 2008-08-16 13:03:08 UTC
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.
Comment 7 Jaco Kroon 2008-08-16 16:13:34 UTC
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.
Comment 8 Alin Năstac (RETIRED) gentoo-dev 2008-08-16 17:00:20 UTC
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?
Comment 9 Jaco Kroon 2008-08-16 17:15:48 UTC
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.
Comment 10 Alin Năstac (RETIRED) gentoo-dev 2008-08-16 17:52:21 UTC
(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.
Comment 11 Jaco Kroon 2008-08-16 23:35:04 UTC
> > 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?
Comment 12 Alin Năstac (RETIRED) gentoo-dev 2008-08-16 23:53:00 UTC
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.
Comment 13 Jaco Kroon 2008-08-17 19:11:25 UTC
Created attachment 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.
Comment 14 Jaco Kroon 2008-08-17 19:12:04 UTC
Created attachment 163127 [details]
ip-up.d/45-wins.sh
Comment 15 Jaco Kroon 2008-08-17 19:12:27 UTC
Created attachment 163129 [details]
ip-down.d/45-wins.sh
Comment 16 Jaco Kroon 2008-08-17 19:17:25 UTC
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").
Comment 17 Jaco Kroon 2008-08-17 20:03:18 UTC
Created attachment 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).
Comment 18 Jaco Kroon 2008-08-17 20:04:00 UTC
Created attachment 163136 [details]
ip-down.d/45-wins.sh

And with ip-up goes ip-down ... need to match.
Comment 19 Jaco Kroon 2008-08-17 20:23:42 UTC
(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.
Comment 20 Alin Năstac (RETIRED) gentoo-dev 2008-08-19 18:27:04 UTC
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