Main menu

Post navigation

There’s plenty of documentation on Internet related to this issue but none of them works with recents firmware. They all talk about using the embedded web interface and force serial mode through some call and then send an AT command to choose default mode.
It’s not working ANYMORE on 22.470.07.00.00 firmware.

In the [QcomSerialPort.NTamd64], add the two following lines
%QcomDevice00% = QportInstall01, USB\VID_12d1&PID_1442&MI_00
%QcomDevice01% = QportInstall00, USB\VID_12d1&PID_1442&MI_01

Now go back to device manager and update driver by choosing the path containing the inf file

If you get this error, you need to disable driver signature verification first (google for it).
BE SURE TO RESTART FIRMWARE UPDATER BEFORE TRYING TO FIX THE DRIVERS AGAIN OTHERWISE IT WONT BE TURNED INTO SERIAL MODE.

After a successful installation you should now see two additional COM ports

Start the firmware updater and wait a bit

On my Windows 8.1 computer it gets stuck here and fails with an error but it worked correctly on Windows 7…

Here is what you should see if it’s working correctly

Finally, the success message saying you firmware has been downgraded to 21.xx

Now we have access to the serial port and we’ll have to issue a few AT command to set a new default mode. Find the COM port used by your modem now

And start Putty on it

Now we can send a few command (press Enter key at the end)
AT: Will reply "OK", it means your actually talking to someone understanding AT commands
AT^FHVER: Confirm you are running firmware 21.xx
AT^SETPORT?: Show current modem default config
AT^SETPORT=?: Display available modes
AT^SETPORT="FF;10,12": Enable diag interface and classic serial based modem emulation (this is what we need to use with wvdial)
AT^RESET: Restart the modem

Screenshot below are a bit wrong: I used AT^SETPORT=”FF;12,10″ instead of AT^SETPORT=”FF;10,12″ so the modem is on ttyUSB1 instead of ttyUSB0 !

Here you can see my AT session (please note that AT^SETPORT? won’t refresh until the modem is restarted)

After issuing AT^RESET the COM id will change (probably increased by 1), you can restart Putty and check default mode is now the one expected.

Spot the issue

Here is how to confirm your issue is related to this bug and not something else. Boot the server and press CTRL+E to get into the iDrac BIOS. Select the network submenu and check the Active LOM entry. LOM stands for LAN On Motherboard.

If it says No Active LOM even if you selected Shared above, it means the iDrac is unable to bind on any on-board LAN, this means you are having this issue.

Then, we’ll create a DOS-based floppy disk image containing some Broadcom firmware related tools that will reconfigure the embedded network controller so it can be use for the iDrac board.

The purpose of this article is to explain how to create an hight availability email server with Dovecot.
We will use internal plain text files as users backend but it can of course easily be extended to use LDAP or SQL, but this article won’t cover this setup.

Install required packages

On both servers we’ll install dovecot as well as the POP3 and IMAP backends

1

apt-get install dovecot-core dovecot-imapd dovecot-pop3d

To use dovecot clustering feature, known as dsync, we need dovecot 2.2 or later. Debian Jessie’s version is ok.

Setup file-based users database

Edit /etc/dovecot/conf.d/auth-passwdfile.conf.ext and set both userdb and passworddb like this:

1

2

3

4

5

6

7

8

9

10

passdb{

driver=passwd-file

args=scheme=PLAIN username_format=%u/etc/dovecot/users

}

userdb{

driver=passwd-file

args=username_format=%u/etc/dovecot/users

default_fields=uid=vmail gid=mail home=/srv/vmail/%u

}

I will use plaintext clear password here because I really want to be able to read the users from the configuration file directly. You can of course use an encrypted format, see Dovecot documentation.

The file /etc/dovecot/users will contains the users accounts and we’ll deliver all emails using paths like /srv/vmail/user@domain.com.
Dovecot is set up to always use the vmail user with mail group to avoid uid/gids madness.

First I tried to create a multi-domain setup, using “username_format=%n /etc/dovecot/%d/users” and “default_fields = uid=vmail gid=mail home=/srv/vmail/%d/%n” but current master/master plugin is unable to handle such configuration (Error: passwd-file: User iteration isn’t currently supported with %variable paths) so I decided to use a single authentication file using email as login (%u instead of %n).

We need to create the system user for dovecot:

1

adduser--system--ingroup mail--uid500vmail--home/srv/vmail

Now we need to enable this backend by commenting auth-system and un-commenting auth-passwdfile from /etc/dovecot/conf.d/10-auth.conf

Not much to say here because everything is already explained in the GitHub README file.

In a few words, I wrote a script that extracts from Active Directory LDAP all Exchange email addresses and export this as a Postfix map. The idea is to be able to reject invalid recipients instead of whitelisting the whole domain. By doing this, your infrastructure will stop sending “non-delivery notifications” back to forged sender addresses because you let some invalid recipient emails go into your system.

And it was happening for a long time. It wasn’t a big deal because the request is denied anyway until I had to do some serious modification on this server and discovered that syslog was nearly unusable, thanks to this amazing flood:

1

2

root@ns1.domaim.com:~# wc -l /var/log/syslog

84960/var/log/syslog

It seems to be impossible to have fine-grained logging with bind9, so I decided to try something else: let’s use shorewall (iptables frontend) to drop all pattern matching “x99moyu.net” (all requests are against this specific domain).

Won’t work. In fact, the DNS request in constructed a different way:
http://stackoverflow.com/questions/14096966/can-iptables-allow-dns-queries-only-for-a-certain-domain-name?answertab=votes#tab-top

If you look at the contents of the DNS request packet in wireshark or similar you will find that the dot character is not used. Each part of the domain name is a counted string, so the actual bytes of the request for google.com will be:

06 67 6f 6f 67 6c 65 03 63 6f 6d
The first byte (06) is the length of google, followed by the 6 ASCII characters, then a count byte (03) for the length of com followed by… you get the idea.

Yep, I got it. We’ll also need to do a “hex” match instead of a simple string:

We had some issues today, at work, with a PHP-based CMS (hello |*@#-?! joomla) being used as a spam gateway.

The root cause (Joomla)

I fixed the issue by figuring out what was the broken PHP file using findbot.pl tool from abuseat.org. But my main concerns is that there’s no way to prevent this to happen again. PHP is broken by design, especially while being used for a CMS.

In the meanwhile, Joomla has been updated an hopefully the security issue has been fixed.
After removing the bad file, the owner of my turned-into-a-spambox-cms looks being annoyed and seemed to try break-in again:

No thanks, really. It’s been a pleasure but it’s time for me to move on:

1

2

root@some.server.com:~# shorewall drop 195.206.253.146

195.206.253.146Dropped

Preventing this from happening again ?

So how could you care about this ? First thing, be sure to not mess your main SMTP IP address with it. Be sure to relay the CMS emails throught a specific dedicated SMTP server that’s not hidden being the same NAT as your main SMTP server. Otherwise, you will get blacklisted as soon as any flows open in Joomla.

To ensure you’re fine, you can use one the multi-rbl checks online like anti-abuse.org or senderbase.org by Cisco. If you’re not listed here, you’re probably fine. Otherwise it’s time to ask for removal on any blacklist and be patient. Your SMTP server won’t be trusted again until at least a couple of hours, probably couple of days to be un-blacklisted on the whole Internet.

Of course, you may consider upgrading Joomla, changing password and avoid having thousands of useless plugins, but I guess you’re not in charge of this Joomla website, right ?

Another thing that may help is to enable some PHP hardening tool called “suhosin“. It wasn’t ready while Debian Jessie has been released, so we’ll use the official upstream repository to get it.

So now, you’re using a different SMTP to relay emails coming from the insecure website… To avoid spaming the world and/or overloading the internet connection, we’ll setup rate-limiting on the postfix server.

We’ll use postfwd for this.

1

apt-get install postfwd

If using Debian Wheezy, make sure to get the one from backports, the default one is completly broken.

Then, we set-up a rule limiting enforcing each client_address (IP connecting this SMTP server) to not send more than 5 emails every 5 minutes.

Then, edit your postfix configuration in /etc/postfix/main.cf to add a new smtpd_recipient_restrictions setting like this:

1

2

3

4

5

smtpd_recipient_restrictions=

check_policy_service inet:127.0.0.1:10040,

permit_mynetworks,

reject_unauth_destination,

permit

The check_policy_service will check postfwd running on port 10040 which will return either permit or deny. Postfwd will reply with a 450 temporary error if the rate has been exceeded.

Beware of the order, in this example, even hosts being allowed to relay emails with this SMTP server, listed in $mynetworks, have been rate-limited.
The reason is that this SMTP server is outside main corporate network and I don’t trust any of the hosts using it.

Here’s another snippet from a production server:

1

2

3

4

5

6

7

8

smtpd_recipient_restrictions=

permit_mynetworks,

permit_sasl_authenticated,

reject_non_fqdn_recipient,

reject_unknown_recipient_domain,

reject_unauth_destination,

check_policy_service inet:127.0.0.1:10040,

permit

If you don’t have this setting yet, you can get the default value on your system by running

1

postconf smtpd_recipient_restrictions

I suggest to always add “permit” as the last action, even if it’s implicit it’s way more easy to understand the workflow by adding it.

Today I got really pissed of to see than mw Debian testing machine was still unable to resume correctly from suspend out of the box…
So I decided to upgrade to kernel 4.0 and update motherboard BIOS to the latest release: no luck.

While looking at Google about that issue I finally found out some information… right here, on my own blog. That was quite disappointing.

I figured out I still had all these error message, just like 3 years ago:

So what happened with that patch fixing the issue in 2012 ? Does it got rejected ? Lost somewhere in some random git space ?
I checked the official git master branch and the fix was applied. The idea was good again, no luck.

Finally, I figured out the issue was triggered by some (new?) ACPI/SATA related stuff that were probably not existing in 2012.

The proper fix is simply to boot your kernel with libata.noacpi=1 and resume works again, YAY \o/

To make it permanent on Debian, edit /etc/default/grub and set the following line:

The register_globals and register_long_arrays php.ini directives have been removed.

Call-time pass by reference has been removed.

That shouldn’t be a big deal unless you’re running some very old code you are not intending to fix. And I did.

After trying to fix the code by adding the required _POST and _GET everywhere, I ended up with half pages still not working. Despites fixing post and get, there were also variables from _SERVER and _COOKIE used everywhere and it’s a lot harder to spot them.

My co-worker said: “Better rewrite everything, it would be faster” and I think he was right.

This is my first post about fixing things in real life so I’d appologise for all english mistakes I’m going to make. I don’t feel really confortable with DIY words in my non-native language 😉

Anyway, my sister texted me “my macbook won’t power up anymore”. It’s an old Macbook 13″ she bought a couple of years ago so I said her “that’s probably the motherboard or some electronic stuff broken, bring it if you want but I won’t be able to do anything than saving your data by removing the internal hard drive…

But I’ve been able to do something, here is how.

Symptoms

The Mac won’t power up. When the power cord is plugged the LED is lit but it’s very low. You can hardly guess it’s up. The battery is discharged (one LED blinking when pushing the battery state button).

Sometime, when pressing the power connector, the LED comes up for one sec.

Cause

This “MagSafe” power adapter uses a specific connector with a magnet inside. The plug pins can go back inside the connector to adjust their own size (using a spring?).

After several years of plug in and plug out, the plug pins won’t go out enough anymore, and thus can’t touch their receiver on the Mac.

Fix it!

There’s nothing we can do for the pins to go out more, it’s probably springs which are tired… But we can use an engineering file to reduce the size of the rest of the connector, so it could go deeper inside the mac.

Well that’s pretty hard to explain, but with a picture, you should get it:

Beware to use the file on the edge only! If you do it on the complete connector, you’ll reduce the pins size as well and it’ll be useless!

You’ll probably need a vice, or a lots of patience. I suggest putting the connector wrapped in something to protect it in the vice.