I don’t really want to even start with this post. This little device has caused me numerous headaches, from as simple as “it simply doesn’t work”, right through to incorrect DNS servers, and even failing VPN connections. Which was the last straw.
The failing VPN connections turned out to be a problem with the way I load balance DNS over all available connections, so having (for the particular site) a DSL line, an iBurst and a 3G connection in place things are mostly resonable and we’ve usually got some options to try when things do bomb out (ie, a dsl line doesn’t fail, it simply keeps on coming up/going down constantly, half the time not even long enough for lcp-echo-interval and lcp-echo-failure to pick up on the problem. So what happens when you load balance the DNS over the available DNS servers (obviously pushing the requests over the correct devices) and _one_ of the three connections provides you with totally bogus DNS servers? Well, let me tell you: On average one out of three DNS requests fail. This means that on average once every three minutes the DNS request for the IPSec peer’s IP fail, causing the vpn to come tumbling down.
Now, on the GLUG mailing list the words WINS came up – which is totally bogus. In fact, it’s so bogus that initially I discarded (and iirc partially flamed) the guy that brought it up. In fact, WINS is so wrong that I have no idea how anybody initially got the idea, except perhaps for staring too long at too many pppd debug traces.
The bottom line is this: The firmware on the Huawei E220 (and by implication the E270 and probably aothers too) is broken. It passes some WINS servers to the pppd process running on the host. If these WINS options are NAKed then things start going totally pearshaped. In fact, it goes so pearshaped that in the last two weeks I didn’t obtain the correct DNS servers on a single instance. So I eventually decided it’s time to give the WINS thing a shot (The more I thought about it, the more disgusting the idea got). After about half an hour of cleaning up the patches that I could locate I finally managed to make it compile with pppd-2.4.4 (Gentoo variation) and install it. And immediately I managed to get the correct DNS servers, connection setup times came down (to a few seconds compared to near minute times).
Annoying. Highly annoying. Anyway, a working patch is available here. I’d like to actually add usepeerwins as well, which will allow for pulling the WINS servers from a pppd peer, and passing that on to ip-up that can reconfigure samba for winbind (mostly) purposes. But that’s the patch for another day.
UPDATE (2008/08/17):
I’ve just finished writing usepeerwins support for pppd, which functions closer to the usepeerdns option in that it requests the peer to send up to two wins servers, and then exports them to ip-up and ip-down vir environment variables WINS1 and WINS2, as well as setting USEPEERWINS=1. It doesn’t actually make any modifications to your smb.conf file. The patch itself can be downloaded here. You can update smb.conf using sed commands such as:
sed -re “s/^[[:space:]]*wins ?server.*/\0 ${LINKNAME}:${WINS1}/” -i /etc/samba/smb.conf
For adding (ip-up), and for removing (ip-down):
sed -re “s/^([[:space:]]*wins ?server.*) ${LINKNAME}:${WINS1//./\\.}/\1/’ -i /etc/samba/smb.conf
If you’re able to use either of these patches with success, please let me know. Please note that from playing around a LOT over the weekend in writing the latter of the patches it seems that the device is especially annoying when plugged in the first time, even without the patch I seem to be able to with quite high repeatability obtain the correct DNS server values by making pppd disconnect and reconnecting without unplugging the device.
UPDATE (2008/08/26):
For general information setting this up, please see this post on TLUG‘s Wiki.
I received this reply on a discussion on the GLUG mailing list:
BTW, I note that the vodafone-mobile-connect-card-driver-for-linux (from https://forge.betavine.net/projects/vodafonemobilec/) package (not a driver, rather a python-twisted-based GUI for configuring and connecting GPRS/3G/HSDPA modems/connections with wvdial) has settings for various network providers, and the one for Vodacom-SA has static DNS IPs, and by default will have the “use static DNS servers” or simlar option checked …
Why anyone would actually want to run WINS on an internet connection though is beyond me, but in case they did, nss_wins may be of some benefit then too …
I replied to the above with:
They don’t. I’m attaching the debug output below, look at what happens though (And some of this is speculation), initially we send a confreq, the modem (not vodacom, because the ppp only runs to the modem) then responds with auth chap MD5 and a magic, which we then rejet – indicating that I haven’t supplied credentials to pppd. Eventually the device actually connects with the GSM network, issues a DiscReq to us so that we can re-establish parameters (because it now got the info from GSM, I suspect), now, when we send the ConfReq for IPCP we send a request for addr, as well as ms-dns1 and 2 – which is all we really want. It then responds with with no addr and both dns and wins (which afaik it _SHOULD_NOT_ respond with as we haven’t requested it). This hops a couple of times, but notice that with the patched pppd it now sends the wins back indicating that we’re willing to accept it. I think I’m going to mod the patch to only do this with a parameter option of acceptwins in order to attempt getting it into mainline if other people find that this works for them too. Now last night the number of hops was fewer, but the result was the same, eventually it sends a ConfReq with no parameters, at which point we ConfNak it due to missing addr info, after which it rejects the WINS servers (in other words – NO WINS INFO IN THE END), we then send another confreq that’s near identical to the original, except we now have 10.11.12.13 and 10.11.12.14 as the initial dns servers as supplied earlier, this now gets Nak’ed and the correct data is _finally_ provided, and our responding Req is Ack’ed and we’ve got lift-off.
I hope this confusing explanation expresses somewhat accurately what I understand of the problem.
You’ll notice that the peer IP is still bogus – this does not matter at all. That IP is not used ANYWHERE except for two routes
1. A route to the pppd peer ip (unused except if you want to ping the pppd peer or something).
2. The default route added by pppd if you have the defaultroute option set, and even then it really doesn’t matter and I don’t know why pppd adds a “via” rule instead of a “dev” rule from the start anyway.
Regards,
Jaco Kroon
Connect: ppp2 <–> /dev/ttyUSB0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf250f1b5> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x3 <asyncmap 0x0> <auth chap MD5> <magic 0x455367cd> <pcomp> <accomp>]
No auth is possible
sent [LCP ConfRej id=0x3 <auth chap MD5>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xf250f1b5> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x455367cd> <pcomp> <accomp>]
sent [LCP ConfAck id=0x4 <asyncmap 0x0> <magic 0x455367cd> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0xf250f1b5]
sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
rcvd [LCP DiscReq id=0x5 magic=0x455367cd]
rcvd [LCP EchoRep id=0x0 magic=0x455367cd f2 50 f1 b5]
rcvd [IPCP ConfNak id=0x1 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x2 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x3 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfNak id=0x3 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x4 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
rcvd [IPCP ConfReq id=0x0]
sent [IPCP ConfNak id=0x0 <addr 0.0.0.0>]
rcvd [IPCP ConfRej id=0x4 <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>]
sent [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>]
rcvd [IPCP ConfNak id=0x5 <addr 196.46.172.91> <ms-dns1 196.207.36.251> <ms-dns3 196.207.36.254>]
sent [IPCP ConfReq id=0x6 <addr 196.46.172.91> <ms-dns1 196.207.36.251> <ms-dns3 196.207.36.254>]
rcvd [IPCP ConfAck id=0x6 <addr 196.46.172.91> <ms-dns1 196.207.36.251> <ms-dns3 196.207.36.254>]
rcvd [IPCP ConfReq id=0x1]
sent [IPCP ConfAck id=0x1]
Could not determine remote IP address: defaulting to 10.64.64.66
local IP address 196.46.172.91
remote IP address 10.64.64.66
primary DNS address 196.207.36.251
secondary DNS address 196.207.36.254
Script /etc/ppp/ip-up started (pid 12581)
Script /etc/ppp/ip-up finished (pid 12581), status = 0x0
You mentioned.
>>The bottom line is this: The firmware on the Huawei E220
>> (and by implication the E270 and probably others too) is broken.
My understanding is that the modem is not involved in the ppp negotiation, it just converts the data from usb/serial/bluetooth to GSM.
The only commands the modem uses is the AT commands to setup the device in the chat script.
The ppp session terminates on some NAS equipment at the provider (similar with dsl).
That is why you would see the same behavior using any usb modem and even with my bluetooth connected Samsung 3G phone.
I still think more of us should log calls with our 3G providers to fix there ppp software. (While we work around them with a patch)
I got the standard reply of ‘Linux is not a supported platform”
Hi,
This is contradictory to what I’ve been told on the GLUG-tech mailing list by someone that worked on firmware for a similar device. I’m unfortunately unable to locate the email at the moment. My understanding was similar to yours. I’m not sure how widespread the problem is, but it does seem to be specific to the Huawei modems.
Even the above eventually broke, so I just added something to restart pppd in ip-up, the box is unfortunately off at the moment, but IIRC it looks something like this:
if [[ $DNS1 = “10.11.12.13” ]]; then
kill -HUP $PPPD_PID
exit 0
fi
Not sure whether $PPPD_PID is standard, but it exists on Gentoo, and I’ll abuse it for as long as is required. This so far is the only 100 % surefire way I’ve found of dealing effectively with the problem – whatever may be the trigger of that.
Please see my other posts regarding Vodacom to understand why I’ve simply stopped caring and is now in a place of calm where my DSL at home should be installed at home in the next few hours, and I’ll be updating my ip-up on my laptop to deal with the sack options by disabling it whenever the 3G link comes up, and re-enabling it whenever it goes down again.
For my servers out in the field, all of them that makes use of 3G for failover are still struggling with the sack problem. Fortunately this isn’t overly serious as it’s mostly web browsing (which goes into transparent proxies that hides the problem) and mail (which gets retried in a few minutes, also hiding the problem).
I stopped getting the “Linux is not a supported platform” when I started threatening with legal action against what they’re doing to my TCP streams. Now they’ve shown that it’s a CISCO router making the changes, and in spite of me proving that what they’re doing is illogical and pointless they insist on still doing it, and looking to fix their code. Anyway, I don’t want to go all red faced again, so I’ll stop right here.