Posted on 31 Comments on Damn you, unworking r8168

Damn you, unworking r8168

I really don’t know why ethernet device makers insist on making it hard for to use their products.  Ethernet has been around for many, many years; surely its not too much to ask for drivers that “just work”.

And so that’s the problem I currently have with my new computer. It has an onboard Ethernet interface which uses a Realtek chip and that’s where the problems have been (with the exception of a power button that wriggled free, but that is also easy to fix).

The device comes up as:

03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)


I’ve used:


    

  • The R8169 driver that comes with most of the Debian kernels
    • 

  • r8168-dkms driver
    • 

  • The 8168 driver from the realtek site
    • 



and all of them don’t work.  It seems that the receive side works fine (I sometimes get a valid IPv6 address) but no packets are sent, even ifconfig eth0 shows zero transmitted packets.


ethtool shows some of the setup, this is with the r8168 driver:


driver: r8168
version: 8.037.00-NAPI
firmware-version:
bus-info: 0000:03:00.0
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: yes
supports-priv-flags: no


 


Interestingly, if I use the r8169 driver in the kernel and try ifup etho then I do get an entry in the firmware-version spot.


dmesg also shows that it finds the device.


[    0.916487] r8168 Gigabit Ethernet driver 8.037.00-NAPI loaded
[    0.916667] r8168 0000:03:00.0: irq 72 for MSI/MSI-X
[    0.939129] r8168: This product is covered by one or more of the following patents: US6,570,884, US6,115,776, and US6,327,625.
[    0.939136] r8168  Copyright (C) 2013  Realtek NIC software team <[email protected]>
[   10.807066] r8168: eth0: link up


So it all looks good, except it won’t send any packets.  Anyone got one of these devices and if so (and more importantly) how did you get it to work?


 

















Posted on  6 Comments on Goodbye mygbiz



Goodbye mygbiz






Google seems to try to invent new and interesting ways for spammers to spam me (and many others).  I’ve still not worked out a good way to block “fake googlegroups” which follow this method:


    

  1. Make new fake gmail login
    2. 

  2. Make new fake google group
    3. 

  3. Add lots of people’s email addresses to the group
    4. 

  4. Send lots of junk to these people
    5. 

  5. Repeat when it gets closed down
    6. 



I’m not sure why  groups aren’t opt-in. A rather simple and standard way to stop this exact problem.


Anyhow, the next new spammer enablement that the nice folks at Google have come up with is the mygbiz.com domain. These are temporary email addresses you can use when setting up Google apps. The only thing I have ever seen from them is spam. So I thought I’d try to report some to Google.  After looping around several help screens that were, despite their name, very unhelpful, I’ve come to the conclusion that Google isn’t too serious about fixing this problem.


If you have postfix, the solution is very simple:


    

  1. vi /etc/postfix/access_sender
    2. 

  2. Add a line like “mygbiz.com  REJECT”
    3. 

  3. postmap /etc/postfix/access_sender
    4. 

  4. postfix reload
    5. 



I find the results to this method far superior to trying to get Google interested in being responsible for a domain they run. If you want to use google apps then spend the $50 and get a domain. Alternatively don’t use something that spammers abuse.


Does it work? You bet it does!


Sep 18 23:26:38 elmo postfix/smtpd[19013]: NOQUEUE: reject: RCPT from mail-ye0-f208.google.com[209.85.213.208]: 554 5.7.1 <[email protected]>: Sender address rejected: Do not send from mygbiz.com domains; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<mail-ye0-f208.google.com>


















Posted on  2 Comments on jqGrid in TurboGears2 Admin Screens



jqGrid in TurboGears2 Admin Screens






I wanted to use the jqGrid for my admin pages as I liked that look and it matches some of the other screens outside the admin controller.  The admin controller, or rather the CrudRestController out of tgext.crud, has a way of exporting results in json format. So surely its a matter of changing the TableBase to use jqGrid in the admin controller and we’re done?


Well, no.


First you need to adjust the jsonReader options so that it lines up to the field names that the controller sends and this was one of the first (or last snags). The json output looks like:


{
  "value_list": {
    "total": 20,
    "items_per_page": 7,
    "page": 1,
    "entries": [(lots of entries)...]
  }
}


Now this is a little odd because of the top-level dictionary that is being used here. Most of the examples have everything that is inside the value_list being returned. In fact adjusting the controller to return only those items in the value_list values works.


To look inside this structure we need to adjust the jsonReader options. jqGrid documentation uses the format “toptier>subtier” for the XML reader so that was the intial attempt. It was also an intial fail, it doesn’t work and you get your very familiar empty grid.


The trick is close to this format, but slightly different for json. You change the options to “toptier.subtier”. In other words change the greater than symbol to a full stop for json access.


The jqGridWidget now has the following options (amongst others):


options = {
  'datatype': 'json',
  'jsonReader': {
    'repeatitems': False,
    'root': 'value_list.entries',
    'total': 'value_list.total',
    'page': 'value_list.page',
  }
}


There might be a way of saying all entries sit under value_list inside jqGrid, but I couldn’t find it. Those options given above do give a working jqGrid on the admin screens.
















Posted on  7 Comments on Odd WordPress pingbacks



Odd WordPress pingbacks






I’m getting some odd log messages for the apache module modsecurity.  Essentially its xml parser is breaking when random places are sending pingbacks. The requests go to xmlrpc.php and the response headers are ok, but the body is binary.  The message in the modsecurity log looks like:


Message: XML parser error: XML: Failed parsing document.


After a bit of guessing and sending messages to and fro, I can now see that it is a gziped response. So I’m not sure if it is modsecurity not realising that the response is gziped or wordpress not marking it correctly. In any case I can regularly get very similar binary strings using gzip and the usual xml response. So that’s half the mystery solved.


Most of the requests are spammers so I’m not too worried.  I think it also impacts legitimate pingbacks because I’ve not had any, even from the usual automatic places.