Watchguard Firebox M440

pglover19

Getting a different checksum.. Here are the results..

pglover19

To download, I right click on the file and select "Save Target As" to my Windows 10 machine. I rename the file and then use WINSCP to move the file to pfSense.

pglover19

I downloaded the sha256sum program for Windows and I'm getting the same checksum on my Windows machine.. Hmm.

E:\Watchguard M440>sha256sum.exe if_igb.ko
d309d1b253ddf4a4444ab2c4fa16c71b2c880e7439f236a35395444edeb0db28 *if_igb.ko

pglover19

Ok.. Here is what is going on..

I used WINSCP to upload the file to pfSense. I ran the sha256 command on the file in pfSense and I get checksum "d309d1b253ddf4a4444ab2c4fa16c71b2c880e7439f236a35395444edeb0db28" which is what you get.

I reboot pfSense and for some reason the checksum of the file changes. I ran the sha256 command on the file in pfSense after the reboot and I get checksum "09baa21ec3e7f90e397be6fec895a80f9e5c2b70641eae57c61318ae173b1edc".

What is going on? Maybe the permissions on the file is incorrect..

pglover19

Couple things that may be wrong.

Should we have a uppercase "YES" in the following line in the config file.
if_igb_load="YES"
The file permission on the .ko file (chmod 644) may not be correct. I noticed that another .ko in the same directory has different permissions (execute permission - chmod 555) .

pglover19

Finally go it working.. I did the 2 things in the previous post.

Here are the results...

0_1539600366081_igb Results.txt

stephenw10

Hmm, well that's.... weird.

I didn't set any special permissions on the file, it loaded and ran fine anyway:

[2.4.5-DEVELOPMENT][root@8860.stevew.lan]/boot/modules: sha256 if_igb.ko 
SHA256 (if_igb.ko) = d309d1b253ddf4a4444ab2c4fa16c71b2c880e7439f236a35395444edeb0db28
[2.4.5-DEVELOPMENT][root@8860.stevew.lan]/boot/modules: ls -la 
total 660
drwxr-xr-x  2 root  wheel     512 Oct 14 22:25 .
drwxr-xr-x  9 root  wheel    1536 Oct 15 11:09 ..
-r-xr-xr-x  1 root  wheel  105504 Sep  5 00:35 bwi_v3_ucode.ko
-rw-r--r--  1 root  wheel  496128 Oct 14 22:25 if_igb.ko
-rw-r--r--  1 root  wheel      88 Oct  7 14:12 linker.hints

That's after rebooting, the file is unchanged here.

I renamed the file after I uploaded it to that box. Shouldn't make any difference though.

Steve

pglover19

Is that the results you were looking for? Please advise. Should I now delete the .ko file?

stephenw10

Ah, OK that is working but that txt file just shows the stuff it throws out every second.

We need the log showing it booting and the driver trying and failing to attach.

pglover19

It seems to be stuck on throwing the stuff on the console and does not enter the boot cycle.. I will try again.

stephenw10

One option here is to reboot from the GUI and then copy out the system log as soon as it boots up.

At Diag > Command prompt run:
clog /var/log/system.log > /tmp/systemlog.txt

Then you can download and look through that txt file.

Steve

pglover19

I got it... Attached is the boot log...

0_1539604066476_BootFile_2.txt

pglover19

Please let me know if the log file is what you need. I will be leaving for work in the next 15 minutes; however, I want to make sure you have the correct log file. Let me now...

stephenw10

It should be in that file, yes. Looking through it.....

pglover19

Ok.. Let me know.. I can stick around for 10 minutes to make sure you got what you need.. I will be available after work (6:00PM EST) to continue working on this issue. Please continue to post throughout the day tasks you want me to execute and I will do that after 6:00PM EST. Thanks

stephenw10

Yeah we have the error. Basically these lines:

e1000_read_phy_reg_mdic
MDI Error
PHY Initialization Error
igb1: Setup of Shared code failed
device_attach: igb1 attach returned 6

Now how to prevent that.....

pglover19

Great.. let me know the next steps..what is your assessment so far? You think we can get all the ports working with pfSense?

stephenw10

Well we have a much better understanding of the issues at this point.

The driver is failing because it can't initialise the PHY. Not surprising because it has no PHY. But WGOS doesn't appear to use a special driver so it could be the switch is not presenting to the NIC as expected at this point.

We know the switch will require some configuration to be usable in pfSense in any way. Right now the best bet for that looks to be via the debug port so at some point that will need investigating. The switch is still somewhat a mystery as there's no datasheet for that part number (I can find).

Steve

pglover19

So what can I do to help?

stephenw10

Is it possible for you to setup a connection for me to access the device? Via SSH?
Probably best via PM if so.

Otherwise I'd look at connecting to the switch debug port. Can you get hold of a serial cable of some sort? A multi-meter will probably do to check the connection type.

Steve